From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4587 invoked from network); 8 Dec 2023 22:03:54 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 8 Dec 2023 22:03:54 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1702073034; b=KpEayjWPRwuSMzBraJ6s+l78hiu1PlKfrJfRmDpuwMCxBbWB2ORli7foI+mYuNorVk8TMUX9En VnyALK0djGP+LQl0TUxrBTReu4W1J8pu009hwbRZ/mMs/A860hn11TZXs/eDFpcYrZGGPhttpu utjdSchBWVVWTKbzAvSo+MCYLDVgFmtgUZC3l8yZK2iiy78cHtI/SJVHCnRah4kT31G83ZW6Ng GIKCtPKOaCXOgk8/vkx119JbJYFvL+6qCB/Qu6DGMG4DGk1zlFo+1UkPxPXXz/3SLbVtBDTuX5 KQO+xxNC2BB8fqwyxr+mQs8t9mY4xyF1NkhU2MOYetTU/w==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-lj1-f179.google.com) smtp.remote-ip=209.85.208.179; dkim=pass header.d=brasslantern-com.20230601.gappssmtp.com header.s=20230601 header.a=rsa-sha256; dmarc=none header.from=brasslantern.com; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20210803; t=1702073034; bh=YWRs6XRZcKLc8GwC293Hgh30xCF9r97dS3cevYCNyHc=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:DKIM-Signature:DKIM-Signature; b=raPufK8D9gwXkoXqW1FGcEuykfHRnu/DmxpgiPGH23hEHE5JbGj4KtLdsFnBqXOY/uIYvxwNFx ta4MsfFxUV5PnonBEqhO3TkfhXvohNUi/mZs6rxqqBa38ey8l4C0kJoVLYQpD5Vu8ZtBYb/LKH csMpdZnuBrtQmlQB47QroAAgVamqVGuQZBDgjhip/7C/9aYp5wUd/YuAHsm907nCaBKl6MIIOI MnRFFkgECZGzA43KLsc7BUSuJZct6Yr8w6DmP2EcoI+rt2nXSsyEYBZ6pM8p5feMFqHVlwf+U1 iISdxaGLXovlfSQJ0+081i+oGZLXu5lJS6fFX/i1cSvcpA==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20210803; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Content-Type:Cc:To:Subject:Message-ID :Date:From:In-Reply-To:References:MIME-Version:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=ubsjtTU4FSz47WP26I/BZe/pXT/GJmxg5Nzg0Z1bKoY=; b=cGlzcqGDFcpa8hakQnkdDt3DiF Fdo7UAWCdKEJeO4dl/SSeYw02IjcXcsUCluWmif2ScShrxPaJYLTyEJLeXKOZOW8duVl9QxzqDloJ cWhf68LMDqBFrLeLQas3EopkRWu1Uf1eIybr4dIXNMdLfrWMRm4Z0Mbu8sMr0pPeT6YO4UljbdEw9 zq506obz3FTyJCyJkuc4ESIs8saKqudQ1+kjCIpgkrAEKFnATi7gAkQhoUfZVsw7eRjdYaFzzuZbc A5QR2k8CcotavNf8M16kcdY3B1sIeYn9K7J8a7WJnL2mLG1TL2wV1ERF1U0jlsVxr7tP5sQayOPQE exaCGd7w==; Received: by zero.zsh.org with local id 1rBiwq-0002NM-Lw; Fri, 08 Dec 2023 22:03:52 +0000 Authentication-Results: zsh.org; iprev=pass (mail-lj1-f179.google.com) smtp.remote-ip=209.85.208.179; dkim=pass header.d=brasslantern-com.20230601.gappssmtp.com header.s=20230601 header.a=rsa-sha256; dmarc=none header.from=brasslantern.com; arc=none Received: from mail-lj1-f179.google.com ([209.85.208.179]:48632) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1rBiwb-00026t-A3; Fri, 08 Dec 2023 22:03:38 +0000 Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-2ca09601127so32808931fa.1 for ; Fri, 08 Dec 2023 14:03:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20230601.gappssmtp.com; s=20230601; t=1702073016; x=1702677816; darn=zsh.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ubsjtTU4FSz47WP26I/BZe/pXT/GJmxg5Nzg0Z1bKoY=; b=cG5V2Ai0f7JB+kAZm9TmJoOlE7X/KxLHGw33bfgPtkjf5zBJegZKn3ydm0unvx/U63 +EiCvhHFQN5eJ9ZOlpvbnJ9QRY2pq/HF065oNYScf02zx4YBU2BioyVdg7HlDtRIv5Sh feupb1nW1Kyxn9vDKbEVZiyaOLCQNA6LiRRokj9gDrO5wSntvrfVdqc7E8PPr3468svB TiCcwy6YrXYh0EDrYH1vcBB7C3gAFkjSsLy/WVP0dEJEiPHhUxN5ABDD3e9AwxojzgwF DrjDHCRx39bs81uiFgrr1NhOk8+bosQyeKyocdgSfeys/rmMVOTzTsIcqRWoJd+19ZiX UxGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702073016; x=1702677816; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ubsjtTU4FSz47WP26I/BZe/pXT/GJmxg5Nzg0Z1bKoY=; b=j3C3krs4klUP2PYbAoWYdmsQCyBgM0XEbVHga/PLFnWdVr/wv31iEs8arCDOzcRSeD kUaf9JCJzXRNmIqPwIq+qz2FN6/FVewCA1SFKhJRNWEPcq94xGXr2HhW0rsD3uyALgRc +Lc/TXUaMl2rfbNRj/ZwgP6Gbd4qnQ6K95OZidDkrvHGSvOhU/sq0opWYC3GiPkJBuzn PVAj7yNzPA+b0HdRVCGiGQkK6px03PhroB+2+EKhwyjH6S0BZfzsPeDXEX1QkihO2Ce6 SSG9mYWecZVj9/+6q6O6FHftQO9G3AudCvVViBu/1b4fLSpnn7AVA/uo0wjIyHvmFQ8i I4JQ== X-Gm-Message-State: AOJu0YzgmMOCjg9zcykB9TQz+bYLS/ip9UtC2QC0FGqxRNFFcUTH01bS L4u7VRtHfnUv5y93C8RyYyVAV5uVSo7ADPisD5/ZuIFEIoGaEEsWoOE= X-Google-Smtp-Source: AGHT+IHrugdjPYqXmqhJfn0hMlKEONiAqEo1IiNcxFmnh9uDldmjjBx/LckHeGSGTs1SI1ckHLxZOsftjbTu0NCclWE= X-Received: by 2002:a2e:94cd:0:b0:2ca:1990:2585 with SMTP id r13-20020a2e94cd000000b002ca19902585mr226536ljh.79.1702073016108; Fri, 08 Dec 2023 14:03:36 -0800 (PST) MIME-Version: 1.0 References: <50885-1702060132.779123@YSiF.CgC_.vGLi> In-Reply-To: <50885-1702060132.779123@YSiF.CgC_.vGLi> From: Bart Schaefer Date: Fri, 8 Dec 2023 14:03:25 -0800 Message-ID: Subject: Re: PATCH: Avoid \e in C code; building on Solaris 11 To: Oliver Kiddle Cc: Zsh workers Content-Type: multipart/alternative; boundary="00000000000081f28a060c06c122" X-Seq: 52384 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: , List-Subscribe: , List-Unsubscribe: , List-Post: List-Owner: List-Archive: --00000000000081f28a060c06c122 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Dec 8, 2023 at 10:29=E2=80=AFAM Oliver Kiddle 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. --00000000000081f28a060c06c122 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Dec 8, 2023 at 10:29=E2=80=AFAM O= liver Kiddle <opk@zsh.org> wrote:<= /div>
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.
=C2=A0
=
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 proble= m with .sh.edmode seems to be that isset(VIMODE) is false.=C2=A0 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 work= s.
=C2=A0
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 remov= ing .syms files?

Would it work to prefix the awk r= ecipe with "-" to ignore that error, and then append another line= to that recipe to clean up on awk failure?
=C2=A0
B03print fails on Tab expansio= n by print. This is because the test
expects tr '\0' Z to work which it doesn't. Neither does the fu= ll octal
'\000' or $'\0'. I'm not clear on what purpose that tra= iling null has
for the test but it is commented with "regression test for multibyte t= ab
expand".

The test is confirming th= at zexpandtabs() doesn't infinite-loop on broken multibyte input which = might include nul bytes.=C2=A0 Could replace the "tr" with someth= ing else.
=C2=A0
/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 testin= g that /dev/fd/ entries are created when new descriptors are created.=C2=A0= 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
+d= nl a special file system.=C2=A0 As zsh needs arbitrary /dev/fd (typically+dnl >10) for its own use, we need to make sure higher fd's are av= ailable.

Aside from that, there are a couple of failures in W02jobs which I can&= #39;t
repdroduce outside of the test system.

= W02jobs runs everything via zpty, there are some commented-out tests in the= re 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 acco= unted for.

--00000000000081f28a060c06c122--