From: Junio C Hamano Date: Fri, 08 May 2015 21:16:19 GMT Subject: Re: t0005-signals.sh fails with ksh Message-ID: In-Reply-To: <20150508205548.GB13457@peff.net> Jeff King writes: > On Fri, May 08, 2015 at 01:34:49PM -0700, Junio C Hamano wrote: > >> evgeny 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.