zsh-workers
 help / color / mirror / code / Atom feed
* Hang in E01 due to zpty on OpenBSD
@ 2022-04-03 21:42 Matthew Martin
  2022-04-04  1:04 ` Bart Schaefer
  2022-04-04  2:39 ` Jun T
  0 siblings, 2 replies; 15+ messages in thread
From: Matthew Martin @ 2022-04-03 21:42 UTC (permalink / raw)
  To: zsh-workers

E01 hangs on OpenBSD-current when run as the _pbuild user. The line that
hangs is L1435
	zpty subshell $ZTST_testdir/../Src/zsh -f +Z
which is because the read call in Modules/zpty.c L472
	ret = read(master, &syncch, 1);
never returns. I believe this is because the forked child fails to open
the corresponding tty when get_pty is called on 362 and the child exits.
I assume the EPERM on open is an OpenBSD bug, but zsh should probably
not hang either.

I'd appreciate if anyone could confirm the below is an accurate minimal
reproducer to report to OpenBSD.


#include <err.h>
#include <fcntl.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>

static int
get_pty(char *path) {
	const char char1[] = "pqrstuvwxyzPQRST";
	const char char2[] = "0123456789"
	    "abcdefghijklmnopqrstuvwxyz"
	    "ABCDEFGHIJKLMNOPQRSTUVWXYZ";

	const char *p1, *p2;
	int fd;

	strcpy(path, "/dev/ptyxx");

	for (p1 = char1; *p1; p1++) {
		path[8] = *p1;
		for (p2 = char2; *p2; p2++) {
			path[9] = *p2;
			if ((fd = open(path, O_RDWR|O_NOCTTY)) >= 0) {
				return fd;
			}
		}
	}

	return -1;
}

int
main() {
	char path[11];
	int ptyfd, ttyfd;

	if ((ptyfd = get_pty(path)) == -1) {
		err(1, "get_pty");
	}

	printf("%d: %s\n", ptyfd, path);

	path[5] = 't';
	if ((ttyfd = open(path, O_RDWR|O_NOCTTY)) == -1) {
		err(1, "open");
	}

	printf("%d: %s\n", ttyfd, path);
}


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Hang in E01 due to zpty on OpenBSD
  2022-04-03 21:42 Hang in E01 due to zpty on OpenBSD Matthew Martin
@ 2022-04-04  1:04 ` Bart Schaefer
  2022-04-04  2:34   ` Matthew Martin
  2022-04-04  2:39 ` Jun T
  1 sibling, 1 reply; 15+ messages in thread
From: Bart Schaefer @ 2022-04-04  1:04 UTC (permalink / raw)
  To: Zsh hackers list

On Sun, Apr 3, 2022 at 2:43 PM Matthew Martin <phy1729@gmail.com> wrote:
>
> I assume the EPERM on open is an OpenBSD bug, but zsh should probably
> not hang either.

I'm not sure what could be done about this from the zsh code.  The
only reasonable assumption for the pty master-side reader is that the
slave-slide will become closed upon an error and the read will fail.
Using a non-blocking read would defeat the purpose.

I suppose we could skip the test on OpenBSD, but there are a bunch of
later tests that rely on zpty functioning.


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Hang in E01 due to zpty on OpenBSD
  2022-04-04  1:04 ` Bart Schaefer
@ 2022-04-04  2:34   ` Matthew Martin
  2022-04-04  3:49     ` Matthew Martin
  0 siblings, 1 reply; 15+ messages in thread
From: Matthew Martin @ 2022-04-04  2:34 UTC (permalink / raw)
  To: zsh-workers

On Sun, Apr 03, 2022 at 06:04:30PM -0700, Bart Schaefer wrote:
> On Sun, Apr 3, 2022 at 2:43 PM Matthew Martin <phy1729@gmail.com> wrote:
> >
> > I assume the EPERM on open is an OpenBSD bug, but zsh should probably
> > not hang either.
> 
> I'm not sure what could be done about this from the zsh code.  The
> only reasonable assumption for the pty master-side reader is that the
> slave-slide will become closed upon an error and the read will fail.
> Using a non-blocking read would defeat the purpose.

