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 changed.
>
> Is this inten
Le Fri, Aug 01, 2025 at 12:44:14PM +0200, Félix Hauri via Bug reports for the
GNU Bourne Again SHell a écrit :
> All this could be done by using `mapfile`!
I wrote a litte `arrayPopulate` function regarding your request:
https://f-hauri.ch/vrac/arrayManip.sh.txt
Usage: arrayPopulate [-O orig
Hello,
the presence of --disable-alias or --disable-FEATURE does not clarify what the
defaults are: is by running only "./configure" that option enabled or disabled.
The remark about the possibility to use --disable-FEATURE does not relate to
the point I raised.
Greetings // Дилян
На 2 авгус
What's with the spate of meaningless noise responses on this thread?
Really, folks, you need to get a grip!
As to the substance of this thread, yeah, if you carefully read the INSTALL
file (as I
did this afternoon), it is all there, but it is not a particularly easy read.
I get where OP is comi
ill code new one
a converter for old configure scripts
it makes threaded checks ..
instant finish guaranteed
On Sat, Aug 2, 2025, 4:15 AM microsuxx wrote:
> old configure scripts are uberoutdated
>
> On Sat, Aug 2, 2025, 4:15 AM microsuxx wrote:
>
>> and
>>
>> --without-*otherthing*
old configure scripts are uberoutdated
On Sat, Aug 2, 2025, 4:15 AM microsuxx wrote:
> and
>
> --without-*otherthing* .
>
> On Sat, Aug 2, 2025, 4:07 AM Lawrence Velázquez wrote:
>
>> On Fri, Aug 1, 2025, at 8:48 PM, microsuxx wrote:
>> > make a small comment
>> >
>> > there is also -
and
--without-*otherthing* .
On Sat, Aug 2, 2025, 4:07 AM Lawrence Velázquez wrote:
> On Fri, Aug 1, 2025, at 8:48 PM, microsuxx wrote:
> > make a small comment
> >
> > there is also --disable-*option* for each
>
> The configure output already says this:
>
> --disable-FEATURE
On Fri, Aug 1, 2025, at 8:48 PM, microsuxx wrote:
> make a small comment
>
> there is also --disable-*option* for each
The configure output already says this:
--disable-FEATURE do not include FEATURE (same as
--enable-FEATURE=no)
--
vq
make a small comment
there is also --disable-*option* for each
On Fri, Aug 1, 2025, 10:32 PM Chet Ramey wrote:
> On 8/1/25 1:47 AM, Дилян Палаузов wrote:
> > Hello,
> >
> > To prepare software for compiling I run ./configure --help and then
> decide how and if to alter the default behaviour. T
On 8/1/25 2:07 AM, Дилян Палаузов wrote:
Hello,
I have installed libreadline 8.3 on the system in a way that it links with
libtinfow, so linking with termcap should not be necessary (but I am not 100%
on the last).
OK. The bash configure still doesn't know that it's supposed to get the
termc
On 8/1/25 1:47 AM, Дилян Палаузов wrote:
Hello,
To prepare software for compiling I run ./configure --help and then decide how
and if to alter the default behaviour. This means that ./configure --help
should suggest what the default behaviour is and how to deviate from it.
I think it's suff
Hello,
All this could be done by using `mapfile`!
Consider this little `dumpArray` function:
$ dumpArray() {
local _fmt_str; local -n _array=$1
printf -v _fmt_str ' [%q]=%%s\n' ${!_array[@]}
printf "$_fmt_str" "${_array[@]@Q}"
}
$ dumpA
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 5:15 PM, Robert Elz wrote:
Date:Wed, 30 Jul 2025 09:31:52 -0600
From:Stan Marsh
Message-ID:
| I wonder why "" was previously special-cased.
Once upon a time, chdir("") would have acted the same as chdir(".")
because in the kernel, the pathname loo
On Thu, Jul 31, 2025 at 1:16 PM Greg Wooledge wrote:
>
> You seem to have the set -u option turned on for some reason.
>
Ouch good catch, lost sight about this one, but it was even worst, I had an
alias on cd that was resolving "" into $HOME :-)
I guess I set it up 40 yr back and forgot it :-)
On Thu, Jul 31, 2025 at 12:58:57 +0200, Phi Debian wrote:
> ksh93 always treats cd "$undefined" as an error, this is true but the error
> is not related to cd
>
> TC$ echo $KSH_VERSION
> Version AJM 93u+m/1.1.0-alpha+11981f5f/MOD 2025-06-22
> TC$ cd $Undefined
> ./arch/linux.i386-64/bin/ksh: U
On Thu, Jul 31, 2025 at 9:28 AM Andreas Kähäri
wrote:
> On Thu, Jul 31, 2025 at 09:01:30AM +0200, Phi Debian wrote:
>
>
> https://www.austingroupbugs.net/view.php?id=1047
>
>
Thanx for the pointer, so the rationale seems to be (citing the ref)
This is bad because many scripts do:
cd "$dir"
On Thu, Jul 31, 2025 at 09:01:30AM +0200, Phi Debian wrote:
> May be this new POSIX feature should be effective in POSIX mode only?
>
> I tried to read de POSIX document in the links, and can't find a rationale
> for such a change, any pointers ?
>
> Cheers
It is discussed in issue #1047 in the
May be this new POSIX feature should be effective in POSIX mode only?
I tried to read de POSIX document in the links, and can't find a rationale
for such a change, any pointers ?
Cheers
Date:Wed, 30 Jul 2025 09:31:52 -0600
From:Stan Marsh
Message-ID:
| I wonder why "" was previously special-cased.
Once upon a time, chdir("") would have acted the same as chdir(".")
because in the kernel, the pathname lookup would see that this is
a relative path (
On 7/30/25 10:25 AM, Grisha Levit wrote:
BTW, `help cd' still has the now outdated statement:
A null directory name is the same as the current directory.
No, a null directory name in CDPATH (that paragraph describes how cd uses
CDPATH) is still the same as `.'.
--
``The lyf so short, t
old stories , ..
On Wed, Jul 30, 2025, 7:25 PM Stan Marsh wrote:
>
> >It is not a bug.
>
> >> The SUS[1] says "If directory is an empty string,
> >> the results are unspecified.".
> >>
> >> [...]
> >>
> >> [1]:
> >> https://pubs.opengroup.org/onlinepubs/9699919799
>It is not a bug.
>> The SUS[1] says "If directory is an empty string,
>> the results are unspecified.".
>>
>> [...]
>>
>> [1]:
>> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/cd.html
>This was changed in POSIX.1-2024:
>If _directory_ is a
On Wed, Jul 30, 2025, at 4:52 AM, Michal Sojka wrote:
> Description:
> When running "cd ''", bash 5.3 fails with "cd: null directory"
> while previous versions succeeded without an error and no
> directory was changed. I'm not sure whether this is considered a
> bug
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
On Wed, Jul 30, 2025, 10:22 Grisha Levit wrote:
>
> On Wed, Jul 30, 2025, 09:51 Michal Sojka wrote:
>
>> Configuration Information:
>> Machine: x86_64
>> OS: linux-gnu
>> Compiler: gcc
>> Compilation CFLAGS: -g -O2
>> uname output: Linux steelpick 6.12.37 #1-NixOS SMP PREEMPT_DYNAMIC Thu
>> Jul
On Wed, Jul 30, 2025, 09:51 Michal Sojka wrote:
> Configuration Information:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -g -O2
> uname output: Linux steelpick 6.12.37 #1-NixOS SMP PREEMPT_DYNAMIC Thu Jul
> 10 14:05:15 UTC 2025 x86_64 GNU/$
> Machine Type: x86_64-pc-li
On Wed, Jul 30 2025, Chet Ramey wrote:
> On 7/30/25 4:52 AM, Michal Sojka wrote:
>> Description:
>> When running "cd ''", bash 5.3 fails with "cd: null directory"
>> while previous versions succeeded without an error and no
>> directory was changed. I'm not sure whether t
On 7/30/25 4:52 AM, Michal Sojka wrote:
Bash Version: 5.3
Patch Level: 0
Release Status: release
Description:
When running "cd ''", bash 5.3 fails with "cd: null directory"
while previous versions succeeded without an error and no
directory was changed. I'm not sure w
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
r
NUL is just an abbreviation for Null (from ASCII, see RFC 20).
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
id say setting pending traps to smth
esp w/o cmds inside
is big error
try setting pending .. w o gdb
On Mon, Jul 28, 2025, 10:21 PM Chet Ramey wrote:
> On 7/25/25 12:37 PM, Chakib Mouzaoui wrote:
> > Hello!
> >
> > We sporadically hit a segfault across different kinds of hardware on
> Bash
> > v
On 7/25/25 12:37 PM, Chakib Mouzaoui wrote:
Hello!
We sporadically hit a segfault across different kinds of hardware on Bash
version 5.1.8(1)-release (x86_64-redhat-linux-gnu).
We found that run_sigchld_trap was run despite our bash script never
explicitly setting a SIGCHLD trap. Indeed, the
++
On Mon, Jul 28, 2025, 4:52 PM Chet Ramey wrote:
> On 7/28/25 4:29 AM, Oğuz wrote:
> > On Sat, Jul 26, 2025 at 9:44 PM Greg Wooledge wrote:
> >> The quotation marks don't appear to matter, but
> >> the trailing $ does.
> >
> > `$!' works as well, when there's no most recent asynchronous job:
On 7/28/25 4:29 AM, Oğuz wrote:
On Sat, Jul 26, 2025 at 9:44 PM Greg Wooledge wrote:
The quotation marks don't appear to matter, but
the trailing $ does.
`$!' works as well, when there's no most recent asynchronous job:
$ printf '<%s>\n' $(seq 3)$!
<1
2
3>
$
I think
On 7/27/25 6:22 PM, Christian Weisgerber wrote:
In bash 5.3, the newly added examples/loadables/strptime.c uses the
%ld format specifier to printf() time_t values. At least on OpenBSD
time_t is long long, which causes a type mismatch between format
specifier and argument.
Thanks for the report
On Sat, Jul 26, 2025 at 9:44 PM Greg Wooledge wrote:
> The quotation marks don't appear to matter, but
> the trailing $ does.
`$!' works as well, when there's no most recent asynchronous job:
$ printf '<%s>\n' $(seq 3)$!
<1
2
3>
$
I think the problem is right here:
https://c
... is nothing .. empty .. nonexisting .. gone .. none ..
On Mon, Jul 28, 2025, 6:57 AM Lawrence Velázquez wrote:
> On Sun, Jul 27, 2025, at 10:26 PM, Wiley Young wrote:
> > bash(1): "If the value of IFS is null, no word splitting occurs."
> >
> > ~ $ IFS=$'\0'
>
> Note that this is the same as
On Sun, Jul 27, 2025, at 10:26 PM, Wiley Young wrote:
> bash(1): "If the value of IFS is null, no word splitting occurs."
>
> ~ $ IFS=$'\0'
Note that this is the same as
IFS=
so there's no reason to use the former assignment.
Also, in the context of the shell language, "null" almost alw
bash(1): "If the value of IFS is null, no word splitting occurs."
~ $ IFS=$'\0'
~ $ S=" "
~ $ echo $S"hello"
hello
~ $ echo $S"hello"$
hello$
~ $ echo $S"hello" | xxd
: 2068 656c 6c6f 0a hello.
~ $ echo $S"hello"$ | xxd
: 2068 656c 6c6f 240a hello$.
~ $ unset IFS
~ $
Definitely
On Sat, Jul 26, 2025 at 13:37:09 -0400, mohos wrote:
> export S=" "
> echo $S"hello"$
> Actual output:
> hello$
> Expected output:
> hello$
I can reproduce this in all versions of bash back to 2.05b, which is
the oldest I have. The quotation marks don't appear to matter, but
the trailing $ does.
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 dumped)
LD_PREL
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 dumped)
> > LD_PRELOAD=/usr/lib64/libuid_wra
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_WRAPPER_ROOT=1
On 2025/07/23 09:24:09 -0400, Chet Ramey wrote:
> On 7/23/25 9:06 AM, Dr. Werner Fink wrote:
> > On 2025/07/23 14:53:23 +0200, Dr. Werner Fink wrote:
> > >
> > > The problem is the LD_PRELOAD use in the libssh test suite
> > >
> > > with HAVE_SETRESUID and HAVE_SETRESGID enabled the call
> > >
>
On 7/23/25 9:30 AM, Andreas Schwab wrote:
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 lib
On 2025/07/23 09:33:01 -0400, Chet Ramey wrote:
> On 7/23/25 9:30 AM, Andreas Schwab wrote:
> > 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,
>
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
On 7/23/25 9:06 AM, Dr. Werner Fink wrote:
On 2025/07/23 14:53:23 +0200, Dr. Werner Fink wrote:
The problem is the LD_PRELOAD use in the libssh test suite
with HAVE_SETRESUID and HAVE_SETRESGID enabled the call
LD_PRELOAD=/usr/lib64/libsocket_wrapper.so:/usr/lib64/libnss_wrapper.so:/usr/lib64
On 7/23/25 3:18 AM, Dr. Werner Fink wrote:
307827 futex(0x7ff1d2806158, FUTEX_WAKE_PRIVATE, 2147483647) = 0
307827 getresuid([399], [399], [399]) = 0
307827 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
307827 +++ killed by SIGSEGV +++
This is just a function to get a
On 2025/07/23 14:53:23 +0200, Dr. Werner Fink wrote:
>
> The problem is the LD_PRELOAD use in the libssh test suite
>
> with HAVE_SETRESUID and HAVE_SETRESGID enabled the call
>
> LD_PRELOAD=/usr/lib64/libsocket_wrapper.so:/usr/lib64/libnss_wrapper.so:/usr/lib64/libuid_wrapper.so:/usr/lib64/libp
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_socket_wrapper_EElgbB/gss/k/krb5.conf
> KRB5_KDC_PROFILE=/tmp/test_socket_w
> > > > >
> > > > > > > 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
> > 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_DEFI
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-lin
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.'' - Chaucer
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 +0
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
osc bl openSUSE_Tumbleweed x86_64 | grep fcntl
[ 19s] checking for working fcntl.h... no
[ 22s] checking
On 2025/07/22 10:33:41 +0100, Sam James wrote:
> "Dr. Werner Fink" writes:
>
> > On 2025/07/22 09:08:38 +0200, wer...@suse.de wrote:
> >> Configuration Information [Automatically generated, do not change]:
> >> Machine: x86_64
> >> OS: linux-gnu
> >> Compiler: gcc
> >> Compilation CFLAGS: -O2 -Wa
"Dr. Werner Fink" writes:
> On 2025/07/22 09:08:38 +0200, wer...@suse.de wrote:
>> Configuration Information [Automatically generated, do not change]:
>> Machine: x86_64
>> OS: linux-gnu
>> Compiler: gcc
>> Compilation CFLAGS: -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3
>> -fstack-protector-
On 2025/07/22 09:08:38 +0200, wer...@suse.de wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3
> -fstack-protector-strong -funwind-tables -fasynchronou
On 7/19/25 5:07 AM, Sam James wrote:
Thanks for the report. In the general case, evaluating the value of a shell
variable as a command should save and restore the parser state. In this
edge case, though, it's not necessary because PROMPT_COMMAND is only
evaluated before parsing a command. The at
Chet Ramey writes:
> On 7/5/25 2:57 PM, Carl Johnson wrote:
>
>> Bash Version: 5.3
>> Patch Level: 0
>> Release Status: release
>> Description:
>> When alias definition contains the 'unalias' builtin with the alias's
>> name as its argument with a newline anywhere after the builtin
>> invocation,
On 7/15/25 11:27 AM, A4-Tacks wrote:
Bash Version: 5.2
Patch Level: 37
Release Status: release
Description:
Macro recording lost C-] argument, e.g `C-x ( C-] c C-x ) C-x e`
Thanks for the report. I'll push a fix to the bash and readline devel
branches soon.
--
``The lyf so short, the c
On 7/18/25 12:02 AM, Zachary Santer wrote:
https://pubs.opengroup.org/onlinepubs/9799919799/functions/tcgetwinsize.html#tag_17_609
says that if libc has tcgetwinsize(), you only need to get
its declaration.
I've attached the /usr/include/sys/termios.h file included in my MSYS2
installation.
Hi Zachary,
thanks for the report. I pushed a patch. This will show up in
the next Cygwin release 3.6.5.
https://sourceware.org/cgit/newlib-cygwin/commit/?id=73600d68227e
Thanks,
Corinna
On Jul 18 00:02, Zachary Santer via Cygwin wrote:
> Was "MacOS Homebrew bash '5.3.0(1)-release' breaks '
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-ve
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
On 7/17/25 8:51 AM, Sam James wrote:
Zachary Santer writes:
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.
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: cygwin
Compiler: gc
Zachary Santer writes:
> 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.
>
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: cygwin
> Compiler: gcc
> Compilation CFLAGS: -Wn
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.
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: cygwin
Compiler: gcc
Compilation CFLAGS: -Wno-error=incompatible-pointer-types
uname
On 7/16/25 10:16 AM, John Sidles wrote:
Please let me thank everyone for their kind attention and thoughtful
remarks on this problem ... I am struggling however to summarize the
discussion so far ... specifically in regard to workarounds. To date, the
sole suggested workaround is:
The fi
while (( ++job <= joblimit )) ; do
job &
done
while true ; do
wait -n
job &
done
On Wed, Jul 16, 2025, 4:21 PM John Sidles wrote:
> Please let me thank everyone for their kind attention and thoughtful
> remarks on this problem ... I am struggling however to summarize the
> discussion so far ...
Please let me thank everyone for their kind attention and thoughtful
remarks on this problem ... I am struggling however to summarize the
discussion so far ... specifically in regard to workarounds. To date, the
sole suggested workaround is:
The fix for your case is to insert `wait' without argum
On 7/15/25 1:26 PM, Zachary Santer wrote:
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 pr
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
My bad, I did'nt upgraded my source tree!
Sorry for the noise!
Le Tue, Jul 15, 2025 at 09:58:56AM -0400, Chet Ramey a écrit :
> On 7/15/25 7:33 AM, Félix Hauri wrote:
>
> >var=99;humanizeVar var;echo $var
> >90.95T
> > looks good, but
> >var=99;humanizeVarFact
On 7/15/25 3:21 AM, Robert Elz wrote:
Date:Mon, 14 Jul 2025 15:22:35 -0400
From:Chet Ramey
Message-ID: <90a41c5d-c407-4a36-b7b1-21a9201b4...@case.edu>
| Say you have something like
|
| if command; then
|declare -i X
|X=some-random-expressio
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.
Date:Tue, 15 Jul 2025 23:17:56 +1000
From:Martin D Kealey
Message-ID:
| For stat to give an accurate answer, a snapshot of the content would have
| to be generated, counted, and discarded,
Not at all - simply define the format in such a way that the size is
eit
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 bash
5.2.
With res
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/14/25 7:00 PM, jason stein wrote:
Hi Chet,
thanks for the suggestion. I will update the code when I get a chance to
make dh a loadable builtin.
There are templates in examples/loadables that will get you started.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
On 7/15/25 7:33 AM, Félix Hauri wrote:
var=99;humanizeVar var;echo $var
90.95T
looks good, but
var=99;humanizeVarFactor=1000 humanizeVar var;echo $var
99.00T
should sow '100.00T' instead!
That's what I get on macOS.
--
``The lyf so short, the craft so long
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 posix-mode. Huh?
I sent a patch to fi
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
1 - 100 of 6845 matches
Mail list logo
