This is the mail archive of the
cygwin-patches
mailing list for the Cygwin project.
Re: [patch] cygcheck.cc update for cygpath()
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