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