Job resumed in background still outputs to stdout in foreground
 

For heehee's I tried

but the output of the dir listing resumed before my eyes. I thought bg meant resume in background, which meant...in the background. Which, I guess I thought meant resume it but disconnect stdio from it and connect it to a new command prompt. Of course, I'm not entirely sure what I mean by "a new command prompt", exactly.

What exactly is happening with these commands, then?

Running a process in the background allows you to continue working but it doesn't necessarily disconnect stdin, stdout or stderr.

Disconnection from stdin is done via the "nohup" command. You can dispose of stdin and stderr with something like "ls -al > /dev/null 2>&1".

I see. Seems like that would kind of detract from the usefulness of bg, though. Why put X in the "background" if in fact its presence is still much in the fore? If I want something to run somewhere while still allowing me to run new stuff, then I'd think it would be a nuisance, if not impossible, to do so since the first task keeps obstructing the i/o of the second.

Not trying to be argumentative, really. Just trying to understand the utility of the function is all. In any case, thanks for the reply.

I don't disagree.

If the program you're putting in the background is well behaved enough it's OK, but many are not. Try getting "top" to run in the background sometime. It just doesn't know what to do there.

The real benefit of "nohup XYZ > /dev/null &" is in automated batch processes that will execute via cron or init without the benefit of a keyboard or screen. It allows the program to open stdin/out and continue. For interactive use, the existence of multiple virtual terms or an xterms generally makes "&" the third best choice.