Bug in #! processing - "pear broken on current"

[Garance A Drosehn]

[moved over from the thread:
        Re: cvs commit: src/sys/kern imgact_shell.c
on the cvs-src mailing list...]

At 11:03 AM -0500 6/9/05, Matthew D. Fuller wrote:
>On Thu, Jun 09, 2005 at 12:00:17PM -0400 I heard the voice of
>Garance A Drosehn, and lo! it spake thus:
>  > Matthew wrote:
>  > ]   See also the "pear broken on current" thread on -current
>  > ]   and -ports around last weekend.  Of course, I don't know
>  > ]   if pear is wrong in what it's trying to do, but the change
>  > ]   does appear to throw it off.
>  >
>  > I'm also willing to write some more changes to sh/options.c, if
>  > that is the best place to fix the problems that these ports are
>  > running into.
>
>Well, I dunno what part of it is giving troubles (and I haven't seen
>it myself, since I'm still on RELENG_5 for the moment; just keeping my
>eyes open).  It doesn't seem like a terribly esoteric line though:
>
>#!/usr/local/bin/php -n -q -dsafe_mode=0 -doutput_buffering=1

It is very likely that the problem which is being seen with this
script is due to the change in parsing I committed on May 28th.
Before the change, php would have been started up with:

            [0] ->  /usr/local/bin/php
            [1] ->  -n
            [2] ->  -q
            [3] ->  -dsafe_mode=0
            [4] ->  -doutput_buffering=1
            [5] ->  /usr/local/bin/name-of-script
         [6...] ->  parameters specified by user

and now php is being started with:

            [0] ->  /usr/local/bin/php
            [1] ->  -n -q -dsafe_mode=0 -doutput_buffering=1
            [2] ->  /usr/local/bin/name-of-script
         [3...] ->  parameters specified by user

Assuming 'php' does not know what to do when all those options are
glommed together in a single argument, then the above script would
not work right on any other operating systems either.  The change
I made on the 28th gets FreeBSD to work more like other OS's when
it comes to parsing that #!-line in scripts.

Changes to /bin/sh would not fix this, because /bin/sh is not
involved in this situation.  But the change I'm thinking of for
/usr/bin/env could be used to fix this, once I write up that change...

-- 
Garance Alistair Drosehn     =      gad at gilead.netel.rpi.edu
Senior Systems Programmer               or   gad at FreeBSD.org
Rensselaer Polytechnic Institute;             Troy, NY;  USA