php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #26818 getopt() parses incorrectly
Submitted: 2004-01-06 14:52 UTC Modified: 2021-11-10 11:58 UTC
From: php at richardneill dot org Assigned: cmb (profile)
Status: Wont fix Package: PHP options/info functions
PHP Version: * OS: *
Private report: No CVE-ID: None
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: php at richardneill dot org
New email:
PHP Version: OS:

 

 [2004-01-06 14:52 UTC] php at richardneill dot org
Description:
------------
When parsing options, if the command line arguments are WRONG, php mangles them in such a way as to give an incorrect, but valid response.

Eg my program normally takes arguments:
      ./getopt.php -a -x foo -y bar
(ie. option a takes no value; options x,y take values)

Therefore, if I run it as
       ./getopt.php -a -x -y bar
this is clearly a mistake: I omitted the value for -x.

HOWEVER, php assumes that I wanted the value for -x to be '-y'

If this is "a feature, not a bug", it might be worth documentig it, or providing a switch to enable the behaviour I'd expect. Thank you.


Reproduce code:
---------------
#!/usr/bin/php
<?
$flags="ax:y:";
$options_array=getopt($flags);

echo "Here are the results of getopt:\n";

foreach ($options_array as $key => $value){
	echo "\tkey:\t $key\t value is:\t $value";
	if ($value===false){
		echo "\t[FALSE]";
	}
	echo "\n";
}
echo "\n";

#N.B. If options -x and -y each expect an argument, then one might expect
# 'getopt.php -x -y foo' to result in $key="x",$value=false; $key="y",$value="foo"
# BUT actually, the result is $key="x",$value="-y"; and foo is left over.


Expected result:
----------------
[rjn]$ ./getopt.php -a -x -y bar
Here are the results of getopt:
        key:     a       value is:              [FALSE]
        key:     x       value is:              [FALSE]      
        key:     y       value is:       bar

Actual result:
--------------
[rjn]$ ./getopt.php -a -x  -y bar
Here are the results of getopt:
        key:     a       value is:              [FALSE]
        key:     x       value is:       -y



Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-01-06 17:30 UTC] sniper@php.net
RTFM: "It does not matter if an argument has leading white space." (it means also: whitespace is omitted)

 [2004-01-06 17:53 UTC] php at richardneill dot org
I agree with you about the manual. BUT, nevertheless, this is not the behaviour that it should have.  Currently, it isn't consistent with the normal (GNU-like) command line behaviour.

If options -x and -y are supposed to take values, then if I enter the command: 
      ./getopt.php -a -x -y bar
it can mean only one of 2 things:

1)I, the user have made a mistake at the command line, and omitted the value for $x. The script should be able to test for this as an error. 

2)I meant to assign a null or false value to $x 
(possible, not likely)

It is *very* unlikely that I meant to assign the value '-y' to $x. (If I had meant to do this, I would have double quoted it).

Please can we at least have an option within getopts to parse options in a standard manner? I'd suggest doing the following:

----------------
If an option expects a value, read along the command line
until reaching the next '-' or the end of line. This value (or false if it is null) is placed in the options_array.
----------------

Thank you.

Richard
 [2004-01-06 18:58 UTC] sniper@php.net
The function uses the GNU getopt function, so the behaviour is exactly same. Moved the FRs.

 [2004-01-06 20:58 UTC] php at richardneill dot org
I do apologise - I thought that GNU's getopts was smarter than that! So, I now agree that PHP is doing the standards-compliant thing. I still think it would be useful if PHP had an option to parse options "my way" :-)

Thanks for your help.

Richard
 [2010-11-24 12:59 UTC] jani@php.net
-Package: Feature/Change Request +Package: *General Issues -Operating System: Linux (Mandrake) +Operating System: * -PHP Version: 4.3.4 +PHP Version: *
 [2010-11-24 12:59 UTC] jani@php.net
-Summary: getopt parses incorrectly +Summary: getopt() parses incorrectly
 [2018-02-11 17:51 UTC] cmb@php.net
-Package: *General Issues +Package: PHP options/info functions
 [2021-11-10 11:58 UTC] cmb@php.net
-Status: Open +Status: Wont fix -Assigned To: +Assigned To: cmb
 [2021-11-10 11:58 UTC] cmb@php.net
I don't think that this will ever be implemented, especially since
getopt() supports an $rest_index parameter for years, which can be
used to detect such issues.  Furthermore, there are more
comprehensive userland solutions available for argument parsing.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 21 17:01:58 2024 UTC