On Saturday, August 2, 2025, Xi Ruoyao wrote:
> Hi,
>
> Bash 5.3 was released in Jul, and the md5sum was
> 4c7fb7d82586f93ab1d833ef20378ee8. But now it has changed to
> 977c8c0c5ae6309191e7768e28ebc951. I compared the content and it seems
> the Georgian translation is ch
Hi,
Bash 5.3 was released in Jul, and the md5sum was
4c7fb7d82586f93ab1d833ef20378ee8. But now it has changed to
977c8c0c5ae6309191e7768e28ebc951. I compared the content and it seems
the Georgian translation is changed.
Is this intentional or accidental?
--
Xi Ruoyao
On 7/31/25 12:25 PM, Ross Burton wrote:
I will republish the tar files.
In the future, could you create a new point release instead of regenerating the
tarball?
Most distros checksum the tarballs for security purposes, and silently swapping
the tarball looks a lot like a supply-chain attack.
>I will republish the tar files.
In the future, could you create a new point release instead of regenerating the
tarball?
Most distros checksum the tarballs for security purposes, and silently swapping
the tarball looks a lot like a supply-chain attack.
Ross
IMPORTANT NOTICE: The contents of t
On 7/30/25 4:32 AM, Christian Weisgerber wrote:
Chet Ramey:
This means the build now
requires the msgfmt(1) tool from the gettext package to regenerate
those .gmo files.
No, if the configure process doesn't find msgfmt, it sets $MSGFMT (which
the Makefile uses) to `:'. I'll have to see what e
Chet Ramey:
> > This means the build now
> > requires the msgfmt(1) tool from the gettext package to regenerate
> > those .gmo files.
>
> No, if the configure process doesn't find msgfmt, it sets $MSGFMT (which
> the Makefile uses) to `:'. I'll have to see what effects that has on the
> build pro
On 7/28/25 5:36 PM, Christian Weisgerber wrote:
The bash-5.3.tar.gz release tarball ships with a number of outdated
.gmo message catalog files, i.e., at least their mtimes are older than
those of the corresponding .po files.
Yes, though the content has not changed.
This means the build now
The bash-5.3.tar.gz release tarball ships with a number of outdated
.gmo message catalog files, i.e., at least their mtimes are older than
those of the corresponding .po files. This means the build now
requires the msgfmt(1) tool from the gettext package to regenerate
those .gmo files.
I assume
BASH PATCH REPORT
=
Bash-Release: 5.3
Patch-ID: bash53-001
Bug-Reported-by:John Sidles
Bug-Reference-ID:
Bug-Reference-URL:
https://lists.gnu.org/archive/html/bug-bash/2025-07/msg00035.html
BASH PATCH REPORT
=
Bash-Release: 5.3
Patch-ID: bash53-003
Bug-Reported-by:Isabella Bosia
Bug-Reference-ID:
Bug-Reference-URL:
https://lists.gnu.org/archive/html/bug-bash/2025-06/msg00173
BASH PATCH REPORT
=
Bash-Release: 5.3
Patch-ID: bash53-002
Bug-Reported-by:
Bug-Reference-ID:
Bug-Reference-URL: https://savannah.gnu.org/bugs/?67326
Bug-Description:
There are too many differences
On 7/23/25 9:41 AM, Dr. Werner Fink wrote:
On 2025/07/23 09:38:41 -0400, Chet Ramey wrote:
On 7/23/25 9:34 AM, Dr. Werner Fink wrote:
Correct configured it seems to work
abuild@noether:/mnt> LD_PRELOAD=/usr/lib64/libuid_wrapper.so ./bash
Segmentation fault (core dum
On 2025/07/23 09:38:41 -0400, Chet Ramey wrote:
> On 7/23/25 9:34 AM, Dr. Werner Fink wrote:
>
> > Correct configured it seems to work
> >
> > abuild@noether:/mnt> LD_PRELOAD=/usr/lib64/libuid_wrapper.so ./bash
> > Segmentation fault (core d
On 7/23/25 9:34 AM, Dr. Werner Fink wrote:
Correct configured it seems to work
abuild@noether:/mnt> LD_PRELOAD=/usr/lib64/libuid_wrapper.so ./bash
Segmentation fault (core dumped)
LD_PRELOAD=/usr/lib64/libuid_wrapper.so ./bash
abuild@noether:/mnt> UID_WRAPPER=1 UID_WRAPPE
me/abuild/rpmbuild/BUILD/libssh-test-0.11.2-build/libssh-0.11.2/build/lib/libfs_wrapper.so
> > > ./bash
> > > Segmentation fault (core dumped)
> > > LD_PRELOAD=/usr/lib64/libsocket_wrapper.so:/usr/lib64/libnss_wrapper.so:/usr/lib64/libuid_wrapper.so:/usr/lib64/
libc fork() wrapper thing.
That's actually posix_spawn.
Bash doesn't use posix_spawn.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
ne3({flags=CLONE_VM|CLONE_VFORK|CLONE_CLEAR_SIGHAND,
> > > > exit_signal=SIGCHLD, stack=0x7f7a0d302000, stack_size=0x9000}, 88
> > > >
> > >
> > > This is a libc fork() wrapper thing.
> >
> > That's actually posix_spawn.
>
> Bash does
On Jul 23 2025, Chet Ramey wrote:
>> Strange ... AFAICS clone3() is used to spawn the subprocess for the shell
>> 307826 clone3({flags=CLONE_VM|CLONE_VFORK|CLONE_CLEAR_SIGHAND,
>> exit_signal=SIGCHLD, stack=0x7f7a0d302000, stack_size=0x9000}, 88
>>
>
> This is a libc fork() wrapper thing.
That's
/lib64/libuid_wrapper.so:/usr/lib64/libpam_wrapper.so:/home/abuild/rpmbuild/BUILD/libssh-test-0.11.2-build/libssh-0.11.2/build/lib/libchroot_wrapper.so:/home/abuild/rpmbuild/BUILD/libssh-test-0.11.2-build/libssh-0.11.2/build/lib/libfs_wrapper.so
./bash
Segmentation fault (core dumped
all the current user and group information.
With `ulimit -c unlimited` I see a core dump of the bash-5.3
#0 0x in ?? ()
Missing separate debuginfos, use: zypper install
socket_wrapper-debuginfo-1.5.0-1.1.x86_64
nss_wrapper-debuginfo-1.1.16-1.3.x86_64 uid_wrapper-debuginfo-1.3.1
pper.so:/usr/lib64/libpam_wrapper.so:/home/abuild/rpmbuild/BUILD/libssh-test-0.11.2-build/libssh-0.11.2/build/lib/libchroot_wrapper.so:/home/abuild/rpmbuild/BUILD/libssh-test-0.11.2-build/libssh-0.11.2/build/lib/libfs_wrapper.so
> ./bash
> Segmentation fault (core dumped)
On 2025/07/23 09:18:45 +0200, Dr. Werner Fink wrote:
>
> Starting sshd with bash-5.3 leads to
>
> 307827 execve("/bin/sh", ["sh", "-c", "--",
> "KRB5CCNAME=/tmp/test_socket_wrapper_EElgbB/gss/cc
> KRB5_CONFIG=/tmp/test
> > > > >
> > > > > > > found a not expanded m4 autoconf macro GL_MDA_DEFINES in
> > > > > > > m4/fcntl-o.m4
> > > > > >
> > > > > > Good catch. What happens if you take that macro out and re-run
> > > > > > aut
NES in
> > > > > > m4/fcntl-o.m4
> > > > >
> > > > > Good catch. What happens if you take that macro out and re-run
> > > > > autoconf
> > > > > and configure?
> > > >
> > > > As I do autoconfig by defau
On 7/22/25 4:57 AM, Dr. Werner Fink wrote:
Description:
The kill test of util-linux fails with bash 5.3
---
/home/abuild/rpmbuild/BUILD/util-linux-2.41.1-build/util-linux-2.41.1/tests/expected/kill/decode
2025-05-05 08:28:45.049284591 +
+++
/home/abuild/rpmbuild/BUILD/util
a not expanded m4 autoconf macro GL_MDA_DEFINES in m4/fcntl-o.m4
Good catch. What happens if you take that macro out and re-run autoconf
and configure?
As I do autoconfig by default for bash it shows
Are you sure it changes config.h?
It changes not the config.h AFAICS ... I only cross this
t; > [...]
> > > >
> > > > found a not expanded m4 autoconf macro GL_MDA_DEFINES in m4/fcntl-o.m4
> > >
> > > Good catch. What happens if you take that macro out and re-run autoconf
> > > and configure?
> >
> > As I do autoconfi
On 7/22/25 9:55 AM, Andreas Schwab wrote:
On Jul 22 2025, Chet Ramey wrote:
On 7/22/25 8:12 AM, Dr. Werner Fink wrote:
On 2025/07/22 13:15:38 +0200, Dr. Werner Fink wrote:
[...]
found a not expanded m4 autoconf macro GL_MDA_DEFINES in m4/fcntl-o.m4
and hence in the final configure script which
you take that macro out and re-run autoconf
and configure?
As I do autoconfig by default for bash it shows
Are you sure it changes config.h?
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ram
On Jul 22 2025, Chet Ramey wrote:
> On 7/22/25 8:12 AM, Dr. Werner Fink wrote:
>> On 2025/07/22 13:15:38 +0200, Dr. Werner Fink wrote:
>> [...]
>> found a not expanded m4 autoconf macro GL_MDA_DEFINES in m4/fcntl-o.m4
>> and hence in the final configure script which leads to
>
> When I take out th
appens if you take that macro out and re-run autoconf
> and configure?
As I do autoconfig by default for bash it shows
bash/bash> grep fcntl.h /abuild/oscbuild/openSUSE_Tumbleweed/.build.log
[ 19s] checking for working fcntl.h... yes
[ 41s] checking for fcntl.h... yes
nevertheless
On 7/22/25 8:12 AM, Dr. Werner Fink wrote:
On 2025/07/22 13:15:38 +0200, Dr. Werner Fink wrote:
[...]
found a not expanded m4 autoconf macro GL_MDA_DEFINES in m4/fcntl-o.m4
and hence in the final configure script which leads to
When I take out that macro, it doesn't change the resulting config
On 7/22/25 8:12 AM, Dr. Werner Fink wrote:
On 2025/07/22 13:15:38 +0200, Dr. Werner Fink wrote:
[...]
found a not expanded m4 autoconf macro GL_MDA_DEFINES in m4/fcntl-o.m4
Good catch. What happens if you take that macro out and re-run autoconf
and configure?
--
``The lyf so short, the craft
On 7/22/25 3:08 AM, wer...@suse.de wrote:
Bash Version: 5.3
Patch Level: 0
Release Status: release
Description:
The kill test of util-linux fails with bash 5.3
OK. Are you reporting a bug here? Anything more specific?
--
``The lyf so short, the craft so long to lerne.''
On 7/22/25 4:57 AM, Dr. Werner Fink wrote:
One line cause this behaviour change:
---
/abuild/oscbuild/openSUSE_Tumbleweed/home/abuild/rpmbuild/BUILD/bash-5.3.0-build/bash-5.3/execute_cmd.c
2025-07-22 10:52:15.705599240 +0200
+++ bash-5.3/execute_cmd.c 2025-06-05 17:02:01.0
for fcntl... yes
[ 29s] checking for fcntl.h... yes
[ 46s] 467 | if (fcntl (herepipe[1], F_GETPIPE_SZ, 0) < document_len)
[ 194s] 467 | if (fcntl (herepipe[1], F_GETPIPE_SZ, 0) < document_len)
whereas the 5.2 does not show that
osc rbl openSUSE:Factory bash st
; -DRECYCLES_PIDS -Wall -g -Wuninitialized -Wextra -Wno-switch-enum
> >> -Wno-unused-variable -Wno-unused-parameter -Wno-parentheses
> >> -ftree-loop-linear -pipe -DBNC382214=0 -DIMPORT_FUNCTIONS_DEF=0
> >> -DDEFAULT_LOADABLE_BUILTINS_PATH='/usr/lib64/bash'
-Wno-unused-parameter -Wno-parentheses
>> -ftree-loop-linear -pipe -DBNC382214=0 -DIMPORT_FUNCTIONS_DEF=0
>> -DDEFAULT_LOADABLE_BUILTINS_PATH='/usr/lib64/bash'
>> uname output: Linux noether 6.11.8-1-default #1 SMP PREEMPT_DYNAMIC Thu Nov
>> 14 12:54:01 UTC 2024 (09
214=0 -DIMPORT_FUNCTIONS_DEF=0
> -DDEFAULT_LOADABLE_BUILTINS_PATH='/usr/lib64/bash'
> uname output: Linux noether 6.11.8-1-default #1 SMP PREEMPT_DYNAMIC Thu Nov
> 14 12:54:01 UTC 2024 (099023b) x86_64 x86_64 x86_64 GNU/Linux
> Machine Type: x86_64-suse-linux-gnu
>
> Ba
-flto=auto -g -D_GNU_SOURCE
-DRECYCLES_PIDS -Wall -g -Wuninitialized -Wextra -Wno-switch-enum
-Wno-unused-variable -Wno-unused-parameter -Wno-parentheses -ftree-loop-linear
-pipe -DBNC382214=0 -DIMPORT_FUNCTIONS_DEF=0
-DDEFAULT_LOADABLE_BUILTINS_PATH='/usr/lib64/bash'
uname output: Lin
On 7/17/25 12:52 AM, Nathan Mills wrote:
Bash Version: 5.3-devel
Patch Level: 0
Release Status: devel-a23c863e
Clang:
```
clang version 19.1.7
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /nix/store/x6rsdc4s0f1j9bn1cx2h1l5fj8765ykw-clang-19.1.7/bin
```
NixOS:
```
nixos
On 7/17/25 8:10 AM, Zachary Santer wrote:
"JWAIT_WAITING"?
All the flags that affect behavior when waiting for jobs start with JWAIT_.
The `WAITING' part means we are looking for jobs that are terminated or
changed state that have the J_WAITING flag set in their job struct,
indicating that we
On 7/17/25 8:10 AM, Zachary Santer wrote:
I've applied your patch, but gcc 15.1.0 has decided that a 'struct
winsize *' not being a 'struct winsize *' is an error now.
Does cygwin have tcgetwinsize(3), and where does it declare
`struct winsize'? You're not the first person to report something l
86_64
OS: cygwin
Compiler: gcc
Compilation CFLAGS: -Wno-error=incompatible-pointer-types
uname output: MSYS_NT-10.0-26100 Zack2021HPPavilion
3.6.3-ab81aae6.x86_64 2025-07-01 18:20 UTC x86_64 Msys
Machine Type: x86_64-pc-cygwin
Bash Version: 5.3
Patch Level: 0
Release Status: maint
Would be nice if ba
cygwin
> Compiler: gcc
> Compilation CFLAGS: -Wno-error=incompatible-pointer-types
> uname output: MSYS_NT-10.0-26100 Zack2021HPPavilion
> 3.6.3-ab81aae6.x86_64 2025-07-01 18:20 UTC x86_64 Msys
> Machine Type: x86_64-pc-cygwin
>
> Bash Version: 5.3
> Patch Level: 0
> Release
ncompatible-pointer-types
uname output: MSYS_NT-10.0-26100 Zack2021HPPavilion
3.6.3-ab81aae6.x86_64 2025-07-01 18:20 UTC x86_64 Msys
Machine Type: x86_64-pc-cygwin
Bash Version: 5.3
Patch Level: 0
Release Status: maint
Would be nice if bashbug were generated even if bash itself failed to build.
>
From: the.true.nathan.mi...@gmail.com
To: bug-bash@gnu.org
Subject: Getopts crashes when passing several zeroes.
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2
uname output: Linux nixos 6.6.87.2-microsoft
a script
immediately, if it's appropriate, while you wait for me to release a patch
the distros will accept."
There is no other workaround. You can use the patch I sent with my first
reply to you on your own version of bash, but it will take a couple of days
for me to get through release engin
27; waits for the sleep process.
>
>
> Hmmm ... yes, the suggested workaround does patch the minimal working
> example (MWE). But it is NOT a general-purpose workaround.
>
> As a concrete---and common-place---example, I use bash-scripts to run
> (asynchronously) cpu-intensiv
place---example, I use bash-scripts to run
(asynchronously) cpu-intensive optical-character-recognition (OCR)
processes. On my system, optimal cpu-loading is achieved when no more than
five OCR processes are running. So I initialize an array PIDS with the
job-ids of the asynchronous OCR processes
URL:
<https://savannah.gnu.org/bugs/?67326>
Summary: Bash 5.3: Problem with new in-process command
substitution ${..} on macOS
Group: The GNU Bourne-Again SHell
Submitter: None
Submitted: Wed 16 Jul 2025 02:07:39
uot;
This means that in posix mode, even when it's given a list of pids to
operate on, bash-5.3 can return the pid of a process from the terminated
background pids list (the `bgpids list') that is not one of the pids
supplied as an argument.
It will do this if it doesn't find on
On Tue, Jul 15, 2025 at 11:39 AM Chet Ramey wrote:
>
> On 7/15/25 11:35 AM, Zachary Santer wrote:
> > On Tue, Jul 15, 2025 at 10:29 AM Chet Ramey wrote:
> >>
> >> With respect to not consulting the list of saved pids if given a list
> >> of pid arguments, solving this problem.
> >
> > I'd like to
On 7/15/25 11:35 AM, Zachary Santer wrote:
On Tue, Jul 15, 2025 at 10:29 AM Chet Ramey wrote:
With respect to not consulting the list of saved pids if given a list
of pid arguments, solving this problem.
I'd like to think that's just a stopgap, but yeah, I can play around with that.
Why do
On Tue, Jul 15, 2025 at 10:29 AM Chet Ramey wrote:
>
> With respect to not consulting the list of saved pids if given a list
> of pid arguments, solving this problem.
I'd like to think that's just a stopgap, but yeah, I can play around with that.
On 7/15/25 10:27 AM, Zachary Santer wrote:
On Tue, Jul 15, 2025 at 9:46 AM Chet Ramey wrote:
Why not just try the patch I attached to the message?
Because I'd rather the new POSIX-mode 'wait -n' behavior work
correctly? You said the patch reverted the behavior to that of b
On Tue, Jul 15, 2025 at 9:46 AM Chet Ramey wrote:
>
> Why not just try the patch I attached to the message?
Because I'd rather the new POSIX-mode 'wait -n' behavior work
correctly? You said the patch reverted the behavior to that of bash
5.2.
On 7/15/25 8:22 AM, Zachary Santer wrote:
On Tue, Jul 15, 2025 at 6:52 AM Zachary Santer wrote:
Alright, that's definitely what's going on.
Actually, no. I am having a heck of a time trying to duplicate this
behavior any other way. See attached. This is the current tip of the
devel branch, 8
On 7/15/25 6:52 AM, Zachary Santer wrote:
On Mon, Jul 14, 2025 at 10:52 PM John Sidles wrote:
I was a pretty big part of that discussion, and this looks broken to
me. If 'wait -n' is passed a list of pids, it shouldn't also be
waiting for other background processes that weren't passed to it as
On 7/14/25 10:52 PM, John Sidles wrote:
Prior to bash 5.3, this functionality was provided (even in posix mode) by
'wait -n "${PIDS[@]}";'' ... this bash idiom worked GREAT.
Now, in bash 5.3, this 'wait -n' functionality still works fine ... EXCEPT
in po
On 7/14/25 1:32 PM, Robert Elz wrote:
Date:Mon, 14 Jul 2025 10:34:12 -0400
From:Chet Ramey
Message-ID: <6a02a36f-d31d-4816-8988-5a4ccf960...@case.edu>
| The short story is that `wait -n' now returns the status of any process
| that's completed and hasn't b
On Tue, Jul 15, 2025 at 8:22 AM Zachary Santer wrote:
>
> I am having a heck of a time trying to duplicate this
> behavior any other way.
I'm betting this is some kind of bash-internal race condition. Does
seem specific to procsub pids in interactive mode, though.
zsant@Zack2021H
ommands executed separately on the command line? Could
that be something about job control messing it up?
On the bright side, John, if you're not running 'wait -n' on the
command line or with PROMPT_COMMAND or something similar, I think
you're good to go.
zsant@Zack2021H
On Tue, Jul 15, 2025 at 06:52:14 -0400, Zachary Santer wrote:
> On Mon, Jul 14, 2025 at 10:52 PM John Sidles wrote:
> >>
> >> I was a pretty big part of that discussion, and this looks broken to
> >> me. If 'wait -n' is passed a list of pids, it shouldn't also be
> >> waiting for other background
printf '%s\n' "${waited_for}"
256
[1]+ Done
Alright, that's definitely what's going on. Chet, this is a bug, man.
This is never going to be what the user wants when they're passing
'wait -n' pid arguments.
> I have more than 100 posix-mode scripts th
7;s doing?
>
I have more than 100 posix-mode scripts that require the functionality (in
words) "for 'PIDS' an array of background process IDs, please wait for at
least one process to finish".
Prior to bash 5.3, this functionality was provided (even in posix mode) by
'wai
Date:Mon, 14 Jul 2025 10:34:12 -0400
From:Chet Ramey
Message-ID: <6a02a36f-d31d-4816-8988-5a4ccf960...@case.edu>
| The short story is that `wait -n' now returns the status of any process
| that's completed and hasn't been waited for yet, just like `wait'. It's
On Mon, Jul 14, 2025 at 11:50 AM Chet Ramey wrote:
>
> The short story is that `wait -n' now returns the status of any process
> that's completed and hasn't been waited for yet, just like `wait'. It's
> not restricted to processes that terminates after it's invoked. It does
> this even when it's g
On 7/13/25 12:37 PM, John Sidles wrote:
Bash Version: 5.3
Patch Level: 0
Release Status: release
Description:
MacOS Homebrew bash '5.3.0(1)-release' (apparently?) breaks 'wait'
bash-settings are as follows (in my experiments,
the sole critical setting is "posix on&qu
Configuration Information [Automatically generated, do not change]:
Machine: aarch64
OS: darwin24.4.0
Compiler: clang
Compilation CFLAGS: -DSSH_SOURCE_BASHRC
-DDEFAULT_LOADABLE_BUILTINS_PATH='/opt/homebrew/lib/bash:/usr/local/lib/bash:/usr/lib/bash:/opt/local/lib/bash:/usr/pkg/lib/bash:/op
Introduction
The first public release of bash-5.3 is now available with the URLs
ftp://ftp.cwru.edu/pub/bash/bash-5.3.tar.gz
ftp://ftp.gnu.org/pub/gnu/bash/bash-5.3.tar.gz
and from the master branch of the bash git repository
(http://git.savannah.gnu.org/cgit/bash.git/log/)
and the
(I wrote):
>> https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html#tag_19_06_02
>> I don't read POSIX specs. I have people who read POSIX specs.
(And Chet wrote):
> Consider asking them first. They're your people, after all.
Good one! Well done.
On 6/30/25 10:20 AM, Stan Marsh wrote:
https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html#tag_19_06_02
I don't read POSIX specs. I have people who read POSIX specs.
Consider asking them first. They're your people, after all.
--
``The lyf so short, the craft so long
(I wrote):
>> I always thought the "colon-free" versions of the P.E. was a bash-ism, but
>> experimentation shows that it works in "dash" as well. And "man dash"
>> contains
>> the following text:
>> In the parameter expansions sho
On 6/29/25 10:13 AM, Stan Marsh wrote:
I always thought the "colon-free" versions of the P.E. was a bash-ism, but
experimentation shows that it works in "dash" as well. And "man dash" contains
the following text:
In the parameter expansions shown previ
On Sun, Jun 29, 2025, at 11:41 AM, Greg Wooledge wrote:
> The colon variants ${var:-word} were added later, IIRC by ksh.
Looks like the System III shell released them first:
https://www.in-ulm.de/~mascheck/bourne/#system3
--
vq
On Sun, Jun 29, 2025 at 06:39:18 -0600, Stan Marsh wrote:
> Note, incidentally, that it is not strictly true that a negative offset has
> to be preceded by a space. A zero will work as well. And I think that is
> clearer. I.e., instead of:
>
> # Print the last 2 characters of $HOME
> $ echo ${H
On Sun, Jun 29, 2025 at 21:51:52 +0700, Robert Elz wrote:
> Date:Sun, 29 Jun 2025 08:13:07 -0600
> From:Stan Marsh
> Message-ID:
>
> | So, is this POSIX, or just a dash-extension?
>
> It is original Bourne Shell (from 7th edition Bell Labs Unix)
> and is (or shoul
Date:Sun, 29 Jun 2025 08:13:07 -0600
From:Stan Marsh
Message-ID:
| So, is this POSIX, or just a dash-extension?
It is original Bourne Shell (from 7th edition Bell Labs Unix)
and is (or should be) supported by every Bourne-compatible shell.
It definitely is in POS
And here is another interesting thing inspired by this thread.
I always thought the "colon-free" versions of the P.E. was a bash-ism, but
experimentation shows that it works in "dash" as well. And "man dash" contains
the following text:
In the parameter expan
>"Note that a negative offset must be separated from the [non-following]
>colon by at least one space to avoid being confused with the ':-'
>expansion,' since a negative offset can exist immediately beside a
>subsequent colon.
>Wiley
Note, incidentally, that it is not strictly true that a negat
On Sat, Jun 28, 2025, at 10:00 PM, Wiley Young wrote:
> I don't see any other written instances of omitting a ':' amongst the
> examples in these x4 descriptions.
>
> Whether the existing omission was intentional or no, I think it would be
> helpful for the reader to point up how that one line of c
On Wed, 25 Jun 2025 14:00:11 -0400 Greg Wooledge wrote:
> Both of those are valid syntax, and they have *slightly* different
meanings.
True, both forms are syntactically valid.
It could be, at some earlier draft, that the variation in syntax was placed
there as an exercise for the reader, given h
After many years of staring at the Bash Reference Manual, I just noticed a typo
in Section 3.5.3 (Shell Parameter Expansion):
[cid:image003.jpg@01DBE5D7.B1DBC120]
The parameter in the echo command is missing a colon. It should be:
$ echo ${v:-unset}
On Wed, Jun 25, 2025 at 17:47:31 +, Wartik, Steven P "Steve" via Bug
reports for the GNU Bourne Again SHell wrote:
> After many years of staring at the Bash Reference Manual, I just noticed a
> typo in Section 3.5.3 (Shell Parameter Expansion):
>
> [cid:image003
On 6/18/25 5:37 PM, Alvaro Falagan wrote:
Hi,
I would like to report an issue I’ve found in Bash (5.0.17) regarding the
use of pipelines involving built-in commands and here-documents.
### Summary
When a built-in (e.g., `echo`, `export`, `cd`, etc.) is used in a pipeline,
and the next command
On Thu, 19 Jun 2025 at 07:37, Alvaro Falagan
wrote:
> Bash does not clean up all its internal memory and leaves at least one file
> descriptor (`/dev/pts/0`, fd 255) open at exit.
Why would it be a problem if memory is still allocated or filedescriptors
are still open at exit?
Memory pag
On 6/14/25 5:17 AM, Stan Marsh wrote:
1) Why is the error ignored, making it almost impossible to determine that
something went wrong?
Because it shouldn't be a fatal error in a pre-release version, where we're
mostly interested in bash bugs.
2) Shouldn
bash "make
install", so
I assume the "makeinfo" thing is new.
It's not. You probably did it with a release version, not a pre-release
version.
Non-release versions of bash ship with formatted documentation that may or
may not be up-to-date; the announcement contains
&q
uring the "configure" step) ?
A lot of people won't have the texinfo tools installed, and bash
itself builds just fine without them. So, my understanding/guess is
that the documentation part is considered "optional", and will be
built if the tools are present, but skipped i
(Followup to my previous post)
To answer my own question, I guess it is pretty obvious that the answer to "How
to
fix?" is "Install texinfo and re-run the make install", but it raises two
important
questions:
1) Why is the error ignored, making it almost impossible to determine that
I found the problem (I think). See below:
--- Cut Here ---
make[1]: Entering directory '/home/username/Build/bash-5.3-rc2/doc'
rm -f bashref.info
makeinfo --no-split -I../lib/readline/doc ./bashref.texi
make[1]: makeinfo: Command not found
Makefile:181: recipe for target 'bashr
x27;t reproduce this.
After I configure --prefix=/fs1/install and run `make install', I get:
$ ls /fs1/install/share/man/man1/
bash.1 bashbug.1
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrate
ly be
preferred over let.[0]
You might find this discussion interesting. It discusses the problems with
double-evaluation of array subscripts and describes the changes that ended
up in bash-5.2.
https://lists.gnu.org/archive/html/bug-bash/2021-03/msg00056.html
--
``The lyf so short, the craft so lo
I did: ./configure --prefix=$HOME/local/bash5
Then make and then make install (all of this is done as a non-root user).
It created the directory listed above and all the necessary subdirs, including
share/man/man1, but left that directory empty.
Shouldn't (at least) a copy of "bash.1&
once, it can get a
bit cranky. Wait a few minutes and try again, is all I can suggest.
> >(( hash[$key]++ ))# is not safe
> >let 'hash[$key]++'# is safe
>
> Could you explain what the issue/problem is? What makes it unsafe?
>
> And, I reall
On Fri, Jun 13, 2025 at 07:08:21 -0600, Stan Marsh wrote:
> BTW, and only tangentially related, "man bash" says that "let" and "(( ))" are
> exactly the same, but "shellcheck" thinks otherwise. "shellcheck" says you
> should
> use &qu
Greg Wooledge wrote:
> On Fri, Jun 13, 2025 at 07:08:21 -0600, Stan Marsh wrote:
>> BTW, and only tangentially related, "man bash" says that
>> "let" and "(( ))" are exactly the same, but "shellcheck"
>> thinks otherwise. "she
On Fri, Jun 13, 2025 at 07:57:54 -0600, Stan Marsh wrote:
> Also, note that if you are running with "set -e" (or "trap ... ERR"), then
> having
> "let" (or "(( ))") return a non-zero exit status when it happens to evaluate
> to zero,
> could cause an unexpected script abort.
This is why I linked
>All of this is intentional, and not a bug.
It is possible to be both.
But, yes, it reflects a fundamental inconsistency in the C/Unix ecosystem.
The fact that in most programming languages (e.g., C, AWK), 0 means false and
non-zero
means true, but in the shell, it is the opposite.
E.g., in AWK
1 - 100 of 1577 matches
Mail list logo
