[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: very wierd commit from emacs (or ntemacs) problem
From: |
Eli Zaretskii |
Subject: |
Re: very wierd commit from emacs (or ntemacs) problem |
Date: |
Fri, 04 May 2001 20:36:33 +0300 |
> 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).