On 02/18/15 01:17, Laurent Bercot wrote:
> On 18/02/2015 00:22, Olivier Brunel wrote:
>> - First off, I found the doc to be a bit confusing, because you
>> alternate between talking about when loopwhilex keeps running prog, and
>> when it stops/exits.
>
> Yes, it's confusing, but it's still accurate.
>
>
>> In fact, it's confusing enough that you yourself got it wrong :p
>
> Nope, the doc is correct here. At least in intent; if loopwhilex's
> behaviour is different, then it's a bug.
Alright, so let me quote you from that very mail, about behavior when
using both -n and -x :
> With the -x option, the "exit loop" codes are the listed argument
> and the "continue looping" code is all the rest.
With -x, breakcodes are when loopwhilex exits. So with -n, they are when
it continues, since it negates it, correct?
Let me repeat: you're saying with both -n & -x, breakcodes are when it
*does* loop.
Ok, now let me quote you the doc for the same case, using both -n & -x :
It will "run prog... as long as it exits a code that is not listed in
breakcodes" (there's even emphasis on the "not").
Let me repeat: the doc is saying with both -n & -x, breakcodes are when
it does *not* loop.
Clearly, one of you is wrong. I still say the doc is wrong there.
> The problem is, loopwhilex behaves differently when the -x option
> is given and when it's not.
> Without the -x option, the "continue looping" code is 0 and the
> "exit loop" code is all the rest.
> With the -x option, the "exit loop" codes are the listed argument
> and the "continue looping" code is all the rest.
> That is why it's confusing: the "explicit set of codes" vs.
> "all the unlisted codes" meaning is reversed when you give the -x
> option.
>
> The -x option was added as an afterthought, and the -n option
> after that one again. I only later realized how confusing it was.
> The right solution is to replace the -x option with another one, where
> you list the "ok" codes, not the "exit" ones, and if you want "-x"
> behaviour, you add "-n". I'll do that for the next release.
>
>
>> - The phrasing on the doc led me to think that if prog is killed by a
>> signal, loopwhilex exits (that signal number). But looking at the code I
>> see that that's not the case, instead it will treat it as if prog had
>> returned 126. Why that magic number? Also, shouldn't it always exit when
>> prog was killed by a signal?
>
> Hmmm, it probably should. I'll check and fix it accordingly.
> The magic number comes from a time when I didn't have a clear vision
> of what to do when programs get killed, and I didn't want to think
> about it too much, so I treated a death by signal like an exit with
> failure by default.
>
>> I was gonna say I'd like to get the exit code from prog that caused the
>> loop to end. So, I was thinking an option to make loopwhilex return the
>> exit code from prog, and maybe be killed by the same signal if prog was
>> signaled.
>
> Signal propagation is dangerous, and I don't like to use it when it's
> not strictly necessary.
>
>
>> loopuntilx [ -n ] [ -x breakcodes ] { progloop... } prog...
>
> That was actually how it worked in early versions of execline; the
> command was called "loopwhile". But with use, I realized that
> implementing a sequence of operations where it's not necessary led to
> code duplication; add a "foreground" around the "loopwhilex" if you
> want that behaviour.
Yes, except when you want the exit code from progloop of course, which
was what I was trying to address here in the first place...
> I like chain loading, a lot, but sometimes exiting is just the right
> thing. :) That's why there's forx (replaced for), forbacktickx (replaced
> forbacktick), and ifte (replaced ifthenelse, that is still around because
> the order of blocks is more intuitive and I actually still have a script
> somewhere relying on ifthenelse -s *shudder*, but that should go the way
> of the dodo at some point).
>
> But yes, even with a foreground construct, your following comment is
> valid:
>
>> (As a side note though, if foreground would set that ? environment
>> variable to 256 instead of 111 when signaled it might be better, since
>> 111 is a valid exit code after all.)
>
> Absolutely, it's the right thing, like the fix to finish scripts.
>
