php cgi/cli request variables problem

[soapsud]

okay i'm going crazy here. i'm trying to get a simple $_POST variable to show up and i'm running into piles of problems.

in environment 1, only bits of data are showing up,
in environment 2 and 3, no post/get data shows up at all:

environment 1: php 4.2.3 (CGI) / redhat linux 7.3 w/ suexec
environment 2: php 4.3.2 (CLI) / mac os x.3.3 no suexec
environment 3: php 4.3.2 (CLI) / redhat linux 7.3 w/ suexec

here's the basic code:

#!/usr/bin/php
<?

echo "Content-Type: text/html\n\n";

print_r($_REQUEST);
print $_POST['head']."<br />";

?>
<form action="test.cgi" method="post">
<input type="text" name="head" />
<input type="text" name="data[option]" />
<input type="text" name="data[value]" />
<input type="submit" value="Go!" />
</form>

in environment one, there is no echo content type (no required). however, if i enter test@test.com for "data['value']" it comes back with "@test.com". seems to arbitrarily butcher various inputs as well

in environment two and three, nothing comes back (no get or post)

any ideas? i'm about to age 50 years and lose all my hair... found the following:

http://66.102.7.104/search?q=cache:P...hl=en&ie=UTF-8

which sort of covers my problem, but not really (they were able to get $_GET, etc...)

if anyone can replicate this on a CGI/CLI machine and let mek now if i'm crazy or not, i would appreciate it very much...

[Phil.Roberts]

Firstly, PHP is not perl: it doesn't require you to explicitly send the content-type header.
Secondly, unless the server is very badly configured you shouldn't require the shebang line either.
Thirdly, PHP will only execute scripts with the extension "php" unless the server is explicitly told to treat other files as PHP.

[sweatje]

Digs up some old code...

/**
 *      will inject unix command line arguments into the $_REQUEST superglobal
 *
 *      assumes the variables are in the form xxx=yyy
 *      any argument without an = will be ignored
 *      @param  boolean $pbGet  optional, suppress injection into $_GET as well
 *      @return void
 */
function simulate_request_from_argv($pbGet=true)
{
        if (array_key_exists('_', $_SERVER)) { //indicate run in unix command line mode
                // you might want to explicitly check the sapi instead
                // insert script name
                $a_argv = $_SERVER['argv'];
                if (!array_key_exists('SCRIPT_FILENAME', $_SERVER)) {
                        $_SERVER['SCRIPT_FILENAME'] = $a_argv[0];
                }
                array_shift($a_argv);
                // insert arguments into superglobals
                foreach($a_argv as $s_arg) {
                        if (preg_match('/\w+=\w*/', $s_arg)) {
                                list($s_key, $s_val) = explode('=',$s_arg);
                                if ($pbGet) {
                                        $_GET[$s_key] = $s_val;
                                }
                                $_REQUEST[$s_key] = $s_val;
                        }
                }
        }
} 

[soapsud]

hey thanks for the suggestions thus far, i might need to clarify. i'm running it as a cgi (ie, like perl or python without mod_perl/python) and due to the setup it will need to be with the shebang, etc...

the current deployment environment is php 4.2.3 (cgi) whereas it will be upgraded shortly to php 4.3.4 (cli).

as far as i'm aware, the CLI version does require the echo content-type (would be glad to be proved wrong on this ).

based on that, $_GET and $_POST should be setup as normal should they not?

this is essentially a basic pass variables from one page in the cgi-bin to another but using php, and i'm baffled as to why it's giving me so many problems.

[Phil.Roberts]

The CLI binary isn't supposed to be used for web CGI.

And PHP can be configured to run in CGI mode without the need for the shebang line. The shebang should only ever be required for shell scripts.

[soapsud]

hey cool, i semi solved my issue. as noted, cli / cgi are quite different thing, for some reason my little brain couldn't grasp that concept. i'm just going to use a stripped down php binary for this project, it'll work like a charm, and won't need to worry about the main php binary being upgraded.