On 9/17/25 10:37 AM, Oğuz wrote:
On Wed, Sep 17, 2025 at 5:31 PM Chet Ramey wrote:
Thanks, this is a mostly-unrelated issue that is easily fixed.
Ah, you beat me to it. The problem is `i' ends up with -1 here
https://cgit.git.savannah.gnu.org/cgit/bash.git/tree/builtins/read.def?h=devel#n595
On Wed, Sep 17, 2025 at 19:16:21 +0700, Robert Elz wrote:
> I think a better question would be, which shell is being
> used to run ./test0 & wait and ./test1 & wait.
>
> The implication is that it also is bash, but I doubt bash would
> act as described. If however it is some other shell (say das
Andreas Kähäri wrote:
> Can you say something about the version of Bash you're running and on
> what platform? I can not reproduce the hanging behaviour of "test1"
> using Bash 5.2.37 on Alpine Linux, nor with 5.2.15 on Debian, or with
> 5.3.0 buildt from the latest sources on Alpine.
Now that you
Date:Wed, 17 Sep 2025 20:04:58 +1000
From:Duncan Roe via Bug reports for the GNU Bourne Again SHell
Message-ID:
| Do you by any chance have job control disabled?
I think a better question would be, which shell is being
used to run ./test0 & wait and ./test1 & wai
On Sep 17 2025, Greg Wooledge wrote:
> I can't tell what those ioctl() calls are doing. Why call TCGETS three
> times in a row?
I see only two times TCGETS. The first TCGETS comes from isatty. The
second one comes from tcgetattr to save the current settings, followed
by tcsetattr to update the
On 9/17/25 9:48 AM, Robert Elz wrote:
g...@wooledge.org said:
| I'm not sure exactly what bash is doing here, but I'm guessing it has
| something to do with switching the terminal from canonical mode to raw
| mode...?
I don't look at bash code, but the NetBSD shell sets the "eol" char
Date:Wed, 17 Sep 2025 10:25:08 -0400
From:Greg Wooledge
Message-ID: <20250917142508.gk22...@wooledge.org>
| I can't tell what those ioctl() calls are doing. Why call TCGETS three
| times in a row?
That's a good question ... and the TCGETS after the (successful)
Date:Wed, 17 Sep 2025 15:33:31 +0200 (CEST)
From:pourko--- via Bug reports for the GNU Bourne Again SHell
Message-ID:
| Why do you need to "doubt" it, when you can just as easily test it?
You're right I could, but I'm lazy, and Duncan had already done that,
and n
Chet Ramey wrote:
> It's more likely that the OP is running the scripts from an interactive
> shell that is not bash.
On my box I have no shells other than bash, and even sh is symlinked to bash
~# help | head -1
GNU bash, version 5.2.37(47)-release (x86_64-slackware-linux-gnu)
On 9/17/25 11:09 AM, pourko--- via Bug reports for the GNU Bourne Again
SHell wrote:
Chet Ramey wrote:
It's more likely that the OP is running the scripts from an interactive
shell that is not bash.
On my box I have no shells other than bash, and even sh is symlinked to bash
~# help | head -1
On Wed, Sep 17, 2025 at 16:37:55 +0200, pourko--- via Bug reports for the GNU
Bourne Again SHell wrote:
> Robert Elz wrote:
> > > Also, if you notice there is a "#!/bin/bash" in each of the examples.
> >
> > That's irrelevant, that's not the shell that is causing the issue.
> > What matters is wh
Robert Elz wrote:
> > Also, if you notice there is a "#!/bin/bash" in each of the examples.
>
> That's irrelevant, that's not the shell that is causing the issue.
> What matters is which shell you are using to run those scripts, that
> is the one in which you're doing
> ./test1 & wait
I s
On 9/17/25 8:16 AM, Robert Elz wrote:
Date:Wed, 17 Sep 2025 20:04:58 +1000
From:Duncan Roe via Bug reports for the GNU Bourne Again SHell
Message-ID:
| Do you by any chance have job control disabled?
I think a better question would be, which shell is being
On Wed, Sep 17, 2025 at 5:31 PM Chet Ramey wrote:
> Thanks, this is a mostly-unrelated issue that is easily fixed.
Ah, you beat me to it. The problem is `i' ends up with -1 here
https://cgit.git.savannah.gnu.org/cgit/bash.git/tree/builtins/read.def?h=devel#n595
and then the SIGTERM and SIGCONT se
On 9/17/25 6:04 AM, Duncan Roe via Bug reports for the GNU Bourne Again
SHell wrote:
[1]+ Stopped./test1
-bash: wait: warning: job 1[4286] stopped
Do you by any chance have job control disabled?
It's more likely that the OP is running the scripts from an interactive
shel
On Wed, Sep 17, 2025 at 20:48:13 +0700, Robert Elz wrote:
> g...@wooledge.org said:
> | I'm not sure exactly what bash is doing here, but I'm guessing it has
> | something to do with switching the terminal from canonical mode to raw
> | mode...?
>
> I don't look at bash code, but the NetBSD
On Wed, Sep 17, 2025 at 15:33:31 +0200, pourko--- via Bug reports for the GNU
Bourne Again SHell wrote:
> Robert Elz wrote:
> > I think a better question would be, which shell is being
> > used to run ./test0 & wait and ./test1 & wait.
> >
> > The implication is that it also is bash, but I doubt
Robert Elz wrote:
> I think a better question would be, which shell is being
> used to run ./test0 & wait and ./test1 & wait.
>
> The implication is that it also is bash, but I doubt bash would
> act as described.
Why do you need to "doubt" it, when you can just as easily test it?
Also, if you no
On Wed, Sep 17, 2025 at 10:29:32AM +0200, Bash development wrote:
> Andreas Kähäri wrote:
> > Can you say something about the version of Bash you're running and on
> > what platform? I can not reproduce the hanging behaviour of "test1"
> > using Bash 5.2.37 on Alpine Linux, nor with 5.2.15 on Debia
On Wed, Sep 17, 2025 at 08:25:01AM +0200, pourko--- via Bug reports for the GNU
Bourne Again SHell wrote:
> Some people suggested that my post was not in a suitable form.
> So I am rephrasing my original post, with simpler examples:
>
> cat <<'EOF' >./test0
> #!/bin/bash
> [ -t 0 ] && [ -t 1 ] ||
20 matches
Mail list logo
