|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #18343 [RH Bug 68798] php command shell -c option parser and doco inaccurate
Submitted: 2002-07-14 21:07 UTC Modified: 2002-07-15 21:55 UTC
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: herrold at owlriver dot com Assigned:
Status: Not a bug Package: PHP options/info functions
PHP Version: 4.2.1 (and 4.1.2) OS: Red Hat Linux 7.3, and Rawhide
Private report: No CVE-ID: None
 [2002-07-14 21:07 UTC] herrold at owlriver dot com
I have 150 material lines of analysis of a doco bug in the php command shell option parser, and related doco at:

Executive Summary -- the PHP.NET web doco is inaccurate, and the option parser of the -c option needs to so a trim() on the option text before applying it.

Failure to do so causes the load of the php.ini options to be skipped in the command line mode.  This in turn causes subtle and hard to diagnose errors.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2002-07-15 03:53 UTC]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.

 [2002-07-15 17:01 UTC] herrold at owlriver dot com
If you cannot be bothered to click a link to see the details behind the Executive Summary, and your 'sniper' function is so hot to close a bug, I guess I wonder if you really want to fix the bug, or close the bug report.

Your close itself is Bogus -- the cited URL does NOT begin suggest that you are unwilling to read reports with detail, summarized here.  Indeed one strength of a web tracker is the ability to see the error in context.

Since you cannot be bothers, here it is in summary form:

1.  The option description for the -c option at:

suggest that the interperter permits a space between the -c and the arguemnt -- It does NOT and the presence of such a space causes subtle errors (vis., it does not stat the file, and skips the -c option calue directory or file).


2.  A trim() in the option parser leg on the object for the -c path will solve the problem.


00 -- specific enough?  

-- Russ herrold
 [2002-07-15 17:33 UTC]
No still not enough info. Are you talking about shebang line for your command line scripts?


or command line like

php -c ...

 [2002-07-15 17:41 UTC] herrold at owlriver dot com
The strace allowed me to see the bug ---

This fails:

 [herrold@server3 herrold]$ head -50 ./birddaemon.php
 #!/usr/bin/php   -c /etc/php.ini
 //      test shim to show bug
 $db_server = "";
 $db_user   = "root";
 $db_passwd = "RedRedRobin";
 $db_name   = "birds";
 print "asdf";
 $link = mysql_connect($db_server, $db_user, $db_passwd)
         or die("Could not connect");
 $isdb = mysql_select_db($db_name)
         or die("Could not get database");
 $query = "update sightingstate set active = 'yes' where active = 'NULL";
 $result = mysql_query($query);
 exit ;


This works:

 [herrold@server3 herrold]$ head -50 ./birddaemon.php
 #!/usr/bin/php   -c/etc/

At the end of the Red hat bugzilla initially quoted:

 Additional comment by
                                                                                    2002-07-14 15:08:09


 bash-2.05a$ strace ./birddaemon.php 2>&1 | grep ini
 open(" /etc/php.ini/php.ini", O_RDONLY) = -1 ENOENT (No such file or directory)
 read(3, "#!/usr/bin/php   -c /etc/php.ini"..., 4096) = 492


 php man page says:

 bash-2.05a$ man php
 No manual entry for php

 =============================== says:

  -c <path>|<file> Look for php.ini file in this directory

 ahhh .... directory ...

 bash-2.05a$ joe ./birddaemon.php
 Processing '/etc/joe/joerc'...done
 Processing '/etc/joe/joerc'...done

 File ./birddaemon.php not changed so no update needed.
 bash-2.05a$ ./birddaemon.php
 X-Powered-By: PHP/4.2.1
 Content-type: text/html

 asdf<br />
 <b>Fatal error</b>:  Call to undefined function:  mysql_connect() in
 <b>/home/herrold/birddaemon.php</b> on line <b>13</b><br />
 bash-2.05a$ strace ./birddaemon.php 2>&1 | grep ini
 open(" /etc//php.ini", O_RDONLY)        = -1 ENOENT (No such file or directory)

 bash-2.05a$ strace ./birddaemon.php 2>&1 | grep ini
 open(" /etc/php.ini", O_RDONLY)         = -1 ENOENT (No such file or directory)
 bash-2.05a$ ls -al  /etc/php.ini
 -rw-r--r--    1 root     root        28245 Jul 14 14:48 /etc/php.ini

 WTF ... it is not finding a file with a space becore the parsed option ...

 bash-2.05a$ strace ./birddaemon.php 2>&1 | grep ini
 open("/etc/php.ini", O_RDONLY)          = 3
 lstat64("/etc/php.ini", {st_mode=S_IFREG|0644, st_size=28245, ...}) = 0

 It found the file ... nasty ; d*mn HTML documentation -- two days
 of my life wasted ...


 try against earlier version:

 [herrold@server3 herrold]$ ./birddaemon.php
 X-Powered-By: PHP/4.1.2
 Content-type: text/html

 asdf[herrold@server3 herrold]$


 So it is REALLY a bad docs bug for MY form of invocation ...


 Notwithstanding, can a trim() please be applied to get rid of improper leading
 spaces in the option parser code for the command mode handler?

 -- Russ Herrold

 Additional comment by
                                                                                    2002-07-14 15:29:39

 old subject: php command shell module inclusion through php.ini broken

 New subject: php command shell -c option parser and doco inaccurate
 [2002-07-15 17:56 UTC]
This is not a PHP bug. The problem is that most Unix kernels, including Linux have very limited shebang line processesing capabilities.

Most standard Unix implemetations have limit of only 1 argument of 32 characters maximum.


#!/usr/bin/php   -c /etc/php.ini

cannot work on Linux.
 [2002-07-15 20:15 UTC] herrold at owlriver dot com
I am familiar with the option line parsing capabilities of the Linux comand shell I am using, and there is not a  relevant limit here.

I start from the point htat it DOES WORK, once the space is gone.  

This implies that IS a PHP bug -- either in the doco having the space in the webified MAN pages, or in the failure to ltrim() a leading space off  ap_php_optarg in sapi/cgi/getopt.c

which sapi/cgi/getopt.c only handles space-separated options of type[abo] at:  
   while ((c = ap_php_getopt(argc, argv, "abo:")) != EOF)

and by implication (through their omission), requires that all other options abut the -[^abo:] option without an intervening space, relying on the line:
   ap_php_optarg = &argv[ap_php_optind][2];
line (or the one two lines above it for a '--' type option)


The fix seems to be to correct the doco if you are uninterested in adding -c as a covered space-supported option in the getopt.c [abo:] list, or do the ltrim() ... 

Certainly this (mis)behaviour (manpage non-conformant to practice in Linux (and indeed, you will find, generally on a POSIX compliant *nix)) is a non-trivial matter.

I understand you are lead on this: sapi/cli/php_cli.c -- but is seems wrong, and that the limitation which you assumed does not exist in light of the fact that it DOES WORK when I omit the indicated space.

This is causing problems for several people -- see the Red Hat bugzilla item I initially posted (for I worked all the realted tickets in hunting this down), and not all can strace to find their issue ...

My $0.02
 [2002-07-15 20:49 UTC]
-c in php 4.2.1 expects a _PATH_ to where php.ini is..
This is fixed in CVS, so try that first.

 [2002-07-15 20:50 UTC]
And I'm not a function, thankyouverymuch..

 [2002-07-15 21:55 UTC] herrold at owlriver dot com
Cue Patrick McGoohan in _The Prisoner_ -- "I am NOT a number ..."

Thanks for your attention ...
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Fri Jan 21 21:03:37 2022 UTC