shell redirection question

Business_Woman

Business_Woman

Hi,

I ran in to the following scenario. I suspended a job, just to have it run silently in the background.
[1] + suspended sudo make distclean

But when issuing bg >&- it's still spewing text all over my stdout. Why?
 
Are you sure it's only stdout which is being used and not stderr as well? Whenever I need to redirect all output I usually use something in the likes of $ myprogram > /dev/null 2>&1.
 
ShelLuser said:
Are you sure it's only stdout which is being used and not stderr as well? Whenever I need to redirect all output I usually use something in the likes of $ myprogram > /dev/null 2>&1.
Click to expand...

Yes, I am sure. I tried both stdout and stderr.
 
Business_Woman said:
Yes, I am sure. I tried both stdout and stderr.
Click to expand...
I think I nailed it down, indeed easy to overlook. It's not bg which is generating the output which you still see, it's the command you initially halted and then continued in the background.

So the only thing you accomplish with the command you pasted is that any output generated by bg itself won't be shown. But all bg would show is a confirmation that the initial job has been placed in the background.

The only solution I can think of is to stop the compile action, then re-start it while redirecting the output then and there.

It's reasons like these why I always use sysutils/screen.
 
Now this is a perfect example why I love this forum from time to time :)

I personally don't go for cool (not at all) especially when we're talking servers. Then functionality takes priority over everything else. But you know how that goes; this also sometimes leads to tunnel vision (sort off). I use sysutils/screen because it works for me so I never looked back (or around).

But that's not saying it's perfect. As @kpa stated; the suid part of screen is an annoying one. One of those "flaws" you take for granted but you don't like it. Another issue, but I haven't quite figured out if this is because of the way I use it or a flaw in the software itself; I sometimes have issues where one of the screens stalls, and nothing I do can bring it back to live.

Thanks for the tip @wblock@ and @wpa, I'm going to dive into this one (building while I write..). To make it easier on others following the thread, here you can find the official Sourceforge page for tmux and as a bonus; if you're like me you'll now be wondering what the advantages of one over the other could be, I found a very good thread (in my opinion) about this on Stack Exchange right here.

Now, let's not hijack the tread and force it right back to where we were..

Stuff like this intrigues me, especially because I've already noticed quite some differences when comparing my FreeBSD experiences to my (dated) Solaris experiences (for me FreeBSD is a Solaris "replacement").

Many posts on many websites seem to share my idea that you can't simply redirect the output of a background process because it is determined during launch time. And then I came across an IO Redirection thread, also on Stack Exchange. I think it could help you out @Business_Woman.
 
Last edited by a moderator:
ShelLuser said:
Many posts on many websites seem to share my idea that you can't simply redirect the output of a background process because it is determined during launch time. And then I came across an IO Redirection thread, also on Stack Exchange. I think it could help you out @Business_Woman.
Click to expand...
If you look at it from a C perspective, the shell creates the necessary file descriptors for redirection; forks to create the process(es) in the pipeline; dup2s the descriptors over fds 0, 1, and 2 as necessary; sets the process group (etc.); then calls execvp to execute the binaries. I assume suspend will stop the forks right before execvp. A process group canonically consists of all of the processes in a pipeline. The only thing that distinguishes a background process group from a foreground process group is whether the session leader (the shell) has given it control of the terminal. If a process group is in the foreground then the shell just blocks for it to give up terminal control, which is why it doesn't prompt for input. When you Ctrl+Z that sends a SIGSTP to the foreground process group, and if the signal isn't blocked then all of the processes stop and incidentally give up terminal control. bg merely sends the process group a SIGCONT, and fg gives it terminal control with tcsetpgrp.

Kevin Barry
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top