On 12/19/19 3:07 PM, Bize Ma wrote:
> To: Chester Ramey
>
> On thu., dec. 19 of 2019 at 12:40, Chet Ramey () wrote:
>
>> On 12/18/19 6:40 PM, Bize Ma wrote:
>>
>
>
> The exit status is 0 if input is available on the specified file
>>> descriptor, non-zero otherwise.
>>
>> Bash-5.0 uses s
On Fri, Dec 20, 2019 at 10:40:26AM -0400, Bize Ma wrote:
> I am not the one making those comments. I don't have enough C expertise
> to neither confirm or deny them. But that also makes me unable to answer to
> the
> author of the comments in the proper way. I intended to receive something to
> cor
On Fri., 20 dec. 2019 at 3:57, Martin Schulte ()
wrote:
> Hello!
>
> > Could you please comment about this assertions:
> >
> > 1.- bash will either do a select() or an ioctl(FIONREAD), or neither
> > of them, but not both, as it should for it to work. read -t0 is broken.
> > 2.- Conclusion: re
. –
No. It works as intended. It's not usable in a pipe in the way you try,
but this is caused by the principles of a pipe, not by a bug in read.
while ! read -t 0; do
echo 'It works as intended - just press RETURN to see why'
done
Best regards,
Martin
To: Chester Ramey
On thu., dec. 19 of 2019 at 12:40, Chet Ramey () wrote:
> On 12/18/19 6:40 PM, Bize Ma wrote:
>
> >>> The exit status is 0 if input is available on the specified file
> > descriptor, non-zero otherwise.
>
> Bash-5.0 uses select/FIONREAD to determine whether or not there is
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
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
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, non-zero otherwise
$RANDOM; do echo test; done | while true; do read -t
> 0.00$RANDOM; echo $REPLY; done
> (usually takes a few seconds to crash, sometimes minutes)
>
> Fix:
> Swap the lines in reset_alarm().
Thanks for the report. This will be fixed in the next release of bash.
--
`
IGALRM comes between those 2 calls and
crashes (sub)shell.
Repeat-By:
while sleep 0.00$RANDOM; do echo test; done | while true; do read -t
0.00$RANDOM; echo $REPLY; done
(usually takes a few seconds to crash, sometimes minutes)
Fix:
Swap the lines in reset_alarm().
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
&g
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: aff
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/rea
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 sh
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 intende
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?
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 s
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 "" | { slee
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 "" | { sleep 1s;
> read -t 0; echo $?; } ; done | sort | uniq -c
> 10 0
>
> I expected that the read will return non-
; i++ )); do echo -n "" | { sleep 1s; read -t
0; echo $?; } ; done | sort | uniq -c
10 0
I expected that the read will return non-zero in this case. I think it returned
with zero because the STDIN was still open. The docs said "read returns success
if input is available on the
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
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, failure otherwise.
Maybe I made a mistake but I tested and I got variable results:
arpa
I really appreciate that. Thank you very much :)
My software would finally work in a loop with no worries.
OK, I was able to figure it out. The problem is that the `read -t'
> generates SIGALRM, which sometimes arrives and is handled while the SIGCHLD
> trap is running (bash-4.2 runs
> took longer before the crash occurred and this is the report I got:
>
> malloc: ./read.def:696: assertion botched
> free: called with already freed block argument
> Aborting...catch.
OK, I was able to figure it out. The problem is that the `read -t'
generates SIGALRM, which
> OK. What version of Linux are you using? Maybe I have that and will be
> able to reproduce it more easily.
>
> Chet
>
Oh sorry, if you mean the kernel version it's 3.4.10-tuxonice in Gentoo but
it happens in most if not all kernels I used.
Glibc version is 2.15-r2.
> OK. What version of Linux are you using? Maybe I have that and will be
> able to reproduce it more easily.
>
> Chet
>
Gentoo, but it happens in Slackware as well. Ubuntu too I think.
> >
> > This doesn't help a lot. How about building bash-4.2.42 with -g so
> > debugging symbols are preserved, then seeing where the crash is?
> >
>
> I compiled 4.2.42 using gcc 4.6.3 (C[XX]FLAGS="-march=native -O2 -g"). It
> took longer before the crash occurred and this is the report I got:
>
I'd suggest to also try valgrind.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
>
> This doesn't help a lot. How about building bash-4.2.42 with -g so
> debugging symbols are preserved, then seeing where the crash is?
>
I compiled 4.2.42 using gcc 4.6.3 (C[XX]FLAGS="-march=native -O2 -g"). It
took longer before the crash occurred and this is the report I got:
malloc: ./read
On 1/24/13 11:32 AM, konsolebox wrote:
> Hi. Thanks for the attention. Here's a backtrace:
This doesn't help a lot. How about building bash-4.2.42 with -g so
debugging symbols are preserved, then seeing where the crash is?
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Hi. Thanks for the attention. Here's a backtrace:
summon.
:
disown.
read.
*** glibc detected *** /bin/bash: double free or corruption (fasttop):
0x006caa60 ***
Program received signal SIGSEGV, Segmentation fault.
0x7740c685 in ?? () from /lib64/libc.so.6
(gdb) bt
#0 0x774
On Friday 25,January,2013 12:28 AM, Chet Ramey wrote:
> On 1/24/13 8:35 AM, konsolebox wrote:
>> Hi. Is there a way to prevent this segmentation fault in Bash? I'm not sure
>> where the fault happens but when there's a function that handles a trap and
>> when a signal is caught during a session of
On 1/24/13 8:35 AM, konsolebox wrote:
> Hi. Is there a way to prevent this segmentation fault in Bash? I'm not sure
> where the fault happens but when there's a function that handles a trap and
> when a signal is caught during a session of read with -t, Bash crashes. An
> example code that makes th
en is this:
#!/bin/bash
shopt -s -o monitor
function catch {
echo catch.
}
trap catch SIGCHLD
while :; do
echo summon.
sleep 4s &
echo :
:
echo disown.
disown
echo read.
read -t 1
done
The output would be somet
On Linux, I get an assertion error, using the following example:
$ for i in {1..1000};do read -t .02 = size) /* XXX was i + 2; use i + 4 for multibyte/read_mbchar */
{
input_string = (char *)xrealloc (input_string, size += 128);
remove_unwind_protect
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 <http://cfaj.freeshell.org>
===
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 ye
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 documentation?
Would anyone know about an alternative,
On Sat, Jun 14, 2008 at 10:15:06PM -0400, Chet Ramey wrote:
> Stephane Chazelas wrote:
>
>> What about a different $? (like 2 for timeout)?
>
> That's reasonable. I'm thinking 128+SIGALRM.
[...]
That makes sense, but it's a bit of a pain to handle.
read -t 10
Stephane Chazelas wrote:
What about a different $? (like 2 for timeout)?
That's reasonable. I'm thinking 128+SIGALRM.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
On Fri, Jun 13, 2008 at 06:52:48PM -0400, Chet Ramey wrote:
[...]
>> Also, it may be good to specify that, if the timeout is
>> reached, bash will consume the input but will not put
>> that consumed input into the variable:
>
> Actually, the bash-4.0 implementation will put the input
Stephane Chazelas wrote:
However, I find that it does have an effect on Unix or
TCP sockets, on /dev/random and other terminals than
"the" terminal.
So maybe a better wording could be: "This option has no
effect on regular files"?
Thanks, I'll put in s
Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='ba
> 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'
Patch Level: 16
Release Status: release
Description:
While looking for a non-blocking read: See below.
Repeat-By:
[EMAIL PROTECTED]:~$ bash
[EMAIL PROTECTED]:~$ while sleep 1; do read -t 0; done
... type ^C ...
Segmentation fault
[EMAIL PROTECTED]:~$
Fix:
I do
[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
pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2
uname output: Linux bugs 2.6.10-5-k7 #1 Tue Apr 5 12:56:05 UTC 2005 i686
GNU/Linux
Machine Type: i386-pc-linux-gnu
Bash Version: 3.0
Patch
47 matches
Mail list logo
