Treat all flags which followd behind the last arguments as normal arg…

[keloyang]

If SkipFlagParsing is not considered,cli treat all words which start by '-' as flag, so when the subcommand has a argument which start by '-', it also will treated as cli' flag, not a argument for subcommand.
e.g.

root@ubuntu:~/# runc exec test ls -la    
Incorrect Usage.

I think cli should treat all flags which followd behind the last arguments as normal arguments,just like this:

root@ubuntu:~/# runc exec test ls -la            
total 44
drwxr-xr-x   12 root     root          4096 Aug 30 06:37 .
drwxr-xr-x   12 root     root          4096 Aug 30 06:37 ..
-rwxr-xr-x    1 root     root             0 Aug 30 02:23 .dockerenv
-rwxr-xr-x    1 root     root             0 Aug 30 02:23 .dockerinit
...

opencontainers/runc#752 for details.
Signed-off-by: Shukui Yang yangshukui@huawei.com

[keloyang]

ping @jszwedko @bryanl @dam5s @gravis @rmg

[gravis]

LGTM
If no one else is taking this, I'll merge the PR in 10 days.

[jszwedko]

The usual "unix-y" way to handle this (which this library supports thanks to stdlib flag support) is to use -- to specify that all following arguments should be parsed as arguments rather than flags.

I can see the argument you are making for ... exec-like commands though. Would the support for SkipFlagParsing support your use case? Or would the exec subcommand also have flags of its own in addition to the freeform command?

[keloyang]

yes, add -- is ok, but use "runc exec -- test ls -la" instead "runc exec test ls -la", some people think it might be a bug.
SkipFlagParsing also don't work for me,
e.g.

runc exec --cwd /  test ls -la 

it will skip -la, but it also skip --cwd.
On the other hand, this pr will change the action for the last argument, So I modify it to add a SkipLastFlagParsing to keep backward compatibility.
ping @jszwedko - -

[jszwedko]

@keloyang gotcha, so the subcommand also has flags.

The behavior you describe is actually the default behavior of the underlying flag library that we use, but we do some argument rearranging (that I removed in the unreleased v2 branch in #398 because it only worked under very specific circumstances and supporting complete reordering would require much more effort).

I can imagine a future where cli supports flags and arguments being intermixed (a need expressed in #427), but because this is not currently supported and wouldn't be in this particular version (nor probably in v2), I'm OK with including this. Given it will be the default behavior in v2, I'm almost inclined to call the option NoArgumentReorder, document that it is backported behavior, and make it closer to the behavior in v2.

Let me know what you think about this and I can backport it.

Thanks for bringing this up! (and apologies for stepping on your toes @gravis 😄 -- this issue just reminded me of the work I'd done in #398 around removing reordering).

[keloyang]

@jszwedko thank for your reply, It's nice to backport #398 and it can resolve the problem above.

[meatballhat]

@gravis you've still got this? 😸

[jszwedko]

I was planning on working on the backport of #398 today, but let me know if anyone is actively working on this!