DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 504INwoE1895396
Authentication-Results:	delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com
Authentication-Results:	delorie.com; spf=pass smtp.mailfrom=cygwin.com
DKIM-Filter:	OpenDKIM Filter v2.11.0 delorie.com 504INwoE1895396
Authentication-Results:	delorie.com;
	dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=PP8RZpoe
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 28AD83858D28
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1736015037;
	bh=vpH1f8+Y8+rGFUFkjg/rkn8Y/4AnzmR3yYSmJCCFLd0=;
	h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe:
	List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	From;
	b=PP8RZpoed+sMH8yyw9L2e9BUPtVAjE5+9waAu+hsIgRJVVWg7SJYvcrjywgCivTlq
	SYohcFsUs9l8G5b4hPyy0xJsK5pp+Kp7N7H7MBpqL2kN66xfl7zAGnRqiDz0pj4F33
	k3M0bP8lPRq/ArQrOsmqeuNdk94iO+jg6YSHhR3Q=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org 0AA703858D21
ARC-Filter:	OpenARC Filter v1.0.0 sourceware.org 0AA703858D21
ARC-Seal:	i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1736014977; cv=none;
	b=IqPkaum0icvwc6nM8ATVTOyLRmZFmiMI07YDhhPQo7FdZTXBayfUxbhjo3mEAT3u/Ffp0H2n1l5vSrr6xBKkR62/gyr8zRgU6mdQEsg7IYw3JoRNVy5oFcevuSqTkvJKX5Jpsm5uB0yqBPQy6dmhxAOT6OIvXsBjpqumvCdA8Xo=
ARC-Message-Signature:	i=1; a=rsa-sha256; d=sourceware.org; s=key;
	t=1736014977; c=relaxed/simple;
	bh=f8Z3KSW9Hfw72tuu8j3hJu36BKnArpZaAvg0TxZ4bhM=;
	h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From;
	b=TEU+RrPxBSV1WdlYLNkJG9hJbpQhgkbh60+5H77xAbyE6rn14j0beLO5yb8iuIaGquhBJHmjQ9W+C5j5qFtZ5mkaHVhB80moKFRq3Gj4bucOhTFFOdm8KEBfE6UxkYzZg/NhltDjWwBi7V5UNGBgUGQLsQX9GZiTi/AI4kskvbA=
ARC-Authentication-Results:	i=1; server2.sourceware.org
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 0AA703858D21
Message-ID:	<21a99c98-1a16-4ffb-97f4-fa9480f7b02d@kircheis.it>
Date:	Sat, 4 Jan 2025 19:22:52 +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>
In-Reply-To:	<1756102695.20250104044139@yandex.ru>
X-Rspamd-Queue-Id:	4YQTMK1lBBz9sdC
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.30
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From:	Federico Kircheis via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	Federico Kircheis <federico AT kircheis DOT it>
Sender:	"Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>

On 04/01/2025 02.41, Andrey Repin wrote:
> Greetings, Federico Kircheis!
> 
>> Hello to everyone,
> 
> 
>> I've noticed that env seems to handle the environment variable PATH in a particular way
> 
> 
>> -----
>   >> cd /d;
>   >> env -i PATH='C:\Windows;C:\Windows\system32;' /c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe
>> # in the powershell instance
>> echo $env:PATH
>> C;D:\Windows;C;D:\Windows\system32;
>> ----
> 
> Fully expected behavior. `env` expects POSIX semantics and parsed your
> command according to that.
> The results are, as I said, expected, although not by you.
What do you mean by POSIX semantic?
On my Linux system, PATH is used unmodified by subprocesses, not 
transformed.
This is (IMHO) the expected semantic.

I am not aware of any rule in POSIX that requires or recommends some 
transformations for environment variables, in that sense, any 
transformation is "unexpected" or an extension to the standard.

It completely makes sense to convert cygwin paths to windows path when 
invoking windows programs, but it is not my case.
Hence why I searched for an option, even an explicit one, to tell cygwin 
not to modify the parameters, but use them as-is.

>>   From this and other examples it seems that env uses for PATH  as
>> separator, then preprends the current drive to all paths that begin with '\'
>> (thus all of them), and ";" is treated as part of the path
> 
> Exactly.
> 
>> I would like to use the PATH as-is in the invoked program, just like it is done for other variables, for example
> 
>> ----
>> cd /d
>> env -i OPATH='C:\Windows;C:\Windows\system32;'
>> /c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe
>> # in the powershell instance
>> echo $env:OPATH
>> C:\Windows;C:\Windows\system32;
>> ----
> 
>> in this case OPATH is forwarded as-is to powershell.exe.
> 
>> I understand that PATH is special, that for cygwin processes some transformation might be necessary.
> 
> It is, but in a way you suppose.
> 
>> But is there any way to achieve what I'm trying?
> 
> Yes. Pass the POSIX paths in $PATH, they will be converted to Windows ones
> when invoking a Windows process.
> Also, I strongly suggest using /proc/cygdrive/ tree in such case, especially
> when you make scripts for somebody else.

I was not aware of /proc/cygdrive/, thank you for the hint, although I 
am not sure how it helps.

>> I search if there is maybe a separation option for telling env to use PATH as-is, but could not find none.
> 
> There's no need or reason to do it.
> 
> In your case, what you wanted to achieve could be written as
> 
>>> env -i "PATH=$(cygpath -UW):$(cygpath -US):$PATH" pwsh

The reason is I already have a variable containing the path I should use 
as PATH, and it is the windows expected format.
I need to convert it to a cygwin path, so that env translates it back again.
It is doable, but sounds completely unnecessary.

Also it comes at a particular cost at runtime.
I want to start the subshell as fast as possible.
Iterating and invoking an external program (cygpath) for every path 
takes some time.

> (The "%SystemRoot%" is NOT NECESSARILY 'C:\Windows', though you CAN use
> "%SystemRoot%\System32" with confidence, once you acquired the former.)
> (Also, why the *** you are using v1.0? Get v7 already, save yourself the
> tragedy.)

Because the executable I invoked is the one installed on all Windows 
versions since Windows 7 (or maybe even Vista?).
Also the actual version is not 1.0, but something like 5.something (if I 
remember correctly)

v7 is AFAIK a different product, but most importantly it needs to be 
installed separately, and would not change the issue I have.

-- 
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

- Raw text -