bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: binfmt_script and ^M


From: Andreas Schwab
Subject: Re: binfmt_script and ^M
Date: 05 Mar 2001 18:12:05 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.99

Paul Flinders <P.Flinders@ftel.co.uk> writes:

|> Jeff Mcadams wrote:
|> 
|> > Also sprach Rik van Riel
|> > >On Mon, 5 Mar 2001, John Kodis wrote:
|> > >> On Mon, Mar 05, 2001 at 08:40:22AM -0500, Richard B. Johnson wrote:
|> > >> > Somebody must have missed the boat entirely. Unix does not, never
|> > >> > has, and never will end a text line with '\r'.
|> >
|> > >> Unix does not, never has, and never will end a text line with ' ' (a
|> > >> space character) or with \t (a tab character).  Yet if I begin a
|> > >> shell script with '#!/bin/sh ' or '#!/bin/sh\t', the training white
|> > >> space is striped and /bin/sh gets exec'd.  Since \r has no special
|> > >> significance to Unix, I'd expect it to be treated the same as any
|> > >> other whitespace character -- it should be striped, and /bin/sh
|> > >> should get exec'd.
|> >
|> > >Makes sense, IMHO...
|> >
|> > That only makes sense if:
|> > #!/bin/shasdf\n
|> > would also exec /bin/sh.
|> 
|> POSIX disagrees with you (accd to the manual page)
|> 
|> $ man isspace

This has no significance here.  The right thing to look at is $IFS, which
does not contain \r by default.  The shell only splits words by "IFS
whitespace", and the kernel should be consistent with it:

$ echo -e 'ls foo\r' | sh
ls: foo
: No such file or directory

Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
Andreas.Schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5



reply via email to

[Prev in Thread] Current Thread [Next in Thread]