bug-bash
[Top][All Lists]
Advanced

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

Re: binfmt_script and ^M


From: Richard B. Johnson
Subject: Re: binfmt_script and ^M
Date: Mon, 5 Mar 2001 21:18:23 -0500 (EST)

On Mon, 5 Mar 2001, Robert Read wrote:

> On Mon, Mar 05, 2001 at 07:58:52PM +0100, Pozsar Balazs wrote:
> > 
> > And what does POSIX say about "#!/bin/sh\r" ?
> > In other words: should the kernel look for the interpreter between the !
> > and the newline, or [the first space or newline] or the first whitespace?
> > 
> > IMHO, the first whitespace. Which means that "#!/bin/sh\r" should invoke
> > /bin/sh. (though it is junk).
> > 
> 
> The line terminator, '\n', is what terminates the interpreter.  White
> space (in this case, only ' ' and '\t') is used to seperate the
> arguments to the interpreter.  This allows scripts to pass args to
> intepreters, as in #!/usr/bin/per -w or #!/usr/bin/env perl -w
> 
> So is '\r' a line terminator? For Linux, no.  Should '\r' seperate
> arguments?  No, that would be very strange.
> 

For research, I suggest a look at getopt(3) or whatever it's called.
The command line args are seperated into chunks based upon what got
seperated into argv[1]....[n], delimited by (hold my breath) white-space.

Of course, it's not getopt(), but "makeopt()" that we are looking for.
...Whatever chopped up those command-line arguments in the first place.

If __that__ corresponds so POSIX rules, then whatever follows must
also comply.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.





reply via email to

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