program fails to find its DLL

[Eric Thomas]

I reply to myself because i'm not registred to the ML.

Thanks a lot for the feedback.

Yes indeed, you're absolutely right Igor.
And the case can easily be reproduced by running any w32 program and
watch its environnement's variables with a tool like process explorer
(sysinternals).
One can also have a similiar result while trying to convert an invalid
path with cygpath
cygpath -w /cygdrive/c/existing_regular_file/
and get an unknown error in return, whereas the following is ok
cygpath -w /cygdrive/c/nonexisting_file/

strace can greatly help here !

Unfortunately I've not been able to find out your patch that would
address that specific point.
Was it a part of a bigger patch that was maybe to obscure to me ?

2 questions left:
. is there any reason for stopping the win32 to posix conversion if one
of the path is realy considered as invalid ?
. should /cygdrive/c/existing_regular_file/ be considered as an invalid
path if /cygdrive/c/nonexisting_file/ is not ?

Regards,
Eric


Eric Thomas wrote:
> Hi all,
> 
> I've got an issue here with some command line programs, all from the 
> same editor.
> 
> Commands are issued from bash 3.0.16-14 / cygwin 1.5.18-1 on a
> computer running W2K SP4.
> Everything was ok until someone introduced an invalid path in the 
> default PATH that bash inherits from cmd.exe .
> Let's say that PATH is made of 3 parts:
> A : valid path
> B : invalid path ("invalid" means that it raise my issue)
> C : valid path
> 
> Since, those programs raise a pop-up to complain that some DLL is
> missing in "path displayed".
> But "path displayed" is incomplete. In fact "path displayed" is only the
> A part.
> The missing DLL belongs to one dir of the C part.
> So, this invalid value prevents the program to look further in the last
> part of PATH.
> 
> Well, one would think that the problem is only on the program's side
> (and maybe it is). But there are other arguments to look at too.
> 
> Only some kind of path format can raise the issue.
> Let's say that
> /cygdrive/c/a   is a directory
> /cygdrive/c/b   is a regular file
> /cygdrive/c/c   does not exist
> 
> Issue raised with
> /cygdrive/c/b/
> /cygdrive/c/b/anyfilename_or_dirname
> 
> It will also happen with a true invalid path like this one: 
> /cygdrive/sure_I_am_an_invalid_path
> 
> But the following won't:
> /cygdrive/c/a
> /cygdrive/c/b
> /cygdrive/c/c
> everything that doesn't start with /cygdrive
> 
> Facts:
> - I didn't managed to reproduce the problem when issuing the command
> directly from a cmd.exe, excepted by setting PATH to "" of course. But
> an invalid path placed in PATH does not hurt.
> - I didn't managed to reproduce the problem with any other program that
> would requiere some DLL (excel for instance)
> 
> So it makes me think that It could be related to cygwin in some way,
> even if it occurs only with those programs because they probably behave
> differently from other programs...
> 
> I've done a fresh installation of cygwin (bash 3.1-6 / cygwin 1.5.21-2)
> on another computer.
> Some changes with this one:
> - no more pop-up, but the program still fails to run due to its missing
> DLL
> - now "/regular_file/" will also raise the problem (at least this point
> is consistent now)
> 
> Could those programs explicitly load some DLL after they start-up ? and
> rely on PATH to do it on purpuse ?
> If so, they manage to deal with invalid path when running from cmd.exe.
> Something must be different when run from bash.
> 
> Just in case you wonder: same behaviour with ash.
> 
> Any comment welcome and appreciated
> 
> Regards,
> Eric
> 
> 


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/