Unix Programming - Question about pipes

Author

Question about pipes

Madhusudan Singh

2004-02-13, 9:34 am

Hi

Just a basic question from someone who is new to pipes.

The statement of the problem is simple :

Instead of using popen(progname,"w"), I wish to use the elementary
functions pipe, fork, dup2, etc. to get the same effect.

You may well wonder why I am trying to do this - I am programming in
another language (Fortran 95) where a library provides equivalents for
pipe(), fork(), dup2() etc., but not for popen().

I do NOT wish to depend upon underscores in the object code and want
to make my code pure Fortran 95.

I would appreciate it if someone could give me a flowchart (with
proper calls like pipe() with the arguments).

Thanks,

MS

Madhusudan Singh

2004-02-15, 5:35 am

On Saturday 14 February 2004 21:37, Gianni Mariani (gi2nospam@mariani.ws)
held forth in comp.os.linux.misc (<c0mm1a$rlj@dispatch.concentric.net> ):

Thanks for the code. I would however prefer to see some clearer C code (or
even pseudo code). Speaking as a programmer wanting to port things over to
another language, and not as a specialist interested in OO code, I find OO
programming to be obfuscating the issue.

I just need the translation of

popen(progname,"w") -> pipe,fork,dup2 in C pseudo code (with the correct
progname calls, etc).

I can figure out how to implement it in Fortran 95 on my own.

Unravelling C++ code to get to what I need can be time consuming for me (I
haven't done any OO C++ programming for at least 6-7 years).

Madhusudan Singh

2004-02-15, 11:33 am

On Sunday 15 February 2004 15:09, Nick Landsberg (hukolau@att.net) held
forth in comp.os.linux.misc
(<QlQXb.4905$aH3.155532@bgtnsc04-news.ops.worldnet.att.net> ):

>
>
> Madhusudan Singh wrote:
>
> It's actually a pretty complex operation and it's been years since
> I've done it so I may miss something along the way. This is pseudo-code
> with all the error checking left out just to be easier to follow.
> It presupposes that on your system, file descriptor zero refers
> to stdin, file descriptor 1 to stdout, file descriptor 3
> to stderr, but we're only interested in fd = 1 right now.
>
> int pipedes[2];
> pid_t childpid;
>
> pipe(&pipedes[2]); /* error checking left out */
>
> /* pipedes[0] now contains a file descriptor (not File *) to
> the read end of the pipe, pipedes[1] contains a file descriptor
> to the write end of the pipe */
>
> childpid = fork(); /* error checking left out */
>
> if (childpid >0) { /* parent process */
> close (pipedes[0]) ; /* error checking left out */
> /* close the read end of the pipe in the parent, assuming parent
> will be writing stuff down the pipe to child */
> ...
> some code to associate a File * with the file descriptor if
> this is C, etc.
> } else { /* child process */
> close (pipedes[1] ; /* error checking left out */
> /* close write end of the pipe, the parent will be writing
> to this descriptor */
> if( dup2(0,pipesdes[0] != 0 ) { /* attach pipe to stdin */
> /* it didn't attach to stdin */
> /* error code goes here */
> }
>
> /* at this point in the child, file descriptor 0
> is attached to the read end of the pipe. This
> presupposes that fd = 0 is the convention for
> standard input on your system. Other file descriptors
> not specifically closed are inherited from the
> parent */
>
> execlp("progname", "progname", "args" ... );
> /* or use your favorite variation of exec in
> section 3 */
>
> my_error_exit("Return from exec?");
> }
> /* now we're in the parent and can write to
> pipedes[1] to our heart's content.
> Note that reads and writes have to be
> synchronized to some extent in that
> the child may block if there is insufficient
> information in the pipe. For example, if
> the parent writes 128 bytes, but the child
> is reading in 512 byte chunks, the child
> will block until there are 512 bytes in the pipe.
> The parent may also block if the pipe size
> (implementation dependent) is exceeded
> and continue to block until the child reads
> some data from the pipe */
>
> As I said, I may have left something out since it's
> been so long since I've done this and I had
> to look up the man pages to refresh my memory
> on most of these calls, so there may be
> some errors up there. It should give you
> a start which will let you experiment, tho.
>
> Hope this helps.
>

Thanks !!!

One excellent, relevant response makes listening to all the rest worthwhile.