The only reasonable thing I can come up with is open both pty and tty on
the first call to get_pty, so the second call can't fail. 

The tests pass when I use openpty; though since that's in libutil and
I didn't immedietly see a way to link that in, there's a terrible work
around with dlopen/dlsym. I have no intention to commit this.

I've sent a mail to OpenBSD. I don't think this should block the
release. Worst case there will be a patch in the port that can be
upstreamed by the next release.


diff --git a/Src/Modules/zpty.c b/Src/Modules/zpty.c
index dfd2a2a7a..3f21c2b89 100644
--- a/Src/Modules/zpty.c
+++ b/Src/Modules/zpty.c
@@ -37,6 +37,12 @@
 #endif
 #endif
 
+#ifdef __OpenBSD__
+#include <dlfcn.h>
+#include <termios.h>
+#include <util.h>
+#endif
+
 /* The number of bytes we normally read when given no pattern and the
  * upper bound on the number of bytes we read (even if we are give a
  * pattern). */
@@ -161,8 +167,38 @@ getptycmd(char *name)
     return NULL;
 }
 
-/* posix_openpt() seems to have some problem on OpenBSD */
-#if defined(USE_DEV_PTMX) && !defined(__OpenBSD__)
+#if defined(__OpenBSD__)
+
+static int
+get_pty(int master, int *retfd)
+{
+    static int mfd, sfd;
+
+    if (master) {
+	void *handle;
+	int (*openpty)(int *, int *, char *, struct termios *, struct winsize *);
+
+	if ((handle = dlopen("libutil.so", 0)) == NULL) {
+	    return 1;
+	}
+	if ((openpty = dlsym(handle, "openpty")) == NULL) {
+	    dlclose(handle);
+	    return 1;
+	}
+	if (openpty(&mfd, &sfd, NULL, NULL, NULL) == -1) {
+	    dlclose(handle);
+	    return 1;
+	}
+	dlclose(handle);
+	*retfd = mfd;
+	return 0;
+    }
+
+    *retfd = sfd;
+    return 0;
+}
+
+#elif defined(USE_DEV_PTMX)
 
 #ifdef HAVE_SYS_STROPTS_H
 #include <sys/stropts.h>
@@ -261,12 +297,7 @@ get_pty(int master, int *retfd)
 #elif defined(__FreeBSD__) || defined(__DragonFly__)
     static char char1[] = "pqrsPQRS";
     static char char2[] = "0123456789abcdefghijklmnopqrstuv";
-#elif defined(__OpenBSD__)
-    static char char1[] = "pqrstuvwxyzPQRST";
-    static char char2[] = "0123456789"
-                          "abcdefghijklmnopqrstuvwxyz"
-                          "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
-#else /* __FreeBSD__ || __DragonFly__  || __OpenBSD*/
+#else /* __FreeBSD__ || __DragonFly__ */
     static char char1[] = "pqrstuvwxyzPQRST";
     static char char2[] = "0123456789abcdef";
 #endif


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Hang in E01 due to zpty on OpenBSD
  2022-04-03 21:42 Hang in E01 due to zpty on OpenBSD Matthew Martin
  2022-04-04  1:04 ` Bart Schaefer
@ 2022-04-04  2:39 ` Jun T
  2022-04-04  2:51   ` Matthew Martin
  1 sibling, 1 reply; 15+ messages in thread
From: Jun T @ 2022-04-04  2:39 UTC (permalink / raw)
  To: zsh-workers


> 2022/04/04 6:42, Matthew Martin <phy1729@gmail.com> wrote:

> I'd appreciate if anyone could confirm the below is an accurate minimal
> reproducer to report to OpenBSD.

I tried it on OpenBSD-7.0, but it worked (no error):

% doas -u _pbuild ./a.out
3:  /dev/ptyp0
4:  /dev/ttyp0

I also tried build/test the git master (as _pbuild), but it didn't hang.

Did you try manually running zpty?


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Hang in E01 due to zpty on OpenBSD
  2022-04-04  2:39 ` Jun T
