Handle terminal output of background processes better?

aardwolf · 2013-06-06 08:36:46

When a process started from the terminal runs as background process and outputs stuff, its text just appears right there in your terminal after your prompt. This is very annoying and confusing, it hides the prompt or does as if something is typed and renders it badly.

Is there any way to make bash handle background process output differently to handle this better? For example not output it at all, or render a new prompt below the output whenever such output appears?

Note: This is about a background process being spawned as part of another process (involving, amongst other things, git). Redirecting to /dev/null does not help, I WANT to see the output of the foreground process, but not of the background process it internally spawns.

Thanks.

Last edited by aardwolf (2013-06-06 08:38:08)

drcouzelis · 2013-06-06 13:15:39

EDIT: I accidentally editted this post instead of writing a new one. Oops. I don't remember what used to be here. It was something about

drcouzelis wrote:

I think the more specific you are about what you want to do (which application, which output...) the easier it will be for other people to help you.

And something about this thread maybe being able to help: https://bbs.archlinux.org/viewtopic.php?id=153737

Last edited by drcouzelis (2013-06-10 16:31:37)

Trilby · 2013-06-06 13:23:43

I agree more specifics are needed. You refer to nested processes - so you launch process A, and process A launches B in the background. In that scenario, the only way to affect B's output without affecting A's output is to change how A starts B. And this would, of course, depend on what A is.

aardwolf · 2013-06-10 15:39:24

One foreground terminal process spawns a version control system in the background, submits something, and quits. This takes only a few seconds. That background process, randomly, may take a few seconds longer or shorter. If it takes longer, then it will output something about "connecting to blah blah" AFTER the foreground process has completed. And the annoying thing about that is that then that text is drawn after the empty prompt, making it seem as if that text was typed in the prompt, and confusing the rendering of history when using ctrl+r or up arrow.

That is very annoying and I would prefer the terminal to render this background process output not in a dumb way right after the prompt, but render a new empty prompt below (or alternatively not render the background process output at all). Is that possible?

2ManyDogs · 2013-06-10 15:45:05

aardwolf wrote:

That is very annoying and I would prefer the terminal to render this background process output not in a dumb way right after the prompt, but render a new empty prompt below (or alternatively not render the background process output at all). Is that possible?

Did you read all of drcouzelis' post, and the thread he linked? There are several ways to prevent the background process from printing output.

aardwolf · 2013-06-10 15:49:13

But I don't want to redirect output of the *foreground* application! Also I already use a colored prompt. And I can't change the way the foregrounds app launches the background app.

I just want bash, and/or Konsole, to be like "hey, I am awaiting the users input in this empty prompt, and suddenly I am receiving some output from some background process in this window! I should render this text in such a way that the user can still properly see their empty promt!".

Last edited by aardwolf (2013-06-10 15:55:32)

Trilby · 2013-06-10 16:26:49

Those background processes are not sending anything to bash - bash knows nothing of their existence. They just happen to send output to the same place bash sends output. You could in principle have bash continually resend the PS1. This would solve the problem you describe, but it would create *many* others; it would make the terminal virtually unusable. The shell (bash) has no way to know when the terminal has been 'dirtied' and when it should send a new prompt.

There may be other ways of solving this particular problem, but they won't be forthcoming when your desciptions are limited to "some foreground process" and "Blah blah blah".

As an aside, any tool/process that backgrounds a subprocess without handling it's output would be considered - in my book - broken. If you do not have control of it yourself, I'd file a bug report with whoever does.

Not only does bash have no way of knowing when the terminal has been 'dirtied', but neither would the terminal. The terminal knows when it has displayed text to the screen, but it has no way of knowing if this came from you, some ongoing process, or some background process. So even if the terminal itself triggered bash to send a fresh prompt, it'd have no way of knowing when to do so.

Last edited by Trilby (2013-06-10 16:41:54)

drcouzelis · 2013-06-10 16:28:39

drcouzelis wrote:

I think the more specific you are about what you want to do (which application, which output...) the easier it will be for other people to help you.

aardwolf wrote:

One foreground terminal process...
a version control system...
submits something...

This isn't helping. What applications are you using? What commands are you typing to run them?

If an application is going to run something in the background and you have no way of changing it, I'm not sure how many options you have.

There might be a way to temporarily change the definition of STDOUT and STDERR to, for example, a temprorary file. Then you can look at it at your convenience. Maybe someone else can help you do that.

As a simple solution, can you just use two terminal windows: one for work and one for the version control software?

jakobcreutzfeldt · 2013-06-10 16:33:54

aardwolf wrote:

And I can't change the way the foregrounds app launches the background app.

Why not? Is it proprietary? That may be your only solution (i.e. have the parent application wait for the child process to finish before exiting).

