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
Received on Mon Aug 23 2021 - 03:52:19 CEST