@ 2022-04-04  2:51   ` Matthew Martin
  0 siblings, 0 replies; 15+ messages in thread
From: Matthew Martin @ 2022-04-04  2:51 UTC (permalink / raw)
  To: zsh-workers

On Mon, Apr 04, 2022 at 11:39:41AM +0900, Jun T wrote:
> 
> > 2022/04/04 6:42, Matthew Martin <phy1729@gmail.com> wrote:
> 
> > I'd appreciate if anyone could confirm the below is an accurate minimal
> > reproducer to report to OpenBSD.
> 
> I tried it on OpenBSD-7.0, but it worked (no error):
> 
> % doas -u _pbuild ./a.out
> 3:  /dev/ptyp0
> 4:  /dev/ttyp0
> 
> I also tried build/test the git master (as _pbuild), but it didn't hang.
> 
> Did you try manually running zpty?

Yes
	zmodload zsh/pty
	zpty subshell true
would run fine under my user, but not under _pbuild. I'm on -current,
but I suspect the issue has been there for awhile since there's been
a failing test for a few releases.


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Hang in E01 due to zpty on OpenBSD
  2022-04-04  2:34   ` Matthew Martin
@ 2022-04-04  3:49     ` Matthew Martin
  2022-04-04  8:34       ` Jun T
  0 siblings, 1 reply; 15+ messages in thread
From: Matthew Martin @ 2022-04-04  3:49 UTC (permalink / raw)
  To: zsh-workers

On Sun, Apr 03, 2022 at 09:34:07PM -0500, Matthew Martin wrote:
> The tests pass when I use openpty; though since that's in libutil and
> I didn't immedietly see a way to link that in, there's a terrible work
> around with dlopen/dlsym. I have no intention to commit this.

OpenBSD has gutted the pty route and strongly prefers openpty over
posix_openpt. Is there a correct way link the zpty module against
libutil?


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Hang in E01 due to zpty on OpenBSD
  2022-04-04  3:49     ` Matthew Martin
@ 2022-04-04  8:34       ` Jun T
  2022-04-04 11:21         ` Mikael Magnusson
  2022-04-04 13:16         ` Matthew Martin
  0 siblings, 2 replies; 15+ messages in thread
From: Jun T @ 2022-04-04  8:34 UTC (permalink / raw)
  To: zsh-workers


> 2022/04/04 12:49, Matthew Martin <phy1729@gmail.com> wrote:
> 
> OpenBSD has gutted the pty route and strongly prefers openpty over
> posix_openpt. Is there a correct way link the zpty module against
> libutil?

Please try the following patch.
Replace the pattern (in configure.ac)
openbsd*)
by
openbsd7*)
or such if openpty() should be used only on specific versions of OpenBSD.



diff --git a/Src/Modules/zpty.c b/Src/Modules/zpty.c
index dfd2a2a7a..cdab1d8e1 100644
--- a/Src/Modules/zpty.c
+++ b/Src/Modules/zpty.c
@@ -249,6 +249,28 @@ get_pty(int master, int *retfd)
     return 0;
 }
 
+/* openpty() is prefered on OpenBSD */
+#elif defined(__OpenBSD__) && defined(HAVE_OPENPTY)
+
+#include <util.h>
+
+static int
+get_pty(int master, int *retfd)
+{
+    static int mfd, sfd;
+
+    if (master) {
+	if (openpty(&mfd, &sfd, NULL, NULL, NULL) == -1)
+	    return 1;
+
+	*retfd = mfd;
+	return 0;
+    }
+
+    *retfd = sfd;
+    return 0;
+}
+
 #else /* No /dev/ptmx or no pt functions */
 
 static int
diff --git a/configure.ac b/configure.ac
index 8bba78c56..6aae71300 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2441,6 +2441,18 @@ int ptsname();]], [[]])],[ac_cv_use_dev_ptmx=no],[ac_cv_use_dev_ptmx=yes])])
    fi
 fi
 
