Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!nrl-cmf!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: system (and popen)
Message-ID: <7172@brl-smoke.ARPA>
Date: 24 Jan 88 22:35:09 GMT
References: <127@dcrbg1.UUCP> <9472@ccicpg.UUCP> <2771@cbdkc1.ATT.COM> <447@cpsc6b.cpsc6a.att.com> <569@cresswell.quintus.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 20

In article <569@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>>But, if their command is a shell script, exec() will fail.
>BSD UNIX doesn't have this restriction; that is a System V "feature".

This Berkeley feature requires that the script start with
an appropriate #! line; not all scripts do.  The #! line
contains system-specific (non-portable) instructions, in
general.  For example, someone just reported a problem
when he used a copy of one of my #!/usr/5bin/sh scripts
on a Sun workstation (which didn't have /usr/5bin/sh).

>{Why isn't there a popen() which gives me *two*
>stdio streams, one to each end of the command?}

Because this isn't generally helpful; if you don't carefully
design an IPC protocol, deadlock can easily result.
If you keep your "packets" below the pipe buffer size,
and use a strict alternation of (write, then read), then
such a connection should work.  But a naive programmer
will just get in trouble with such a facility.