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
