Re: very wierd commit from emacs (or ntemacs) problem

[Eli Zaretskii]

> From: Kevin Rodgers <kevinr@ihs.com>
> Newsgroups: gnu.emacs.bug
> Date: Fri, 04 May 2001 09:32:42 -0600
> 
> Eli Zaretskii wrote:
> > It is actually a bug to use explicit-shell-file-name unconditionally:
> > this variable only exists in the Windows version of Emacs.
> 
> Since when?  I can't find any record of that change in the Emacs 20.7
> ChangeLog, etc/NEWS, or lisp/ChangeLog files.

Sorry, that was my bad: I got it mixed up with w32-shell-name.

The problem with explicit-shell-file-name is that it is defined by
shell.el, which might not be loaded.  So the end result is the same:
explicit-shell-file-name should not be used unconditionally, I think.

> Also, shouldn't every use of shell-file-name also reference
> shell-command-switch instead of "-c"?

Yes, but this is a different issue.  AFAIK, shell-command-switch is
meant to be used by applications and users; it is unconditionally set
to "-c" and no platform changes it.  The Windows port warns if the
user doesn't change it to "/c" when using a Windows shell.  The MS-DOS
port simply uses "/c" inside the call-process primitive if the command
specifies "-c" and the shell is not a Unixy shell (personally, I think
the Windows port should do the same).