HOW TO RE-DIRECT THE STDIN/STDOUT FOR A PROCESS RUNNING IN THE BACKGROUND

HOW TO RE-DIRECT THE STDIN/STDOUT FOR A PROCESS RUNNING IN THE BACKGROUND

Post by Vinay Pan » Sun, 12 Nov 1995 04:00:00



Hi

I am writing an application which runs as a SERVER in the background.
Any client process can form a connection to this server which forks
a child process to serve this client. I need to have a menu selection
in this child server process which can accept the input from keyboard.
This may sound strange but the application really needs to do this. The
main server is started during the boot time. Note that this application
will be running on Solaris system running open windows!

Has anyone done this before or has any idea how to proceed?

Vinay

---

 
 
 

HOW TO RE-DIRECT THE STDIN/STDOUT FOR A PROCESS RUNNING IN THE BACKGROUND

Post by Doug Hughe » Mon, 13 Nov 1995 04:00:00



> Hi

> I am writing an application which runs as a SERVER in the background.
> Any client process can form a connection to this server which forks
> a child process to serve this client. I need to have a menu selection
> in this child server process which can accept the input from keyboard.
> This may sound strange but the application really needs to do this. The
> main server is started during the boot time. Note that this application
> will be running on Solaris system running open windows!

> Has anyone done this before or has any idea how to proceed?

> Vinay


You can't have a background process taking keyboard input. What you most
likely want is the client process accessing the keyboard, passing the
information to the server, the server doing something with it, and passing
that back to the client. Background processes are just that, in the
background. Having them try to interact with the keyboard isn't a good
idea. Also, if you want to print messages from a background process, you're
better off using syslog for this.

____________________________________________________________________________
Doug Hughes                                     Engineering Network Services
System/Net Admin                                Auburn University

        Apple T-shirt on Win95 - "Been there, done that"

 
 
 

HOW TO RE-DIRECT THE STDIN/STDOUT FOR A PROCESS RUNNING IN THE BACKGROUND

Post by Patrick Deboi » Tue, 14 Nov 1995 04:00:00


Hello Vinay,

you did not tell in which language you are writing the server/client.
Under Unix (if I'm right) what you need is indeed replace the stin
or stdout with a filedescriptor. So you might say
close(0)(stdin),close(1)(stdout),close(2)(stderr).
Whenever a new filedescriptor is opened it looks for the first available
in the list thereby taking f.i. stdin.

I think that may solve you problem

Patrick.

 
 
 

1. freopen ( ), re-direct stdout/stderr

Hi,

I know there were a lot of posts talked about freopen ( ) before
but I could not find a complete solution. Maybe I did not search
hard enough?

Anyway, I wrote a test program myself and it seems working okay.

#include <stdio.h>
#include <unistd.h>

void print_to_screen(void)
{
    printf("\nprint_to_screen: start\n");
    printf("print_to_screen: done\n");

void print_to_file(void)
{
    FILE* outfile;
    outfile = freopen("outputfile", "w", stdout);
    printf("print_to_file: start\n");
    printf("print_to_file: done\n");
    fflush(outfile);
    /* fclose (outfile); */

void main()
{
    int i;

    print_to_screen();

    dup2(STDOUT_FILENO, i);
    print_to_file();

    dup2(i,STDOUT_FILENO);
    print_to_screen();

But I got a couple questions that I am not sure the answers.

First, if I took out "fflush(outfile);", then everything will
output to screen instead. I guess the data still in the buffer,
then when I call the "dup2(i,STDOUT_FILENO);". There is no chance
for the buffer to be written to the file. So, it flushs out to screen
when the program exit out.

Second, if I uncommented out "fclose(outfile)", the second
print_to_screen message will be missing. I guess the freopen
close out stdout stream and map the "outfile" stream to it.
So, I can't close it. Otherwise, there will not no more stdout
to use. Then the "dup2(i,STDOUT_FILENO);" restore the
original stdout.

Are my assumptions correct?
Any comments/suggestions are welcome?

Thanks!

Kevin

2. stateful rules and UDP

3. redirecting stdin & stdout of a running process

4. Sound Blaster Live

5. Suggestions for redirecting stdin/stdout from a running process?

6. ppp question revisited

7. STDIN and STDOUT for jobs background-launched

8. UNrm or UNdelete?

9. sockets dup()ed to stdin and stdout of a process

10. Controlling forked processes stdin/stdout

11. Using separate window child process for stdin/stdout

12. Managing stdin and stdout of new processes

13. Taking over a child process's stdin/stdout