Help: redirecting process input/output

Hi,
below is a simplified version of my program. I am trying to
implement a version of popen() where my keyboard input goes to a
process's standard input; and its standard output goes to my screen
(well - without just running the program directly :-)) However, it's
not working, the child-to-parent pipe c2p never gets written to (at
least with /bin/ls and /bin/date). Is it wrong to close c2p[0] and
p2c[1] in child?

Invoke as: <progname> /bin/someprog arg1 arg2 arg3 (args for someprog)
e.g.
<progname> /bin/ls .

#include <sys/select.h>
#include <stdio.h>
#include <unistd.h>

int main (int argc, char *argv[])
{
int p2c[2], c2p[2], count;
char buf[1024];

pipe(p2c); pipe(c2p);
if (fork()) {
fd_set r;
close(p2c[0]); close(c2p[1]);
while (1) {
FD_ZERO(&r);
FD_SET(0, &r);
FD_SET(c2p[0], &r);
select(c2p[0], &r, NULL, NULL, NULL);
if (FD_ISSET(c2p[0], &r)) {
if ((count = read(c2p[0], buf, 1024))
> 0) {
write(1, buf, count);
}
}
if (FD_ISSET(0, &r)) {
if ((count = read(0, buf, 1024)) > 0)
{
write(p2c[1], buf, count);
}
}
}
} else {
close(0);
dup(p2c[0]);
close(p2c[0]);
close(1);
dup(c2p[1]);
close(c2p[1]);
execvp(argv[1], &argv[1]);
}
return 0;
}

Knight wrote:
> Hi,
> below is a simplified version of my program. I am trying to
> implement a version of popen() where my keyboard input goes to a
> process's standard input; and its standard output goes to my screen
> (well - without just running the program directly :-)) However, it's
> not working, the child-to-parent pipe c2p never gets written to (at
> least with /bin/ls and /bin/date). Is it wrong to close c2p[0] and
> p2c[1] in child?

No

>
> Invoke as: <progname> /bin/someprog arg1 arg2 arg3 (args for someprog)
> e.g.
> <progname> /bin/ls .
>
> #include <sys/select.h>
> #include <stdio.h>
> #include <unistd.h>
>
> int main (int argc, char *argv[])
> {
> int p2c[2], c2p[2], count;
> char buf[1024];
>
> pipe(p2c); pipe(c2p);
> if (fork()) {
> fd_set r;
> close(p2c[0]); close(c2p[1]);
> while (1) {
> FD_ZERO(&r);
> FD_SET(0, &r);
> FD_SET(c2p[0], &r);
> select(c2p[0], &r, NULL, NULL, NULL);

First parameter should have 1 added
Robert

> if (FD_ISSET(c2p[0], &r)) {
> if ((count = read(c2p[0], buf, 1024))
>> 0) {
> write(1, buf, count);
> }
> }
> if (FD_ISSET(0, &r)) {
> if ((count = read(0, buf, 1024)) > 0)
> {
> write(p2c[1], buf, count);
> }
> }
> }
> } else {
> close(0);
> dup(p2c[0]);
> close(p2c[0]);
> close(1);
> dup(c2p[1]);
> close(c2p[1]);
> execvp(argv[1], &argv[1]);
> }
> return 0;
> }

On Mar 21, 1:51*am, Robert Harris <robert.f.har...@blueyonder.co.uk>
wrote:
> > * * * * * * * * * * * * select(c2p[0], &r, NULL,NULL, NULL);
>
> First parameter should have 1 added
> Robert

Thank you! Last place I suspected!
Sorry, a simple "Thank You" does not adequately express the depth of
my gratitude for catching this bug.

THANK YOU!!!! THANK YOU!!!! THANK YOU!!!! THANK YOU!!!! THANK YOU!!!!
Vote Harris for World President!

A little better.

On Mar 21, 1:06 pm, Knight <knightt...@yahoo.com> wrote:

> Thank you! Last place I suspected!
> Sorry, a simple "Thank You" does not adequately express the depth of
> my gratitude for catching this bug.
>
> THANK YOU!!!! THANK YOU!!!! THANK YOU!!!! THANK YOU!!!! THANK YOU!!!!
> Vote Harris for World President!
>
> A little better.

By the way, your code is largely operating by luck. It has a very
serious, and very subtle, bug that can lead to deadlock.

You cannot assume that it is safe to refuse to read from one
connection until you finish writing to another. If two processes do
that, they can wind up each refusing to read until the other reads,
which is fatal.

You also didn't set the sockets non-blocking, which can also lead to
deadlock for much the same reason.

