Re: t0005-signals.sh fails with ksh

Jeff King [off-list ref] writes:

On Fri, May 08, 2015 at 01:34:49PM -0700, Junio C Hamano wrote:

quoted

evgeny [off-list ref] writes:

quoted

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.