From: Oliver Kiddle <opk@zsh.org>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Zsh workers <zsh-workers@zsh.org>
Subject: Re: PATCH: Avoid \e in C code; building on Solaris 11
Date: Sun, 10 Dec 2023 00:43:14 +0100 [thread overview]
Message-ID: <20135-1702165394.429946@o8Bt.xo_H.6Uja> (raw)
In-Reply-To: <CAH+w=7ZuvPdqnTVvpZmhW=khZekc6DiTxM6ai6Hi0cmDnfNh5A@mail.gmail.com>
Bart Schaefer wrote:
> /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 [2]configure.ac, not Test/*)
Yes, sorry. However it was something that was only apparent when running
test cases because it caused some to get skipped.
It occurred to me that /bin/sh on Solaris 11 is ksh 93 and that test
consistently doesn't work with ksh (88 or 93). The same applies with
ksh93 on Linux.
> 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.
While that talks about FreeBSD 5, that isn't a situation that has
changed at all. Annoyingly, most package builds take place in a jail
where fdescfs is not mounted so PATH_DEV_FD is probably undefined for
most users on FreeBSD even if they mount fdescfs.
Just doing test -e on /dev/fd/3 gives the same results as the existing
test on FreeBSD both with and without fdescfs. Do you see a problem with
this approach?
Oliver
diff --git a/configure.ac b/configure.ac
index a42758bf3..2871dcb7c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2016,7 +2016,7 @@ AH_TEMPLATE([PATH_DEV_FD],
[Define to the path of the /dev/fd filesystem.])
AC_CACHE_CHECK(for /dev/fd filesystem, zsh_cv_sys_path_dev_fd,
[for zsh_cv_sys_path_dev_fd in /proc/self/fd /dev/fd no; do
- test x`echo ok|(exec 3<&0; cat $zsh_cv_sys_path_dev_fd/3 2>/dev/null;)` = xok && break
+ (exec 3<&0; test -e $zsh_cv_sys_path_dev_fd/3;) && break
done])
if test x$zsh_cv_sys_path_dev_fd != xno; then
AC_DEFINE_UNQUOTED(PATH_DEV_FD, "$zsh_cv_sys_path_dev_fd")
next prev parent reply other threads:[~2023-12-09 23:43 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
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 [this message]
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=20135-1702165394.429946@o8Bt.xo_H.6Uja \
--to=opk@zsh.org \
--cc=schaefer@brasslantern.com \
--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).