Newer versions of darcs-devel give "darcs failed:   resource vanished"
when piping the output of changes. If I run "darcs changes" I do not
get the message.  If I run "darcs changes | less" (or more) and then
hit "q" to quit it will display the error before going back to the
prompt.

It does not happen with 1.0.5.  I tried going back a ways (about 80
patches) on darcs-devel and the problem still showed up, so it doesn't
seem to be from any very recent patches.

I wouldn't be surprised if this is a "broken pipe" error or something
similar, but I'm not sure how to go about checking this.

On Wed, Dec 21, 2005 at 05:38:02AM +0000, Zachary P. Landau wrote:
> I wouldn't be surprised if this is a "broken pipe" error or something
> similar, but I'm not sure how to go about checking this.

It almost certainly is this.  We catch the SIGPIPE exception, but then if
we try to write to stdout again, we get hosed.  I'm not sure of the best
solution here.  We could figure out who's writing after the SIGPIPE, or
perhaps we could just close stderr, which would keep the messages from
being seen.

Confirmed that this shows up in darcs-unstable (plus a few of my patches,
actually), but not in darcs-stable.

You can also reproduce with `darcs changes | head`

I think maybe an strace would help here...
-- 
David Roundy
http://www.darcs.net

Here's the relevant line from the strace output:

  write(1, "fix bug in doesDirectoryReallyEx"..., 8191) = -1 EPIPE (Broken pipe)

The error message is definitely puzzling, but I'm too lazy to check the Ghc
library sources.

I believe the only issue is the error message.  Reporting EPIPE as an error
is standard practice.

> I believe the only issue is the error message.  Reporting EPIPE as an error
> is standard practice.

Agreed.  But the error message comes from GHC it seems  Is it too
hackish to, when catching  error messages, convert "resource vanished"
into "Broken Pipe" or what have you?  Resource vanished and broken
pipe do describe the same thing, but everyone is used to "Broken Pipe"
and many are probably thrown off by resource vanished, like I was.

On Fri, Jan 13, 2006 at 10:42:13PM +0000, Juliusz Chroboczek wrote:
> I believe the only issue is the error message.  Reporting EPIPE as an error
> is standard practice.

I disagree.  I'd prefer not to report EPIPE with an error message.  I don't
like geting error messages when using pipes for things like

darcs changes | head

In SignalHandler we don't report SIGPIPE signals precisely for this
reason.  I guess something must have changed so now we get both an EPIPE
and a SIGPIPE.  I'd prefer not to report either.
-- 
David Roundy
http://www.darcs.net

I can't reproduce this with 1.0.9 or 2.0.0pre2, and there has been no further
activity on this bug since 2006, so I'm considering it resolved. 

Please re-open if you find otherwise.

I still get this on MacOS X with darcs > 2.0.0pre2.  Doing darcs changes | less
and hitting q (on the darcs darcs repository) gives me a "resource vanished" error.

kowey, thanks for the follow-up. Let's narrow the environments where it happens
and doesn't happen then. 

For me, with Ubuntu Gutsy, using Bash 3.2.25 and 'less' 406, it doesn't happen.
 With what version of shell and pager did you experience it?

On Sat, Jan 19, 2008 at 15:43:25 -0000, Mark Stosberg wrote:
> For me, with Ubuntu Gutsy, using Bash 3.2.25 and 'less' 406, it doesn't happen.
>  With what version of shell and pager did you experience it?

less 328 (default on MacOS X Tiger)
zsh 4.2.3 (likewise)

I'm pushing a test that I think ought to trigger this bug, in which I use head
instead of less to trigger the bug.  Except that it's not triggered for me...

Anyhow, let us know, Eric, if you can use this test to trigger the bug.  If not,
perhaps you can use it as a starting point for writing a test that *does* fail
on your system?

This test passes for me with a current build from darcs-unstable as well:

 perl shell_harness broken-pipe.sh

An updated trigger-case from Eric would be ideal.

The test still passes for me. I also tested with "zsh", which I believe OSX uses. 
The test still passed with zsh 4.3.4.

On Fri, Feb 08, 2008 at 01:57:40 -0000, Mark Stosberg wrote:
> The test still passes for me. I also tested with "zsh", which I believe OSX uses. 

No, I had switched to zsh on a whim.

It turns out that this bug is now reproducible on the buildbots.  It'd be nice
to get it fixed, just so we can move the test (bugs/broken-pipe.sh) back into
the test suite.  Alas, I've no more of an idea as to what triggers this bug.

I can no longer reproduce this on the command line (in darcs darcs repository:
darcs changes | less; hit q).  

MacOS X Leopard, zsh, less 394 (last time, I was using Tiger).

We need somebody to check why David's repository marked this as passing.  Is it
just because he wasn't using buildbot any more?