Mail Archives: cygwin/2006/08/22/04:03:25
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/
- Raw text -