Subshell not working with Bourne shell /bin/sh (not bash)

[woodsb02]

The subshell is not working with the Bourne shell /bin/sh, specifically in my case on FreeBSD. Note this is different to BASH.

When mc has been compiled with subshell support, and started in the Bourne shell, it fails to start with the following error message

common.c: unimplemented subshell type 1
read (subshell_pty...): No error: 0 (0)

Note that this error message occurs when mc starts - not afterwards when trying to view the subshell with ctrl+o.

The FreeBSD bug for this is ​PR 208391

[woodsb02]

Attempt at patch to fix subshell with Bourne shell /bin/sh (not work)

[woodsb02]

The attached patch allows mc to start without error. However, there is a 5 second delay when it starts. When trying to use the subshell, it simply shows a blank terminal, at which point any key press returns you to the normal mc file layout screen.

[and]

Confirm on Solaris Bourne shell.

But subshell will never work on sh because precmd() comparable feature (for signaling current PWD back to mc) is missing.

[andrew_b]

Ticket #3689 has been marked as a duplicate of this ticket.

[sierkb]

Confirm on macOS 10.12.0 (Sierra).
See also ​MacPorts ticket ​#52511 – mc: subshell not working with /bin/sh incl. comments.

Please fix and release. And please target for next possible release or bug fix release instead for any undefined future release, so that patches relating this issue can take effect as soon as possible on the user's side.

[zaytsev]

Fix and release what? Do you know of a way to support Bourne shell? Otherwise, if you want to use Bourne shell, you have to start mc without subshell. I can't see what can be done here...

[willbproggin]

Replying to zaytsev:

Fix and release what? Do you know of a way to support Bourne shell? Otherwise, if you want to use Bourne shell, you have to start mc without subshell. I can't see what can be done here...

This affects me ​on FreeBSD as well. Can mc be fixed to just start internally without subshell support if it can't support a shell instead of failing ungracefully?

[andrew_b]

Closed as duplicate of #373.

[Snelius]

Fix path

[zaytsev]

Ticket #4531 has been marked as a duplicate of this ticket.

[zaytsev]

It seems to be very confusing for users that when mc is built with subshell, it is sometimes either silently disabled (for various reasons - mostly initialization problems, but could also be wrong configuration), or even, if mc detects SHELL_SH, it just dies with an error message printed to the console.

To make matters worse, mc can be built with three modes:

1. Subshell support is disabled at build time
2. Subshell support is enabled at build time, but disabled by default at runtime
3. Subshell support is enabled at build time and enabled by default at runtime

This just adds to the total confusion.

I researched the ENABLE_SUBSHELL guards and came to the following conclusions:

• It seems that no extra dependencies are pulled in when subshell support is enabled
• All relevant code is already wrapped with if (mc_global.tty.use_subshell)
• Binary size difference is negligible

I see no good reason for this configure option to exist in 2024.

My suggestion is to

1. Remove --enable-subshell completely and always build with subshell enabled by default
2. Add a warning message if subshell cannot be started at runtime

The warning will not appear if the -u parameter was passed (subshell was explicitly disabled).

The only problem I can foresee is that users who didn't want subshell and had it disabled at build time, or had it disabled by itself due to some error, will now see an error message.

I'm not sure how numerous this group will be and how aggressive they will be. I think setting the alias to mc -u is a fair option, but if there is a strong demand, we can add a config option to disable the subshell. I believe this is much more useful and convenient than the build time switch and confusing inconsistent behavior.