>> [...cross-build breaking...]
> OK, a Makefile tried to use the "mv" command, and got "./mv", which
> was a version that had just been corss-compiled for a different
> architecture.

Eeeeeexactly.

>> Yes, having . in the path is arguably a bad idea in general, and I
>> wouldn't be too surprised if a build refused to run under those
>> circumstances.  But this is definitely not a correct way for it to
>> fail, it seems to me.
> What would you like to happen?

Well, best would be to make it Just Work...but, as you note, that would
involve a lot of work and be at least somewhat fragile.

Next best, I think, would be for build.sh, or the Makefile machinery,
to notice the . in the path early on and bail out with an error message
that's descriptive of the problem to a naïve builder.  (If I weren't a
Unix expert who'd seen such things lots of times before, I would
probably have found that failure totally cryptic and baffling.)

> (I'd prefer to get ENOEXEC from the kernel, and to have the shell
> report that; I think it's a bug for shells to try executing binaries
> as if they were shell scripts.)

I daresay that's a holdover from the days before #! recognition in the
kernel.  I'm not sure whether I think it's something that should be
eliminated in general; at the moment I'm inclined to say it is, but I
haven't thought about it at length.

> 1) [...]
> 2) [...]
> 3) Change build.sh to remove "." from the PATH.

4) Change build.sh to error out with a *descriptive* message if . is
in the PATH.  Perhaps something like

case "$PATH"
	.:*|:*|*::*|*:.:*|*:|*:.)
		echo Please remove \".\" from \$PATH when running build.sh. 1>&2
		exit 1
		;;
esac

It's arguable whether the last two cases - . at the end of the path -
should be there or not.

I wonder if perhaps any non-absolute path in $PATH should produce
similar errors...I can just imagine the problems if, say, ../mv is in
$PATH somehow!

The major advantage of this is that it's easy to do, it prevents the
cryptic breakage, and it doesn't involve silently ignoring something
the user set because we think we know better.  (I'd argue the ". in
$PATH" (or perhaps "non-absolute path in $PATH") check should be
overridden, or at least downgraded to a warning, by -E.)

>> Worth a PR?
> If we decide on 1 or 3 or both, I am willing to do the work.  (I
> know, I still haven't come through on a different build.sh issue you
> raised about a year ago.)

Well, I'm hardly in a position to carp at you for that when I haven't
exactly been falling all over myself to fix it myself.  That's how
volunteer projects work, after all - them as does the work get to
decide what work gets done. :-)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B