Bug in #! processing - One More Time
David G. Lawrence
dg at dglawrence.com
Thu Feb 24 02:29:26 PST 2005
> 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, 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!.
David G. Lawrence
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.
More information about the freebsd-arch