> if (FD_ISSET(c2p[0], &r)) {
> if ((count = read(c2p[0], buf, 1024))
>> 0) {
> write(1, buf, count);
> }
> }
> if (FD_ISSET(0, &r)) {
> if ((count = read(0, buf, 1024)) > 0)
> {
> write(p2c[1], buf, count);
> }
> }

Notice that you do not perform the second 'read' until the first
'write' completes? But your 'write' can only complete if there is
sufficient space in the pipe, which may require the consuming process
to 'read' from the pipe. But the consuming process might be blocked in
'write' waiting for space in the pipe which will only be made
available by your second 'read'. So you are each waiting for the
other.

You must not wait to call the second 'read' until the first 'write'
completes.

You can get the same deadlock the other way around as well. You could
be blocked in the first 'write', unable to find buffer space because
the program you are trying to 'write' to cannot call 'read' until you
perform the first 'read' on the next pass of your 'select' loop.

Sorry for the bad news.

The simplest fix is just to 'fork' and use one process for each
direction. Each process blocks in 'read' and then blocks in 'write'.
The way, one process blocking in 'write' won't keep the other one from
'read'ing.

Otherwise, you have to use 'select' for your writes as well, and you
must set the sockets non-blocking.

DS

On Mar 22, 6:35*am, David Schwartz <dav...@webmaster.com> wrote:
>
> By the way, your code is largely operating by luck. It has a very
> serious, and very subtle, bug that can lead to deadlock.
>
> You cannot assume that it is safe to refuse to read from one
> connection until you finish writing to another. If two processes do
> that, they can wind up each refusing to read until the other reads,
> which is fatal.
>
> You also didn't set the sockets non-blocking, which can also lead to
> deadlock for much the same reason.
>
> > * * * * * * * * * * * * if (FD_ISSET(c2p[0], &r)) {
> > * * * * * * * * * * * * * * * * if ((count = read(c2p[0], buf, 1024))
> >> 0) {
> > * * * * * * * * * * * * * * * * * * * * write(1, buf, count);
> > * * * * * * * * * * * * * * * * }
> > * * * * * * * * * * * * }
> > * * * * * * * * * * * * if (FD_ISSET(0, &r)) {
> > * * * * * * * * * * * * * * * * if ((count = read(0, buf, 1024)) > 0)
> > {
> > * * * * * * * * * * * * * * * * * * * * write(p2c[1], buf, count);
> > * * * * * * * * * * * * * * * * }
> > * * * * * * * * * * * * }
>
> Notice that you do not perform the second 'read' until the first
> 'write' completes? But your 'write' can only complete if there is
> sufficient space in the pipe, which may require the consuming process
> to 'read' from the pipe. But the consuming process might be blocked in
> 'write' waiting for space in the pipe which will only be made
> available by your second 'read'. So you are each waiting for the
> other.
>
> You must not wait to call the second 'read' until the first 'write'
> completes.
>
> You can get the same deadlock the other way around as well. You could
> be blocked in the first 'write', unable to find buffer space because
> the program you are trying to 'write' to cannot call 'read' until you
> perform the first 'read' on the next pass of your 'select' loop.
>
> Sorry for the bad news.
>
> The simplest fix is just to 'fork' and use one process for each
> direction. Each process blocks in 'read' and then blocks in 'write'.
> The way, one process blocking in 'write' won't keep the other one from
> 'read'ing.
>
> Otherwise, you have to use 'select' for your writes as well, and you
> must set the sockets non-blocking.
>
> DS

Sorry, I didn't understand this bit. The first write (in the parent)
is to file descriptor 1 (tty output) and not to the pipe. Similarly
the second read is from fd 0 (tty input).
I don't think you're saying they will block because of insufficient
space in the pipe, right?

Or is this the scenario you're visualizing: Parent writes to p2c[1]
but blocks due to insufficient space. Child was already blocked on a
write to its 1 (which used to be c2p[1] before all the close()/dup()
stuff). Now neither will advance because neither is reading?

BTW in my situation (embedded system, limited RAM) I think it will be
better to set sockets nonblocking, do select() for writes and reads
both, and retry them; rather than 2 forks.

On Mar 23, 11:12 pm, Knight <knightt...@yahoo.com> wrote:

> Or is this the scenario you're visualizing: Parent writes
>to p2c[1] but blocks due to insufficient space. Child was
> already blocked on a write to its 1 (which used to be
> c2p[1] before all the close()/dup() stuff). Now neither
> will advance because neither is reading?

That is definitely one of the two ways it can deadlock.

> BTW in my situation (embedded system, limited RAM) I think
> it will be better to set sockets nonblocking, do select()
> for writes and reads both, and retry them; rather than 2
> forks.

That's a good solution, but it's a bit tricky to implement correctly.

DS