php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #14930 CLI header suppression problems
Submitted: 2002-01-08 10:54 UTC Modified: 2002-01-11 22:51 UTC
Votes:1
Avg. Score:3.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: dark_panda at hotmail dot com Assigned:
Status: Closed Package: Output Control
PHP Version: 4.1.1 OS: linux 2.4.9
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: dark_panda at hotmail dot com
New email:
PHP Version: OS:

 

 [2002-01-08 10:54 UTC] dark_panda at hotmail dot com 
I don't know if this should go under output control but 
anyways...

The command line executable is having problems suppressing 
the headers using the -q option in combination with the -c 
option if you're running the script as, well, a script. For 
instance, take this small script:

#!/usr/local/bin/php -c /path/to/ini/file -q
<?php
echo "hello world";
?>

The headers won't be suppressed if you try running the 
script with a command like

$ ./smallscript.php
X-Powered-By: PHP/4.1.1
Content-type: text/html

hello world

However, running the script like so:

$ php -q -c /path/to/ini/file smallscript.php
hello world

produces the expected result, without the headers.

Also, this may or may not be an associated bug, but if you 
put the -q option before the -c option in the command line 
for a script, i.e.

#!/usr/local/bin/php -q -c /some/path
<?php 
...
?>

An error is produced, which looks something like this:

Error in argument 1, char 3: option not found
Error in argument 1, char 4: option not found -
Error in argument 1, char 3: option not found

along with the output from "php -h". This doesn't happen 
when you execute directly from the command line, only when 
the command line is in the script file itself.

J

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-01-08 19:29 UTC] edink@php.net 
I was able to reproduce this. However it does not appear
to be a php bug. Most likely a glibc bug.

If I put this line on top of my script:
#!/usr/bin/php -q -c /path/to/ini/file -C

the following values get passed to
php's main() function.

argc=3
argv[0]: php
argv[1]: -q -c /path/to/ini/file -C
argv[2]: ./test (which is the name of the script)

With parameters passed like that, php has
no chance of passing them correctly.

FreeBSD systems appear to be free of this problem.
 [2002-01-10 16:32 UTC] elixer@php.net 
I don't think this is a glibc issue.  Its (AFAIK) the kernel's responsibility to set this stuff up.  Take a look at load_script() in fs/binfmt_script.c of the linux source.  It seems that only one argument is allowed, and everything after the interpreter (/usr/local/bin/php) up until the EOL is considered one argument.  I'm sure there is a reason for implementing it this way, I just don't know what it is.

Sean
 [2002-01-11 22:51 UTC] edink@php.net 
After some research on the subject I found out
that there is no good and
portable way of solving this. Some unix systems
simply allow only one argument in the #! line. One
of those systems is Linux. Some others limit the
line length to 32 characters.

For a good description of these limitations see
http://groups.google.com/groups?q=shell+limit+one+argument&hl=en&selm=qij4tk2zgp9.fsf%40lambda.ai.mit.edu&rnum=7

Workarounds:
* You can put all the options that do not require
  parameters as one, for example -qC
* Use PHPRC env variable to set the php.ini path
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Wed May 07 11:01:29 2025 UTC