#! incompatible -- binfmt_script.c broken?

Compatibility with _what_? Linux works exactly the same as Tru64 Unix for example - it supplies everything after the program to execute as the first argument. Are you going to make the kernel honor the setting of the IFS environment variable? Should it split only on space? What about tab? Or $LANG (maybe space is different in different character sets)?

The difference is that Tru64's /bin/sh (and /usr/bin/posix/sh and /usr/bin/ksh) stops processing the argument and continues without error after it hits a (single or double) dash and a space, while bash (and pdksh and ash and zsh) don't handle that.

Try the following under your shell. On Solaris and Tru64 sh and ksh, it is handled with no error. Under bash (on Linux, Solaris, and Tru64), it returns an error:

$ set "-- xyzzy"
$ echo $?

According to SUSv3, bash is not compliant, because for set, under the section "CONSEQUENCES OF ERRORS" is listed "None." and the "EXIT STATUS" is "Zero."

Fix the shell(s).

Chris Adams <[email protected]>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

That's correct. But how do you derive that the sh command line must behave the same? The sh command is not the sh special built-in.

However, it would be reasonable if a /bin/sh set $1 to be "-- xyzzy" if a file "foo" with

#! /bin/sh -- xyzzy

was executed (as path = [/bin/sh] argv = [./foo] [-- xyzzy]); and although I didn't check, I wonder how shells without the "--" long options parse that line.

Matthias Andree <[email protected]> writes:

|> On Wed, 04 Dec 2002, Chris Adams wrote:
|> 
|> > Try the following under your shell.  On Solaris and Tru64 sh and ksh, it
|> > is handled with no error.  Under bash (on Linux, Solaris, and Tru64), it
|> > returns an error:
|> > 
|> > $ set "-- xyzzy"
|> > $ echo $?
|> > 
|> > According to SUSv3, bash is not compliant, because for set, under the
|> > section "CONSEQUENCES OF ERRORS" is listed "None." and the "EXIT STATUS"
|> > is "Zero."
|> 
|> > Fix the shell(s).
|> 
|> That's correct. But how do you derive that the sh command line must
|> behave the same? The sh command is not the sh special built-in.
|> 
|> However, it would be reasonable if a /bin/sh set $1 to be "-- xyzzy" if
|> a file "foo" with
|> 
|> #! /bin/sh -- xyzzy
|> 
|> was executed (as path = [/bin/sh] argv = [./foo] [-- xyzzy]);
|> and although I didn't check, I wonder how shells without the "--" long
|> options parse that line.

POSIX is quite clear about that: only "--" as a single argument is defined, other uses are undefined.

Andreas.

Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."