Re: 'fg'ing a PID


Reid Ellis (rae@tnir.mef.org)
Tue, 27 Jul 1999 20:54:19 -0400


Thus spake Evan Read (evan@advcomm.co.nz):
> I have logged into an old Linux box (slackware 2.0xxx kernal) and ran
> rc5des client. Anyways, when I log off, the thing keeps running. I
> forget what they call that but it is great!

In olden days you had to use 'nohup' to prevent a background app's death when
you log out. These days it seems that 'nohup' is the default.

> Anyways, I would like to foreground it so I can see how it is doing. But
> I can't work out how to fg it...

The simple answer is that you can't. The output 'file descriptor' is forever
destroyed when you log out. The correct solution is to redirect the output to
a file, which can be checked at any time.

Let's say you want to run "rc5des", and it spits stuff out from time to time.
If you were running csh [or tcsh] you would do this:

% rc5des >& output &

You will get the usual "[1] rc5des" notification that job 1 is rc5des, but if
you 'fg' it, you will get nothing, because all the output is going to the file
you named, 'output'.

If you are running sh, ksh, bash or ash, you will have to do this:

$ rc5des > output 2>&1 &

In either case, at any time you can look at 'output' using "cat", "more",
"less", or -- my favorite -- "tail". "tail" is especially useful if you want
to watch the output as it goes, by doing this:

% tail -f output

tail will sit there, watching the file, and print out any new data that
appears. Note, however, that the output of a program can behave quite
"chunky" when not connected directly to a terminal [i.e. to a file]. This is
called "buffered I/O", and is generally a good thing for fast transfer of
data, but less suitable for text output from a program.

> it has no job number ecause it was launched during a previous login that I
> terminated. I run "ps -aux" and find the PIDs, but "fg pidno" doesn't
> work.
>
> What does?

There is no way that I know of to hook up your terminal to an arbitrary
process's output. But hey, you have *all* the source, so anything is
possible, right? :-)

Reid

-- 
Reid Ellis    <rae@tnir.mef.org>     http://tnir.mef.org/~rae/
MGI Software  <reide@mgisoft.com>    http://www.mgisoft.com/



This archive was generated by hypermail 2.0b3 on Sat Jul 31 1999 - 11:30:08 MDT