Re: stdio handling is broken

[Gregory Szorc]

On Sun, Mar 12, 2017 at 7:59 PM, Bryan O'Sullivan 
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?
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: stdio handling is broken

[Augie Fackler]

Add a check to hghave for dev/full existing, then use a #if guard in a
test.

(On phone from biergarten, sorry for top post)

On Mar 12, 2017 19:59, "Bryan O'Sullivan"  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?
>
> ___
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>
>
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

stdio handling is broken

[Bryan O'Sullivan]

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?
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel