Archived

This topic is now archived and is closed to further replies.

cyanide

un*x shell question

Recommended Posts

Hi, does anybody know how do I get back to some previous output stream (via putty or some other telnet client)? I guess I can best describe my question with this example: suppose on the bash command I typed this (via putty): tail -f somefile (example) now its streaming a constant output on my screen.. and suddenly my computer crashes and I loose my connection. Now when I re-connect and re-login, its a totally new session and prompt.. But I know the above program hasn''t terminated as its still showing in ps . So, is there anyway to get back to the previous output stream (without spawning another instance)? Sorry if its is a n00b question, but i guess will have to learn it once Thanks in advance

Share this post


Link to post
Share on other sites
I don''t know of a way (Not that there isn''t one) to "attach", and get the stdout of a running process, but there are a number of ways to avoid the situation alltogether.

One is to re-direct the output of your program into a file that you can then tail. If you get dropped, you just re-connect, and continue tailing the file.

For example:

./myprogram >> logfile&
tail -f ./logfile

A simpler way is to use a program called "nohup":

nohup ./myprogram&

This should append output to a file called nohup.out. You can then tail this file...

-- Aaron

| HollowWorks.com |

Share this post


Link to post
Share on other sites
quote:
Original post by mrhollow
A simpler way is to use a program called "nohup":

nohup ./myprogram&

This should append output to a file called nohup.out. You can then tail this file...

-- Aaron



thanks! just what I was looking for.. it works out just great

Share this post


Link to post
Share on other sites
nice! and even better since I can now go back typing interactive commands too than just seeing the output.
I read about scren in the unix power tools book once but never realized that it can be so powerful until now. Also I had a strange misconception that the job was stopped when detaching (but just verified with a perl counter script that it isn''t). Thanks again for the tip

Share this post


Link to post
Share on other sites