Re: [PATCH] git-prompt: use builtin test

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

>> That's possible, but I suspect the burden is minimal.  As you said, this
>> is bash and zsh specific, and for those shell coders who only write
>> Bourne dialect it's to be read as a "strong" left square bracket.  For
>> example, to minimize any shock to the eyeballs I've intentionally not
>> re-written string operations `[ a = b ] && [ c = d ]` to `[[ a == b && c
>> == d ]]`.  I promise it wasn't mere laziness!
>
> I guess my concern was less about doing it once, and more about: is this
> something we want to continue enforcing as time goes on? That is, would
> we want to catch it in review and complain about people using "test"?

Yes, if this is just a mental exercise burning off excess calories
and too much spare time and nothing else, I'm hesitant to burden our
reviewers and casual contributors, who do not have excess calories
or too much spare time to burn off just to play nice with the result
of this patch, with an issue that is apparently only theoretical
like this one, with which nobody actually is hurt in practice.

It's not like local variables used in prompt and completion leaking
out, which can hurt real users (as it is quite normal to use throw
away variables in your interactive sessions).  It's not even like
these scripts being "set -u" clean, that may hurt those who use "set
-u" in their interactive sessions (what for?) but nobody else.  

If you write your own shell function "test" that is grossly
incompatible with everybody else's "test", where do you do that?
Not in your .bashrc, or you would break more than just prompt and
completion.

If this came with additions to t9903 that redefines "test" and tries
to make sure we consistently use bashism [[...]] and such a change
to "test" would not break it, I might have been more sympathetic,
but I dunno.  I sort-of like the purity of mind when we say "this is
a #!/bin/bash script and we maximally write in a way a bash-script
expert would", but many of our shell scripts outside these two
contrib/ scripts HAVE to be portable and free of bashisms, so...

> That's a subtle thing to remember to look for, though I guess we could
> automate it via the tests. Or would we rely on people who cared to
> notice new instances and submit patches? That's how we deal with some
> other portability issues (if nobody is screaming, how broken could it
> be?). But it sounds from your description like this was a one-off even
> for you.
>
> So I dunno. I'm not really opposed, but I'm not convinced it's really
> accomplishing much here.

I guess I am mostly on the same page here.

Thanks.