On Mon, 19 Mar 2007, der Mouse wrote:
> I just tried to cross-build hpcmips on i386.  For reasons not really
> relevant here, I happened to have . early in my PATH when I did this.
> The build broke

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.

> mv: 1: Syntax error: "(" unexpected
> [cascade of failures up to the top level, snipped]

> 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?  (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 see several possible fixces for different parts of the problem:

1) Track down why the binary was executed as if it was a shell script,
   and make whatever changes are necessary to get the build to fail with
   an error along the lines of "mv is not executable".

2) Change all Makefiles to use ${MV} instead of just mv.  Similarly with
   all other trivial commands.  This would be a lot of work, but it's
   probably a good idea.  However, it would not be sufficient, because
   if we had MV=mv in bsd.sys.mk, we would still have the same problem.

3) Change build.sh to remove "." from the PATH.

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

--apb (Alan Barrett)