Bug in shell.el: explicit-bash-args does not work for bash 1.x

Bug in shell.el: explicit-bash-args does not work for bash 1.x

[Kim F. Storm]

It is quite a mystery to me why I just started to get bitten by the
follow change [which is now 4 month old]:

2002-06-28  Andreas Schwab  <schwab@suse.de>

	* shell.el (explicit-bash-args): New user option.


This is specified to define explicit-bash-args to --noediting -i
which are the proper options for bash 2.x

However, for bash 1.x (included with e.g. redhat 6.2), the --noediting
option isn't recognized and bash refuses to start.

For bash 1.x, the corresponding option was named -nolineediting, but
even setting that option doesn't really work, as (for some reason I
don't understand) process-send-eof is then unable to terminate the
running bash 1.x (so C-d at EOB no longer exits the shell)!

Only reverting back to explicit-bash-args not including neither
--noediting nor -nolineediting makes it work ok.

As I said above, I'm puzzled why I didn't discover this earlier -- I
use shell buffers all the time, but maybe it's been some time since I
actually did that on the system where I still have redhat 6.2
installed.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Bug in shell.el: explicit-bash-args does not work for bash 1.x

[Richard Stallman]

    However, for bash 1.x (included with e.g. redhat 6.2), the --noediting
    option isn't recognized and bash refuses to start.

That is fairly old.  I don't think we should drop the feature
just for the sake of old systems.  Is there a way to detect the
error and start bash again in a suitable way for bash 1.x?

Re: Bug in shell.el: explicit-bash-args does not work for bash 1.x

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     However, for bash 1.x (included with e.g. redhat 6.2), the --noediting
>     option isn't recognized and bash refuses to start.
> 
> That is fairly old.  I don't think we should drop the feature
> just for the sake of old systems.  Is there a way to detect the
> error and start bash again in a suitable way for bash 1.x?
> 

The following code returns the proper setting for bash 1.x and 2.x. 

I suppose it could be used as the initial value for explicit-bash-args.


