From: Bart Schaefer <schaefer@brasslantern.com>
To: Oliver Kiddle <opk@zsh.org>
Cc: Zsh workers <zsh-workers@zsh.org>
Subject: Re: PATCH: Avoid \e in C code; building on Solaris 11
Date: Fri, 8 Dec 2023 14:03:25 -0800 [thread overview]
Message-ID: <CAH+w=7ZuvPdqnTVvpZmhW=khZekc6DiTxM6ai6Hi0cmDnfNh5A@mail.gmail.com> (raw)
In-Reply-To: <50885-1702060132.779123@YSiF.CgC_.vGLi>
[-- Attachment #1: Type: text/plain, Size: 2656 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 4086 bytes --]
next prev parent reply other threads:[~2023-12-08 22:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-08 18:28 Oliver Kiddle
2023-12-08 22:03 ` Bart Schaefer [this message]
2023-12-08 22:15 ` Bart Schaefer
2023-12-09 23:04 ` Oliver Kiddle
2023-12-10 0:29 ` Bart Schaefer
2023-12-09 22:41 ` Oliver Kiddle
2023-12-09 23:43 ` Oliver Kiddle
2023-12-10 0:33 ` Bart Schaefer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAH+w=7ZuvPdqnTVvpZmhW=khZekc6DiTxM6ai6Hi0cmDnfNh5A@mail.gmail.com' \
--to=schaefer@brasslantern.com \
--cc=opk@zsh.org \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).