DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 50DH51DB2905403
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 105B23858D21
Message-ID: <251f0ab7-aae1-4198-a863-fbbe64d0c702@kircheis.it>
Date: Mon, 13 Jan 2025 18:03:27 +0100
MIME-Version: 1.0
Subject: Re: env and PATH
To: cygwin AT cygwin DOT com
References: <77a3709d-ec4d-497b-bf6c-75f29dc8c992 AT kircheis DOT it>
 <1756102695 DOT 20250104044139 AT yandex DOT ru>
 <21a99c98-1a16-4ffb-97f4-fa9480f7b02d AT kircheis DOT it>
 <383539154 DOT 20250104231316 AT yandex DOT ru>
 <dfce0589-5f52-408c-a8f9-f42771c724a3 AT kircheis DOT it>
 <123712861 DOT 20250109103130 AT yandex DOT ru>
 <9375d5cd-792e-45f4-958b-40521d15afd5 AT kircheis DOT it>
 <1056238423 DOT 20250113115946 AT yandex DOT ru>
In-Reply-To: <1056238423.20250113115946@yandex.ru>
From: Federico Kircheis via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Federico Kircheis <federico AT kircheis DOT it>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>

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.


-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple