> Niah? I don't understand. Are you telling us that your host does not
> honor PATH assignments?
Hmm - right - I think I was seeing this wrong...
> This is not good, as we don't mean to pass the new PATH to conftest,
> rather we want to have the shell change its own PATH, and *then* to
> look for conftest in it.
Come to think of it, I don't even remember why I changed it in the
first place. I _think_ it failed to detect ';' as pathsep on my system,
but I can't seem to reproduce that. Afterwards, it *looked* right, so
I didn't bother double-checking it DTRT.
Note that the ';' still isn't needed:
PATH="foo:bar" conftest
behaves exactly like
PATH="foo:bar"; conftest
except that the former does not affect PATH after the command is run.
We probably don't care for the purpose of our test, as the command
is run in a subshell. However, the first version might still be safer,
as the use of a subshell is probably an implementation detail of
AC_RUN_LOG. Should that macro ever be changed to use a mechanism other
than a subshell (probably unlikely, but you never know), the PATH
assignment would affect the entire configure script (I think).
> Could you please try to explore this into the details? I suppose you
> are referring to Bash under DJGPP, right?
Yep - that's what I run for now.
> In particular, I'm just understanding that we may have a problem if
> `pwd` returns something with : in it, we might run into false
> positives in some cases. This is just my imagination as I don't run
> this system, but suppose you have pwd = c:/my/autoconf-dir.
>
> Then you end up with PATH=.;c:/my/autoconf-dir. Then *if* splitting
> is performed on `:', you get `.;c' (fails), and then
> `/my/autoconf-dir'. I have no idea whether on such platform
> `/my/autoconf-dir' works, but I wouldn't surprised. It would explain
> what you observed.
'/' or '\' without a drivespec refers to the current drive, so with `pwd`,
stripping the drivespec still results in the same location (as long as
you stay on the current drive). So your suspicion is well-founded.
But if the path seperator is forced to be ':' on DJGPP, pwd won't return
a path with a drivespec, so I don't think it's a real issue here.
Example:
e:\Tmp\Source\autoconf-cvs>bash --norc
bash-2.04$ pwd
e:/Tmp/Source/autoconf-cvs
bash-2.04$ PATH_SEPARATOR=':'; pwd
/dev/e/Tmp/Source/autoconf-cvs
bash-2.04$ PATH_SEPARATOR=';'; pwd
e:/Tmp/Source/autoconf-cvs
bash-2.04$ ^D
> Therefore I tend to think I've been stupid choosing .;`pwd`. Rather,
> sane thinking would have suggested `.;.'. Could you try to see if I
> make sense, and if it fixes the issue?
Definitely makes sense. There's apparently no issue to fix (for DJGPP at
least), but it would be safer to use '.;.' I guess - provided that doesn't
break on any Unix platforms; I don't want another "test -x" on my
conscience :-)
