On Sun, Mar 09, 2008 at 04:14:40PM +0100, Corinna Vinschen wrote: >On Mar 9 10:38, Christopher Faylor wrote: >> On Sun, Mar 09, 2008 at 10:28:06AM +0100, Corinna Vinschen wrote: >> >Bash as well as tcsh, as well as zsh (and probbaly pdksh, too) create an >> >environment variable $PWD. Maybe Cygwin should create $PWD for native >> >apps if it's not already available through the parent shell. >> >> I'd really rather not do that. I don't think Cygwin should be polluting >> the environment any more than it has to. Even if this worked, it is >> easily defeatable by setting a PWD environment variable before running >> cygwin, so you'd have to keep track of this value through multiple >> levels of process invocation. > >Nothing against adding a cygwin_internal for such a purpose, but how is >that going to work? Assuming the MingW application is called from a >Cygwin application. If the parent application's cwd is a long path, the >MingW child gets its own cwd for apparent reasons. If it loads the >cygwin DLL dynamically, as cygcheck already does, how is that new >invocation of the DLL supposed to know the cwd of the parent process?
I guess I misunderstood. I thought that the current working directory could be derived through some complicated combination of Nt*() calls. >Maybe I miss something, but I don't see how that could work without >using another mechanism to transmit the cwd of the parent application to >the child, and the environment seems like a pretty simple way to do it. > >What about just using PWD if it's set, but not to invent it in Cygwin if >it doesn't exist? I see two situations which probably cover 99% of the >cases. The problem with environment variables are that they are under the user's control. If the user decides to modify PWD, then it can cause issues. That's why I was looking for a more foolproof solution. That + I hate the thought of adding YA special environment variable for Cygwin to worry about. A "real" "OS" would never consider passing stuff around in environment variables. cgf
