Req #26818 [Opn->Wfx]: getopt() parses incorrectly
| From: | cmb@php.net | Date: | Wed, 10 Nov 2021 11:58:55 +0000 |
| Subject: | Req #26818 [Opn->Wfx]: getopt() parses incorrectly | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-237662@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=26818&edit=1
ID: 26818
Updated by: cmb@php.net
Reported by: php at richardneill dot org
Summary: getopt() parses incorrectly
-Status: Open
+Status: Wont fix
Type: Feature/Change Request
Package: PHP options/info functions
Operating System: *
PHP Version: *
-Assigned To:
+Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2004-01-06 20:58:30] 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
------------------------------------------------------------------------
[2004-01-06 18:58:52] sniper@php.net
The function uses the GNU getopt function, so the behaviour is exactly same. Moved the FRs.
------------------------------------------------------------------------
[2004-01-06 17:53:42] 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 17:30:17] sniper@php.net
RTFM: "It does not matter if an argument has leading white space." (it means also:
whitespace is omitted)
------------------------------------------------------------------------
[2004-01-06 14:52:41] 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
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=26818&edit=1