[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New behavior proposal --halt -% with job killing
From: |
Rasmus Villemoes |
Subject: |
Re: New behavior proposal --halt -% with job killing |
Date: |
Sat, 25 Apr 2015 09:42:55 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
On Sat, Apr 25 2015, Ole Tange <ole@tange.dk> wrote:
> On Thu, Apr 23, 2015 at 3:56 PM, Rasmus Villemoes <rv@rasmusvillemoes.dk>
> 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
- New behavior proposal --halt -% with job killing, Martin d'Anjou, 2015/04/21
- Re: New behavior proposal --halt -% with job killing, Ole Tange, 2015/04/22
- Re: New behavior proposal --halt -% with job killing, Ole Tange, 2015/04/25
- Re: New behavior proposal --halt -% with job killing,
Rasmus Villemoes <=
- Re: New behavior proposal --halt -% with job killing, Ole Tange, 2015/04/26
- Re: New behavior proposal --halt -% with job killing, Ole Tange, 2015/04/26
- Re: New behavior proposal --halt -% with job killing, Martin d'Anjou, 2015/04/27
- Re: New behavior proposal --halt -% with job killing, Ole Tange, 2015/04/27
- Re: New behavior proposal --halt -% with job killing, Ole Tange, 2015/04/27