Some bugs in inferior shell doc and handling

[Lennart Borgman]

Shell argument quoting on w32 is difficult! I looked at this again and 
think I found a couple of more bugs.


******* defun shell:
doc string says

 Program used comes from variable `explicit-shell-file-name',
   or (if that is nil) from the ESHELL environment variable,
   or else from SHELL if there is no ESHELL.

The last line should probably be

   or else from shell-file-name if there is no ESHELL.

Info has the same doc bug.


**** environ var ESHELL doc:
(info "(emacs) General Variables") says

`ESHELL'
    Used for shell-mode to override the `SHELL' environment variable.

I think ESHELL is rather used for starting the inferior process for 
`shell' and `term'.


**** defun term:
Is this supposed to work on w32? It currently does not which is a bug. 
Either the doc string should say it does not work on w32 or it should 
work I think.


**** defcustom explicit-shell-file-name
Doc string is unclear to me. Does "explicitly requested inferior shells" 
simply mean "interactive shells started by `shell'?


**** defun w32-shell-name
This is the worst bug. The intention of this function is unclear. The 
doc string does not tell its intended use however and that is to me a 
bug. w32-shell-dos-semantics uses w32-shell-name but should probably 
just use shell-file-name instead since that is what is used when 
starting non-interactive inferior shells AFAICS. This is currently a bug 
in w32-shell-dos-semantics.

w32-shell-name is however also used in bat-generic-mode-compile and 
bat-generic-mode-run-as-comint which seems to assume that it points to 
cmd.exe or command.com. This is another bug (or two). Maybe 
w32-shell-name should be for that instead? Perhaps there are people out 
there using w32-shell-name so I instead suggest a new function like this 
for use in those bat-* functions

   (defun w32-default-console-name()
   "Return "cmd.exe" on NT and "command.com" on DOS."
  ...)

Or perhaps just fix the bat-* functions?


**** defun text-start-shell
This supposes a unix style shell. However it does not check that it 
actually is a unix style shell. This is a bug. Could it use w32 style 
shells too if text-start-shell was changed to allow this?

The way it chooses shells suggests to me that it also should check 
explicit-shell-file-name (before ESHELL) to be consistent with the use 
of these variables. But I am not sure about the intention here. Maybe 
the ESHELL test should be removed instead?


**** The use of SHELL and ESHELL
This is an important matter I believe. I wonder about the use of SHELL 
and ESHELL. SHELL is used to initialize shell-file-name. Why should it 
be used more in the code? What about starting inferior shells? If you 
change shell-file-name do you have to change SHELL to?

Could not ESHELL be used in the same way to initialize 
explicit-shell-file-name?