After the advice from Alex Pilon, I update the commit message and resend the patch using `git send-email'. Here's the description of this fix (which is essentially the same as the previous post https://lists.suckless.org/hackers/2108/17978.html).
Problem: When st is started with fd 0, 1, and 2 being closed, some of the standard streams (file descriptors 0, 1, and 2) are closed in the child process (i.e., the shell process). Description: In the current implementation, the slave PTY (assigned to the variable `s') is always closed after duplicating it to file descriptors of standard streams (0, 1, and 2). However, when the allocated slave PTY `s' is already one of 0, 1, or 2, this causes the unexpected closing of a standard stream. The same problem occurs when the file descriptor of the master PTY (the variable `m') is one of 0, 1, or 2. Repeat-By: The problem can be reproduced by e.g. starting `st' with file descriptors 0, 1, and 2 being closed: $ st 0<&- 1>&- 2>&- Then in the opened `st' window, $ echo hello[RET] will produce the following error messages from Bash (when the shell is Bash): bash: echo: write error: Bad file descriptor bash: echo: write error: Bad file descriptor This is because the standard error output (fd 2) is unexpectedly closed. Fix: In this patch, the original master PTY (m) is closed before it would be overwritten by duplicated slave PTYs. The original slave PTY (s) is closed only when it is not one of the standard streams. Here's also the inline copy of the patch (though my email client breaks the whitespaces): Koichi Murase (1): fix a problem that the standard streams are unexpectedly closed st.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- 2.21.3
