On 1/24/17 4:16 AM, Siteshwar Vashisht wrote:
>
>
> - Original Message -
>> From: "Chet Ramey"
>> To: "Siteshwar Vashisht" , bug-bash@gnu.org
>> Cc: "chet ramey"
>> Sent: Monday, January 23, 2017 8:01:38 PM
>> Subje
- Original Message -
> From: "Chet Ramey"
> To: "Siteshwar Vashisht" , bug-bash@gnu.org
> Cc: "chet ramey"
> Sent: Monday, January 23, 2017 8:01:38 PM
> Subject: Re: read() may fail due to nonblocking stdin
>
> Something like this,
On 1/23/17 10:45 AM, Chet Ramey wrote:
> On 1/23/17 10:42 AM, Chet Ramey wrote:
>> On 1/22/17 2:32 PM, Siteshwar Vashisht wrote:
>>> If a child process sets stdin to non-blocking and does not set it back to
>>> blocking before exiting, other processes may fail to read from stdin.
>>
>> It's not th
On 1/23/17 10:42 AM, Chet Ramey wrote:
> On 1/22/17 2:32 PM, Siteshwar Vashisht wrote:
>> If a child process sets stdin to non-blocking and does not set it back to
>> blocking before exiting, other processes may fail to read from stdin.
>
> It's not the shell's business to be resetting this for p
On 1/22/17 2:32 PM, Siteshwar Vashisht wrote:
> If a child process sets stdin to non-blocking and does not set it back to
> blocking before exiting, other processes may fail to read from stdin.
It's not the shell's business to be resetting this for processes it spawns.
What bash should do is to t
If a child process sets stdin to non-blocking and does not set it back to
blocking before exiting, other processes may fail to read from stdin.
Reproducer steps :
$ cat set_nonblock.c
#include
#include
#include
int main() {
char buff[256];
int flags = fcntl (0, F_GETFL);
