How to prevent child process to interfere with bash prompt?

Question

The application in question is DaVinci Resolve. I start it from terminal. And when I close it, the message "Socket Disconnected" from the app is written to the terminal output. Then the bash prompt appears as normal. I start typing the new command, and suddenly another message appears in terminal "Socket Disconnected". And this interferes with the input I made. It looks like this:

[andrew@unihost ~]$ davinci-resolve
... # Now I exit the application.
Host 'Fusion' Removed
FusionScript Server [37457] Terminated
Socket disconnected
[andrew@unihost ~]$ ls ls Socket disconnected
wtf!!!^C
[andrew@unihost ~]$

Video demo: https://youtu.be/arcCOjrN7kw

Why this is happening and is there a way to prevent this?

My guess is that there is subprocess of the main process, which still is alive even after main process dies. I have found this answer. Is that the developer's fault? Can I workaround this somehow (maybe nohup for child process)?

Answer 1

Preliminary note

I haven't tested davinci-resolve at all. This answer is designed to be generic.

---

Analysis

Your shell waits for davinci-resolve to exit before it puts itself back in the foreground and prints the prompt. Apparently some child (or further descendant) of the main davinci-resolve prints the unwanted message after the main process exits and the shell reacts.

---

Solution

A solution may be as easy as:

davinci-resolve | cat

The trick is cat won't exit until all processes writing to the pipe close their end of the pipe. The troublesome child probably inherits the stdout from the main davinci-resolve, so cat will wait for it. Normally this will work even if the unwanted message is printed to stderr or /dev/tty (i.e. it bypasses our cat). What matters is the child keeps the pipe open, even if it's printing to elsewhere.

There are disadvantages:

• The exit status of the entire pipe will come from cat, not from davinci-resolve. In some shells you can do something about it.

• stdout and stderr from davinci-resolve (and its descendants) will lose sync because the former goes via cat and the latter doesn't.

• If you Ctrl+c then you will kill the cat, possibly before the other processes finish printing, so you may miss some output you do want to see. Additionally if the troublesome message gets printed to stderr then it will be printed anyway, possibly after you see the prompt.

  You can make the cat immune to Ctrl+c though:

  davinci-resolve | sh -c 'trap "" INT; exec cat'
  

• The troublesome process may close or redirect its stdout early and still print to stderr. In this case cat will not wait for it.

• The troublesome process may be designed to remain and the unwanted message does not mean the process exits. If the process remains and keeps the pipe open then our cat will remain; you obviously don't want this. It seems unlikely any descendant of davinci-resolve remains (unless there's a bug), but in general it may happen.

For some of these reasons you may want to pass stdout and stderr via cat. Making the cat immune to Ctrl+c is still a good idea:

  davinci-resolve 2>&1 | sh -c 'trap "" INT; exec cat'

Note now you cannot tell apart stderr of davinci-resolve (and its descendants) from stdout, they both go via cat and its stdout. It shouldn't be a problem, as you wanted them to mix in the terminal anyway. If you ever want to redirect or capture them separately then you should drop our contraption and start from scratch.

It may be the troublesome process closes or redirects its stdout and stderr early, and it prints the unwanted message directly to /dev/tty (example). In this case our cat cannot help.

---

Shell function

You can implement our solution as a shell function:

davinci-resolve() {
   command davinci-resolve "$@" 2>&1 | sh -c 'trap "" INT; exec cat'
}

The function supports passing arguments to davinci-resolve, but its exit status comes from cat, not from davinci-resolve process (if it's a problem then see the already given link for ideas).

Answer 2

The background process is not actually interfering with your shell, it's just scribbling on your screen and the output from the background process and the shell are mixing.

There are several approaches to fix this:

• You can use something like nohup or file redirection to remove the messages from your terminal, possibly saving them to a file.
• You can ignore the mess and just keep typing, or if you haven't typed anything, just hit return to get a fresh prompt.
• You can read the messages sent by the background process and then use a command line editing keystroke to refresh what you typed and make it readable again. In a plain cooked terminal mode, Ctrl-R will do this. In many other applications like bash, Ctrl-L will clear the screen and reprint the prompt and what you typed.
• You could run that application in a dedicated window and use the power of a graphical windowing system to open another window that is not polluted with its output. :) (I keep a small window off to the side just to run such noisy applications.)
• If this is occurring after you have ended the application, and it has left worker threads behind that you want to discontinue, you may be able to find them with ps -t (to show what is running on the current terminal) and kill them.

Answer 3

You can type control-l to clear the screen. This will clear the "Socket disconnected" messages but will keep your command prompt and partially written command intact. Unfortunately it will also clear the output of davinci-resolve, which may or may not be okay for what you're trying to do.

Answer 4

If the "Socket disconnected" messages come pretty quickly after the main process exits, you could add ; sleep 2 to your command and put it in a shell alias. It would basically be a way to remind yourself not to type a new command right away. To do this, add

alias davinci-resolve="davinci-resolve; sleep 2"

to your .bashrc