+dnl On (some) OpenBSD, it seems openpty() is the only reliable way to get pty.
+AH_TEMPLATE([HAVE_OPENPTY],
+[Define to 1 if openpt() is available on OpenBSD])
+case "$host_os" in
+  openbsd*)
+    AC_SEARCH_LIBS(openpty, util)
+    if test x$ac_cv_search_openpty != xno; then
+      AC_DEFINE(HAVE_OPENPTY)
+    fi
+    ;;
+esac
+
 dnl -----------------
 dnl multibyte support
 dnl -----------------





^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Hang in E01 due to zpty on OpenBSD
  2022-04-04  8:34       ` Jun T
@ 2022-04-04 11:21         ` Mikael Magnusson
  2022-04-04 13:16         ` Matthew Martin
  1 sibling, 0 replies; 15+ messages in thread
From: Mikael Magnusson @ 2022-04-04 11:21 UTC (permalink / raw)
  To: Jun T; +Cc: zsh-workers

On 4/4/22, Jun T <takimoto-j@kba.biglobe.ne.jp> wrote:
>
> Please try the following patch.
>
> diff --git a/Src/Modules/zpty.c b/Src/Modules/zpty.c
> index dfd2a2a7a..cdab1d8e1 100644
> --- a/Src/Modules/zpty.c
> +++ b/Src/Modules/zpty.c
> diff --git a/configure.ac b/configure.ac
> index 8bba78c56..6aae71300 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2441,6 +2441,18 @@ int ptsname();]],
> [[]])],[ac_cv_use_dev_ptmx=no],[ac_cv_use_dev_ptmx=yes])])
>     fi
>  fi
>
> +dnl On (some) OpenBSD, it seems openpty() is the only reliable way to get
> pty.
> +AH_TEMPLATE([HAVE_OPENPTY],
> +[Define to 1 if openpt() is available on OpenBSD])

Missing y here in openpty.


-- 
Mikael Magnusson


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Hang in E01 due to zpty on OpenBSD
  2022-04-04  8:34       ` Jun T
  2022-04-04 11:21         ` Mikael Magnusson
@ 2022-04-04 13:16         ` Matthew Martin
  2022-04-06  5:48           ` Jun T
  1 sibling, 1 reply; 15+ messages in thread
From: Matthew Martin @ 2022-04-04 13:16 UTC (permalink / raw)
  To: zsh-workers

On Mon, Apr 04, 2022 at 05:34:09PM +0900, Jun T wrote:
> 
> > 2022/04/04 12:49, Matthew Martin <phy1729@gmail.com> wrote:
> > 
> > OpenBSD has gutted the pty route and strongly prefers openpty over
> > posix_openpt. Is there a correct way link the zpty module against
> > libutil?
> 
> Please try the following patch.

I had tried a similar patch, but since openpty is in libutil, that needs
to be linked in which is why I have the dlopen/dlsym calls in 49980.

> Replace the pattern (in configure.ac)
> openbsd*)
> by
> openbsd7*)
> or such if openpty() should be used only on specific versions of OpenBSD.

I would only support OpenBSD-current unless anyone objects. Each release
gets a corresponding snapshot of the ports tree and then only security
updates are accepted for that version.


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Hang in E01 due to zpty on OpenBSD
  2022-04-04 13:16         ` Matthew Martin
@ 2022-04-06  5:48           ` Jun T
  2022-04-06 12:53             ` Matthew Martin
  0 siblings, 1 reply; 15+ messages in thread
From: Jun T @ 2022-04-06  5:48 UTC (permalink / raw)
  To: zsh-workers


> 2022/04/04 22:16, Matthew Martin <phy1729@gmail.com> wrote:
> 
> On Mon, Apr 04, 2022 at 05:34:09PM +0900, Jun T wrote:
> 
>> Replace the pattern (in configure.ac)
>> openbsd*)
>> by
>> openbsd7*)
>> or such if openpty() should be used only on specific versions of OpenBSD.
> 
> I would only support OpenBSD-current unless anyone objects

