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

 
 

bug #7201: Windows Path search works incorrectly

Submitted by:  None
Submitted on:  Mon 12 Jan 2004 11:19:39 AM UTC  
 
Severity: 2 - MinorItem Group: Enhancement
Status: Wont FixPrivacy: Public
Assigned to: NoneOpen/Closed: Closed
Component Version: 3.79.1Operating System: MS Windows
Fixed Release: NoneTriage Status: None

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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>
Project 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>
Project 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>
Project 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 File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 27 Apr 2013 05:50:15 PM UTCelizStatusNone=>Wont Fix
      Open/ClosedOpen=>Closed
    Sat 21 Feb 2004 05:23:50 PM UTCpsmithSummaryPath search for commands to be executed works incorrectly=>Windows Path search works incorrectly
    Wed 21 Jan 2004 05:48:33 AM UTCpsmithSeverity3 - Normal=>2 - Minor
      Item GroupBug=>Enhancement

    Back to the top


    Powered by Savane 3.1-cleanup1