Re: PATH & Perl 5.6 on Win32 ?

[Johan Holmberg]

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