bugmake - Bugs: bug #7201, Windows Path search works...

 
 

bug #7201: Windows Path search works incorrectly

Submitter:  None
Submitted:  Mon 12 Jan 2004 11:19:39 AM UTC
   
 
Severity:  2 - Minor Item Group:  Enhancement
Status:  Wont Fix Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Component Version:  3.79.1 Operating System:  MS Windows
Fixed Release:  None Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Sat 27 Apr 2013 05:50:15 PM UTC, comment #4: 

I'm closing this bug because I think Make on Windows behaves exactly as the shell would if it were to invoke the program.

If there are situations where the above is incorrect, please feel free to reopen with relevant information.

Eli Zaretskii <eliz>
Group Member
Wed 30 Mar 2005 08:56:34 PM UTC, comment #3: 

Thanks for the note, Alessandro.  I'm not so sure that this is as clear-cut as that, though.  The standard for make defines that it will invoke a shell to run the command on the command line.  GNU make has a "fast path" which avoids invoking a shell and instead runs the command directly, but the fast path is valid and should be used IF and ONLY IF make is sure that the fast path would yield identical results to invoking the shell.  For UNIX, this means that if the SHELL variable is not "/bin/sh", OR there are any shell metacharacters including quoting, pipes, variable references, etc., then the fast path is not used.

This needs to be true of Windows as well: the behavior of the Windows fast path needs to mimic what would happen in the "slow path", where a shell is invoked.  I'm no expert, to be sure, in what that means if the shell is command.com or whatever, but if Windows finds and uses a UNIX shell (unixy_shell is true) then either we have to disable the fast path, or we have to make sure that the fast path and slow path behave the same way.  It's not acceptable for the commands "echo hi" and "echo 'hi'" behave differently, when everything else is identical.

Paul D. Smith <psmith>
Group administrator
Sun 06 Mar 2005 01:15:05 PM UTC, comment #2: 

This is not a bug, or is it is a bug it is Windows',
not GNU make's. Windows searches PATH as a last resort.
E.g. for CreateProcess() (See (long link)
<http://msdn.microsoft.com/library/en-us/dllproc/base/createprocess.asp>)
1. The directory from which the application loaded.
2. The current directory for the parent process.
3. The 32-bit Windows system directory.
4. The 16-bit Windows system directory.
5. The Windows directory.
6. The directories that are listed in the PATH environment variable.

Even if make tried to mimic Unix, such an attempt would
be defeated by multi-tier utilities that in turn create
processes, e.g. gcc, cl, javac, etcetera. Furthermore,
trying to subvert the OS behaviour may lead to inconsistenly
running the wrong worker-tier.

It is the user's responsibility to ensure the environment
is correct under OS-specific rules. In the example,
installing java in GNU make's directory or specifying the
full path to java.exe may work.

Alessandro Vesely <ale2003>
Sun 18 Jan 2004 05:01:23 PM UTC, comment #1: 

I'm happy to apply patches to resolve this issue that someone supplies, if Windows users feel that this is the right way to go.  The Windows port is maintained entirely by volunteers; the maintainers don't even own any systems that run Windows much less one with a development environment, etc. installed.

Paul D. Smith <psmith>
Group administrator
Mon 12 Jan 2004 11:19:39 AM UTC, original submission:  

It appears that make does not search the $(PATH) correctly for commands to be executed (i.e. compilers, tools). If a command can be found in the Windows system directory, for example, it takes precedence over the same command in path. This leads to trouble if the commands differ, e.g. a wrong version of a tool could be easily used by mistake.

Whenever make uses a shell to execute commands, no problems arise. Obviously the shells, including cmd.exe, respect the $(PATH) setting.

Probable sources for the problem are the CreateProcess() and OpenFile() function calls in process_begin() and find_file() functions, respectively, in the w32/subproc/sub_proc.c file.

If these functions are given a file name without directory
path, according to MS Developer Network, the system searches for the file in the directory where the calling application (in this case, make) was found, in the current directory, both Windows system directories and the Windows directory before looking at the PATH environment variable.

Even though this is a feature of these Windows calls, and it might make sense for some applications, it would seem more logical for make to only look at the $(PATH), and nothing else.

This bug was detected using make 3.79.1 mingw32 on Windows 2000. The source references are valid for version 3.80.

---

A short example:
 - java.exe can be found in both c:\jdk1.3\bin and c:\winnt\system32
 - c:\winnt\system32 is not in PATH
 - which looks at PATH only

Makefile:

all:
        which java.exe
        java -version

Make:

% make -d all
[a lot of garbage removed here and there]
which java.exe
c:\jdk1.3\bin\java.exe
java -version
CreateProcess(C:\WINNT\system32\java.exe,java -version,...)
[etc]

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by eliz (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-04-27 eliz StatusNone Wont Fix
        Open/ClosedOpen Closed
    2004-02-21 psmith SummaryPath search for commands to be executed works incorrectly Windows Path search works incorrectly
    2004-01-21 psmith Severity3 - Normal 2 - Minor
        Item GroupBug Enhancement

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code