On Sat, Apr 25 2015, Ole Tange <[email protected]> wrote: > On Thu, Apr 23, 2015 at 3:56 PM, Rasmus Villemoes <[email protected]> > wrote: > >> How about >> allowing --halt be given multiple times, with each invocation overriding >> certain aspects of the behaviour requested so far. Then one could do >> >> --halt 25% --halt 2 >> >> with --halt 25% --halt 1 being the same as --halt 25% by >> itself. Encountering --halt 0 would restore the default behaviour. >> >> I really prefer when any command-line option can be overridden (or reset >> to the default) by a later option > > Agreed. > > I am not fond of the repeating argument, though. > > How about: > > --halt 2,25% == --halt 25%,2 > > Then --halt <<whatever>> would override that.
That seems reasonable - only the latest --halt has any effect, and --halt takes a comma-separated list of 'directives' to tell it exactly how to behave. While at it, it would probably be nice to avoid the magic numbers (though they'd probably need to stick around for compatibility). Something like --halt on-fail,25%,no-cleanup (aka --halt 2,25%) --halt on-success,50%,cleanup (aka --halt -1,50%) --halt on-fail,cleanup (aka --halt 1) --halt never (aka --halt 0) I'm not sure how to incorporate the 'external' halting conditions (SIGTERM etc.), maybe that's better handled by a separate set of options. >> (instead of the >> error-prone process of trimming the current list of options, where one >> has to be careful with --halt=25% versus --halt 25% etc.). > > Are you aware that --foo X is the same as --foo=X ? Yes, exactly, that's way it's error-prone for a wrapper script to try to remove from a list of options: Removing the --foo option is not just removing any word starting with --foo=; one also has to worry about the '--foo X' case. In other words, one needs intimate knowledge of how the wrapped program parses its options, and then essentially duplicate all that. It is much simpler to just append '--foo=Y' and know that that then takes effect. Rasmus
