As no doubt most everyone on this list knows, most Unix shells will try
to run a "program" as a script if the kernel refuses to exec() it as a
binary.

This generally causes nasty things like the following to appear on one's
terminal:

====================
۠
: not found
/usr/local/bin/base64-decode: è¶Pè YXQÍ€rÿá¸ÿÿÿÿÿá/usr/libexec/ld.soNo: not found
d.so: not found
Failure: not found
Bad: not found
Cannot: not found
crt0:: not found
ld.so: not found
U‰åƒì: not found
ƒÄƒøÿuj: not found
j: not found
/usr/local/bin/base64-decode: 17: Syntax error: "(" unexpected
====================

In this particular case I'd accidentally installed binaries for
NetBSD-i386 on a sparc.

I've always thought that the shell(s) should be a little bit smarter and
refuse to even try to run things that "were obviously binaries".  I know
that lots of non-Unix fans find this quirk of Unix to be rather annoying
(though of course most of them think the filename extension should
define what files are programs and how a program is run ;-).

Now that I've got a wider and growing collection of machines of
different architecture on my local network, most running NetBSD, I've
been encountering this problem even more often because I do have lots of
legitimate binaries accessible to various machines but which were built
on foreign architectures.  I've been using the "noexec" mount flag a lot
more, but this doesn't work for development directories where I'm
intending to build and test stuff, especially for software that doesn't
use BSDOBJDIR or its logical equivalent.

What I'm thinking is that maybe the shell(s) could at least try to
recognize binaries from other NetBSD architectures and give a more
meaningful error message.  I don't know if it would be a good idea to
try and make the NetBSD shell(s) know about every type of binary, but at
least for the NetBSD varieties we've got fairly intimate knowledge of
what files cannot possibly be shell scripts of any kind and which the
shell(s) can politely refuse to be run.  Of course a file would only
ever need to be tested in this way if the kernel exec() of it had
already failed.

So far this is only an idea -- though I'll implement some code and try
it out when I get the time.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>