Being able to pass options after operands

Created by: diotteo

This is something I am also interested in. I created pull request #44 to that effect.

Created by: allmarkedup

1

I need this exact behaviour too. Seems like it is quite a common pattern and I can't see any downsides to supporting it?

Created by: func0der

Yep, I would find this very useful, too. If you would not want to support it in your code, maybe you could make the CommandLineParser injectable so that we would be able to overwrite it ourselves.

Created by: tavinus

Hi all.
I know this is old, but since I just made some changes to be able to pass stuff after operands in my little script tavinus/cli-barcode, I decided to post it here.

I just changed the file CommandLineParser.php. Instead of breaking on Operands I assign them and continue the loop. Operands are already being sanitised afterwards so that was not touched. It is a very minimal change actually.

Basically just added:

    if ($arg !== '--') $operands[] = $arg;
    continue;

But since the $operands array gets cleaned anyways, that could also be:

    $operands[] = $arg;
    continue;

Or maybe I am wrong and shouldn't remove the '--' from here. Seems the same though.

Then removed some 2 lines with the array_slice and break.

This is how the parse() function looks now:

public function parse($arguments)
{
    if (!is_array($arguments)) {
        $arguments = explode(' ', $arguments);
    }
    $operands = array();
    $numArgs = count($arguments);
    for ($i = 0; $i < $numArgs; ++$i) {
        $arg = trim($arguments[$i]);
        if (empty($arg)) {
            continue;
        }
        if (($arg === '--') || ($arg === '-') || (mb_substr($arg, 0, 1) !== '-')){
            // EDIT BY TAVINUS: Making execution not stop on operands, so we can have
            // options being passed even after operands. Eg. myScript.php ./file -a
            // not sure why processing '-' and '--', but only '--' is removed
            // foreach loop few lines below seems necessary even when not adding '--'
            // should we also test for '-'? Or should we not test for either at all?
            // this is an operand, store and continue
            if ($arg !== '--') $operands[] = $arg;
            continue;
        }
        if (mb_substr($arg, 0, 2) == '--') {
            $this->addLongOption($arguments, $i);
        } else {
            $this->addShortOption($arguments, $i);
        }
    } // endfor
    $this->addDefaultValues();
    // EDIT BY TAVINUS: why we do this?
    // remove '--' from operands array
    foreach ($operands as $operand) {
        if ($operand !== '--') {
            $this->operands[] = $operand;
        }
    }
}

Can anyone explain to me why '-' and '--' are tested as well?
And then why only '--' is removed and '-' kept?

Changing the original function for this one should be enough. No other changes needed. Or you can even just check the 2 lines changed in the code.

The whole file can be seen here.

And it works :)

$ barcode "AWESOME BAR" $HOME/test.svg -f svg -e CODE_39 -v -v
2017-05-20T12:20:08-03:00 | PHP-CLI Barcode v1.0.6 - Verbose Execution
2017-05-20T12:20:08-03:00 | Output File       : /home/guneves/test.svg        
2017-05-20T12:20:08-03:00 | Barcode String    : AWESOME BAR                   
2017-05-20T12:20:08-03:00 | Barcode Encoding  : CODE_39                       
2017-05-20T12:20:08-03:00 | Output Format     : SVG                           
2017-05-20T12:20:08-03:00 | Width Factor      : 2                             
2017-05-20T12:20:08-03:00 | Height of Barcode : 30                            
2017-05-20T12:20:08-03:00 | Hex Color         : #000000                       
2017-05-20T12:20:08-03:00 | Final Status      : Success

Created by: okdana

I'm on mobile, so forgive me for that, but i can tell you that -- has a special meaning in argument processing — it tells the parser to treat everything that follows as an operand, even if it begins with -. So mycmd -- --not-an-option lets mycmd know not to process --not-an-option. It's thrown away because it's only a 'meta' argument, it doesn't do anything but signify how the parser should treat the arguments following it. It should only be thrown away once though — mycmd -- -a -- -b should treat the second -- as an operand.

- on the other hand is NOT special to the parser and has no 'meta' purpose. Without looking at the code, i'd guess the parser checks for it specially to make sure it doesn't flag it as an invalid short option.

Created by: tavinus

Thanks dude.
So, from what I understand the proper solution seems to involve processing -- as a unique operand (where array slice even makes sense), but only once and only for '--'. While normal operands should be processed separatelly and without array_slice and treating all else as an operand. I mean, any operand was being treated as a -- (breaking processing).

PS: I believe there are more people wanting post-operand parameters than to use the -- operand anyways PS2: Seems easy enough to implement too. Just need to make sure I understand it correctly. PS3: Only thing I remember is that the '-' operand usually redirects output to stdout

EDIT: Sorry for posting so many times here. I was trying to understand this a bit better. From what I understand, we have the basic UNIX/POSIX standard and the GNU way.

UNIX/POSIX standard
- Do NOT accept options after operands
- Do NOT accept the special '--' operand
GNU getopt
- Accepts options after operands
- Accepts the special '--' operand

And the function of GNU '--' special parameter:

Ends processing and gets all else until the end as an operand.
This is used to pass -something as an operand (things that start with -).

So from what I understand this is already in a kind of mixed mode. Where we have the '--' (GNU) but cannot pass options after operands (POSIX). I will make a fork and try to implement the "full" GNU way. The code above has removed the '--' possibility. To have both we need to test is separatelly. But that is easy.

@diotteo 's PR#44 seems to be still valid, or at least almost there. He made these before the lastest version but no conflicts detected.

References:

Created by: tavinus

I need to ask though: @ulrichsg, is this abandonned?
It has been more than 2 years since the last commit here.

@tflori 's fork has many patches and maybe is a better one to use (and modify) at this point?

We can't post issues there though. I can't really send messages to @tflori as well. So maybe we need somewhere else to continue this if @ulrichsg gave up on it.

Created by: okdana

The special behaviour of the -- argument actually is in the POSIX spec — Base Definitions, Utility Conventions, 12.2.10. You're right that POSIX expects options to precede operands. AFAICT this project conforms to POSIX except that it adds support for GNU-style long options (--foo). It should probably conform completely to the expectations of one or the other rather than mixing them.

In any case, as you say, this project hasn't seen much activity in quite a while. At this point you're probably better served by Symfony\Console, which has become pretty much the de facto standard for writing PHP-based command-line tools.

If you want something lighter-weight, there's also Zend\Console\Getopt.

Unfortunately i feel like none of the available argument parsers for PHP is quite feature-complete. Most of them can't distinguish between multiple option invocations (-v vs -vvv), most don't elegantly support aliases (accepting --nocolour for --no-colour), and in general they don't expose state to options being parsed (so there's no way to tell the difference between -qqvv and -qvqv). I may have unusually high expectations of an argument parser, though, idk

Created by: tflori

we moved all together to getopt-php org.

I think that the GNU-style should be made possible. And therefore operands should not stop parsing. But the -- should stop parsing anyway.

The best will be to be fully compatible to this definition: https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html

Being able to pass options after operands

Designs

Child items ...

Activity