[hackers] [st][PATCH] fix a problem that the standard streams are unexpectedly closed

From: Koichi Murase <myoga.murase_AT_gmail.com>
Date: Thu, 19 Aug 2021 17:00:34 +0900

Hello, is this the right place to send a patch for st (simple
terminal)? This is the first time for me to submit a patch to
suckless.org. I'm not familiar with the development flow of suckless
software. If I should have completed something before submitting the
patch (for example, opening a discussion in another mailing list
dev_AT_suckless.org in prior to sending the patch), please feel free to
tell me that. I'd be happy to follow the standard procedure.

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:

  I attach a patch file:

  - st-DontCloseStandardStreamsUnexpectedly-20210819-2ec571a.diff

  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):

------------------------------------------------------------------------
Received on Thu Aug 19 2021 - 10:00:34 CEST