emacs user needed to help with PR bin/41954

[Robert Elz <kre%munnari.OZ.AU@localhost>]

Hi all,

One of the final remaining real (at least potential) sh related PRs
on my list to look at/fix is bin/41954  (from just about 9 years ago)

A summary:

	"sh -i" behaviour changed somewhere in between 5.0 
	release and today,
[August 2009]
	Emacs shell-mode doesn't function now.

Since there is no way anyone could pay me (any amount) to
ever install emacs, this one is kind of hard to test...

It is possible that in the intervening 9 years, this has been fixed by
accident, in which case the PR could just be closed (OBE).

So, if there is an emacs user out there running any relatively recent
/bin/sh (it does not need to be up to the minute, the version  shipped
with NetBSD-8, including its beta and RC pre-releases,  will do just fine
for this, nothing has changed in the intervening period that can possibly
be relevant that I can think of) could you please do a quick test and see
if emacs shell-mode works now ?

A workaround for the problem in the PR was ...

	(setq explicit-shell-file-name "/bin/sh")
	(setq explicit-sh-args '("+i"))

(to cause /bin/sh to run in non-interactive mode).   That's not at
all suitable as a solution/workaround, so while you can test if that works
(assuming the problem still exists) I'd appreciate it if (in addition,
or instead) you could check that nothing in your $ENV (or anywhere
else) turns on emacs mode (I'll just assume that if you're an emacs
user you are not turning on sh's (libedit's) vi editing mode ... but if you
are, temporarily turn that off too), and change the second line above
to
	(setq explicit-sh-args '("+VE"))

and let me know if that helps the situation (that one would almost be
a suitable workaround - though it would be better done in $ENV by
having it test if the shell came from emacs, and disabling line editing
that way if so ... but we would need to work out how to perform that
test in order to do that).

It seems likely that the issue is/was some kind of interaction between
libedit and emacs, and so disabling line editing, which +i does (but that
also makes lots of other changes - disabling prompts is just the tip of the
iceberg ... that is the part you see, but not the dangerous part) but which
explicitly disabling both emacs & vi modes also does, might avoid the problem.

If the problem still exists, and if disabling line editing does fix it, then we
will know where to start on finding the underlying issue, and can
investigate more.

Note that you should not need to compile/install anything to run this
test, just be an emacs user (that is, I am assuming you already are,
honestly, I am not trying to persuade anyone to go over to the dark side!)
with a NetBSD-8 (including beta/RC) shell as /bin/sh (or HEAD of course),
and (assuming you know how, I don't) enter "Emacs shell-mode", and see
if it works.   You might need to start emacs with SHELL=/bin/sh in your
environment, again, I have no idea if it is needed, but
		SHELL=/bin/sh emacs
should accomplish that, unless you are also a csh user, in which case
you'd need
		env SHELL=/bin/sh emacs

Thanks,

kre