Control: tag -1 + fixed-upstream confirmed Control: found -1 5.0.7-5 Hi Brian,
brian m. carlson wrote: > If a continue occurs in an && chain inside a loop, the continue is not > effective. For example, if you save the following as foo.sh: Thanks for the bug report. > This breaks the Git testsuite under zsh's sh mode, Hmmm, actually, your example code shows "set" for me even without sh emulation mode: → zsh continue.sh set → zsh --emulate sh continue.sh set > which was formerly passing. When was "formerly", i.e. in which package or upstream version? > There's a patch upstream at > https://github.com/zsh-users/zsh/commit/12e5db145b098a62ff11b88eea26f473ea2ecdcf. Actually the lines changed in the upstream fix were last changed in the year 2000. And I was able to reproduce this issue in zsh 5.0.7 from Debian 8 Jessie (now ELTS). So it's in there for probably at least 23 years and clearly not a recent regression — if it's a regression at all. (I kinda doubt it with my current state of knowledge.) So I suspect that the Git testsuite only recently started to use "continue &&" recently? Then actually only find only a single occurence of "continue &&" (which is not "--continue &&" or suchlike) and that one seems to be a comment: t/t3418-rebase-continue.sh: : skip and continue && And the test which contains that (suspected) comment was added in 2018 in commit d5bc6f292ab0a1715ff021f5854ac5a81c2b88b0. > It would be great if this could be backported to zsh in Debian, Can do, but for Bookworm this is likely too late as we're now in the last stage of the freeze with the release planned for in one month and this change clearly changes a longtime zsh behaviour. > since the release cycle tends to be long Well, 5.9 is out for quite a while already. So I think we can expect a new release before the the Debian 13 release. ;-) But yeah, I think we can cherry-pick this from upstream after the Bookworm release. > and it prevents the shell from being effectively used as a POSIX sh. Well, zsh's POSIX mode is officially declared as being incomplete and it's IIRC also not recommended to actually use it or at least not rely on it. Also upstream's statements like "probably ought to be regarded as a bug" and "However, it's not logically wrong, either." sound as if it's more a bug by goodwill, not by conviction. And I must admit that "continue &&" as bash, ksh and all others process it IMHO makes less sense than how zsh used to do it. That's probably what upstream meant with "it's not logically wrong". But let's follow upstream here. :-) Regards, Axel -- ,''`. | Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
