On Thu, Aug 08, 2024 at 06:02:28AM +0200, Stefano Brivio wrote:
> On Thu, 8 Aug 2024 10:57:24 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > On Wed, Aug 07, 2024 at 01:28:40PM +0200, Stefano Brivio wrote:
> > > Given that pasta supports specifying a command to be executed on the
> > > command line, even without the usual -- separator as long as there's
> > > no ambiguity, we shouldn't eat up options that are not meant for us.
> > > 
> > > Paul reports, for instance, that with:
> > > 
> > >   pasta --config-net ip -6 route
> > > 
> > > -6 is taken by pasta to mean --ipv6-only, and we execute 'ip route'.
> > > That's because getopt_long(), by default, shuffles the argument list
> > > to shift non-option arguments at the end.
> > > 
> > > Avoid that by adding '-' at the beginning of 'optstring', and mark the
> > > position of the first non-option argument (getopt_long() will now
> > > return the character code 1 once we hit it), so that we can use that
> > > as command to run, or as PID for the target namespace.
> > > 
> > > Reported-by: Paul Holzinger <pholzing@redhat.com>
> > > Signed-off-by: Stefano Brivio <sbrivio@redhat.com>  
> > 
> > Eh... I'm kind of ambivalent about the idea.  I tend to think that
> > accepting options in any position is generally expected behaviour, and
> > anything programmatically adding commands to pasta should routinely
> > insert a "--" (that's certainly what I do in testing code).
> 
> Sure, on the other hand it's convenient when you're quickly trying out
> ip -6 route show, or some command where "--" would add 10% of typing or
> so.

Ok, sure.

> > But, that's not a particularly strong opinion, so whatever.
> > 
> > The implementation looks more complex than necessary, though.  AFAICT
> > if you just add a '+' to the front of the optstring it will do exactly
> > what you want without having to juggle the first_nonopt and other
> > variables.
> 
> Oops, that's actually the first approach I considered, but I didn't see
> any guarantee that optind would assume the expected value after the
> loop. However, it does... sending v3.

I don't really see how it could be anything else, after all you still
need to parse the remaining non-option arguments in this case.

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson