This was caused by a "darcs record --all" invocation:

Anacron wrote:
> /etc/cron.daily/etckeeper:
> Reading pristine 104 done, 1108 queued. 0000006482-68e3535cd2ad1b9867a70fc31c620

This progress information should not be emitted unless stdio is a tty.

This sounds like it could be easy to fix.  We have some general smarts
like this using the Haskeline library

Is this actually still a problem? 
AFAICT, the code in Progress.hs
appears to do the right thing.
And e.g. darcs get --lazy http://darcs.net > darcs.txt leaves no progress 
report in darcs.txt.

Alexander Njemz wrote:
> 
> Alexander Njemz <f.alexander.njemz@gmail.com> added the comment:
> 
> Is this actually still a problem? 
> AFAICT, the code in Progress.hs
> appears to do the right thing.
> And e.g. darcs get --lazy http://darcs.net > darcs.txt leaves no progress 
> report in darcs.txt.

I don't know offhand, I will try to find time to do some testing.

It'll likely be stderr (2) not stdout (1); and it'll only occur if the
operation takes a while, which wouldn't happen with a lazy get that
you already have cached.

This bug is still present as of the time of this comment. The code
responsible is in src/Darcs/Patch/Progress.hs and makes heavy use of
unsafePerformIO.

I agree that changing this is a good idea. Currently progress goes to 
stderr. I would like to make it go to stdout and disable it when that 
is not a terminal. With terminal-size >= 0.3.4 we can now more 
reliably detect that condition. Will send a patch.

See Patch2291