aardwolf · 2013-06-10 17:59:40

Ok... if it isn't bash rendering the text (I assume it was), how is the process called that draws the terminal characters on screen (be it a text mode full screen, or a terminal window)?

drcouzelis · 2013-06-10 18:10:11

aardwolf wrote:

if it isn't bash rendering the text, how is the process called that draws the terminal characters on screen?

A process will send text to STDOUT and STDERR and the terminal emulator displays it.

...I think.

Trilby · 2013-06-10 18:45:30

Yes, this is the terminal. Bash knows nothing of your screen. Bash - like most programs - reads a data stream from stdin, and writes output to stdout or stderr. The terminal is what allows you to use a keyboard to send information to the shell's stdin, and this terminal is what converts the shell's stdout and stderr into characters on the screen.

The issue you are facing is that some (yet unnamed!) process is backgrounding some other (yet unnamed!) process then returning control to the shell (bash). So bash sends the PS1 characters on it's stdout, the terminal gets these characters and draws them on the screen. But the terminal is also getting the stdout or stderr from that backgrounded process. Both bash's PS1 characters and the backgrounded process's output are being dumped into the terminal's input. The terminal has no way to know which is which, it just faithfully draws each on the screen.

It is easy to screw this up when backgrounding processes. Most people remember to direct the stdout somewhere (/path/to/subprocess >/dev/null &), but sometimes forget to redirect stderr (/path/to/subprocess >/dev/null 2>&1 &). If this is not properly done, there is nothing you can do about it at the level of the terminal.

This is why we've asked, again and again, to know what processes you are actually talking about as the only solution is to fix the poorly behaving process which backgrounds something else without managing the output.

Last edited by Trilby (2013-06-10 18:46:20)

AdamCDunlap · 2013-06-11 02:18:07

zsh handles this problem quite nicely. When it notices that something has been printed to the terminal after the prompt, it redraws the prompt. It also manages to not have the prompt be on the same line as the last line of text if there's no trailing newline, which is nice.

% ( sleep 5; echo NOPE ) &                 
[1] 3519
% NOPE

[1]  + done       ( sleep 5; echo NOPE; )
%

This happened without me typing anything after the sleep line. % is the prompt.

Trilby · 2013-06-11 02:37:33

No, that is a bad example. It redraws the prompt because it got a signal that the process completed.

Try the following, it will *not* redraw the prompt after "NOPE":

(sleep 5; echo NOPE; sleep 5) &

Actually I think bash handles this much better. Neither shell refreshes the prompt when interupted by "NOPE" as they have no way to know that was printed. But bash also holds the information about the terminated sub process until the next prompt. In zsh it will interrupt you in mid command if you are typing something.

Last edited by Trilby (2013-06-11 02:43:49)

AdamCDunlap · 2013-06-13 06:37:49

Trilby wrote:

No, that is a bad example. It redraws the prompt because it got a signal that the process completed.
Try the following, it will *not* redraw the prompt after "NOPE":
(sleep 5; echo NOPE; sleep 5) &

Oh, interesting. That's too bad.

Actually I think bash handles this much better. Neither shell refreshes the prompt when interupted by "NOPE" as they have no way to know that was printed. But bash also holds the information about the terminated sub process until the next prompt. In zsh it will interrupt you in mid command if you are typing something.

This is configurable in both. In bash it's set +b or set -b and in zsh its setopt notify or setopt nonotify

Arch Linux

#1 2013-06-06 08:36:46

Handle terminal output of background processes better?

#2 2013-06-06 13:15:39

Re: Handle terminal output of background processes better?

#3 2013-06-06 13:23:43

Re: Handle terminal output of background processes better?

#4 2013-06-10 15:39:24

Re: Handle terminal output of background processes better?

#5 2013-06-10 15:45:05

Re: Handle terminal output of background processes better?

#6 2013-06-10 15:49:13

Re: Handle terminal output of background processes better?

#7 2013-06-10 16:26:49

Re: Handle terminal output of background processes better?

#8 2013-06-10 16:28:39

Re: Handle terminal output of background processes better?

#9 2013-06-10 16:33:54

Re: Handle terminal output of background processes better?

#10 2013-06-10 17:59:40

Re: Handle terminal output of background processes better?

#11 2013-06-10 18:10:11

Re: Handle terminal output of background processes better?

#12 2013-06-10 18:45:30

Re: Handle terminal output of background processes better?

#13 2013-06-11 02:18:07

Re: Handle terminal output of background processes better?

#14 2013-06-11 02:37:33

Re: Handle terminal output of background processes better?

#15 2013-06-13 06:37:49

Re: Handle terminal output of background processes better?

Board footer