On Wednesday, November 24, 2004, at 10:22 PM, Glen Johnson wrote:

>
> Dear NetBSD-Users Group,
> I am an embedded software engineer and work on a system that can send 
> text out
> of the system.  Currently it only sends out text, my debug info.  My 
> desire is
> to use my i386 PC running Net BSD to display the output and maybe even 
> pipe it
> to a file.
...
The comp.unix.shell answer to the question,   "display output and also 
to file,"   would be 'tee' ,
But, the problem with tee is if you want to ^C to stop looking at it ( 
temporarily ) or logout, you end up
killing the whole pipe line.
So, I like tail -f.   Tail prints out the last few lines of file, but 
with -f, it will do that, but also keep the file handle open and keep 
printing what gets appended, which is perfect for logfiles.   ( tail -f 
/var/log/messages, for example )
Another example:  tail -f  /var/log/messages  < /dev/ttyE4  > 
/dev/ttyE4  2> /dev/ttyE4   &
and current messages are a virtual console.    If your program isn't 
already a deamon, then you'll need to run it nohup and redirect stderr  
as well, that is if you want to be be able to survive logouts, xterm,  
windowmangers, or xserver crashes etc.

If you want to do just want you asked in its most basic level, then it 
would be just be:
foo > foo.log &
Then tail -f fog.out   when you want to look at current output,  ^C 
when done, repeat when you want
current display.    Or run it xterm -e, etc.    Run in different 
windows, consoles etc.

Nice thing, is you just need read permissions to the file.   You don't 
have to be running as the same uid as the producing process,  and it 
scales fairly well across multiple viewers,  the viewers can be 
different uids, and no exposing a shell.    And,  I'd say its the 
cheapest way to imp this,  resource wise.    Tail is smaller than 
script, and script is actually 2 processes and a pty layer.   Screen 
does more, so uses more ram,  also an extra terminal emulation level, 
and a unix socket, or named pipe, for communication.    And,  you don't 
have to muck with how
you start your server or producing process, which might be nice if your 
aiming toward daemon operation.

The only down side is if the server process  does weird things like 
unlink its own log file, or truncates,  but generally logfiles are 
opened append, and tail -f works great in that scenario.