[PHP-DEV] Bug #14930 Updated: CLI header suppression problems

[edink]

ID: 14930
Updated by: edink
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Analyzed
Bug Type: Output Control
Operating System: linux 2.4.9
PHP Version: 4.1.1
New Comment:

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.

Previous Comments:


[2002-01-08 10:54:04] [EMAIL PROTECTED]

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


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


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






Edit this bug report at http://bugs.php.net/?id=14930&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14930 Updated: CLI header suppression problems

[elixer]

ID: 14930
Updated by: elixer
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: Output Control
Operating System: linux 2.4.9
PHP Version: 4.1.1
New Comment:

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


Previous Comments:


[2002-01-08 19:29:05] [EMAIL PROTECTED]

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-08 10:54:04] [EMAIL PROTECTED]

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


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


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






Edit this bug report at http://bugs.php.net/?id=14930&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14930 Updated: CLI header suppression problems

[edink]

ID: 14930
Updated by: edink
Reported By: [EMAIL PROTECTED]
Old Status: Analyzed
Status: Closed
Bug Type: Output Control
Operating System: linux 2.4.9
PHP Version: 4.1.1
New Comment:

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



Previous Comments:


[2002-01-10 16:32:04] [EMAIL PROTECTED]

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-08 19:29:05] [EMAIL PROTECTED]

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-08 10:54:04] [EMAIL PROTECTED]

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


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


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






Edit this bug report at http://bugs.php.net/?id=14930&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]