From owner-freebsd-hackers@freebsd.org Sat Jan 16 18:08:58 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D52B9A84069 for ; Sat, 16 Jan 2016 18:08:58 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from mst-rip6-missouri-out.um.umsystem.edu (mst-rip6-missouri-out.um.umsystem.edu [198.209.50.149]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "um-tip1.um.umsystem.edu", Issuer "InCommon RSA Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 770F51A66 for ; Sat, 16 Jan 2016 18:08:58 +0000 (UTC) (envelope-from stephen@missouri.edu) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AmBQDWhppW/9KeoM9egzpSc4hQtR4ihW0CgSY8EAEBAQEBAQGBCoQ1AQEEeBECAQgYCRYPCQMCAQIBICUCBAEMCAEBiBcOvFYBgwABAQEHAQEBAQEaBItUiT0FlxoBhUeCdJQkjl05K4QLhh4HPAGBBwEBAQ X-IPAS-Result: A2AmBQDWhppW/9KeoM9egzpSc4hQtR4ihW0CgSY8EAEBAQEBAQGBCoQ1AQEEeBECAQgYCRYPCQMCAQIBICUCBAEMCAEBiBcOvFYBgwABAQEHAQEBAQEaBItUiT0FlxoBhUeCdJQkjl05K4QLhh4HPAGBBwEBAQ Received: from um-ncas5.um.umsystem.edu ([207.160.158.210]) by mst-rip6-exch-relay.um.umsystem.edu with ESMTP; 16 Jan 2016 12:08:45 -0600 Received: from UM-MBX-N02.um.umsystem.edu ([169.254.5.100]) by UM-NCAS5.um.umsystem.edu ([207.160.158.210]) with mapi id 14.03.0266.001; Sat, 16 Jan 2016 12:08:45 -0600 From: "Montgomery-Smith, Stephen" To: Yuri , "freebsd-hackers@freebsd.org" Subject: Re: How to send EOF to the popen(3) pipe? Thread-Topic: How to send EOF to the popen(3) pipe? Thread-Index: AQHRUBBE+GmWWEt160m/VZ+mWUx+kJ798zuAgADgjACAAAKNAA== Date: Sat, 16 Jan 2016 18:08:44 +0000 Message-ID: <569A872C.2010806@missouri.edu> References: <5699BAC9.3060407@rawbw.com> <5699C8AB.7070006@missouri.edu> <569A8508.80908@rawbw.com> In-Reply-To: <569A8508.80908@rawbw.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 x-originating-ip: [207.160.158.194] Content-Type: text/plain; charset="Windows-1252" Content-ID: <11C04C1810695B4E9DACE3D33305AF3A@missouri.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 18:08:58 -0000 On 01/16/2016 11:59 AM, Yuri wrote: > On 01/15/2016 20:35, Montgomery-Smith, Stephen wrote: >> Maybe I am displaying my ignorance. But wouldn't you do this by >> invoking the function pclose? >=20 > No, pclose kills the process and returns the exit code. Half-closed > connection though can be alive for a while, until the other side > finishes and closes the pipe. >=20 >> My memory of using this was that this could gridlock because of >> buffering. Suppose process A popens a process B. A sends a message to >=20 > Gridlocks are possible if reads/writes are performed in the wrong order. > But this is besides the point of the original question. >=20 > I think the answer to my question is "no". popen(3) can't send EOF. > Protocol needs to support EOF signal on the application-level. Yes. I think a "proper" implementation would be via a function like popen2 https://emergent.unpythonic.net/01108826729, which creates 2 file handles, not just one. Then to send the EOF, you would close one of the file handles (the "to_child"), and then only close the other file handle (the "from_child") when it receives an EOF. For the popen2 code to be compatible with stdio, you should run fdopen on each file descriptor to create FILE*s.