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 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.