PATH vs. Path ([Fwd: Returned mail: see transcript for details]

[Alessandro Vesely]

I sent that message also to the e-mail address showed, but it
had permanent fatal errors:

<address@hidden>
    (reason: 550 5.1.1 <address@hidden>... User unknown)

   ----- Transcript of session follows -----
... while talking to d03mjd01.boulder.ibm.com.:
>>> DATA
<<< 550 5.1.1 <address@hidden>... User unknown
550 5.1.1 <address@hidden>... User unknown
<<< 503 5.0.0 Need RCPT (recipient)

The archives at http://lists.gnu.org/archive/html/make-w32/
only go back to april 2001. However, from a post that Rob
sent in 2002 it may be argued that the `Path' spelling arose
as a mean to use different paths for sh.exe and the rest of
the Windows system. I paste the relevant part below, and
comment it:

> http://lists.gnu.org/archive/html/make-w32/2002-09/msg00057.html
> From:  Rob Tulloh 
> Subject:  Re: Useful patch for GNUmake on Windows 
> Date:  Wed, 18 Sep 2002 09:56:38 -0700 (PDT) 
> 
> [...]
> One caveat is that you must take care with PATH and Path 
> to ensure that no unintended user environment creeps into the path
> unless you desire this to happen. To ensure that PATH/Path are set as
> you want, you should set the values in your global make configuration
> so that all sub-makes and sub-shells get the value of PATH and Path
> that  you expect. Note I only mention PATH vs Path because of
> the way that Bourne shell implementations will usually want PATH 
> to be set whereas Win32 systems are happy with virtually any 
> spelling as Win32 does not know the difference.

The latter statement is not fully correct, since win9x is not happy.
`strings sh.exe | grep Path' didn't yield anything, so I guess the
former statement is true also for MinGW's sh.exe, i.e. it doesn't
treat "Path" specially.

> However, Path is the more common spelling that you find in practice. 
> Where both variables must be managed, I have handled it like this: 
>   
> PATH = $(VAR1):$(VAR2):$(VAR3) 
> Path = $(PATH) 
>
> In this way, you can manage the settings for both Windows and sh.exe

Except that Windows won't like ":"s

> at the same time. This is also more likely to be portable since existing 
> Unix-based environments will already be managing PATH and you can 
> avoid to change everything by simply making Path the same as PATH. 
> Windows specific stuff can be added to PATH if needed and portability 
> is retained. For example, you could say something like this if you wanted to: 
>   
> ifeq ($(INTERP),win32) 
> PATH += $(SystemRoot)/system32 
> endif 

Thus, it looks like `Path' is needed to avoid _contaminating_ the Windows
setup with unixy stuff. Astonishing. (I recall early MS Windows programmers
saying that "new [16bit!] apps should use the registry rather than legacy
means such as _the environment_ that oldapps used to rely upon".)

Anyway, malfunctioning of the $(shell) on win98 is definitely related to the
Path vs PATH problem. I did a brutal replacement of "Path" with "PATH" in
main.c and variable.c and run the following test

no sh.exe in PATH

  D:\tmp\TOOLS\test>sh
  Comando o nome file non valido

makefile

  D:\tmp\TOOLS\test>cat sh
  # test is $(shell) works
  tt := $(shell cat sh | sed -n -e "1s/^[^$$]*  *//p")
  ifeq "" "$(strip $(tt))"
    tt := $$(shell) failed
  endif

  all:
          @echo $(tt)

running yesterday's make (with "Path")
("Comando o nome file non valido" = "Invalid command or file name" from 
command.com)

  D:\tmp\TOOLS\test>gmake -f sh
  Comando o nome file non valido
  Comando o nome file non valido
  $(shell) failed

running the brutally patched make (with "PATH")

  D:\tmp\TOOLS\test>c:\util\gmake -f sh
  $(shell) works

if sh.exe is in PATH or with MSYS, the makefile fails (echoing `$(shell)')
but the $(shell) function still works; it works equally well in the unpatched
version.

  478$ /d/tmp/tools/test
  $ c:/util/gmake -f sh
  C:/WINDOWS/TEMP/make-782027-1.sh: shell: command not found
  works


I don't include the brutal patch, because it's brutal. I just mention the lines
changed for the above test. Perhaps only some of those changes are needed.

  main.c:766:    struct variable *v = lookup_variable ("Path", 4);
  main.c:1113:      else if (!windows32_path && !strnicmp(envp[i], "Path=", 5)) 
{
  main.c:1150:      define_variable("Path", 4, windows32_path, o_env, 
1)->export = v_export;
  main.c:1152:      define_variable("Path", 4, unix_path, o_env, 1)->export = 
v_export;
  main.c:1154:      define_variable("Path", 4, "", o_env, 1)->export = v_export;
  variable.c:1433:  char *path = allocated_variable_expand ("$(Path)");
  variable.c:1450:  environ_path = concat ("Path", "=", path);

Finally, this test has nothing to do with the variables/SHELL suite which,
as its name says, is about the SHELL variable, not the shell function.

-------- Original Message --------
Date: Wed, 02 Mar 2005 09:37:16 +0100
From: Alessandro Vesely <address@hidden>
To: Eli Zaretskii <address@hidden>, Rob Tulloh <address@hidden>
CC: address@hidden
Subject: PATH vs. Path (was: Re: Savannah W32 patches... are any OK?

[...]
Wed Oct  1 15:45:09 1997  Rob Tulloh <address@hidden>

        * main.c [WINDOWS32]: Any arbitrary spelling of Path can be
        detected. Make will ensure that the special spelling `Path' is
        inserted into the environment when the path variable is propagated
        within itself and to make's children.

[...]