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 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


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