mc: subshell not working with /bin/sh

[sierkb@…]

After upgrading from macOS 10.11 to 10.12 and reinstalling MacPorts with all the ports, I run into the following problem:

When trying a

$ sudo mc
Password:

on macOS 10.12.0 (Sierra), mc throws a

common.c: unimplemented subshell type 1
read (subshell_pty...): No such file or directory (2)

Searching for this error, I've stumbled over similar problems/bugs relating mc on FreeBSD:

• mc: ​Ticket #3658 (new defect) - Subshell not working with Bourne shell /bin/sh (not bash)
• FreeBSD: ​Bug 208391 - misc/mc SUBSHELL not working with /bin/sh

I've never had this problem before on macOS 10.11.x and older, and I guess, something might have changed on 10.12 relating /bin/sh resp. the shell environment. Please fix here on MacPorts with a patch or upstream, so that mc is usable again with subshell on macOS 10.12.x (Sierra).

[mkae (Marko Käning)]

Tested this on "Sierra 10.12.1 Beta" just now and can't reproduce the error.

Tell me, have you entered

/opt/local/bin/bash -l

in Terminal.app's "Preferences/Profiles/Startup/Run command" and check-marked it?

[sierkb@…]

Replying to mk@…:

Tested this on "Sierra 10.12.1 Beta" just now and can't reproduce the error.

OK... 10.12.1 Beta. And 10.12.0? Maybe a bug in macOS 10.12.0 and fixed in 10.12.1 Beta?

Tell me, have you entered

/opt/local/bin/bash -l

in Terminal.app's "Preferences/Profiles/Startup/Run command" and check-marked it?

No. I have it this way since years without problems:

Added /opt/local/bin/bash to the end of /etc/shells with

sudo bash -c 'echo /opt/local/bin/bash >> /etc/shells'

Change the user login default shell to /opt/local/bin/bash with

chsh -s /opt/local/bin/bash

Verify this change in System Preferences > Users & Groups > Current User > Advanced Options (per right-click) > Login Shell > /opt/local/bin/bash

[mkae (Marko Käning)]

Well, I can't test on 10.12.0, unfortunately... Not sure what to do about this for now.

Re bash: OK, I see, you've globally set that for your user account.

[mkae (Marko Käning)]

Perhaps you can contact upstream, sierkb, and report back if there is something new happening.

Alternatively I could try adapt the patch for MacPorts and attach it to this ticket so that you can test it locally on your system. Once your Sierra gets an update you can check again with the unpatched version of mc in order to verify what I am seeing here on my Beta.

[sierkb (Sierk Bornemann)]

Replying to mkae:

Perhaps you can contact upstream, sierkb, and report back if there is something new happening.

Done. See ​mc ticket 3658: Subshell not working with Bourne shell /bin/sh (not bash), comment 5 and first reaction in ​comment 6.

Alternatively I could try adapt the patch for MacPorts and attach it to this ticket so that you can test it locally on your system.

OK. Yes, please.

Once your Sierra gets an update

Apple has released 10.12.1 update yesterday, I've installed it:

$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.12.1
BuildVersion:	16B2555

you can check again with the unpatched version of mc in order to verify what I am seeing here on my Beta.

OK… Result:

$ sudo mc
common.c: unimplemented subshell type 1
read (subshell_pty...): No such file or directory (2)

Same error as before. I have no clue, why your 10.12.1 beta seems to work at that point, but not the stable 10.12.1 release on my installation. And no clue, why I've had no problem at the very same point with 10.11.x and lower but since 10.12.x. What has changed in 10.12.x concerning shell/subshell that effects this?

[mkae (Marko Käning)]

I have something consoling for you:

$ sudo mc
Password:
common.c: unimplemented subshell type 1
read (subshell_pty...): Undefined error: 0 (0)

as observed on my Sierra release 10.12.1.

You know what, I think I all along missed the sudo in front of my mc call... ;-/

---

I'll look into this (patch) and let you know. I hope it's not a pressing matter for you, as I won't be able to do this immediately. Stay tuned and patient please. :)

[mkae (Marko Käning)]

So, I've built and ran a patched mc on Sierra (and for reference also on Mavericks) w/o seeing the above issue anymore.

Done in r154272! (Let's hope that the buildbots will be fine with it!)

Yet, I don't know what to make of the ​patch source's comment:6... Well, it's solved for MacPorts now. If they don't want to commit this patch they'll surely figure out another solution.

[sierkb (Sierk Bornemann)]

Replying to mkae:

So, I've built and ran a patched mc on Sierra (and for reference also on Mavericks) w/o seeing the above issue anymore.

Done in r154272! (Let's hope that the buildbots will be fine with it!)

OK. Thanks a lot. It works for me. But this tiny patch used by you has a disadvantage (delay of 5 or 10 seconds), as also mentioned in ​mc Ticket #3658 comment 1:

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.

I guess, there seems to be a better and more sophisticated upstream patch around (hint: this mc upstream comment ​mc doesn't recognize shell (e.g., /bin/sh) as bash when it is a link to bash binary, comment 11), which avoids such delays and other things:

​mc Ticket #3692 More sophisticated shell type detection method

Maybe prefer this more sophisticated mc ticket 3692 patch over the quick fix mc ticket 3658 patch used by you?

Yet, I don't know what to make of the ​patch source's comment:6...

See below.

Well, it's solved for MacPorts now.

See above.

If they don't want to commit this patch they'll surely figure out another solution.

Maybe they prefer this mentioned ​mc Ticket #3692 More sophisticated shell type detection method (which is targeted: Future Releases, that's why I asked them to ship it more early rather than in any so far unnamend future release)?

[mkae (Marko Käning)]

OK, will look into the alternative patch. This time, though, it will take much longer... I am sorry, but please test that yourself locally, if possible.