When invoking PHP from the command line, it accepts a
file name as argument, and processes the contents of this
file. When invoked from a CGI, the behaviour is different,
and it doesn't accept command line arguments. So far, so
good. However, when invoked from inside a CGI script, or
similar circumstances, e.g.

    #! /bin/sh
    echo "X-My-Header: testing"
    echo "Content-type: text/plain"
    /usr/local/bin/php /my/script/file.php | tail +3

PHP incorrectly assumes it's being invoked as a CGI script
interpreter, and ignores the command line argument, giving
the completely misleading error message "No input file
specified.".

At the very least, this is a documentation problem, but it
would be rather desirable if PHP could make better guesses
as to whether it's being invoked as a real CGI or not. The
current algorithm (in main() in sapi/cgi/cgi_main.c) bases
its guess on whether any of the environment variables
SERVER_SOFTWARE, SERVER_NAME, GATEWAY_INTERFACE and
REQUEST_METHOD are defined. It's possible to circumvent
the problem by undefining these variables before invoking
PHP, but that obviously won't work if one wants to use the
value of any of those variables in the script.

If there is no easy way of improving the guessing strategy,
one solution would be to follow the current guess by a test
for an extra environment variable PHP_NO_CGI_PLEASE or
something like that, and behave in the non-CGI way if it
is set.