Job resumed in background still outputs to stdout in foreground
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: Hardy (Gnome on Ubuntu 8.04) on Compaq N600c laptop
Posts: 323
Rep:
Job resumed in background still outputs to stdout in foreground
For heehee's I tried
Code:
me$ls -R
ctrl-z
me$bg
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?
Distribution: Hardy (Gnome on Ubuntu 8.04) on Compaq N600c laptop
Posts: 323
Original Poster
Rep:
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 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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.