Re: [PATCH 3/3] mingw: document the experimental standard handle redirection

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Eric,

On Mon, 30 Oct 2017, Eric Sunshine wrote:

> On Mon, Oct 30, 2017 at 1:10 PM, Johannes Schindelin
> <johannes.schindelin@xxxxxx> wrote:
> > This feature is still highly experimental and has not even been
> > contributed to the Git mailing list yet: the feature still needs to be
> > battle-tested more.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx>
> > ---
> > +`GIT_REDIRECT_STDIN`::
> > +`GIT_REDIRECT_STDOUT`::
> > +`GIT_REDIRECT_STDERR`::
> > +       (EXPERIMENTAL) Windows-only: allow redirecting the standard
> > +       input/output/error handles. This is particularly useful in
> > +       multi-threaded applications where the canonical way to pass
> > +       standard handles via `CreateProcess()` is not an option because
> > +       it would require the handles to be marked inheritable (and
> > +       consequently *every* spawned process would inherit them, possibly
> > +       blocking regular Git operations). The primary intended use case
> > +       is to use named pipes for communication.
> > ++
> > +Two special values are supported: `off` will simply close the
> > +corresponding standard handle, and if `GIT_REDIRECT_STDERR` is
> > +`2>&1`, standard error will be redirected to the same handle as
> > +standard output.
> 
> Consistent with the Unixy special-case for '2>&1', I wonder if the
> 'off' case would be more intuitively stated as '>/dev/null' or just
> '/dev/null'...

I feel this is the wrong way round. `>/dev/null` may sound very intuitive
to you, but this feature is Windows only. Guess three times how intuitive
it sounds to Windows developers to write `>/dev/null` if you want to
suppress output...

:0)

Ciao,
Dscho



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux