This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: dealing with unset PATH
On Oct 29 14:16, Earnie Boyd wrote:
> Quoting Corinna Vinschen <corinna-...>
> >On Oct 28 13:40, Earnie Boyd wrote:
> >>Quoting Eric Blake <ebb9-...>
Earnie, please http://cygwin.com./acronyms/#PCYMTNQREAIYR
> >>>env PATH=. foo
> >>>
> >>>expecting to find ./foo and nothing else. So a default fallback won't
> >>>necessarily solve everything. Thoughts?
> >>>
> >>Maybe use LIB_PATH or LD_LIBRARY_PATH to find the libraries but the
> >>foo program would need to set the dll path using these environments.
> >
> >That would only work for dlopen, but not when spawning the process since
> >that calls CreateProcess, which depends on the Windows DLL load order.
> >The Windows loader wouldn't even find cygwin1.dll given the above example.
> >
>
> Ugh, winders! How about appending the values of these environments
> to PATH prior to CreateProcess and resetting PATH afterward?
Sure, that would be possible. But it is still unexpected behaviour and
doesn't really solve the `env PATH=. foo' situation. If foo doesn't
need any non-standard DLLs, then this command should "just work" I guess,
so we need to add the Cygwin default DLL path /bin to $PATH before
calling CreateProcess. Using SetDllDirectory on post XP would be much
nicer, though, IMHO...
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat