Re: Support ksh93 x=${cmd;}

Cedric Blancher writes: > Good morning! > > Could bash please support x=${cmd;} alongside x=$(cmd)? > > x=$(cmd;} works like x=$(cmd), except that cmd does not run in > a subshell, i.e. the stdout within ${cmd;} is redirected to the > variable "x", but any other changes of variables (global/stati

Re: printf fails in version 5.2.026-3

Daniel Lublin writes: > Apparently the patch needed to fix this was the one Florian Weimer > posted in november 2023, in "C compatibility issue in the configure > script" <8734oqnlou@gentoo.org> (if you don't have the mail history: > https://lists.gnu.org/archive/html/bug-bash/2023-11/msg0010

Re: printf fails in version 5.2.026-3

szige...@delg0.elte.hu writes: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt > -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security > -fs

Re: bash-4-2 issue

On Thu, Jan 11, 2024 at 1:03 AM Grisha Levit wrote: > On Wed, Jan 10, 2024 at 5:33 PM Grisha Levit > wrote: > > I'm not sure this is fixed. In all versions, including 4.2 [...] > > > > $ bash -m -c 'trap /usr/bin/true DEBUG; :|:' > > bash: child setpgid (49581 to 49579): Operation not pe

bash-4-2 issue

. I am looking to figure out the particular fix that fixed this issue from the above commit and to backport to bash4-2 version. Is it a known issue? Could you help to identify the change set that fixed the issue from the commit "a0c0a00fc419b"? Thanks in advance. Regards, Sam

Re: Enable compgen even when programmable completions are not available?

Chet Ramey writes: > On 6/29/23 11:16 PM, Eli Schwartz wrote: > >> I assume that, given the option exists in the configure script, there >> are people who will want to use the option made available to them. One >> reason might be because they are configuring it for a system that isn't >> fussed

Re: Enable compgen even when programmable completions are not available?

alex xmb ratchev writes: > On Mon, Jun 26, 2023, 11:55 alex xmb ratchev wrote: > >>[snip] > u also really dont need eval at all > > by the way , what does this nonsense code supposed to do >> separate between vars for future list / deletement ? If you read the linked bug, you'd find out.

posix_spawn (or vfork) support?

ork/ has an interesting set of benchmarks. * https://metacpan.org/pod/Proc::FastSpawn implements this in Perl with some interesting discussion on the performance benefits. best, sam signature.asc Description: PGP signature

Re: [PATCH] Pacify gcc -Wpointer-to-int-cast

Paul Eggert writes: > * lib/sh/random.c (genseed): Use a different type, to pacify GCC > "warning: cast from pointer to integer of different size > [-Wpointer-to-int-cast]" on platforms with 64-bit pointers > and 32-bit int. Thanks for this one. I've been meaning to report it because -Wpointer-

Re: Bash not portable to C23

Chet Ramey writes: > On 3/24/23 1:23 AM, Sam James wrote: > >> I hope so. I'm waiting for a review of an issue in one of its configure >> checks with a strict compiler too [0]. >> [0] >> https://lists.gnu.org/archive/html/bug-bash/2023-02/msg0.html > &

Re: Bash not portable to C23

Paul Eggert writes: > On 3/23/23 18:23, Lawrence Velázquez wrote: >> On Thu, Mar 23, 2023, at 9:16 PM, Paul Eggert wrote: >>> I see that Bash won't compile with a C23 compiler, since it still uses >>> old-style function definitions which C23 no longer supports. Is there >>> any effort and/or int

Re: [PATCH] aclocal.m4: fix -Wimplicit-function-declaration in dup2 check

> On 2 Feb 2023, at 05:46, Sam James wrote: > > dup2 requires a include. Fixes the following when diffing > config.log > when testing with a stricter compiler: > ``` > -warning: call to undeclared function 'dup2'; ISO C99 and later do not > support implicit

[PATCH] aclocal.m4: fix -Wimplicit-function-declaration in dup2 check

dup2 requires a include. Fixes the following when diffing config.log when testing with a stricter compiler: ``` -warning: call to undeclared function 'dup2'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] +error: call to undeclared function 'dup

UBSAN error in lib/sh/random.c:79

libc_start_main (/usr/lib64/libc.so.6+0x23344) #28 0x559791878590 in _start (/usr/bin/bash.self+0x13e590) ``` This is on x86_64-pc-linux-gnu with GCC 13.0.0_pre20230101. Best, sam signature.asc Description: Message signed with OpenPGP

Re: Bash-5.2 official patch 9

> On 14 Nov 2022, at 20:03, Chet Ramey wrote: > > On 11/12/22 4:39 AM, Kerin Millar wrote: >> On Tue, 8 Nov 2022 09:50:51 -0500 >> Chet Ramey wrote: >>> BASH PATCH REPORT >>> = >>> >>> Bash-Release: 5.2 >>> Patch-ID: bash52-009 >> Are there any plans to backport the "f

Re: add custom environment variable in bash source code

> On 18 Aug 2022, at 00:19, b1431736...@163.com wrote: > > Because I'm using Android, Android doesn't support #!/bin/sh and #!/bin/bash, > there is a dynamic library that fixes it, so I want to automatically add > LD_PRELOAD before starting bash to make this dynamic library work , I want to >

Re: bash 5.1 heredoc pipes problematic, shopt needed

On Mon, 25 Apr 2022, 22:03 Chet Ramey, wrote: > On 4/22/22 9:51 AM, Sam Liddicott wrote: > > > Please could we at least have a shopt to maintain the old > behaviour? > > Let's start with making it part of BASH_COMPAT=50. > Thanks- that's great. Sa

Re: bash 5.1 heredoc pipes problematic, shopt needed

ther idea enters their head, nor do they assume anything about whether a called program will or will not redundantly stat the "file" name to check that it is a file. What they do assume is that what worked with bash 5.0 will keep working with minor revision 5.1 This is going to keep coming u

Re: bash 5.1 heredoc pipes problematic, shopt needed

e("/dev/fd/3"))' 3<< /dev/pts/1 lrwx-- 1 sliddicott sliddicott 64 Apr 22 16:05 1 -> /dev/pts/1 lrwx-- 1 sliddicott sliddicott 64 Apr 22 16:05 2 -> /dev/pts/1 lr-x-- 1 sliddicott sliddicott 64 Apr 22 16:05 3 -> '/tmp/tmp.rkDXYvp4hn (deleted)' lr-x---

bash 5.1 heredoc pipes problematic, shopt needed

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 junior 5.15.0-25-g

Re: Crash with 5.2 beta in compgen

> On 16 Apr 2022, at 17:11, Chet Ramey wrote: > > On 4/16/22 1:45 AM, Sam James wrote: > >> Bash Version: 5.2 >> Patch Level: 0 >> Release Status: beta >> Description: >> Bash crashes when running compgen -c -X a. >>

Crash with 5.2 beta in compgen

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: x86_64-pc-linux-gnu-gcc Compilation CFLAGS: -O2 -pipe -march=native -ggdb3 uname output: Linux 2021-10-24 5.15.34-gentoo-dist-hardened #1 SMP Sat Apr 16 02:20:51 BST 2022 x86_64 AMD Ryzen 9

Request for new 5.2 alpha?

Hi, Is there a plan for a 2nd 5.2 alpha? A number of reported bugs have been addressed since and it may help resolve duplicates. Best, sam signature.asc Description: Message signed with OpenPGP

Re: Bash-5.2-alpha available

he new Bash alpha. See https://bugs.gentoo.org/831764#c2 but it seems like it's related? Best, sam signature.asc Description: Message signed with OpenPGP

Re: %q with truncating size loses safeness of %q

it this behaviour, I will make a report there. This is another candidate for shellcheck I guess, which reminds me that I forgot to submit the one for leaky named file descriptors (in contrast to numeric ones). Sam

Re: %q with truncating size loses safeness of %q

so I went harp on about it anymore unless I find a more egregious opportunity for abuse. Sam On Fri, 17 Apr 2020, 23:38 Robert Elz, wrote: > Date:Fri, 17 Apr 2020 16:12:20 -0400 > From:Chet Ramey > Message-ID: <4bacf2f0-9802-67d3-f30b-80e37d058...@case

Re: %q with truncating size loses safeness of %q

So is it to be "fixed" in the documentation with a warning that truncating-size specifiers for %q may nullify the safety benefits for which it is used? Sam On Fri, 17 Apr 2020, 21:12 Chet Ramey, wrote: > On 4/17/20 10:22 AM, Sam Liddicott wrote: > > > Bash Version: 4

%q with truncating size loses safeness of %q

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE

Re: leaks fd for internal functions but not external command

add it to the wishlist for bash 5 ;-) On Thu, 25 Jul 2019 at 15:11, Chet Ramey wrote: > On 7/25/19 9:03 AM, Sam Liddicott wrote: > > > Perhaps if the named fd is also closed on the same statement that opened > > it, it could be kept closed rather than saved and re-opened. &g

Re: leaks fd for internal functions but not external command

unset "$2" set -- "$1" "${@:3}" done return $1 } tmp_fd= && echo {tmp_fd}>&2 2>&1 1>&${tmp_fd} {tmp_fd}<&- ; maybe-close tmp_fd they are my thoughts on avoiding the need to detect the special case of internal commands in order

Re: leaks fd for internal functions but not external command

ternal (long lived) commands This would allow users to have full and safe benefit of bash-selected fd's, which I am sure is what is intended. I have done my best to be clear in a reasonable manner, but you are the man, it is your project, we stand or fall by your decisions, not mine. Sam O

Re: leaks fd for internal functions but not external command

and 2 or between 2 and 4. Sam On Tue, 23 Jul 2019, 21:57 Chet Ramey, wrote: > On 7/23/19 12:12 PM, Sam Liddicott wrote: > > > Given what you have explained as intentional, it the difference between 1 > > and 2, but it is best understood as a 4-way difference, outlined here: &g

Re: leaks fd for internal functions but not external command

On Tue, 23 Jul 2019 at 16:45, Chet Ramey wrote: > On 7/23/19 11:40 AM, Sam Liddicott wrote: > > > > On Tue, 23 Jul 2019 at 16:35, Chet Ramey > <mailto:chet.ra...@case.edu>> wrote: > > > > On 7/23/19 11:20 AM, Sam Liddicott wrote: > >

Re: leaks fd for internal functions but not external command

On Tue, 23 Jul 2019 at 16:35, Chet Ramey wrote: > On 7/23/19 11:20 AM, Sam Liddicott wrote: > > > > On Tue, 23 Jul 2019 at 16:15, Sam Liddicott > <mailto:s...@liddicott.com>> wrote: > > > > > > > > On Tue, 23 Jul 2019 at 16:13, Ch

Re: leaks fd for internal functions but not external command

On Tue, 23 Jul 2019 at 16:15, Sam Liddicott wrote: > > > On Tue, 23 Jul 2019 at 16:13, Chet Ramey wrote: > >> On 7/23/19 11:11 AM, Sam Liddicott wrote: >> >> > The report concerns the different behaviour with internal and external >> > operations. &g

Re: leaks fd for internal functions but not external command

On Tue, 23 Jul 2019 at 16:13, Chet Ramey wrote: > On 7/23/19 11:11 AM, Sam Liddicott wrote: > > > The report concerns the different behaviour with internal and external > > operations. > > Right. The close-on-exec is deliberate. That's how it was intended. > Doe

Re: leaks fd for internal functions but not external command

On Tue, 23 Jul 2019 at 16:05, Chet Ramey wrote: > On 7/23/19 10:33 AM, Sam Liddicott wrote: > > > Bash Version: 4.4 > > Patch Level: 20 > > Release Status: release > > > > Description: > > Bash redirection sequence cases a file descriptor to be lea

leaks fd for internal functions but not external command

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE

time builtin does not work with set -e when a command fails

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKA

Bash wrongly attaches subcommand stdin on syntax error

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE

Re: fd leak with {fd}>

On Tue, Nov 27, 2012 at 7:08 AM, Pierre Gaston wrote: > > > On Mon, Nov 26, 2012 at 10:48 PM, Chet Ramey wrote: > >> On 11/26/12 12:11 PM, Sam Liddicott wrote: >> > 3. there already exists simple and explicit way to get the supposed >> benefit >> > usi

Re: fd leak with {fd}>

On Mon, Nov 26, 2012 at 5:02 PM, Chet Ramey wrote: > On 11/26/12 9:26 AM, Sam Liddicott wrote: > > > It seems that ksh93 behaves just like bash in this regard > > Well, as I don't use it I don't really care, but I vote for this as a > > bug as

