stdio handling is broken

[Gregory Szorc]

On Sun, Mar 12, 2017 at 7:59 PM, Bryan O'Sullivan <bos at serpentine.com>
wrote:

> For complicated historical reasons, Mercurial doesn't handle errors upon
> writes to stdout or stderr correctly.
>
> You can test this on a Linux box very easily. Correct behaviour involves
> trying to print an error message, followed by an error exit:
>
> $ /bin/echo a > /dev/full
> /bin/echo: write error: No space left on device
>
> Meanwhile, Mercurial goes "what, me worry?":
>
> $ hg status >/dev/full
> $ echo $?
> 0
>
> Eek!
>
> I have a patch series that purports to fix this, but /dev/full is a
> Linux-specific thing, and I am scratching my head over how to test the fix
> portably.
>
> So far, the "best" idea I have is to create a fake file object that raises
> an ENOSPC IOError upon flush, but by the time I can use the extension
> mechanism to cram this into place, the early dispatch code already has the
> stdio handles stuffed away the request object, which extension code can't
> get at.
>
> If you have any better ideas, I'm all ... eyes?
>

You aren't going to like this answer but it works.

You can change dispatch.py:run() to assign the request instance to a local
variable. Then, when your extension loads it can walk the stack, find the
frame for run(), then swap out request.{fin,fout,ferr}. If you promise not
to tell anyone I wrote it, you can find an example for doing this in an
extension at
https://hg.mozilla.org/hgcustom/version-control-tools/file/6d3e12142e2f/hgext/serverlog/__init__.py#l376
.

That being said, I thought ui.{fin,fout,ferr} were just refs to the
setbinary'd streams canonically available in util. Can't you just swap out
ui.{fin,fout,ferr} in a uisetup() for the purposes of testing?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170312/cfa8259c/attachment.html>