Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:7595
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Wed, 4 Feb 2004 15:26:41 -0800 (PST)
To: internals@lists.php.net
Message-ID: <Pine.LNX.4.58.0402041517210.1449@thinkpad.lerdorf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: php-cgi command line switch memory check
From: rasmus@lerdorf.com (Rasmus Lerdorf)

In our SAPI cgi we have a check along these lines:

    if (getenv("SERVER_SOFTWARE")
        || getenv("SERVER_NAME")
        || getenv("GATEWAY_INTERFACE")
        || getenv("REQUEST_METHOD")) {
        cgi = 1;
    }

    if(!cgi) getopt(...)

As in, we do not parse command line args for the cgi binary if we are 
running in a web context.  At the same time our regression testing system 
tries to use the cgi binary and it sets these variables in order to 
properly test GET/POST requests.  From the regression testing system we 
use -d extensively to override ini settings to make sure our test 
environment is sane.  Of course these two ideas conflict, so currently our 
regression testing is somewhat broken.  We haven't noticed because we 
don't have many tests that have GET/POST data and we rarely build the cgi 
binary.

The point of the question here is if anybody remembers why we decided not 
to parse command line args for the cgi version?  I could easily see it 
being useful to be able to write a cgi script like:

  #!/usr/local/bin/php-cgi -d include_path=/path
  <?php
      ...
  ?>

and have it work both from the command line and from a web context.

As far as I can tell this wouldn't conflict with anything, but somebody at 
some point must have had a reason for disallowing this.

-Rasmus