[Bug 208391] misc/mc SUBSHELL not working with /bin/sh

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208391

Alexey Dokuchaev <danfe@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|ports-bugs@FreeBSD.org      |danfe@FreeBSD.org
           Severity|Affects Only Me             |Affects Some People
             Status|Open                        |In Progress
                 CC|                            |danfe@FreeBSD.org

--- Comment #6 from Alexey Dokuchaev <danfe@FreeBSD.org> ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.