I can confirm that the patch resolves all the issues I had.
Thank you very much for your help, it is very appreciated.
On 10/15/24 11:08 AM, Thomas Oettli wrote:
> Got it, I just backported your patch to Bash 5.2 and it fixed the issue on
> my build host.
> I will roll out the patched version to a
On 10/15/24 11:08 AM, Thomas Oettli wrote:
Got it, I just backported your patch to Bash 5.2 and it fixed the issue on
my build host.
I will roll out the patched version to all my hosts this weekend and keep
you noticed if anything strange happens.
BTW: will this patch be backported to previous
?
Von: Chet Ramey
Gesendet: Dienstag, 15. Oktober 2024 16:24
An: Thomas Oettli ; bug-bash@gnu.org
Cc: chet.ra...@case.edu
Betreff: [EXT] Re: AW: Re: AW: Re: read command sometimes misses newline on
timeout
CAUTION: This email originated from outside the SFS organization. Do not follow
On 10/15/24 10:06 AM, Thomas Oettli wrote:
That sounds promising. Is the fix somewhere accessible for me? I would gladly
test it.
I pushed it to the devel branch this morning.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocra
That sounds promising. Is the fix somewhere accessible for me? I would gladly
test it.
- Thomas
On 10/7/24 9:49 AM, Thomas Oettli wrote:
I agree with you, but it should never happen that read returns timeout,
also returns the full line and has already read the newline character.
If that happens, there is no way for the script to decide what to do.
I think I found the problem and fixed
On 10/7/24 9:49 AM, Thomas Oettli wrote:
I agree with you, but it should never happen that read returns timeout,
also returns the full line and has already read the newline character.
I don't see how that can happen, given how the code is structured. It's
possible for the shell to re
your help.
*
Thomas
Von: Martin D Kealey
Gesendet: Dienstag, 8. Oktober 2024 06:23
An: Martin D Kealey
Cc: Thomas Oettli ; bug-bash
Betreff: [EXT] Re: read command sometimes misses newline on timeout
CAUTION: This email originated from outside the SFS
On Tue, 8 Oct 2024 at 06:26, Greg Wooledge wrote:
> From: *Thomas Oettli*
> > The result is two lines in the buffer (without "\n" in between). Do you
> understand now what I mean?
>
> If bash is returning nonzero status after reading a full line, then that
> may be a bug that should be fixed.
>
ot; ; done
) |&
sort | uniq -c
1 +# Hit read timeout SIGALRM, run from line 699 in ./read.def #+
STATUS 142 1 TES
1 +# Hit read timeout SIGALRM, run from line 72 in zread.c #+
STATUS 142 1
2 +# Hit read timeout SIGALRM, run from line 865 in ./read.def #+
STATUS 142 1 T
1
> -- Forwarded message --
> From: *Thomas Oettli*
>1. the script calls "read" on pipe
>2. "read" hits timeout just after it has read "\n" from the pipe
>3. "read" returns the full line, but exits with rc &
.
Von: alex xmb sw ratchev
Gesendet: Montag, 7. Oktober 2024 21:50
An: Thomas Oettli ; bash list
Betreff: [EXT] Re: read command sometimes misses newline on timeout
CAUTION: This email originated from outside the SFS organization. Do not follow
guidance, click links
t; chet.ra...@case.edu>
> *Betreff:* [EXT] Re: read command sometimes misses newline on timeout
>
> CAUTION: This email originated from outside the SFS organization. Do not
> follow guidance, click links or open attachments unless you recognize the
> sender and know the content
homas Oettli
Cc: bug-bash@gnu.org ; chet.ra...@case.edu
Betreff: [EXT] Re: read command sometimes misses newline on timeout
CAUTION: This email originated from outside the SFS organization. Do not follow
guidance, click links or open attachments unless you recognize the sender and
know the conte
t; read -t .01 buf # try to read line to $buf with
> timeout
> rc=$?
> if (( rc == 0 )); then # got a full line or the rest of a
> partial line, append $buf to $line
> line+=$buf
> elif (( rc > 128 )); then
Sorry Alex, I don't understand exactly what you mean.
Here is the Test-Script again with some comments:
function reader() {
local buf line
while :; do
read -t .01 buf # try to read line to $buf with timeout
rc=$?
if (( rc == 0 ));
there is a case , u [[ $readreply ]] after read
On Monday, October 7, 2024, Thomas Oettli via Bug reports for the GNU
Bourne Again SHell wrote:
> I agree with you, but it should never happen that read returns timeout,
> also returns the full line and has already read the newline character
I agree with you, but it should never happen that read returns timeout, also
returns the full line and has already read the newline character.
If that happens, there is no way for the script to decide what to do. Please
see the provided test script, it showcases the error.
If I did a mistake
;.
If the timeout occurs in just the right moment, read returns the full line,
but the return code says timeout (rc > 128).
If the read command times out, it always returns > 128, so if you have a
return code in that range, you can assume read timed out and react
accordingly.
Th
GenuineIntel
> GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
>
> Bash Version: 5.2
> Patch Level: 26
> Release Status: release
>
> Description:
> I have tried to write a bash script that asynchronously reads from
> a pipe (line by line) with the help of "read -
GenuineIntel GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.2
Patch Level: 26
Release Status: release
Description:
I have tried to write a bash script that asynchronously reads from a
pipe (line by line) with the help of "read -t".
If the timeout occurs in just
oint is that if it's easy enough -- and it is -- to do it without
adding features to bash itself, then there's not a compelling argument,
nor sufficient demand, to add more code to bash.
So then fleshing this out, let me ask: Is it reasonable to add an
optional timeout to the "
Chet Ramey writes:
> On 4/20/23 1:53 PM, Dale R. Worley wrote:
>> How difficult would it be to add an optional timeout argument to the
>> "wait" builtin?
>
> Try a variant of this.
> ...
My interest here isn't "Can I accomplish this task with B
On 4/20/23 1:53 PM, Dale R. Worley wrote:
How difficult would it be to add an optional timeout argument to the
"wait" builtin?
Try a variant of this.
trap 'echo timeout!' USR1 # choose your fighter
wait_with_timeout()
{
pid=$1
timeout=$2
{ sl
How difficult would it be to add an optional timeout argument to the
"wait" builtin?
I occasionally run into situations where this functionality is
desirable, more often than I expect, really. And though the last thing
Bash needs is an additional feature, naively it seems like it would
to
> > use the monotonic timer, adding a new variable like MONOSECONDS, or some
> > other call to get monotonic time via clock_gettime).
>
> Interesting. I was wondering how you got onto this, so I looked around for
> any utilities (e.g., timeout, sleep), library functions, or
ipts that are sitting in
> loops, calculating a timeout based on the $SECONDS variable. The current
> behavior using realtime instead of monotime is surprising to us.
>
> It would be nice if $SECONDS was using `clock_gettime(CLOCK_MONOTONIC,
> &val)` as it would usually make the most
e via clock_gettime).
Interesting. I was wondering how you got onto this, so I looked around for
any utilities (e.g., timeout, sleep), library functions, or system calls
that use the monotonic clock and couldn't find any. It must be too `new';
everyone seems to use the realtime clock.
I'll
On Fri, 24 Mar 2023 at 10:42, William Kennington via Bug reports for the
GNU Bourne Again SHell wrote:
> It would be nice if $SECONDS was using `clock_gettime(CLOCK_MONOTONIC,
> &val)` as it would usually make the most sense when you want to know the
> time since the script started.
Generally n
as the potential to break any scripts that are sitting in
> > loops, calculating a timeout based on the $SECONDS variable. The current
> > behavior using realtime instead of monotime is surprising to us.
>
> So the system jumps forward in time at some random point, after the s
sitting in
loops, calculating a timeout based on the $SECONDS variable. The current
behavior using realtime instead of monotime is surprising to us.
So the system jumps forward in time at some random point, after the shell
script has started and $SECONDS has been initialized. You're worried
We have systems that start off with inaccurate clocks and at some point
after the boot process synchronize with the network and jump forward in
time. This has the potential to break any scripts that are sitting in
loops, calculating a timeout based on the $SECONDS variable. The current
behavior
On 11/23/22 7:52 AM, Csaba wrote:
Hello!
If I use timeout with read shell command, next read command use it too.
Thanks for the report.
https://lists.gnu.org/archive/html/bug-bash/2022-11/msg00035.html
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Hello!
If I use timeout with read shell command, next read command use it too.
See my test shell program:
#!/bin/bash
read -rest 2
od -An -tx1 <<<"${REPLY}"
read -ren2 -p $'---\nIs this OK? [y/N] '
echo
od -An -tx1 <<<"$
hat was not mine... Tested at https://www.jdoodle.com/ia/3EO
$ sed <<"eotest" >/tmp/test-timeout-race.sh 's/^//'
#!/bin/bash
declare -p BASH_VERSI{NFO,ON}
uptime
uname -a
po() {
for f in {1..1};do
read -t .
On Wed, Oct 28, 2020 at 09:23:09AM -0400, Chet Ramey wrote:
>
> I can't reproduce this using the following stripped-down reproducer:
> trap 'echo $f ; exit' SIGINT
>
> for f in {1..1}; do
> read -t .01 v
> if [ $? -ne 142 ]; then
> echo $f: $?
> fi
> done
On 10/28/20 7:06 AM, felix wrote:
> Bash Version: 5.1
> Patch Level: 0
> Release Status: rc1
>
> Description:
> Trying to see limits of timeout with `read -t`, I encounter strange
> and unconstant result: sometime `read -t .01` don't consider
>
: 0
Release Status: rc1
Description:
Trying to see limits of timeout with `read -t`, I encounter strange
and unconstant result: sometime `read -t .01` don't consider
timeout, when running fastly multiple time.
From help:
-t timeout time out and return failure... may
On 11/27/16 3:47 PM, Dmitry Goncharov wrote:
> On Fri, Nov 25, 2016 at 12:40:58PM -0500, Chet Ramey wrote:
>> On 11/25/16 9:57 AM, Dmitry Goncharov wrote:
>>> Auto variables have unspecified values after a call to longjmp.
>>
>> This is true. It's what the USE_VAR macro is intended to defeat, but
On 11/25/16 9:57 AM, Dmitry Goncharov wrote:
> Auto variables have unspecified values after a call to longjmp.
This is true. It's what the USE_VAR macro is intended to defeat, but let's
see what marking i volatile does.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
that's not true https://gist.github.com/fa4efd90376ff2714901e4429fdee734
>>> read successfully reads the data, but then it's discarded by bash
>>>
>>>
>>
>>It's discarded by bash because the read doesn't read 10
>> characters within the
;It's discarded by bash because the read doesn't read 10
> characters within the time limit. If you use -N 5, you get
> your output. "-t" says it will timeout and return failure if a
> specified number of characters is not read within timeout period.
>
Th
ou use -N 5, you get
your output. "-t" says it will timeout and return failure if a
specified number of characters is not read within timeout period.
If timeout is exceeded, then return status is > 128:
bash -c '( printf 12345; sleep 2 ) | ( read -t 1 -N 10 v; echo "s=$?,
<$v>" )'
s=142, <>
(status is > 128)
On 11/24/16, Chet Ramey wrote:
> On 11/24/16 2:57 AM, Clark Wang wrote:
>> See following example:
>>
>> # echo $BASH_VERSION
>> 4.4.5(2)-release
>> # ( printf 12345 ) | ( read -t 1 -N 10 v; echo "<$v>" )
>> <12345>
>> # ( printf 12345; sleep 2 ) | ( read -t 1 -N 10 v; echo "<$v>" )
>> <>
>> #
>>
>
On 11/24/16 2:57 AM, Clark Wang wrote:
> See following example:
>
> # echo $BASH_VERSION
> 4.4.5(2)-release
> # ( printf 12345 ) | ( read -t 1 -N 10 v; echo "<$v>" )
> <12345>
> # ( printf 12345; sleep 2 ) | ( read -t 1 -N 10 v; echo "<$v>" )
> <>
> #
>
> The second "read" did not save "12345" to
See following example:
# echo $BASH_VERSION
4.4.5(2)-release
# ( printf 12345 ) | ( read -t 1 -N 10 v; echo "<$v>" )
<12345>
# ( printf 12345; sleep 2 ) | ( read -t 1 -N 10 v; echo "<$v>" )
<>
#
The second "read" did not save "12345" to "v". Is this a bug?
-clark
On 6/6/16 10:01 AM, George Schwab wrote:
> Bash Version: 4.3
> Patch Level: 11
> Release Status: release
>
> Description:
> The read builtin does not appear to save partial reads to the
> variable when a timeout has occured.
> This is contrary to the do
e67 #3 SMP Tue May 10 10:22:44
EDT 2016 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.3
Patch Level: 11
Release Status: release
Description:
The read builtin does not appear to save partial reads to the
variable when a timeout has occured.
This is co
> > Does it really need to be in the help text, which is
> > just a short reminder reference, as well?
>
> I think info about how "read -t" exits should be _moved_ from under
> the -t discussion to the Exit Status section. Right now there is
> complete documentation in one
> The documentation already says "the exit status is greater than
> 128 if the timeout is exceeded" in a couple of places.
Oh, look at that, a mere four lines above the text I quoted. I guess
I can downgrade this to a documentation request.
> Doe
;
> I would like to be able to distinguish the no-data conditions. In
> particular I want to know whether I got a timeout or an end-of-file,
> but as you can see, Bash is not documented to behave differently in
> these two cases.
>
> As it happens, in Bash 4.2, "read" ex
;
> I would like to be able to distinguish the no-data conditions. In
> particular I want to know whether I got a timeout or an end-of-file,
> but as you can see, Bash is not documented to behave differently in
> these two cases.
>
> As it happens, in Bash 4.2, "read"
I want to know whether I got a timeout or an end-of-file,
but as you can see, Bash is not documented to behave differently in
these two cases.
As it happens, in Bash 4.2, "read" exits with status 1 on EOF and
SIGALRM on timeout. This is just what I want. Can I count on this
behavior? If
On Sat, Apr 04, 2009 at 08:37:32AM -0300, Sergio Charpinel Jr. wrote:
> So, first of all, I'm trying to find a way to combine TMOUT variable with
> vlock.
What's vlock?
> I just found a way to do this in zhs. And if it is not possible, I
> need to set TIMEOUT just for roo
On Sat, 4 Apr 2009 08:37:32 -0300, Sergio Charpinel Jr. wrote:
> Hi,
> I'm in this mailing list, and I dont know if I am in the right place. If it
> doesnt, tell me.
comp.unix.shell
I know, it's not very intuitive...
Jonesy
--
Marvin L Jones| jonz | W3DHJ | linu
Hi,
I'm in this mailing list, and I dont know if I am in the right place. If it
doesnt, tell me.
So, first of all, I'm trying to find a way to combine TMOUT variable with
vlock. I just found a way to do this in zhs. And if it is not possible, I
need to set TIMEOUT just for root, an
Mike gmail.com> writes:
>
> Hi, I have a question.
>
> Why is the "timeout" command disappearing from recent Linux
> distributions?
> I am referring to the command that allows a time limit to be set for
> another command:
>
> # timeout 10 ftp ...
Mike wrote:
Hi, I have a question.
Why is the "timeout" command disappearing from recent Linux
distributions?
[...]
I don't think it is a bash built-in command, but why not?
No demand. It's so trivial to do as a separate command.
Chet
--
``The lyf so short,
Hi, I have a question.
Why is the "timeout" command disappearing from recent Linux
distributions?
I am referring to the command that allows a time limit to be set for
another command:
# timeout 10 ftp ...
It is useful to me.
I don't think it is a bash built-in comma
define a timeout value after which the script
will no longer attempt to talk to the server and go on to the next server in
the list.
How can I accomplish that?
Here is part of my script:
- - - - - - 8< - - - - -
until [ $done ]
do
read <&3 servername
if [ $? !=
From: iuso
To: bug-bash@gnu.org
Subject: timeout option for read that restarts on type
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation
CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCO
61 matches
Mail list logo
