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 Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
9 + 10 = ?
Subscribe to this entry?

 
 [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

Add a Patch

Pull Requests

Add a Pull Request

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-2024 The PHP Group
All rights reserved. 		Last updated: Thu Apr 18 06:01:28 2024 UTC