Description: ------------ It's common for apps that have a usage of: Usage: myapp [OPTION]... FILE to allow "-" to be the FILE option to mean STDIN. However, Console_Getopt will not provide that back to you. Test script: --------------- <?php require_once 'Console/GetOpt.php'; $short = "h"; $con = new Console_Getopt; $args = $con->readPHPArgv(); array_shift($args); $options = $con->getopt2($args, $short); print_r($options); ?> php script.php -h - Expected result: ---------------- Array ( [0] => Array ( [0] => Array ( [0] => h [1] => ) ) [1] => Array ( [0] => - ) ) Actual result: -------------- Array ( [0] => Array ( [0] => Array ( [0] => h [1] => ) ) [1] => Array ( ) )

Console_Getopt also allows this usage for what you need: myapp -- - where -- is the end of options. As - without an option could often be a typo, I don't think the supplied patch is the best option. Perhaps also adding a facility to explicitly allow this with the options passed into Console_Getopt? Not sure how this would look.

I thought the point of this extension was to provide a POSIX compliant getopt() implementation? - is a perfectly valid flag that should not be parsed and provided to the application. The utility guidelines of POSIX explicitly mention that - is denoted to be used for standard input. Specifically, -- - is redundant and unnecessary as per the spec.

I should provide a link. http://www.opengroup.org/onlinepubs/000095399/functions/getopt.html If, when getopt() is called: ... argv[optind] points to the string "-" getopt() shall return -1 without changing optind. i.e. Essentially optind is equivalent to array index [1] of the return from getopt2()

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better. you've convinced me