Re: strange behavior

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Jan 30,  1:37am, Vincent Lefevre wrote:
} Subject: Re: strange behavior
}
} On 2011-01-28 07:49:15 -0800, Bart Schaefer wrote:
} > There has to be some kind of race condition here.  2>>(filter) runs
} > filter in the background, so if something behind svn also runs as an
} > separate process, it could be possible for the filter to exit and
} > close it's stdin (thereby closing everything else's stdder) before
} > operating-system-level exit-time buffer-flushing has finished.
} 
} Yes, this happens, but I don't see why this could make the script
} terminate with a broken pipe.

Possible epiphany:  zsh prints "zsh: exit 141" like that only if the
exit status came from a builtin or shell function (Src/exec.c).  For
all external commands or subshells it appends the jobtext after the
status number (Src/jobs.c).  Those are the only PRINTEXITVALUE cases.

Thus the exit value of 141 must be coming from one of these places:

(1) "read" builtin in the inner loop of "filter"
(2) "printf" in the ?* branch of the case in "filter"
(3) "echo" in the { ... } expression

I can't imagine how "read" could return 141.

For the { echo } statement, I get "zsh: broken pipe" every way I try
to make it fail, before zsh ever gets around to PRINTEXITVALUE.

That leaves "printf" ...

Which at first let me to wonder if what's happening is that the inner
while loop is failing to consume the entire svnwrapper:term$'\012' in
a single pass around the outer loop, e.g. that the -t option you're
adding after reading the first character causes read to time out on
some calls instead of reading the next character.  But that implies
that the stderr of "filter" is getting closed somehow, and I can't
think of a way that would happen.

So I'm still stuck.  What we need is an "strace -ff -o ..." or the
equivalent to tell which process is printing that, but tracing may resolve
the race condition and prevent the error.

} Note that when I obtained the "zsh: exit 141", the svn output wasn't
} redirected, so that a "Broken pipe" message from svn was not possible.

I don't understand what "wasn't redirected" means.  Stderr is always
redirected; "Broken pipe" could occur if svn prints something to
stderr after 2>>(filter) has exited.  I still can't figure out how
to tie that to "zsh: exit 141" given the constraints above, though.

} > Hmm, another thought ... maybe the "zsh: exit 141" is coming from
} > the shell's exit-time handling of the "filter" program, rather than
} > from svn.  I've lost enough context here that I don't recall whether
} > that was previously ruled out too.
} 
} What do you mean here?

I meant that 2>>(...) is handled specially.  Because "filter" is a
shell function, it runs in a subshell which might have inherited the
printexitvalue setopt from its parent.  When filter exits inside the
subshell, perhaps the subshell is printing "exit 141" before it also
exits.  *That* could correspond to printf barfing, but what would be
closing the stderr of the command substitution?