Works perfectly well for me on -current 8.99.23 amd64 and emacs 25.3. Chavdar
On Thu, 16 Aug 2018 at 06:45 Robert Elz <[email protected]> wrote: > 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 > >
