Bug in #! processing - One More Time

[David G. Lawrence]

> The change committed back in 2000 made the comment: "This complies
> to POSIX 1003.2, in that Posix says the implementation is free to
> choose whatever it likes.".  I actually like the idea that FreeBSD
> splits up the arguments from the shebang-line, but that leaves us
> with the problem of figuring out shebang-options from user-specified
> options given on the command-line.
> 
> As I see it, we have the following choices to fix this:
> 
> 1) MFC the January 31st change to kern/imgact_shell.c to 5.3-stable,
>    as it is.  This means we haven't fixed the problem that people
>    complained about in 2002 and again in 2004.  And I still think
>    it is "not appropriate" for the execve() system to be deciding
>    what '#' means on that line.  The biggest advantage is that this
>    means 5.4-release will behave exactly the same as 3.5 through
>    5.3-release have behaved.
> 
> 2) Remove '#'-processing from kern/imgact_shell.c, and remove my
>    change to bin/sh/options.c (which doesn't work right once we
>    do that).  This breaks shell-scripts which use the feature as
>    documented by perl (and other scripting languages), and fixes
>    the problem people complained about in 2002/2004.
> 
> 3) Change kern/imgact_shell.c to process shebang options the same
>    way other (non-BSD?) operating systems do.  By that I mean:
>    send the entire string as arg[1], and let the scripting
>    language sort it out.  This is an incompatible change from
>    FreeBSD 5.3 to 5.4, but would put make us "more consistent"
>    with other operating systems.
> 
> 4) Provide some way for /bin/sh to find out where the shebang
>    options end, and the user-specified options begin.  This could
>    make everyone happy, but it's more work and right now (this
>    close to 5.4-release) that wouldn't make me particularly happy...

   Probably the best option is #3. That's actually how I wrote the code
originally, but then changed it to parse out the arguments individually
when I realized that any interpreter would have to be specially written
to do its own argument processing otherwise - and that didn't seem right.
I recall having a discussion with someone about it at the time, but it
was so long ago (12 years!) that I can't remember how it went.
   I doubt that any standard component of FreeBSD will be affected by
this, but of course that needs to be verified.
   Great job on the investigation, BTW. Well done!.

-DG

David G. Lawrence
President
Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500
TeraSolutions, Inc. - http://www.terasolutions.com - (888) 346 7175
The FreeBSD Project - http://www.freebsd.org
Pave the road of life with opportunities.