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.
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.
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.
--
Laurent
Received on Wed Feb 18 2015 - 00:17:35 UTC