Re: read -t 0 fails to detect input.

On 12/18/19 6:40 PM, Bize Ma wrote: It seems that read -t 0 should detect if there is input from a pipe (and others). From man bash: If timeout is 0, read returns immediately, without trying to read any data. The exit status is 0 if input is available on the specified file descriptor, n

Re: read -t 0 fails to detect input.

Date:Wed, 18 Dec 2019 19:40:45 -0400 From:Bize Ma Message-ID: | A little delay seems to get it working: | | $ echo value | { read -t 0 var; } ; echo $? | 0 It might, but that is adding no significant delay, and the results are unpredictable. jinx$ echo val

Re: read -t

On 1/4/15 11:43 AM, isabella parakiss wrote: > Ok, that makes sense, but why doesn't it work if I change the delimiter? > > read -t 3 -d q *press random keys without pressing q* > > I think the same should happen here, I'm asking bash to read as much input as > it can until it reads a q. S

Re: read -t

Forgot to include mksh: | dualbus@hp ~ % mksh -c 'read -t 3' | afafafafafafa% | dualbus@hp ~ % afafafafafafa | zsh: command not found: afafafafafafa | dualbus@hp ~ % mksh -c 'read -t 3 -d d' | affafafafafafaf% | dualbus@hp ~ % affafafafafafaf | zsh: command not found: affafafafafafaf :-) 4 imple

Re: read -t

I think the issue here is the inconsistent behavior of read -t when delim != '\n'. read -t 3 -d will *not* leave the input as typeahead. read -t 3 -d $'\n'will leave the input as typeahead. I tried playing with the 'unbuffered_read' variable in builtins/read.def (forcing it to be 1 even f

Re: read -t

Ok, that makes sense, but why doesn't it work if I change the delimiter? read -t 3 -d q *press random keys without pressing q* I think the same should happen here, I'm asking bash to read as much input as it can until it reads a q. Since I don't press q, whatever I typed should be used as

Re: read -t

On 1/4/15 12:45 AM, isabella parakiss wrote: > I'm trying to use read -t in an interactive shell > > read -t 3 *press random keys* > > Everything i press is now part of the next command in the prompt. > It only happens when the delimiter is a \n. > Is this intended? What's the point? It's diff

Re: read -t 0 anomaly

On Fri, Oct 4, 2013 at 3:30 PM, Pierre Gaston wrote: > > > > On Fri, Oct 4, 2013 at 3:29 PM, Pierre Gaston wrote: > >> >> >> >> On Fri, Oct 4, 2013 at 3:08 PM, Kunszt Árpád < >> arpad.kun...@syrius-software.hu> wrote: >> >>> On 2013. October 4. 14:51:00 Pierre Gaston wrote: >>> > On Fri, Oct 4, 20

Re: read -t 0 anomaly

On Fri, Oct 4, 2013 at 3:29 PM, Pierre Gaston wrote: > > > > On Fri, Oct 4, 2013 at 3:08 PM, Kunszt Árpád < > arpad.kun...@syrius-software.hu> wrote: > >> On 2013. October 4. 14:51:00 Pierre Gaston wrote: >> > On Fri, Oct 4, 2013 at 2:20 PM, Kunszt Árpád >> ... >> > >> > >> > There is a race condi

Re: read -t 0 anomaly

On Fri, Oct 4, 2013 at 3:08 PM, Kunszt Árpád < arpad.kun...@syrius-software.hu> wrote: > On 2013. October 4. 14:51:00 Pierre Gaston wrote: > > On Fri, Oct 4, 2013 at 2:20 PM, Kunszt Árpád > ... > > > > > > There is a race condition, you cannot know if echo will run before read. > > I see, and it's

Re: read -t 0 anomaly

On 2013. October 4. 14:51:00 Pierre Gaston wrote: > On Fri, Oct 4, 2013 at 2:20 PM, Kunszt Árpád ... > > > There is a race condition, you cannot know if echo will run before read. I see, and it's logical. But this stills confuses me. arpad@terminus ~ $ for(( i=0; i<10; i++ )); do echo -n "" |

Re: read -t 0 anomaly

On Fri, Oct 4, 2013 at 2:20 PM, Kunszt Árpád < arpad.kun...@syrius-software.hu> wrote: > I tried to use "read -t 0" to check if there is any data on the STDIN or > not. > > The man page said: > > If timeout is 0, read returns success if input is available on the > specified file descriptor, failur

Re: read -t 0 not supported? (poll)

On Wed, 22 Jul 2009, Marc Herbert wrote: It seems polling using "read -t 0" is not supported. It is supported in bash 4.0. -- Chris F.A. Johnson === Author: Shell

Re: read -t 0 not supported? (poll)

On Wed, Jul 22, 2009 at 12:03 PM, Marc Herbert > wrote: > Hi, > > It seems polling using "read -t 0" is not supported. Apparently because > the implementation is based on alarm() (as opposed to be based on > poll()/select()). > > - is this true? > - if yes, doesn't this deserve more explicit doc

Re: read -t 0 causes segfault on SIGINT

> Repeat-By: > [EMAIL PROTECTED]:~$ bash > [EMAIL PROTECTED]:~$ while sleep 1; do read -t 0; done > ... type ^C ... > Segmentation fault > [EMAIL PROTECTED]:~$ Hi Heike, This bug sounds like the one I just reported to Debian: http://bugs.debian.org/331381 There's a patch there. -jim

Re: read -t loses data

[EMAIL PROTECTED] wrote: > If "read -t" times out without fulfilling a request, any pending data is > lost. > Via strace it's apparent that the problem is that when the user requests a > line of > data, bash read is actually calling read() with a buffer size of one. So bash > is > holding t