Jeff King <peff@xxxxxxxx> writes:
> On Fri, May 08, 2015 at 01:34:49PM -0700, Junio C Hamano wrote:
>
>> evgeny <illumsoft.org@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html