Thread: IPC using PIPES

Originally Posted by BMathis

seems to work so far

Looks good to me.

Originally Posted by BMathis

That is originally what I wanted to do. In my parent I
close(commpipe[1]);
when I am done writing into the pipe. Is that EOF sent through the pipe just before it is closed?
If that is the case, my child is not seeing the EOF. It continues to sit there and wait for input till I shove an EOF through the pipe myself using printf().

Well, I can't explain that. Closing the write end of the pipe should cause the read end to receive an EOF. I haven't really looked at your code though.

Also, EOF doesn't get sent through the pipe. It's not a character. The OS just causes the next read() on the pipe to return 0, which means "EOF".

Originally Posted by brewbuck

Well, I can't explain that. Closing the write end of the pipe should cause the read end to receive an EOF. I haven't really looked at your code though.

This was probably because fgets won't catch EOF, and the while (!feof(stdin)) was ineffective (I've never tried this method but I've seen some caveats against it).

Originally Posted by MK27

This was probably because fgets won't catch EOF, and the while (!feof(stdin)) was ineffective (I've never tried this method but I've seen some caveats against it).

It won't? I'm pretty sure that fgets() will return NULL if it receives EOF before any character has been read.

Originally Posted by BMathis

would it make more sense for the child to be using read() to read in from the pipe rather than fgets()

read() is great because it just needs a file descriptor but you should use fread(), because fread() is more portable and so will work everywhere

Originally Posted by brewbuck

It won't? I'm pretty sure that fgets() will return NULL if it receives EOF before any character has been read.

I don't use fgets(), but looking at the GNU reference there is no mention of that, and based on the OP's observations it really must not...

But what happens if it reads the EOF after the first character? Would the EOF be gone so the next fgets just hangs?

Originally Posted by MK27

I don't use fgets(), but looking at the GNU reference there is no mention of that, and based on the OP's observations it really must not...

But what happens if it reads the EOF after the first character? Would the EOF be gone so the next fgets just hangs?

you are talking as if EOF is some character.
EOF is condition "no more characters to read", and this condition goes nowhere, no matter how many tries you do to read from the closed stream

Originally Posted by vart

you are talking as if EOF is some character.
EOF is condition "no more characters to read", and this condition goes nowhere, no matter how many tries you do to read from the closed stream

Hmmm, I wonder what this is?

Code:

#include <stdio.h>

int main() {
     printf("%x\n",EOF);
     return 0;
}

My imagination?

Again: I don't use fgets, I was going by what the OP claimed. And NO ONE has actually contributed a working piece of code to demonstrate the OP wrong, so s/he is probably right.

Originally Posted by MK27

Hmmm, I wonder what this is?
My imagination?
.

This is a macro used by SOME functions to indicate the EOF condition. It is NOT the character read from the stream

Originally Posted by MK27

Hmmm, I wonder what this is?

A program that prints a negative integer in hexadecimal representation to standard output.

Originally Posted by MK27

Again: I don't use fgets, I was going by what the OP claimed. And NO ONE has actually contributed a working piece of code to demonstrate the OP wrong, so s/he is probably right.

At this point I would like to ask BMathis: what is your current code and what is the corresponding input, expected output and actual output?

Originally Posted by MK27

read() is great because it just needs a file descriptor but you should use fread(), because fread() is more portable and so will work everywhere

It doesn't matter, because you could not have created a pipe using a portable method in the first place.

Originally Posted by vart

This is a macro used by SOME functions to indicate the EOF condition. It is NOT the character read from the stream

Live and learn.

Originally Posted by brewbuck

It doesn't matter, because you could not have created a pipe using a portable method in the first place.

Oh pooh! Some aspect of the Original Point remains worthwhile, perhaps, anyway.