Bug 208391 - misc/mc SUBSHELL not working with /bin/sh
Summary: misc/mc SUBSHELL not working with /bin/sh
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Alexey Dokuchaev
URL: https://www.midnight-commander.org/ti...
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-30 04:15 UTC by gja822
Modified: 2021-05-27 08:51 UTC (History)
4 users (show)

See Also:


Attachments
Add pkg-message explaining the issue (1.72 KB, patch)
2020-10-06 13:55 UTC, Mateusz Piotrowski
0mp: maintainer-approval?
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description gja822 2016-03-30 04:15:18 UTC
SUBSHELL option (and usability) do not work for my ordinary users with /bin/sh login shell, either option chosen or not during port build process. This behaviour was noted for ages. And I even used to it. For my root (with csh login shel) SUBSHELL worked fine (and I use it).
But from previous (or last) upgrade, misc/mc if built with chosen SUBSHELL option do not even start for users with /bin/sh as default login shells.
Error is:

common.c: unimplemented subshell type 1
read (subshell_pty...): No error: 0 (0)
Comment 1 Ben Woods freebsd_committer freebsd_triage 2016-06-26 11:56:37 UTC
I have reported this problem to the upstream mc project team here:
https://www.midnight-commander.org/ticket/3658
Comment 2 Patrick McMunn 2020-09-02 20:25:07 UTC
This is a longstanding bug. I would suggest that the subshell build option be disabled by default or that, at the very least, an informational message be emitted that a user either needs to use the -u option to start or that the user's default shell should be changed, if a different shell will cause it to work.
Comment 3 Mateusz Piotrowski freebsd_committer freebsd_triage 2020-10-06 13:42:41 UTC
It looks like the ticket is still pending: https://midnight-commander.org/ticket/373

Interestingly, Debian ash and BusyBox ash are now supported: https://github.com/MidnightCommander/mc/commit/f596c916a42a0868897b3314e557b0a82df37017
Comment 4 Mateusz Piotrowski freebsd_committer freebsd_triage 2020-10-06 13:55:14 UTC
Created attachment 218560 [details]
Add pkg-message explaining the issue

Would you mind if I commit the attached pkg-message to explain the problem to our users?
Comment 5 Ben Woods freebsd_committer freebsd_triage 2021-05-22 02:25:32 UTC
Sorry, due to a lack of time I have reset the maintainer of this port back to ports@FreeBSD.org. Hopefully someone else is able to step in to help.
Resetting the assignee of this bug accordingly.
Comment 6 Alexey Dokuchaev freebsd_committer freebsd_triage 2021-05-24 03:12:24 UTC
(In reply to Patrick McMunn from comment #2)
> This is a longstanding bug.
Well, it depends on one's definition of a bug. :-)  Technically, ``env SHELL=/bin/sh mc'' tells users up-front that this combination is unsupported and refuses to work.  It could probably emit less cryptic diagnostics, but that's about it.  It's simply not possible to support /bin/sh as a subshell in a way mc(1) deals with shells.

When it launches a subshell, mc(1) installs so called "precmd" hook (executed before each prompt) so the shell can report its current working directory back to mc(1).  Some shells are advanced enough and provide this feature out of the box, e.g. for bash(1):

> echo $PROMPT_COMMAND
> pwd>&7;kill -STOP $$
For tcsh(1):

> alias
> ...
> precmd  echo $cwd:q >>/tmp/mc-danfe/mc.pipe.78491; kill -STOP $$
Other supported shells like dash(1) are not so advanced, but they support command expansion in the PS1, so this behavior can be emulated.  Alas, our /bin/sh supports none of these.

> I would suggest that the subshell build option be disabled by default
We should not cripple package defaults just for the sake of ~1% of users who are confined to /bin/sh as their interactive shell.

> or that, at the very least, an informational message be emitted that a user
> either needs to use the -u option to start or that the user's default shell
> should be changed
Yes, that's what we should do.  I'll take Mateusz's text but rework it, as it's a bit too wordy while lacking technical details about this issue.
Comment 7 Mateusz Piotrowski freebsd_committer freebsd_triage 2021-05-24 09:29:54 UTC
(In reply to Alexey Dokuchaev from comment #6)
Thanks for working on that!
Comment 8 commit-hook freebsd_committer freebsd_triage 2021-05-27 08:46:02 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=b20b92686b504c322dd809c3107acb4edda0eb08

commit b20b92686b504c322dd809c3107acb4edda0eb08
Author:     Alexey Dokuchaev <danfe@FreeBSD.org>
AuthorDate: 2021-05-27 08:42:00 +0000
Commit:     Alexey Dokuchaev <danfe@FreeBSD.org>
CommitDate: 2021-05-27 08:42:43 +0000

    misc/mc: the port had been improved (+)

    - GC outdated CONFLICTS (misc/mc-light had been removed on 2019-10-16)
    - Add missing SCREEN_DESC (screen library) option description
    - Offer new option, EXTATTR (ext2fs extended attributes support) and
      ensure, in somewhat ugly way, that dependency on `sysutils/e2fsprogs'
      won't be silently picked up if this option is disabled
    - Tell users that /bin/sh, our base system sh(1), is not supported as
      concurrent subshell because it does not allow "precmd" hooks [1]
    - Fix entering RAR archives after `archivers/unrar` had been updated
      to version 6.x [2]
    - Use helper target and simplify installation of documentation files

    PR:     208391 [1], 251404 [2]

 misc/mc/Makefile                   | 36 +++++++++++++++++++-----------------
 misc/mc/files/pkg-message.in (new) | 17 +++++++++++++++++
 2 files changed, 36 insertions(+), 17 deletions(-)