Re: t0005-signals.sh fails with ksh

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

Jeff King <peff@peff.net> writes:

> On Fri, May 08, 2015 at 01:34:49PM -0700, Junio C Hamano wrote:
>
>> evgeny <illumsoft.org@gmail.com> writes:
>> 
>> > expecting success: 
>> >         OUT=$( ((large_git; echo $? 1>&3) | :) 3>&1 ) &&
>> >         test "$OUT" -eq 141
>> >
>> > t0005-signals.sh[499]: eval: syntax error at line 4: `(' unmatched
>> > Memory fault
>> 
>> Does this work if you did
>> 
>> 	OUT=$( ( (large_git ; echo $? 1>&3) | : ) 3>&2 ) &&
>> 
>> instead?
>
> It does for me. I've tested our suite with mksh before, and it passed
> (that's why the earlier check already covers ksh). But using the ksh I
> get from "apt-get install ksh" on Debian (ksh93, it looks like?) fails
> as described. 
> ...

Yuck.

> I'm on the fence, though, on declaring ksh93 to be unsupported. I don't
> know how many other instances of this are in our test suite, and it's
> one more maintenance headache to deal with. Are there really platforms
> with no actual POSIX shell (on Solaris, for example, the xpg6 shell is a
> much better choice)?

Yeah, ksh has gone too far and now is on the other side, I would
have to say.  Introducing new keywords and semantics to let its
users use new features (e.g. "let") is one thing, but breaking a
valid POSIX shell construct and interpreting it in an incompatible
way is going just too far for it to be treated as a Bourne variant.

I wonder if zsh is in the same league.  Do we support people who do
SHELL_PATH=/bin/zsh and bend over backwards when it breaks?

I'm on the fence, too.