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

On Sat, Apr 18, 2020 at 05:37:52AM +0700, Robert Elz wrote: > The end result is as Greg said, "Don't do that", if precisions are > needed with %q do something like > > printf 'echo %q%q\n' "$(printf %.2s "a'b")" ';ls' Or something like printf '%q\n' "${myvar:0:2}" since I would assume the

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

Date:Fri, 17 Apr 2020 16:12:20 -0400 From:Chet Ramey Message-ID: <4bacf2f0-9802-67d3-f30b-80e37d058...@case.edu> | I would say this is a programmer error. The way precisions work with | string arguments is that the argument is fetched or generated (this | inclu

Re: looking for consistent C-c trap behavior

Apr 17, 2020, 22:14 by gentoo_esh...@tutanota.com: > > > > Apr 17, 2020, 22:02 by dual...@gmail.com: > >> On Fri, Apr 17, 2020 at 12:59 PM gentoo_eshoes--- via Bug reports for >> the GNU Bourne Again SHell wrote: >> >>> >>> I've noticed that if I trap SIGINT in a bash script, the behavior when

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.4 > > Patch Level: 20 > > R

Re: Expansions for array assignment not documented

On 4/17/20 5:48 AM, E. Choroba wrote: > Bash Version: 4.4 > Patch Level: 23 > Release Status: release > > Description: >     Expansions in an assignment are documented under "SIMPLE COMMAND > EXPANSION": > >     > The text after the = in each variable assignment undergoes tilde >     > expansion

Re: looking for consistent C-c trap behavior

Apr 17, 2020, 22:14 by gentoo_esh...@tutanota.com: > > > > Apr 17, 2020, 22:02 by dual...@gmail.com: > >> On Fri, Apr 17, 2020 at 12:59 PM gentoo_eshoes--- via Bug reports for >> the GNU Bourne Again SHell wrote: >> >>> >>> I've noticed that if I trap SIGINT in a bash script, the behavior whe

Re: looking for consistent C-c trap behavior

On Fri, Apr 17, 2020 at 1:09 PM Greg Wooledge wrote: > > On Fri, Apr 17, 2020 at 01:02:20PM -0700, Eduardo Bustamante wrote: > > On Fri, Apr 17, 2020 at 12:59 PM gentoo_eshoes--- via Bug reports for > > the GNU Bourne Again SHell wrote: > > > > > > I've noticed that if I trap SIGINT in a bash scr

Re: looking for consistent C-c trap behavior

Apr 17, 2020, 22:02 by dual...@gmail.com: > On Fri, Apr 17, 2020 at 12:59 PM gentoo_eshoes--- via Bug reports for > the GNU Bourne Again SHell wrote: > >> >> I've noticed that if I trap SIGINT in a bash script, the behavior when >> encountering C-c depends on whether an external command (eg.

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

On 4/17/20 10:22 AM, Sam Liddicott wrote: > Bash Version: 4.4 > Patch Level: 20 > Release Status: release > > Also occurs on 5.0.7(1)-release > > Description: > printf %q with a truncating size will emit partially escaped > sequence thus losing the safety and composability that %q > is intended

Re: How can redirection operator aka ">" open output in append instead of ordinary write mode?

the only issue I've encountered with this so far is that 'dd' will fail some of its tests because it's not using of=  but instead using the redir operator and then it assumes it's NOT open in append mode ;)) so then it tries to seek past EOF (which doesn't work in append mode) to make holes(of z

Re: looking for consistent C-c trap behavior

On Fri, Apr 17, 2020 at 01:02:20PM -0700, Eduardo Bustamante wrote: > On Fri, Apr 17, 2020 at 12:59 PM gentoo_eshoes--- via Bug reports for > the GNU Bourne Again SHell wrote: > > > > I've noticed that if I trap SIGINT in a bash script, the behavior when > > encountering C-c depends on whether an

Re: looking for consistent C-c trap behavior

On Fri, Apr 17, 2020 at 12:59 PM gentoo_eshoes--- via Bug reports for the GNU Bourne Again SHell wrote: > > I've noticed that if I trap SIGINT in a bash script, the behavior when > encountering C-c depends on whether an external command (eg. 'sleep 100') or > a builtin command (like 'read -p') w

looking for consistent C-c trap behavior

I've noticed that if I trap SIGINT in a bash script, the behavior when encountering C-c depends on whether an external command (eg. 'sleep 100') or a builtin command (like 'read -p') was encountered. I attach an example script which requires me to press C-c twice to interrupt the builtin 'read

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

On Fri, Apr 17, 2020 at 03:22:16PM +0100, Sam Liddicott wrote: > printf %q with a truncating size will emit partially escaped > sequence thus losing the safety and composability that %q > is intended to provide. So... don't do that.

%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

Expansions for array assignment not documented

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc -I/home/abuild/rpmbuild/BUILD/bash-4.4 -L/home/abuild/rpmbuild/BUILD/bash-4.4/../readline-7.0 Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -

Trap in command substitution breaks parent

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='bash' -DSHELL -DHAVE_CONFIG_H   -I.  -I../. -I.././include -I.