Re. svn's behavior on writing to a broken pipe, e.g.
> svn log | head
> [...]
> svn: Write error: Broken pipe
Jack Repenning wrote:
> Classic Unix commands of this sort all respond to the event silently.
> So, too, should svn.
>
> Don't you think?
Indeed, this long-standing behaviour has always been a bit annoying. Like most
things, defining the "right" behaviour takes a bit more thought than it ought,
but I've thought it through reasonably well.
Reading through the related issues and emails, there is general agreement that
it would be nicer not to print an error. The only cautionary note seems to be
the one from William Uther in issue #779 saying something about "svn diff >
my.patch" and also that some other programs including CVS do report "broken
pipe" errors.
I propose this rule:
When svn is performing a read-only subcommand[1]:
on attempting to write to stdout and finding it is a broken pipe:
svn should clean up and then terminate without printing an error message.
When svn is doing something else and producing textual output as a side effect,
it should not obey that rule; the current behaviour is probably satisfactory.
I wondered whether to make the rule conditional on options like
"--non-interactive" and "--xml", or on types of output like "progress messages"
versus "file content or diff", on the premise that they tell us something about
whether the output is expected to be read by a human and whether such an error
is likely to be important. However, these distinctions fail to give a useful
answer and would just make the semantic complexity greater than is warranted
for the problem it's solving. The only distinguisher I use is to restrict the
behaviour to "stdout".
If no objections to this, I'll file an issue with this proposal and the
references below.
- Julian
[1] A read-only subcommand is one that doesn't change stored state in any way
that matters. (Changing temporary state by logging in to the server is OK.)
Related issues:
Issue #779 (closed) "Killing output results in an error on stdout"
<http://subversion.tigris.org/issues/show_bug.cgi?id=779>
Is mainly about svn calling diff and then printing an error when diff dies
due to a broken pipe, but also mentions the error when "svn" finds a broken pipe.
Issue #1693 (closed) "Improved signal handling for svnadmin, svnlook and svn"
<http://subversion.tigris.org/issues/show_bug.cgi?id=1693>
Added "Ignore SIGPIPE" to prevent the program from terminating without a
chance to clean up.
Other email threads raising this issue (expansions of the tinyurls mentioned
below):
<http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=227902>
<http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=147114>
Jack Repenning wrote:
> A long, long time ago (2004-01-20), Julian Foad remarked:
>
>> On head of trunk on SuSE Linux 9, "svn log | head" aborts with "svn:
>> Can't write to stream: Broken pipe" after displaying the ten lines of
>> correct output. I think this is a serious unfriendliness which I
>> would not like to see in release 1.0, though it is getting a bit late
>> for such changes. I thought this had been discussed and perhaps
>> resolved a few weeks ago. Perhaps not. At least I think a consensus
>> was reached that it should die quietly and the way to achieve this
>> was known.
>
> A very short discussion ensued (see <http://tinyurl.com/2etm8m>). I
> guess it's also related to this one: <http://tinyurl.com/2f4a8q>.
> Since those discussions, the problem has spread: some commands that
> were noted at the time as not displaying this problem now do.
>
> There's also a lot of speculation in those discussions relating to the
> exact shape of the various bits of code that lead to these behaviors.
> That seems to me off-base. The code exists to create an effect, not to
> justify it. The effect is justified (or, as I think in this case,
> unjustified) based on what it ought to do, what the user has requested
> and what they got. Subversion is reporting "broken pipe" because it
> receives a broken pipe signal. It receives a broken pipe signal
> because the program at the consumer end of the pipe ("head" or similar)
> has terminated, which closes its end of the pipe, which is the whole
> reason the "broken pipe" signal was invented. So svn is telling the
> truth, no questions there.
>
> The question that remains is: just how much of this truth telling
> should it actually be doing? Programs (and commands like "log"), that
> produce output expected to be read by humans, should be prepared for
> the possibility that the humans will use something like "head" or
> "more" or "less," something that allows them to terminate the display
> prematurely. A two-line gobbledygook message is not a friendly way of
> telling the human "exactly what you wanted to happen did in fact happen."
>
> Classic Unix commands of this sort all respond to the event silently.
> So, too, should svn.
>
> Don't you think?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 3 23:28:04 2007