Job management in bash

[michaelsanford]

I've got S@H running on my Slackware machine with the following command...
alias setibg='cd /root/sah;setiathome -nice 19 > /dev/null &;cd $OLDPWD'

...which starts s@h in the background, giving me the standard +[1] setiathome job message right after; 'top' says everything's runinng fine.

However, if I quit the shell (i.e., go back to login prompt) the job seems to get released from my shell but keep running, with no warning. When I start a new shell and issue jobs I get a newline, as though I had no jobs running and top still says s@h is running.

I know that bash will warn you about stopped background jobs at logout, then terminate them if you try to log out again. So what exactly is going on with my bg job. I'm guessing it has to do with the combination of > /dev/null and & ?

 

[scruffy]

By default, jobs started with & are set up to ignore SIGHUP - the 'hangup' signal that tells them their controlling terminal has gone away.

If you want to be able to reattach to the job later you might want to use 'screen'.

redirecting to /dev/null just stops the output from cluttering up your terminal if you want to continue working with it. I don't know but I suspect that after you close the controlling terminal, the output would just get redirected there anyway...

 

[michaelsanford]

Oh yeah I totally should have used screen I was just wondering how it worked...and to figure out why the bg job was controlled...seemingly abnormally.

I was also wondering why the script's readme says I can start it with cron using (please explain the bold part) setiathome -nice 19 > /dev/null 2> /dev/null

 

[scruffy]

the 2> /dev/null part?

That means standard error (file descriptor 2) goes to /dev/null. Processes have three default file descriptors when they start - standard input = fd0, standard output = fd1, and standard error=fd2. By default, the > operator assumes you mean fd1, but you can specify another file descriptor instead - you could say 4>/dev/null, but the process doesn't have a fd4 by default, so it wouldn't do anything.

If you're in a directory with one file, a, and you do "ls -l a b", you get two lines of output - one giving you info about a, the other an error telling you that there's no such file as b. The first actually went to fd1, the second to fd2; you just see both on the terminal, since both file descriptors point to the terminal you're on. You can check this by redirecting first output, then error, to different files and see what ends up in them.

 

[michaelsanford]

Hey that's wicked ! Where can I find out more stuff like this (recommend an O'Reilly book)?

Another thing I've wanted to do is switch to another virtual terminal when I'm at the console (with no GUI) is that possible ?

 

[Darkshadow]

Not on OSX. I do miss that. I used to use it a lot in Linux. You can still simulate it in a way with screen, though. Though if I do that, I find myself trying to use the F keys to switch between 'em.

Oh, and if you want a process to come back to the front so that it'll die when the term window is closed, you can use fg job number. That'll only work in the same term as you started it from, of course, since as you found out the jobs don't carry across. That's for bash; not sure if the other shells use fg or have a different built in function by a different name that does the same thing.