backgrounding.... (solved.. _Screen it_)

[shrimp123]

Hi,

here is a question

start 2 xterms
on xterm1 start a job (in foreground)
from xterm2, i want to background the job on xterm1

utility : imagine xterm1 being run locally on a machine that i can only ssh into

when i check bg man page, it says bg <job id>. How do i get job id? using ps? (tried it, pid =/= job id)

thanks,
S

[Dan]

If i understand you correctly, sounds like you should be using screen to accomplish what you want
http://gentoo-wiki.com/TIP_Using_screen

[xoomix]

I was gonna suggest screen as well (app-misc/screen). I just played with it a bit a minute ago and sure enough, on term 1 you'd type in 'screen' to start the program. Then you'd do whatever process you wanted. On term 2 you'd type in 'screen -d' to 'detach' the first runnning screen session, containing your job. Now on any term you can just do a 'screen -r' to re-attach that screen session.

[shrimp123]

thanks for the replies.

umm.... may be i stated my question incompletely.

xterm1 is on machine1 (which , say, is at home and was started locally) - may or may not have started screen. (u see, my home machine is actually an old 486 thats a firewall/router that has minimal resources)

xterm2 is on machine2 (which , say, is at work =/= home), using which i have ssh-ed into machine1

in that case, would screen still work?

so the refined question is

1. is it possible to do it without screen? bg should(?) let me do it right?
2. is it possible if screen is not running on machine1? (looking at the wiki, seems like -r tty_num should work)

thanks,
S

[xoomix]

Screen will still work. From the second PC, after ssh'ing into machine1 you still run the same screen commands.

[timeBandit]

screen will work perfectly in the situation you describe. I used to do it all the time, connecting (via SSH) to my home machine from work to monitor long-running emerges. I'd become root, start screen, start the emerge, detach screen, logout and leave. From work, I'd connect via SSH, become root, re-attach the screen session, and see what was going on (which I always hoped would be compiler output, not an error message ).

The catch is you do have to remember to start screen before beginning your "real" work, else you won't be able to transfer the session to another terminal. It can be automated without too much trouble if it's something you would do all the time.
_________________
Plants are pithy, brooks tend to babble--I'm content to lie between them.
Super-short f.g.o checklist: Search first, strip comments, mark solved, help others.

[shrimp123]

works. thanks.

quote :

Screen it!