We can't specify -current here.
I've upgraded to OpenBSD-7.1 but still can't reproduce your problem.

But since openpty() works fine on OpenBSD7.0/7.1, I will push the patch
with 'openbsd7*)' (with Mikael's fix of typo) if there is no objection.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Hang in E01 due to zpty on OpenBSD
  2022-04-06  5:48           ` Jun T
@ 2022-04-06 12:53             ` Matthew Martin
  2022-04-06 20:12               ` Bart Schaefer
  2022-04-07  3:47               ` Jun T
  0 siblings, 2 replies; 15+ messages in thread
From: Matthew Martin @ 2022-04-06 12:53 UTC (permalink / raw)
  To: zsh-workers

On Wed, Apr 06, 2022 at 02:48:00PM +0900, Jun T wrote:
> 
> > 2022/04/04 22:16, Matthew Martin <phy1729@gmail.com> wrote:
> > 
> > On Mon, Apr 04, 2022 at 05:34:09PM +0900, Jun T wrote:
> > 
> >> Replace the pattern (in configure.ac)
> >> openbsd*)
> >> by
> >> openbsd7*)
> >> or such if openpty() should be used only on specific versions of OpenBSD.
> > 
> > I would only support OpenBSD-current unless anyone objects
> 
> We can't specify -current here.
> I've upgraded to OpenBSD-7.1 but still can't reproduce your problem.
> 
> But since openpty() works fine on OpenBSD7.0/7.1, I will push the patch
> with 'openbsd7*)' (with Mikael's fix of typo) if there is no objection.

I'd prefer something like the below where it's a feature test instead of
an OS test.

diff --git a/Src/Modules/zpty.c b/Src/Modules/zpty.c
index dfd2a2a7a..f4c95537d 100644
--- a/Src/Modules/zpty.c
+++ b/Src/Modules/zpty.c
@@ -37,6 +37,15 @@
 #endif
 #endif
 
+#ifdef HAVE_OPENPTY
+#ifdef OPENPTY_REQUIRES_PTY
+#include <pty.h>
+#elif defined(OPENPTY_REQUIRES_UTIL)
+#include <termios.h>
+#include <util.h>
+#endif
+#endif
+
 /* The number of bytes we normally read when given no pattern and the
  * upper bound on the number of bytes we read (even if we are give a
  * pattern). */
@@ -161,8 +170,26 @@ getptycmd(char *name)
     return NULL;
 }
 
-/* posix_openpt() seems to have some problem on OpenBSD */
-#if defined(USE_DEV_PTMX) && !defined(__OpenBSD__)
+#ifdef HAVE_OPENPTY
+
+static int
+get_pty(int master, int *retfd)
+{
+    static int mfd, sfd;
+
+    if (master) {
+	if (openpty(&mfd, &sfd, NULL, NULL, NULL) == -1) {
+	    return 1;
+	}
+	*retfd = mfd;
+	return 0;
+    }
+
+    *retfd = sfd;
+    return 0;
+}
+
+#elifdef USE_DEV_PTMX
 
 #ifdef HAVE_SYS_STROPTS_H
 #include <sys/stropts.h>
@@ -261,12 +288,7 @@ get_pty(int master, int *retfd)
 #elif defined(__FreeBSD__) || defined(__DragonFly__)
     static char char1[] = "pqrsPQRS";
     static char char2[] = "0123456789abcdefghijklmnopqrstuv";
-#elif defined(__OpenBSD__)
-    static char char1[] = "pqrstuvwxyzPQRST";
-    static char char2[] = "0123456789"
-                          "abcdefghijklmnopqrstuvwxyz"
-                          "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
-#else /* __FreeBSD__ || __DragonFly__  || __OpenBSD*/
+#else /* __FreeBSD__ || __DragonFly__ */
     static char char1[] = "pqrstuvwxyzPQRST";
     static char char2[] = "0123456789abcdef";
 #endif
diff --git a/configure.ac b/configure.ac
index 8bba78c56..e3ff0aca4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2400,6 +2400,37 @@ dnl ---------------
 
 zsh_CHECK_SOCKLEN_T
 
