lkml.org 
[lkml]   [2002]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: #! incompatible -- binfmt_script.c broken?
From
Date
Matthias Andree <matthias.andree@gmx.de> 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, schwab@suse.de
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."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:31    [W:0.294 / U:0.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site