On Wed, 31 Jan 2024 at 01:04, Andreas Schwab wrote:
> On Jan 30 2024, Zachary Santer wrote:
> > There's no way this is the intended behavior, right?
>
> The command is doing exactly what it is documented to do, that is do all
> of the shell word expansions.
>
If that's how the documentation is i
Version 5.2.15
see example script below, the unassigned $nope is reported to be in line
4 which is obviously wrong. Removing the parentheses around the echo
fixes the problem.
#!/bin/bash
set -u
( echo x ) | while read f ; do
echo Test $f
echo Test $f
echo Test $f
echo Test $f
Like you, I can't reproduce it on the desktop platforms I have available
right now.
The bash devel git branch has fairly fine granularity. If you can automate
the signal sending somewhat, maybe by having a child process send signals
to $$, you could use your script and `git bisect' to find the c
Hello again,
Here is another analysis that my collegue made on the issue:
Bash Compiled for wrong OS?
Analysis with strace.
After receiving SIGUSR1, Debian only blocks SIGCHLD, then clears the block:
205295 --- SIGUSR1 {si_signo=SIGUSR1, si_code=SI_USER, si_pid=205327,
si_uid=1040} ---
205
I was just watching the discussion because I thought the existing
behavior would never be changed as it behaved this way for a long
time. However, I now think I should leave a comment because even
Martin (who I believed was one of the careful people about backward
compatibility as seen in [1,2]) se
> Before Bash 3.2
P.S. Sorry, I meant "In Bash 3.2 and before,", where 3.2 is included
in the statement.
On 1/29/24 12:51 AM, A4-Tacks wrote:
Bash Version: 5.2
Patch Level: 21
Release Status: release
Description:
input M-C-e (shell-expand-line),
expand the result containing `'` (single quotation mark) failed.
Repeat-By:
```bash
# echo "$(echo $'ab\n\'cd\nef')"
ab
On 2/2/24 3:32 PM, Tavian Barnes wrote:
Bash Version: 5.2
Patch Level: 26
Release Status: release
Description:
When a SIGCHLD trap is set, commands that include two process
substitutions fail with a strange "unexpected EOF" error.
Thanks for the report. This was fixed last September, the re
On 2/3/24 8:36 AM, Matthias Urlichs via Bug reports for the GNU Bourne
Again SHell wrote:
Version 5.2.15
see example script below, the unassigned $nope is reported to be in line 4
which is obviously wrong. Removing the parentheses around the echo fixes
the problem.
#!/bin/bash
set -u
( echo
On 2/2/24 6:33 PM, Grisha Levit wrote:
On Thu, Feb 1, 2024 at 7:41 PM Chet Ramey wrote:
On 1/22/24 9:44 PM, Grisha Levit wrote:
The size of the buffer used for printf -v is tracked in an int but this
can overflow since the buffer can be built up by multiple vsnprintf(3)
calls, each of which c
On 2/3/24 10:00 AM, Mykyta Dorokhin wrote:
I have found the commit on devel branch which breaks things for me (and
probably other Yocto-based builds):
This one still works
==
commit 89d788fb0152724a93e0fdab8c15116e5c76572b
Author: Chet Ramey
Date: Mon Feb 17 11:41:35 20
Hello Chet,
The release of 5.2 is from October 2022 and thus should include a patch
for this issue.
To double-check, I just downloaded, patched up, and built 5.2.26. It
also fails.
Thus I conclude that your fix from 2022 was incomplete.
Proof:
~/src/bash/bash-5.2.21$ grep define.PATCH patc
On 2/3/24 10:28 AM, Mykyta Dorokhin wrote:
Analysis with strace.
After receiving SIGUSR1, Debian only blocks SIGCHLD, then clears the block:
205295 --- SIGUSR1 {si_signo=SIGUSR1, si_code=SI_USER, si_pid=205327,
si_uid=1040} ---
205295 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
205295 rt_si
On 2/3/24 3:09 PM, Matthias Urlichs wrote:
Hello Chet,
The release of 5.2 is from October 2022 and thus should include a patch for
this issue.
No. bash-5.2 was frozen earlier in September, 2022 and released September
26, 2022. That fix came in after the release (and wouldn't have been
enough
On 2/2/24 9:39 AM, Mike Jonkmans wrote:
From the manual, glob-expand-word:
The word before point is treated as a pattern for pathname expansion,
and the list of matching filenames is inserted, replacing the word.
If a numeric argument is supplied, an asterisk is appended before
pathn
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -flto=auto -ffat-lto-objects -flto=auto
-ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security
-Wall
uname output: Linux maxwell 5.19.0-5
On 2/2/24 5:15 PM, Mike Jonkmans wrote:
On Fri, Feb 02, 2024 at 09:50:46AM -0500, Greg Wooledge wrote:
On Fri, Feb 02, 2024 at 03:39:54PM +0100, Mike Jonkmans wrote:
[ mkdir test; cd test; touch file1 file2 ]
Going into `vi-command' mode on the line `ls *' puts the cursor on the `*'.
Then `glo
On Sat, Feb 03, 2024 at 03:43:45PM -0500, Chet Ramey wrote:
> On 2/2/24 9:39 AM, Mike Jonkmans wrote:
> > From the manual, glob-expand-word:
>
> glob-expand-word doesn't work that great in vi command mode, mostly for
> the reasons you suspect. What made you use it over the standard vi mode
> bind
On Sat, Feb 03, 2024 at 04:59:08PM -0500, Chet Ramey wrote:
> On 2/2/24 5:15 PM, Mike Jonkmans wrote:
> > On Fri, Feb 02, 2024 at 09:50:46AM -0500, Greg Wooledge wrote:
> > > On Fri, Feb 02, 2024 at 03:39:54PM +0100, Mike Jonkmans wrote:
> > > > [ mkdir test; cd test; touch file1 file2 ]
> > > > Go
Hello,
Again, I'm on ("commit bash-20200221 snapshot") commit, the one I think breaks
things:
https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=0df4ddca3f371bc258fe4185cdec36fce3e7be7b
There is a line in trap.c with your change. If I revert it then everything
works again:
- if (i
On Fri, Feb 2, 2024 at 4:21 PM Chet Ramey wrote:
> OK, I'll take that as a feature request for a future version.
>
While I'm making feature requests.
I hit C-x C-e and enter the following into my editor:
var='duck'
declare -p var
(
var='squirrel'
declare -p var
)
declare -p var
I save tha
On Sunday, February 4, 2024, Zachary Santer wrote:
>
> While I'm making feature requests.
>
I want to make one too. Multiline commands retrieved from history can be
short-circuited like this:
$ ls
x y
$ echo '
> rm *
> ' >z
$
$ ls
x y z
$ echo ''
rm *
' >z
> ^C
$ ls
On Sun, 4 Feb 2024, 02:01 Koichi Murase, wrote:
> I now think I should leave a comment because even Martin (who I believed
> was one of the careful people about backward compatibility as seen in
> [1,2]) seems to suggest a breaking change.
>
That's a fair point.
I am generally concerned about b
Thank you for the discussion.
2024年2月4日(日) 12:59 Martin D Kealey :
> I am generally concerned about breaking changes that affect existing
> scripts, but I see changes to readline as less problematic,
I also assume shell scripts, but shell scripts for interactive
settings. Interactive settings ca
On Sun, 4 Feb 2024 at 15:17, Koichi Murase wrote:
> 2024年2月4日(日) 12:59 Martin D Kealey :
> > I am generally concerned about breaking changes that affect existing
> scripts, but I see changes to readline as less problematic,
>
> I also assume shell scripts, but shell scripts for interactive settin
25 matches
Mail list logo
