On Fri, Dec 8, 2023 at 10:29 AM Oliver Kiddle <opk@zsh.org> wrote:

> A couple of uses of the non-standard \e in C strings have crept into the
> code in relatively recent patches. Most modern compilers support this
> but the Solaris compiler doesn't and \033 should be used instead.
>

Sorry about that.


> Incidentally, .sh.edmode doesn't appear to work on any system in
> my testing, even on other platforms. I get an empty variable and
> ${#.sh.edmode} remains zero.
>

The problem with .sh.edmode seems to be that isset(VIMODE) is false.  I
thought we'd rigged it so that "bindkey -v" would implicitly perform
"setopt vi"?

If you explicitly "set -o vi" (which would be the ksh way to get there)
then .sh.edmode works.


> Annoyingly, it does leave a size zero
> Src/builtin.syms and make clean then doesn't delete that (it fails) and
> a subsequent attempt with gawk then fails to compile builtin.c.
>

"(it fails)" means "make clean" actually returns error, or just that it
doesn't have a rule for removing .syms files?

Would it work to prefix the awk recipe with "-" to ignore that error, and
then append another line to that recipe to clean up on awk failure?


> B03print fails on Tab expansion by print. This is because the test
> expects tr '\0' Z to work which it doesn't. Neither does the full octal
> '\000' or $'\0'. I'm not clear on what purpose that trailing null has
> for the test but it is commented with "regression test for multibyte tab
> expand".
>

The test is confirming that zexpandtabs() doesn't infinite-loop on broken
multibyte input which might include nul bytes.  Could replace the "tr" with
something else.


> /dev/fd tests are being skipped because it doesn't detect /dev/fd.
> That test is: echo ok|(exec 3<&0; cat /dev/fd/3 2>/dev/null;)
>

(This refers to configure.ac, not Test/*)

This is testing that /dev/fd/ entries are created when new descriptors are
created.  The commit log says "work around /dev/fd problem on FreeBSD":
+dnl FreeBSD 5 only supports /dev/fd/0 to /dev/fd/2 without mounting
+dnl a special file system.  As zsh needs arbitrary /dev/fd (typically
+dnl >10) for its own use, we need to make sure higher fd's are available.

Aside from that, there are a couple of failures in W02jobs which I can't
> repdroduce outside of the test system.
>

W02jobs runs everything via zpty, there are some commented-out tests in
there marked with:
#### Races presumed to be associated with zpty mean that
#### tests involving suspending jobs are not safe.

It would be unsurprising if there are other races that need to be accounted
for.