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? 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 first case is starting cygcheck from the native command shell. That shell doesn't understand long paths anyway and always has a cwd which can be fetched by GetCurrentDirectory. The second case is starting cygcheck from a Cygwin shell. The Cygwin shell sets $PWD anyway, at least bash, tcsh and zsh. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
