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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Junio,

On Fri, 3 Nov 2017, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >> If I was correct in assuming that "2>&1" is just as foreign as
> >> ">/dev/null", then we should be shunning "2>&1" just like we shun
> >> ">/dev/null".  That was all I meant to say.
> >
> > Did you know that `2>&1` works in Powershell?
> 
> No.  And that makes me curious if ">&-" is also there to replace
> "off" ;-)

No, it does not:

-- snip --
PS C:\Users\me> echo 123 >&-
At line:1 char:11
+ echo 123 >&-
+           ~
Missing file specification after redirection operator.
At line:1 char:11
+ echo 123 >&-
+           ~
The ampersand (&) character is not allowed. The & operator is reserved for future use; wrap an ampersand in double
quotation marks ("&") to pass it as part of a string.
    + CategoryInfo          : ParserError: (:) [],
ParentContainsErrorRecordException
    + FullyQualifiedErrorId : MissingFileSpecification
-- snap --

Besides, we're really getting off-track here. I do not *like* `2>&1` as
quite cryptic placeholder for `redirect stderr into the same handle as
stdout was already redirected`. It is Perl-level obscurity.

Adding even more of those "let's string together non-alphanumerical
characters together and declare that they have some special meaning that
nobody would guess so they have to ask us and thereby make us feel smarter
than we are" is definitely not anything I want.

In my opinion, `off` is kind of a compromise that is both easy to
understand and hard to confuse.

If there was a short, succinct and easy-to-understand textual
representation of `same as stdout` that would not be easily confused for a
real file path, I would rather use that instead.

Please note, though, that I am again very reluctant to change things for
less than really compelling reasons at this stage. I have just burned two
days as a consequence of Peff's decision to take my --no-lock-index work
and turn it into something different enough that I had to put in more work
to adjust it, only to introduce a bug in something that worked without any
problem for over one entire year.

It is quite a bit ridiculous just how much bug hunting time I have to
spend lately on stuff that used to work and that got broken on transit
into git.git. It adds a whole new stress level to my work.

Ciao,
Dscho