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.
On Fri, May 08, 2015 at 02:16:19PM -0700, Junio C Hamano wrote:
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.
Yeah, especially after my followup email, I think I'm not on the fence
anymore.
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 tried "make SHELL_PATH=zsh test", but had trouble seeing the test
output for all of the errors being spewed to stderr. ;)
Certainly this:
$ zsh ./t0000-basic.sh -v -i
> [...]
test_cmp:1: command not found: diff -u
not ok 4 - pretend we have a fully passing test suite
is not especially encouraging (it looks like running "$FOO bar" does not
word-split $FOO). I am not a zsh user, though, so there may be ways to
convince it to be more POSIX-y (e.g., just calling it as "sh").
-Peff
On Fri, May 08, 2015 at 05:21:47PM -0400, Jeff King wrote:
On Fri, May 08, 2015 at 02:16:19PM -0700, Junio C Hamano wrote:
quoted
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 tried "make SHELL_PATH=zsh test", but had trouble seeing the test
output for all of the errors being spewed to stderr. ;)
Certainly this:
$ zsh ./t0000-basic.sh -v -i
> [...]
test_cmp:1: command not found: diff -u
not ok 4 - pretend we have a fully passing test suite
is not especially encouraging (it looks like running "$FOO bar" does not
word-split $FOO). I am not a zsh user, though, so there may be ways to
convince it to be more POSIX-y (e.g., just calling it as "sh").
I use zsh. It's possible to convince it to be more POSIXy by saying
"emulate sh" or invoking it via a symlink called sh. However, having
said that, I don't recommend it. I set /bin/sh to zsh on my Debian
system and a lot of things broke. Early versions of Mac OS X did that,
too, and they stopped because it was very broken.
As for ksh, I don't know whether you want to kill support for just ksh93
or mksh as well. I've generally had good experience with mksh as
/bin/sh when I've tried it, and it's at least semi-supported in Debian
because it meets Debian's POSIX-plus requirements.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187