[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Background process I\O redirection
On Sun, Jun 17, 2001, guy keren wrote about "Re: Background process I\O redirection":
>
>...
> 3. on a shell attached to '/dev/tty5' i run a debugger:
> gdb /usr/bin/ncftp 7787
>
> in the debugger:
>
> (gdb) print open("/dev/tty4", 0) /* '0' stands for O_RDONLY */
> $ = 4
> (gdb) print dup2(4, 0);
>...
> it'll be interesting to check this method on the shell itself. if it'll
> work, it'll give a screen-like behaviour without having to run screen in
> advance, or having it installed on the system. any system with a debugger
> on it will work...
This is very interesting, but screen has another important capability, which
is to remember the previous output that the program generated. In your
method, whatever output the program generated while it wasn't "attached"
is lost (unless it was originally saved to a file, like your nohup example).
Screen is a very useful utility to get aquainted with, for many reasons. If
you always run screen in advance, you can always attach back to your processes
and see what output they generated while you were away. This is extremely
useful, for example, in modem connections which tend to disconnect at the
exact moment you are running an important command and forgot to "nohup" it.
P.S. why did you have to do these 'fdopen' stuff? Since the file descriptors
remained the same, the previous definitions of 'stdin', 'stdout', etc., should
work just the same, so these calls are redundant. If you were thinking that
this would flush the old buffers, etc., then there are few problems with that
thinking:
1. I don't think it would, since you are just overwriting the 'stdin'
variable. stdouts's old buffers may be completely lost, rather then
flushed to the old (or new) output file or terminal.
2. Are you sure stdin, etc., are variables? I remember in old versions of
AT&T unix that these were macros, pointing to some internal stuff in the
stdio library. You weren't supposed to set them. Does ANSI C guarantee
that they are standard variables?
BTW, in Linux, stdin is defined as "extern FILE *stdin;", and then they
do "#define stdin stdin", commenting about that:
/* C89/C99 say they're macros. Make them happy. */
So I guess you shouldn't go around redifining stdin, etc.
3. Why just stdin - how can you assume that this program uses stdio? What
about C++'s "cin"? What if the program uses its own IO library?
--
Nadav Har'El | Sunday, Jun 17 2001, 26 Sivan 5761
nyh@math.technion.ac.il |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |A good programmer is someone who looks
http://nadav.harel.org.il |both ways before crossing a one-way street.
=================================================================
To unsubscribe, send mail to linux-il-request@linux.org.il with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail linux-il-request@linux.org.il