Re: fd leak with {fd}>

eat.html) to the simple "bash do it for me" and things broke because they didn't work like anything similar in bash. I would expect: exec {fd}>( ... } to keep the descriptor open. if the user wants that he can do: { exec {fd}>... ; ... ; } if he wants it to be closed when the scope ends he will do: { ... ; } {fd}>... So I think this surprising behaviour adds nothing that wasn't there already, and nothing that the user expects and also adds things that the user will not expect Sam

Re: fd leak with {fd}>

On Thu, Nov 22, 2012 at 7:15 PM, Chet Ramey wrote: > On 11/16/12 10:47 AM, Sam Liddicott wrote: > > Repeated executions of: { echo $fd ; } {fd}> /dev/null > > will emit different numbers, indicating that fd is not closed when the > > block completes. > > This is int

fd leak with {fd}>

Repeated executions of: { echo $fd ; } {fd}> /dev/null will emit different numbers, indicating that fd is not closed when the block completes. As an interesting aside it seems not to be possible to close the FD within the block either: { echo $fd ; eval exec "$fd>&-" ; } {fd}> /dev/null

pwd as first command changes script behavior

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAG

RE: pwd as first command changes script behavior

Hi Jonathan, Thanks for taking the time. I get it now. I am sorry to have bothered you -Sam -Original Message- From: Jonathan Nieder [mailto:jrnie...@gmail.com] Sent: Thursday, September 01, 2011 2:27 PM To: Quiring, Sam Cc: bug-bash@gnu.org; b...@packages.debian.org Subject: Re: pwd

Re: variables set on command line

gs='${CFLAGS}' \ soname='$dll' lib='$lib' output_objdir='$dyndir' \ eval XCC_CREATESHARED=\"${archive_cmds}\" CC=$CC_save however, this does not distinguish between unset CC and CC=''. (is there a way to distinguish these two si

variables set on command line

)-release (i686-pc-cygwin) is this the expected behavior? thanks. -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031 http://palestinefacts.org http://openvotingconsortium.org http://memri.org http://www.PetitionOnline.com/tap12009/ http://dhimmi.com He who laughs last thinks slowest.

Re: conditional aliases are broken

> * Eric Blake [2011-08-15 16:59:29 -0600]: > > On 08/15/2011 04:40 PM, Sam Steingold wrote: >>> * Andreas Schwab [2011-08-15 22:04:04 +0200]: >>> >>> Sam Steingold writes: >>> >>>> Cool. Now, what does this imply? >>> >

Re: conditional aliases are broken

