I've gradually learned to almost always allocate a PTY, whether it be ssh or some docker run. Too many programs work badly or unexpectedly differently when fd 0 or 1 is not a terminal. Maybe we should start collecting a hall of shame for programs that insist on dealing with a terminal, not just a pipe.

Another fun fact I just came across a few weeks ago. The sudo command doesn't always handle job control signals in the way you expect it to. From its manual:

> There are two distinct ways sudo can run a command. If an I/O logging plugin is configured or if the security policy explicitly requests it, a new pseudo-terminal (“pty”) is allocated and fork(2) is used to create a second sudo process, referred to as the monitor. The monitor creates a new terminal session with itself as the leader and the pty as its controlling terminal, calls fork(2), sets up the execution environment as described above, and then uses the execve(2) system call to run the command in the child process. The monitor exists to relay job control signals between the user's existing terminal and the pty the command is being run in. This makes it possible to suspend and resume the command. Without the monitor, the command would be in what POSIX terms an “orphaned process group” and it would not receive any job control signals from the kernel.