Date: Fri, 11 Sep 1998 08:10:41 +0100 From: Mark Ovens <marko@uk.radan.com> To: Leo Papandreou <leo@talcom.net> Cc: questions@FreeBSD.ORG Subject: Re: Help needed with fork(), pipe() & dup2() Message-ID: <35F8CCF1.B2BD199E@uk.radan.com> References: <35F6EE38.7DC97F21@uk.radan.com> <19980909182820.16714@talcom.net> <35F77884.E4FEAA21@uk.radan.com> <19980910173817.42597@talcom.net> <35F85DAF.2B23FC42@uk.radan.com> <19980911004700.52247@talcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Leo Papandreou wrote:
>
> >
> > arg 2 in execvp() is a global char* that holds a list of filenames
>
> char **, you mean?
Er yes, well it was late & I'd had a couple of beers....
>
> > (delimited by \n and starts with "file", the name of the prog, and is
> > terminated by a NULL) that the prog can't identify so it passes them to
> > file(1) to try to id them.
>
> I'm not sure I understand the \n part. file(1) will interpret the
> '\n' literally.
Doh, I'd put in a for loop to printf() the contents of files for
debugging, that was where I got \n from . Well it was late and.....
>
> >
> > What puzzles me is that the Linux binary works OK under FreeBSD (2.2.7)
> > Linux emulation. I'm building it with gcc 2.8.1.
> >
> > I've re-quoted the code below....
>
> I rewrote foo() and embedded it into a short main() stub. It *did*
> work under Linux but it only worked under FreeBSD for the first
> call to foo():
>
[code & output snipped]
>
> > What puzzles me is that the Linux binary works OK under FreeBSD (2.2.7)
> > Linux emulation. I'm building it with gcc 2.8.1.
> >
>
> Yeah, the above code produces the "expected" results on a RedHat machine.
> I'd love to know why and where the difference in semantics lies.
>
So would I. I'm glad that someone else got the same results (at least
I know it wasn't stupidity on my part). Surely using pipes for
inter-process comms is a fairly standard construct so one would expect
it to behave consistently across different flavours of Unix?
> > I've re-quoted the code below....
> >
> > Thanks for your help with this Leo.
>
> Thank Brian Sommers. His sol'n was correct.
>
> void foo()
> {
>
> [...]
> else if (pid > 0)
> { /* parent */
> FILE *in;
>
> close(fd[1]);
> if ((in = fdopen(fd[0], "r")) == NULL)
> {
> close(fd[0]); /* child gets SIGPIPE */
> err(1, NULL);
> }
That's another beer I owe Brian (he gave me a lot of patient help with
ppp). It would appear that dup2() is the culprit as the only real
change is using fdopen() instead of dup2(), but only for the parent,
Brian's sol'n implies that dup2() still works in the child code.
--
When everything's coming your way, you're in the wrong lane.
Mark Ovens, CNC Applications Engineer, Radan Computational Ltd
Sheet Metal CAD/CAM Solutions
mailto:marko@uk.radan.com http://www.radan.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?35F8CCF1.B2BD199E>