+dnl ---------------
+dnl Check for openpty support
+dnl ---------------
+AH_TEMPLATE([HAVE_OPENPTY],
+  [Define to 1 if you have the `openpty' function.])
+AH_TEMPLATE([OPENPTY_REQUIRES_PTY],
+  [Define to 1 if the `openpty' function requires pty.h.])
+AH_TEMPLATE([OPENPTY_REQUIRES_UTIL],
+  [Define to 1 if the `openpty' function requires termios.h and util.h.])
+AC_MSG_CHECKING([for openpty])
+openpty=no
+AC_LINK_IFELSE([AC_LANG_SOURCE(
+[[#include<pty.h>
+int main () { int (*p)(int *, int *, char *, const struct termios *, const struct winsize *) = openpty; }]])],
+  [AC_DEFINE([HAVE_OPENPTY])
+   AC_DEFINE([OPENPTY_REQUIRES_PTY])
+   openpty=yes])
+if test $openpty = no; then
+AC_LINK_IFELSE([AC_LANG_SOURCE(
+[[#include<termios.h>
+#include <util.h>
+int main () { int (*p)(int *, int *, char *, const struct termios *, const struct winsize *) = openpty; }]])],
+  [AC_DEFINE([HAVE_OPENPTY])
+   AC_DEFINE([OPENPTY_REQUIRES_UTIL])
+   openpty=yes])
+fi
+AC_MSG_RESULT([$openpty])
+if test $openpty = yes; then
+AC_SEARCH_LIBS(openpty, util)
+fi
+
 dnl ---------------
 dnl Check for pty multiplexer for use in pty module.
 dnl We need to open it read/write, so make sure it is writeable.


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Hang in E01 due to zpty on OpenBSD
  2022-04-06 12:53             ` Matthew Martin
@ 2022-04-06 20:12               ` Bart Schaefer
  2022-04-07  3:47               ` Jun T
  1 sibling, 0 replies; 15+ messages in thread
From: Bart Schaefer @ 2022-04-06 20:12 UTC (permalink / raw)
  To: Zsh hackers list

On Wed, Apr 6, 2022 at 5:55 AM Matthew Martin <phy1729@gmail.com> wrote:
>
> I'd prefer something like the below where it's a feature test instead of
> an OS test.

+1


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Hang in E01 due to zpty on OpenBSD
  2022-04-06 12:53             ` Matthew Martin
  2022-04-06 20:12               ` Bart Schaefer
@ 2022-04-07  3:47               ` Jun T
  2022-04-07  4:52                 ` Matthew Martin
  1 sibling, 1 reply; 15+ messages in thread
From: Jun T @ 2022-04-07  3:47 UTC (permalink / raw)
  To: zsh-workers


> 2022/04/06 21:53, Matthew Martin <phy1729@gmail.com> wrote:
> 
> I'd prefer something like the below where it's a feature test instead of
> an OS test.

I was thinking that we should better minimize the possible side effects
just before the new release.

If we use your patch (with some fixes) openpty() will be used on ALL systems
(Linux, other BSDs and macOS, ...) if it is available. Is this what you
want to achieve? It may work but we need to test on lots of systems.


> diff --git a/Src/Modules/zpty.c b/Src/Modules/zpty.c
(snip)
> +#elifdef USE_DEV_PTMX
#elif defined(USE_DEV_PTMX)

> -#elif defined(__OpenBSD__)
> -    static char char1[] = "pqrstuvwxyzPQRST";
> -    static char char2[] = "0123456789"
> -                          "abcdefghijklmnopqrstuvwxyz"
> -                          "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
I think we need to keep this in case openpty() is not available on OpenBSD.

> diff --git a/configure.ac b/configure.ac
(snip)
> +AC_MSG_CHECKING([for openpty])
> +openpty=no

We need to call AC_SEARCH_LIBS(openpty, util) here to add -lutil to LIBS.
Otherwise the following two AC_LINK_IFELSE() fail and openpty() will never
be used.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Hang in E01 due to zpty on OpenBSD
  2022-04-07  3:47               ` Jun T
@ 2022-04-07  4:52                 ` Matthew Martin
  2022-04-08  7:51                   ` Jun T
  0 siblings, 1 reply; 15+ messages in thread
From: Matthew Martin @ 2022-04-07  4:52 UTC (permalink / raw)
  To: zsh-workers

On Thu, Apr 07, 2022 at 12:47:18PM +0900, Jun T wrote:
> 
> > 2022/04/06 21:53, Matthew Martin <phy1729@gmail.com> wrote:
> > 
> > I'd prefer something like the below where it's a feature test instead of
> > an OS test.
> 
> I was thinking that we should better minimize the possible side effects
> just before the new release.
> 
> If we use your patch (with some fixes) openpty() will be used on ALL systems
> (Linux, other BSDs and macOS, ...) if it is available. Is this what you
> want to achieve? It may work but we need to test on lots of systems.

I was thinking I'd wait until after the release and put the patch in the
OpenBSD port until the next release. That way things are fixed with no
need to rush.

> > diff --git a/Src/Modules/zpty.c b/Src/Modules/zpty.c
> (snip)
> > +#elifdef USE_DEV_PTMX
> #elif defined(USE_DEV_PTMX)
> 
> > -#elif defined(__OpenBSD__)
> > -    static char char1[] = "pqrstuvwxyzPQRST";
> > -    static char char2[] = "0123456789"
> > -                          "abcdefghijklmnopqrstuvwxyz"
> > -                          "ABCDEFGHIJKLMNOPQRSTUVWXYZ";

They no longer really support the /dev/ptyxx route. When I asked the
response I got was, why do you think that should work it's dead and
archaic. If openpty is removed in the future, falling back to /dev/pty
is unlikely to be an option.

> > diff --git a/configure.ac b/configure.ac
> (snip)
> > +AC_MSG_CHECKING([for openpty])
> > +openpty=no
> 
> We need to call AC_SEARCH_LIBS(openpty, util) here to add -lutil to LIBS.
> Otherwise the following two AC_LINK_IFELSE() fail and openpty() will never
> be used.

It worked here, but I don't claim to be an auto* expert. So just put the
AC_SEARCH_LIBS before AC_MSG_CHECKING (otherwise the output is mixed up)?


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Hang in E01 due to zpty on OpenBSD
  2022-04-07  4:52                 ` Matthew Martin
@ 2022-04-08  7:51                   ` Jun T
  0 siblings, 0 replies; 15+ messages in thread
From: Jun T @ 2022-04-08  7:51 UTC (permalink / raw)
  To: zsh-workers


> 2022/04/07 13:52, Matthew Martin <phy1729@gmail.com> wrote:
> 
> I was thinking I'd wait until after the release and put the patch in the
> OpenBSD port until the next release. That way things are fixed with no
> need to rush.

OK, but for the next release:

I tried openpty() on Fedora-35 but it didn't work (W02jobs hangs).
posix_openpt() does not work on OpenBSD.
I can't think of any simple way to decide which of them to use
other than using OS test.

# or maybe we need to make zpty more robust?, but how?


^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2022-04-08  7:52 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-03 21:42 Hang in E01 due to zpty on OpenBSD Matthew Martin
2022-04-04  1:04 ` Bart Schaefer
2022-04-04  2:34   ` Matthew Martin
2022-04-04  3:49     ` Matthew Martin
2022-04-04  8:34       ` Jun T
2022-04-04 11:21         ` Mikael Magnusson
2022-04-04 13:16         ` Matthew Martin
2022-04-06  5:48           ` Jun T
2022-04-06 12:53             ` Matthew Martin
2022-04-06 20:12               ` Bart Schaefer
2022-04-07  3:47               ` Jun T
2022-04-07  4:52                 ` Matthew Martin
2022-04-08  7:51                   ` Jun T
2022-04-04  2:39 ` Jun T
2022-04-04  2:51   ` Matthew Martin

Code repositories for project(s) associated with this 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).