This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: dealing with unset PATH


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]