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. Runtime knows, env does not. Runtime does conversion, not env. > 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. > 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.) > 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. -- With best regards, Andrey Repin Monday, January 13, 2025 11:01:39 Sorry for my terrible english... -- 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