> * Andreas Schwab [2011-08-15 22:04:04 +0200]: > > Sam Steingold writes: > >> Cool. Now, what does this imply? > >"For almost every purpose, shell functions are preferred over aliases." so, how do I write alias a=b as a function? (remember that argumen

Re: conditional aliases are broken

> * Andreas Schwab [2011-08-15 18:42:30 +0200]: > > Sam Steingold writes: > >> this works: >> >> $ alias z='echo a' >> $ zz(){ z b; } >> $ zz >> a b >> >> however, after sourcing this file: >> if true; then >>

conditional aliases are broken

z, and z is defined as an alias, but zz does not know what z is an alias. -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031 http://pmw.org.il http://dhimmi.com http://ffii.org http://palestinefacts.org http://iris.org.il http://mideasttruth.com http://memri.o

Re: test -nt not sane

> * Curtis Doty [2011-08-10 11:53:52 -0700]: > > They have identical mtimes (as set by touch)--i.e. the directory is > *not* newer than the symlink--but it still outputs "yes". Why? mtime for a symlink comes from stat(), not stat(). anything is newer than a non-exi

delete matching entries from history

how do I delete matching entries from bash history? every other line in the file is "#time" so I cannot use the simple grep. -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031 http://dhimmi.com http://camera.org http://memri.org http://thereligiono

Re: A Feature Request for History

> * Sam Steingold [2011-08-03 11:12:42 -0400]: > > here is my current top: > > 29475 sds 25 0 240m 171m 1344 R 100.1 1.4 15:58.20 bash > 10482 sds 25 0 231m 162m 1336 R 100.1 1.4 16:24.99 bash > 24588 sds 25 0 230m 161m 1340 R 99.7 1.3 13:2

Re: A Feature Request for History

0x0041b4ef in parse_command () #14 0x0041b5c6 in read_command () #15 0x0041b74e in reader_loop () #16 0x0041b2aa in main () (gdb) (same tree for all of them!) also, is there some internal bash locking which would prevent different bash processes from writing history at the s

Re: BASH_SUBSHELL documentation misleading

On 23/03/11 20:32, Maarten Billemont wrote: On 23 Mar 2011, at 21:28, Chet Ramey wrote: OK. What wording would you like to see? I don't mind the wording he proposed: On 23 Mar 2011, at 17:12, Sam Liddicott wrote: maybe it should say BASH_SUB

Re: BASH_SUBSHELL documentation misleading

On 23/03/11 18:52, Chris F.A. Johnson wrote: On Wed, 23 Mar 2011, Sam Liddicott wrote: Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCO

BASH_SUBSHELL documentation misleading

Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DP$ uname

how to keep newlines in ``

this: foo=`ls` echo $foo will print files in one line even though ls prints them with newlines. is there a way to preserve newlines in the above echo? thanks.

how to get out of the vi editing mode

I hit something by accident and command line editing no longer works. (I think I switched to the vi mode). 1. how do I get back to the emacs mode? (aka what did I hit?!) 2. how do I disable vi mode forever and ever (short of recompiling bash myself)? thanks. -- Sam Steingold (http

readline/history cvs?

Where is the readline/history cvs (or git or whatever) repository? to keep the clisp readline module up to date with the current readline/history releases, I would like to be able to get a diff between readline.h & history.h from readline 5.0 and readline 5.2. how do I get those diffs (without

Re: time command

Chuck Swiger wrote: On Jun 24, 2008, at 7:47 AM, Sam Steingold wrote: I would like all long-running commands to be auto-timed. i.e., all commands I type at the prompt should be run as if with "time" built-in, but if the real or user time is smaller than some value (specified by the

Re: time command

Francis Litterio wrote: Eric Blake wrote: According to Yu Cha Yung on 6/23/2008 12:24 AM: |time ls > time.txt |It doesnt show the information of time in time.txt. That's because in bash, time is a reserved word, and because time's output goes to stderr, not stdout. [...] \time ls >

rfe: auto-timing

able), the timing output should be omitted. keeping the timing of every command costs essentially nothing, so this may even simplify the code. an extension of the idea is to keep this timing information in the history so that one could look up timings for previous commands. thanks Sam.

Bash is broken

The following does not work on my computers: If [ "1" > "2" ] then echo "greater" else echo "not greater" fi Bash thinks this is I/O redirection and creates a file by the name of "2" in my director

Directing to a file...

Running program many times I noticed that ps -p $$ -o pid,args > waiting.$$; lockfile -1 setting if ! cat waiting.$$ | egrep -q '[0-9]' then ps -p $$ -o pid,args > check.$$ echo "What's going on!!!" exit 1; fi sometimes it prints "What is going on". File waiting.1234

Re: sigsegv in rl_resize_terminal

> * Chet Ramey <[EMAIL PROTECTED]> [2005-10-16 22:38:38 -0400]: > > Sam Steingold wrote: >>>* Chet Ramey <[EMAIL PROTECTED]> [2005-10-16 17:53:39 -0400]: >>> >>>Sam Steingold wrote: > >> >> is there a way to check whether readl

Re: sigsegv in rl_resize_terminal

> * Chet Ramey <[EMAIL PROTECTED]> [2005-10-16 17:53:39 -0400]: > > Sam Steingold wrote: >> I get this: >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x2821e472 in rl_resize_terminal () from /usr/lib/libreadline.so.4 >> >> (Fre

sigsegv in rl_resize_terminal

rules for invoking rl_resize_terminal? do I need to call rl_initialize() or readline() before rl_resize_terminal? -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.palestinefacts.org/> <http://www.savegushkatif.org> <http://www.openvotingconsortium.org/> <

readline & signals

#x27;(unwind-protect (sleep 100) (print "cleanup"))' & $ kill %1 Exiting on signal 15 "cleanup" Bye. $ we do not call rl_set_signals() (we need to handle most signals ourselves). we do call rl_resize_terminal() from our own sigwinch handler. so, what are we doing wro