NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

xsrc/59548: luit(1): initial winsize is 0



>Number:         59548
>Category:       xsrc
>Synopsis:       luit(1): initial winsize is 0
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    xsrc-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jul 24 08:10:00 +0000 2025
>Originator:     RVP
>Release:        NetBSD-10.99.15
>Organization:
>Environment:
NetBSD-10.99.15 on amd64
>Description:
When xterm(1) is run in a non-UTF-8 locale, it invokes luit(1) to
convert I/O chars. from the current charset to UTF-8 and back.

luit(1), however, comes up with an initial window size of 0 (rows &
cols) until the xterm window is resized. Programs like vi(1), which
rely on a proper window dimensions being set, act wonky.

The sizes are 0 because:

1. On a new open of a tty device, the kernel memset()s the window size
   to 0. (See [1]--I'm assuming this is historical BSD behaviour, so
   I'm not simply commenting out that line.)

2. luit(1) itself does this wrong: first it sets the window size on the
   PTY master, _then_ the child opens the corresponding slave (ie. the
   reverse of how openpty(3) does it).

[1]: https://github.com/NetBSD/src/blob/trunk/sys/kern/tty.c#L443

>How-To-Repeat:
LC_ALL=C xterm -e 'stty -a; read'
>Fix:
---START patch---
diff -purN xsrc/external/mit/luit.orig/dist/luit.c xsrc/external/mit/luit/dist/luit.c
--- xsrc/external/mit/luit.orig/dist/luit.c	2023-08-11 18:34:32.000000000 +0000
+++ xsrc/external/mit/luit/dist/luit.c	2025-07-24 07:12:39.785745755 +0000
@@ -501,6 +501,9 @@ setup_io(int pty)
     }
 
     setWindowSize(0, pty);
+#ifdef SIGWINCH
+    raise(SIGWINCH);	/* force parent to set win-size before 1st I/O */
+#endif
 
     return rc;
 }
---END patch---

This suffices for the in-tree luit(1). You can also do it the openpty(3)
way by opening the slave PTY, then setting the winsize[2], but, if you
go this route, then it's better to just import Tom Dickey's luit[3]
because upstream has stopped supporting this program[4].

[2]: https://github.com/ThomasDickey/luit-snapshots/blob/master/luit.c#L790
[3]: https://invisible-island.net/luit/
[4]: https://gitlab.freedesktop.org/xorg/app/luit/-/commit/2aaa5d75f1b92a5383af676dbd7f0998e26023ac



Home | Main Index | Thread Index | Old Index