(let* ((prog (or (and (boundp 'explicit-shell-file-name) explicit-shell-file-name)
		 (getenv "ESHELL") shell-file-name))
       (name (file-name-nondirectory prog)))
  (if (and (equal name "bash")
	   (file-executable-p prog)
	   (string-match "bad option"
			 (shell-command-to-string (concat prog " --noediting"))))
      '("-i")
    '("--noediting" "-i")))


It is optimized to run (when shell.el is loaded) only if the
configured shell is actually bash, meaning that it isn't set properly
if the user later changes from some other shell to bash after loading
shell.el.

If that behaviour is not acceptable, we can check for bash explicitly
and set the option unconditionally:

  (if (string-match "bad option"
		    (shell-command-to-string "/bin/bash --noediting"))
      '("-i")
    '("--noediting" "-i"))

However, that assumes that bash 1.x is located in /bin/bash for the 
proper [reduced] setting is selected -- probably a reasonable
assumption, and still not much harm done if it makes the wrong
choice.


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Bug in shell.el: explicit-bash-args does not work for bash 1.x

[Richard Stallman]

    The following code returns the proper setting for bash 1.x and 2.x. 

    I suppose it could be used as the initial value for explicit-bash-args.

It looks reasonable to me--unless someone finds ways to improve it,
please install it.

Re: Bug in shell.el: explicit-bash-args does not work for bash 1.x

[Stefan Monnier]

> (let* ((prog (or (and (boundp 'explicit-shell-file-name) explicit-shell-file-name)
> 		 (getenv "ESHELL") shell-file-name))
>        (name (file-name-nondirectory prog)))
>   (if (and (equal name "bash")
> 	   (file-executable-p prog)
> 	   (string-match "bad option"
> 			 (shell-command-to-string (concat prog " --noediting"))))
>       '("-i")
>     '("--noediting" "-i")))

I must say I don't like the idea of running a program when loadng
a .el file.  It's already done at various places, tho.

There is no strong reason, but one of the recent problem I came
across in this area is that process operations don't work properly during
dumping (the handling of sigchld is explicitly not turned on because
it can supposedly prevent unexec from working right).

That prevents byte-compiling ediff with temacs, for example, because
ediff runs `patch' (IIRC) while loading one of its .el files.


	Stefan

Re: Bug in shell.el: explicit-bash-args does not work for bash 1.x

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> > (let* ((prog (or (and (boundp 'explicit-shell-file-name) explicit-shell-file-name)
> > 		 (getenv "ESHELL") shell-file-name))
> >        (name (file-name-nondirectory prog)))
> >   (if (and (equal name "bash")
> > 	   (file-executable-p prog)
> > 	   (string-match "bad option"
> > 			 (shell-command-to-string (concat prog " --noediting"))))
> >       '("-i")
> >     '("--noediting" "-i")))
> 
> I must say I don't like the idea of running a program when loadng
> a .el file.  It's already done at various places, tho.
> 
> There is no strong reason, but one of the recent problem I came
> across in this area is that process operations don't work properly during
> dumping (the handling of sigchld is explicitly not turned on because
> it can supposedly prevent unexec from working right).
> 

The following code doesn't execute the program; it does a brute-force
check for the version of the bash program by looking inside the
executeable.  This works for me on GNU/Linux -- again, if it
doesn't work on other platforms, it doesn't do any worse than
the current default...

(let* ((prog (or (and (boundp 'explicit-shell-file-name) explicit-shell-file-name)
		 (getenv "ESHELL") shell-file-name))
       (name (file-name-nondirectory prog)))
  (if (and (equal name "bash")
	   (file-executable-p prog)
           (file-readable-p prog)
	   (with-temp-buffer
	     (insert-file-contents-literally prog)
	     (goto-char (point-min))
	     (search-forward "@(#)Bash version 1" nil t)))
      '("-i")
    '("--noediting" "-i")))

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Bug in shell.el: explicit-bash-args does not work for bash 1.x

[Eli Zaretskii]

On 29 Oct 2002, Kim F. Storm wrote:

> The following code doesn't execute the program; it does a brute-force
> check for the version of the bash program by looking inside the
> executeable.

I think this is very non-portable and should be avoided at all costs.

Re: Bug in shell.el: explicit-bash-args does not work for bash 1.x

[Eli Zaretskii]

On Mon, 28 Oct 2002, Stefan Monnier wrote:

> There is no strong reason, but one of the recent problem I came
> across in this area is that process operations don't work properly during
> dumping (the handling of sigchld is explicitly not turned on because
> it can supposedly prevent unexec from working right).
> 
> That prevents byte-compiling ediff with temacs, for example, because
> ediff runs `patch' (IIRC) while loading one of its .el files.

Perhaps there's a need for some new `eval-*' form that would not run at 
dump time?

Re: Bug in shell.el: explicit-bash-args does not work for bash 1.x

[Stefan Monnier]

> > There is no strong reason, but one of the recent problem I came
> > across in this area is that process operations don't work properly during
> > dumping (the handling of sigchld is explicitly not turned on because
> > it can supposedly prevent unexec from working right).
> > 
> > That prevents byte-compiling ediff with temacs, for example, because
> > ediff runs `patch' (IIRC) while loading one of its .el files.
> 
> Perhaps there's a need for some new `eval-*' form that would not run at 
> dump time?

Why bother: you can already test `purify-flag'.


	Stefan

Re: Bug in shell.el: explicit-bash-args does not work for bash 1.x

[Kai Großjohann]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> I must say I don't like the idea of running a program when loadng
> a .el file.  It's already done at various places, tho.

Yes.  How about starting bash with one set of args, if that fails try
the other set of args?  I think it's not much of a problem to start
bash twice instead of once (if the first try fails).

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Bug in shell.el: explicit-bash-args does not work for bash 1.x

[Kim F. Storm]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

> "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> 
> > I must say I don't like the idea of running a program when loadng
> > a .el file.  It's already done at various places, tho.
> 
> Yes.  How about starting bash with one set of args, if that fails try
> the other set of args?  I think it's not much of a problem to start
> bash twice instead of once (if the first try fails).

It could be done, but as proposed, this requires special treatment
of bash in M-x shell.

Maybe we could have explicit-SHELL-args-2 which is an alternate
set of args to use in case the shell fails to start with the
args provided in explicit-SHELL-args.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Bug in shell.el: explicit-bash-args does not work for bash 1.x

[Kai Großjohann]

storm@cua.dk (Kim F. Storm) writes:

> Maybe we could have explicit-SHELL-args-2 which is an alternate
> set of args to use in case the shell fails to start with the
> args provided in explicit-SHELL-args.

Yes, or explicit-SHELL-args could be a vector of lists of strings if
multiple tries are necessary.

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Bug in shell.el: explicit-bash-args does not work for bash 1.x

[Richard Stallman]

    There is no strong reason, but one of the recent problem I came
    across in this area is that process operations don't work properly during
    dumping (the handling of sigchld is explicitly not turned on because
    it can supposedly prevent unexec from working right).

    That prevents byte-compiling ediff with temacs, for example, because
    ediff runs `patch' (IIRC) while loading one of its .el files.

There can be a conditional to avoid running the program
if purify-flag is non-nil.

Re: Bug in shell.el: explicit-bash-args does not work for bash 1.x

[Kim F. Storm]

storm@cua.dk (Kim F. Storm) writes:

> The following code returns the proper setting for bash 1.x and 2.x. 
> 
> I suppose it could be used as the initial value for explicit-bash-args.
> 
> 
> (let* ((prog (or (and (boundp 'explicit-shell-file-name) explicit-shell-file-name)
> 		 (getenv "ESHELL") shell-file-name))
>        (name (file-name-nondirectory prog)))
>   (if (and (equal name "bash")
> 	   (file-executable-p prog)
> 	   (string-match "bad option"
> 			 (shell-command-to-string (concat prog " --noediting"))))
>       '("-i")
>     '("--noediting" "-i")))
> 

I added a check for (not purify-flag) to the above and installed it.
It works nicely on my GNU/Linux platforms (mixture of Bash 1.x and 2.x).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk