Re: PATH & Perl 5.6 on Win32 ?

['Trent Mick']

Johan,

I am not a Perl hacker so I can't really help push this forward. I would
suggest that you and/or Eric raise these issues on the perl5-porters or
related Perl development list.

Trent



On Tue, Apr 17, 2001 at 05:31:32PM +0200, Johan Holmberg wrote:
> 
> On Tue, 10 Apr 2001, 'Trent Mick' wrote:
> >
> > Here was Sarathy's answer to that:
> > > >But it works in Python. :) Oh well.
> > >
> > > Probably because Python uses MSVCRT's spawnvp() to implement system().
> > > IIRC, MSVCRT will attempt to locate the file by navigating the PATH,
> > > and give up if it can't "find" it.  (The rules for what constitutes
> > > "finding" it are fuzzy, and subject to MSVCRT bugs.)
> > >
> > > To avoid any MSVCRT issues, Perl calls CreateProcess() directly, and
> > > doesn't attempt to locate the file by itself--instead, it lets the OS
> > > find it using its "normal" rules.  MSVCRT's rules may be more "normal"
> > > in some situations, but what the OS does is distinctly better in others.
> > >
> > > It's hard to implement both kinds of bugs simultaneously.  :-)
> >
> >
> 
> I don't think this is a correct description, or at least it misses
> the point I (and Eric I think) is trying to make.
> 
> The behaviour I see when running 5.6 with some print-debugging added
> by myself is this:
> 
>     - my script changes $ENV{PATH}
> 
>     - my script calls something like:
> 
>         system("cl /c foo.c")
> 
>     - the function implementing "system" in Perl is "win32_spawnvp"
>       in the file "win32\win32.c" in the Perl source code.
> 
>     - that function first calls CreateProcess with arguments like:
> 
>         CreateProcess("cl",
>                       "cl /c foo.c", ....);
> 
>       since there is no file called "cl" in the current directory
>       this call usually fails. Not even if there is a "cl.exe" there
>       it will be found. CreateProcess requires an *exact* match.
> 
>     - after this "win32_spawnvp" tries to locate "cl" by itself by
>       calling "qualified_path" (defined in "win32\win32.c" in the
>       Perl source code), and then calling CreateProcess again
>       with the result of that call:
> 
>         CreateProcess("c:\full\but\wrong\path\to\cl.exe",
>                       "cl /c foo.c", ....);
> 
>     - the reason we get the wrong PATH above is that
>       "qualified_path" calls "win32_getenv" to obtain the value
>       of the PATH environment variable. That (incorrect) value is then
>       used to transform "cl" to "c:\full\but\wrong\path\to\cl.exe".
> 
> 
> The description above is slightly different from what Eric described
> in his bug-report on ActiveState Perl 5.6 (APR#1342), but the
> essential point is the same: that there are two different values of
> PATH:
> 
>     1) the one current when the script started (which is used to
>        initialize $ENV{PATH} in Perl)
> 
>     2) the value of $ENV{PATH} at the time of the system call
> 
> Eric seems to have assumed that CreateProcess was called in such a
> way that Perl relied on Win32's own searching of the PATH. I think
> that Perl calculates the full path to the exe-file all by itself in
> "qualified_path".
> 
> So when Sarathy says (cited by Mick Trent):
> 
> > > To avoid any MSVCRT issues, Perl calls CreateProcess() directly, and
> > > doesn't attempt to locate the file by itself--instead, it lets the OS
> 
> I think this is incorrect.
> 
> And I don't understand how the current behaviour could be "better"
> or "bug compatible" with anything else ...
> 
> Wouldn't a simple change in "qualified_path" be enough.
> If that function consulted the current value of $ENV{PATH}, things
> would be much better ....
> 
> (maybe the code implementing "system" should be reworked more.
>  Now the code still searches the current directory before trying
>  the PATH. This is *not* how it works on UNIX, and could be
>  surprising to users (see above))
> 
> I have tried above to show that the problem we are discussing here
> really is a *BUG*. Without an accurate view of the current behaviour
> of Perl's "system" function, it is easy to discuss the wrong things.
> 
> I hope that I have given a correct account of how things work.
> It's the first time I have compiled the Perl source myself on NT,
> but I have followed the build instructions carefully, so I assume
> that the behaviour in my build is the same as in the official
> precompiled version of ActiveState Perl (all symptoms indicate
> that).
> 
> /Johan Holmberg
> 
> 
> 
> _______________________________________________
> address@hidden
> http://mail.gnu.org/mailman/listinfo/cons-discuss
> Cons URL: http://www.dsmit.com/cons/

-- 
Trent Mick
address@hidden