[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
possible bug in process.c?
From: |
Michael Vezie |
Subject: |
possible bug in process.c? |
Date: |
Wed, 14 Jan 2004 13:52:44 -0500 |
User-agent: |
Mutt/1.3.28i |
In process.c, in DEFUN("start-process...
Around line 1193 or so (in 21.3, although I've seen the same code in 20.7) is
the following
snippet of code:
/* If program file name is not absolute, search our path for it */
if (!IS_DIRECTORY_SEP (XSTRING (program)->data[0])
&& !(XSTRING (program)->size > 1
&& IS_DEVICE_SEP (XSTRING (program)->data[1])))
{
... at which point it then processes a relative pathname file (looking through
Vexec_path
for the executable, etc).
Maybe I'm reading this wrong (help me out if I am), but shouldn't that last
line there read:
&& !IS_DEVICE_SEP (XSTRING (program)->data[1])))
note ^
Here's how I read it:
If the first character is not a directory separator ('/' or '\\') and the
string is longer than
1 and the second character is a device separator (':')... you're checking here
if the string denotes
a relative path. But if the second character is a ':', then it's something
like:
c:/fsf/emacs-21.3/bin/cmdproxy.exe
which is an absolute path, and doesn't require looking through Vexec_path.
In any case, I get an error preceeded by "Searching for program" when I set my
SHELL environment
variable to c:/fsf/emacs-21.3/bin/cmdproxy.exe (it should never search for the
program in the path
with an absolute path like that), and things work fine when I set my SHELL
environment variable to
simply cmdproxy.exe
Michael
- possible bug in process.c?,
Michael Vezie <=