env and PATH

Federico Kircheis federico@kircheis.it
Mon Jan 13 17:03:27 GMT 2025


On 13/01/2025 09.59, Andrey Repin wrote:
> Greetings, Federico Kircheis!
> 
>> On 09/01/2025 08.31, Andrey Repin wrote:
>>> The apparent issue you are missing is that you are calling native app from
>>> Cygwin environment.
>>> Each have its own rules, and to have it working with minimal issues, you'd
>>> need to satisfy both sides.
>>> In specific case, PATH is a special environment variable for both sides, and
>>> you have to correctly translate it from one side to the other.
> 
>> What do you mean?
>> I'm perfectly aware that PATH is special, and why it is, I also wrote it in the first mail.
> 
> It is special TO BOTH SIDES. The "both" is the key word.
> 
>> I questioned the statement that the conversion is expected _because_ `env`
>> expects POSIX semantics and parsed my command according to that.
> 
> No, it is expected because of its meaning to both sides AND because env don't
> know, what kind of program it is running.

But I know that the program is a windows program, thus a setting for 
manually disabling the conversion made sense (at least in my head).

> Runtime knows, env does not. Runtime does conversion, not env.

Ah, ok I missed the part that the conversion is not done by env but 
somewhere else, thus a flag for env does might not make that much sense.

>> Since POSIX says nothing about the interaction of env and PATH,
> 
> Why it should? This is Cygwin specifics.
> 
>> and conversions are not described by the standard (as you confirmed), the
>> behavior is expected because of what cygwin does, not because of POSIX. (and
>> yes, I knew cygwin does the conversion from cygwin PATH to Windows PATH, so
>> that was expected, I did not expect it to break a Windows PATH and to depend
>> on the current drive)
> 
> env don't expect Windows paths to begin with. And dependency on current drive
> is coincidental, since your paths, read as POSIX, were interpreted as relative.
> 
>> The main question of this thread was:
> 
>> "I noticed that PATH is converted, and cannot find a switch do disable this
>> conversion. Is it possible to define an environment and use it as is,
>> without having some implicit conversions?"
> 
>> I mean, there are other variables that have special meanings; all those that define a path.
>> (Examples would be HOME, XDG_CACHE_HOME, XDG_DATA_HOME, ...)
> 
> Special to both sides?
> While HOME and TMP do have a meaning to both sides (though, HOME is
> questionable), XDG_* ones are purely *NIX specific.

XDG_* are not purely unix specific; they are just environment variables.
For example, I actually expect a multiplatform programs that respect 
XDG_* on a Linux machine to respect it also on Windows.
Why should a program that supports XDG_* environment variables go out of 
it's way and explicitly ignore them?

>> The answer seems to be no (which was what I feared).
> 
>> Thus special casing for some environment variables is necessary as there is no such switch.
>> I saw PATH as particularly problematic because I was not aware of the option --path of cygpath.
> 
>>> I provided a wrapper script I use myself, you could add any massaging to it
>>> that you feel necessary. Like `unset TERM` or PATH modifications.
> 
>> Attachment seems to be missing,
> 
> Was not an attachment. (The list is not very tolerant to those.)

Ah sorry, I thought you provided a wrapper script as attachment, and 
could not find it.

>> but I think unsetting environment variables
>> one by one, changing existing, and adding the missing, is too error-prone.
>> Defining a "clean" environment once seems to have less chances to have some errors.
> 
> That's up to you.
> I have more intricate wrappers than this one. Just didn't want to flood the
> list.



More information about the Cygwin mailing list