#43313 [Com]: getopt() doesn't handle unknown parameters
ID: 43313
Comment by: j dot boggiano at seld dot be
Reported By: RQuadling at GMail dot com
Status: To be documented
Bug Type: Documentation problem
Operating System: *
PHP Version: 5CVS-2008-11-11
New Comment:
I fixed this as far as the doc is concerned, but I still agree that
having a third "array &$rest" argument would be useful. I'll let others
decide whether this ought to be closed or not.
Previous Comments:
------------------------------------------------------------------------
[2009-12-16 22:40:17] svn@php.net
Automatic comment from SVN on behalf of seld
Revision: http://svn.php.net/viewvc/?view=revision&revision=292224
Log: Adds a note about unknown parameters ending getopt() parsing,
fixes bug #43313
------------------------------------------------------------------------
[2009-04-01 13:44:15] rquadling@php.net
The main problem is that you don't get any feedback to say that
userland getopt() HAS encountered an unknown parameter.
If you have supplied a set of parameters to getopt() and one is
mistyped at the command line, you only get the valid ones to the left
of the mistyped one.
I'm happy that that array returned should only contain valid
parameters.
What I would like to have is the broken parameter and any remaining
parameters to be returned as an additional array.
Ideally, skipping broken parameters, but I think that would actually
cause more headaches.
Having to process $argc manually to determine if all the supplied
parameters have been parsed appropriately completely negates the use
of getopt().
------------------------------------------------------------------------
[2009-04-01 11:34:32] jani@php.net
Let's stick with the POSIX way. And document it as is.
------------------------------------------------------------------------
[2009-03-31 15:41:12] hradtke@php.net
I have a patch for this bug. Actually, I am not sure this is even a
bug. POSIX says that getopt should break on the first non-option.
Also, the php_getopt() function needs to break on the first non-option.
Consider the following: php -n test.php -a 1 -b 2
That being said, the getopt() userspace function can be made to work
both ways. I have a patch to allow php_getopt() to ignore unknown
parameters.
One question: Should getopt() have its prototype changed to: array
getopt ( string $options [, array $longopts, bool posix ] ) ? It would
default to true if not specified (for BC). Setting it to false would
make it ignore non-options.
------------------------------------------------------------------------
[2007-11-16 15:18:00] RQuadling at GMail dot com
Description:
------------
getopt() stops processing at the first unknown parameter.
I'm not sure if this is ...
a php bug - getopt should return them as is
or ...
a doc bug - getopt() will cease operation at the first hurdle.
My preference is to return them as is. Maybe a third param to the
function to collect unknown parameters. This would provide backward
compatibility if the function didn't die when an unknown parameter was
reached.
The code is a simple test to examine the command line.
Run this with this parameter
-a 1
and then with these
broken -a 1
Reproduce code:
---------------
<?php
var_dump($_SERVER['argv'], getopt('a:b', array('apple=',
'bag')));
?>
Expected result:
----------------
array(3) {
[0]=>
string(17) "C:\phpargtest.php"
[1]=>
string(2) "-a"
[2]=>
string(1) "1"
}
array(1) {
["a"]=>
string(1) "1"
}
array(4) {
[0]=>
string(17) "C:\phpargtest.php"
[1]=>
string(6) "broken"
[2]=>
string(2) "-a"
[3]=>
string(1) "1"
}
array(1) {
[0]=>
string(6) "broken"
["a"]=>
string(1) "1"
}
Actual result:
--------------
array(3) {
[0]=>
string(17) "C:\phpargtest.php"
[1]=>
string(2) "-a"
[2]=>
string(1) "1"
}
array(1) {
["a"]=>
string(1) "1"
}
array(4) {
[0]=>
string(17) "C:\phpargtest.php"
[1]=>
string(6) "broken"
[2]=>
string(2) "-a"
[3]=>
string(1) "1"
}
array(0) {
}
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=43313&edit=1
Thread (5 messages)