This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: dealing with unset PATH
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-developers at cygwin dot com
- Date: Wed, 28 Oct 2009 11:22:10 +0100
- Subject: Re: dealing with unset PATH
- References: <4AE7941D.5050308@byu.net>
- Reply-to: cygwin-developers at cygwin dot com
On Oct 27 18:45, Eric Blake wrote:
> POSIX allows an implementation to define its own behavior when PATH is
> unset. I recently spent some time cleaning up several tests in the
> coreutils testsuite that failed because they overly restricted PATH.
> Right now, any cygwin app just fails to run, because an unset PATH means
> windows can't find /bin to locate cygwin1.dll. It would make a bit more
> sense if we had a default fallback path, which included /bin, which we
> used if we ever detect PATH being unset or empty. But that still won't
> help apps that do:
>
> env PATH=. foo
>
> expecting to find ./foo and nothing else. So a default fallback won't
> necessarily solve everything. Thoughts?
The easiest solution: "Don't do that".
Beginning with Windows XP SP1 and Windows 2003 we could simply use the
SetDllDirectory(*) function to replace the current working directory
with the /bin directory in the DLL search path. But that won't help for
pre XP, unfortunately. Only adding /bin to $PATH explicitely before
calling CreateProcess would help.
Corinna
(*) http://msdn.microsoft.com/en-us/library/ms686203%28VS.85%29.aspx
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat