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
