'mapfile -O1 array' breaks '[[ -v array ]]'

[Wiley Young]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-g>
uname output: Linux localhost-live 6.0.7-301.fc37.x86_64 #1 SMP
PREEMPT_DYNAMIC>
Machine Type: x86_64-redhat-linux-gnu

Bash Version: 5.1
Patch Level: 16
Release Status: release

Description:
When an array 'a_foo' is created with 'mapfile -d '' -t', it is
tested with '[[ -v a_foo ]]' and '[[' returns 0. When '-O 1' is added to
mapfile, '[[ -v a_foo ]]' returns non-0.

Repeat-By: In test 3, when declare shows array "y" exists and has indices
beginning at 1, "[[ -v" shows array "y" doesn't exist.

I=1
for AB in '' "-O1"; do
  for CD in '' a_quux; do
:;:;:
printf '\nloop %d\n' $(( I++ ))
unset a_quux a_foo
a_quux=( x y z )
mapfile -d '' $AB -t a_foo < <( printf '%s\0' "${a_quux[@]}" )
[[ $CD == a_quux ]] && a_foo+=( [0]=workaround )
declare -p a_foo
[[ -v a_foo ]]
printf 'exit: "[[ -v": %d\n' $?
  done
done

Thanks,
Wiley

With DEBUG trap, resizing window crashes script

[Wiley Young]

From: liveuser
To: bug-bash@gnu.org
Subject: With DEBUG trap, resizing window crashes script


Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
uname output: Linux localhost-live 6.2.9-300.fc38.x86_64 #1 SMP
PREEMPT_DYNAMIC Thu Mar 30 22:32:58 UTC 2023 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu

Bash Version: 5.2
Patch Level: 15
Release Status: release

Description:
  While using the DEBUG trap and prompt is waiting for user input, resizing
the terminal window causes the script to crash.

Repeat-By:
  The script is set up to enable the DEBUG trap and prompt. When the first
user prompt appears, in this case `set -x` although xtrace was enabled at
the crashbang, if I resize the window then press enter, the script dies and
displays that a SIGWINCH was received.

...
++./find-and-scan-shell-scripts-sh:280:_mk_deltas: : '_mk_deltas ENDS  ' 2
'  '
++./find-and-scan-shell-scripts-sh:288:_debug_prompt: read -rp
'[./find-and-scan-shell-scripts-sh:288] set -x?' _
[./find-and-scan-shell-scripts-sh:288] set -x?

# ...resize window and press enter...

+++./find-and-scan-shell-scripts-sh:1:_debug_prompt: set -x
+++./find-and-scan-shell-scripts-sh:1:_debug_prompt: echo SIGWINCH
SIGWINCH
+++./find-and-scan-shell-scripts-sh:1:_debug_prompt: trap SIGWINCH
+++./find-and-scan-shell-scripts-sh:1:_debug_prompt: kill -s 2 96527
./find-and-scan-shell-scripts-sh:2:_debug_prompt: trap - DEBUG
...

Error message: cannot find _struct in shared object

[Wiley Young]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
uname output: Linux localhost-live 6.2.9-300.fc38.x86_64 #1 SMP
PREEMPT_DYNAMIC Thu Mar 30 22:32:58 UTC 2023 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu

Bash Version: 5.2
Patch Level: 15
Release Status: release

Description:

A syntax error on a variable assignment lead to $x being unset when `enable
-n "$x" was executed, which produced this error message:
  ./test.sh: line 22: enable: cannot find _struct in shared object :
/usr/bin/bash: undefined symbol: _struct


Repeat-By:

x="${1:='export'}"
./test.sh: line 19: $1: cannot assign in this way
readonly x
+ readonly x
declare -p x
+ declare -p x
declare -r x
enable -n "$x"
+ enable -n ''
./test.sh: line 22: enable: cannot find _struct in shared object :
/usr/bin/bash: undefined symbol: _struct
./test.sh: line 22: enable: : not a shell builtin

[liveuser@localhost-live]$ set -x; declare -p x;
+ set -x
+ declare -p x
bash: declare: x: not found
[liveuser@localhost-live]$ x="${1:='export'}"
bash: $1: cannot assign in this way
[liveuser@localhost-live]$ readonly x
+ readonly x
[liveuser@localhost-live]$ declare -p x
+ declare -p x
declare -r x
[liveuser@localhost-live]$ enable -n "$x"
+ enable -n ''
bash: enable: cannot find _struct in shared object : bash: undefined
symbol: _struct
bash: enable: : not a shell builtin

Cheers,
Wiley

Segfault, 29 May '23

[Wiley Young]

Hi,
  While trying to capture line numbers in an array to print with the rest
of the shell's debugging info, a segfault ..
  Wiley

[liveuser@localhost-live]$ bash
...
$ set -x
+ set -x
$ echo $SHLVL
+ echo 2
2
$ declare -n n=BASH_SOURCE; declare -n e=LINENO; shopt -s expand_aliases
+ declare -n n=BASH_SOURCE
+ declare -n e=LINENO
+ shopt -s expand_aliases
$ alias L_='"l[8-${#n[@]}]+=$e"; m=("${l[@]}")'
+ alias 'L_="l[8-${#n[@]}]+=$e"; m=("${l[@]}")'
$ L_
+ 'l[8-0]+=10'
bash: l[8-0]+=10: command not found
+ m=("${l[@]}")
Segmentation fault (core dumped)
[liveuser@localhost-live]$ echo $SHLVL
1

double free SIGSEGV and SELinux AVC denial

[Wiley Young]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
uname output: Linux localhost-live 6.2.9-300.fc38.x86_64 #1 SMP
PREEMPT_DYNAMIC Thu Mar 30 22:32:58 UTC 2023 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu

Bash Version: 5.2
Patch Level: 15
Release Status: release


Description:
  While trying to capture line numbers in an array, there was a
reproducible double free with an accompanying AVC denial. Uncommenting line
25 somehow eliminates the double free.


[liveuser@localhost-live]$ cat ./test-script.sh
#!/usr/bin/env -iS bash -x
ec='exit-code,'
: 'First duplicate definition of function:test'
function test(){
  shopt -s expand_aliases
: "$ec shopt: $?"
  alias M_='m=("${l[@]}")'
: "$ec alias: $?"
  wait -f
: "$ec wait: $?"
  type -a M_
: "$ec type: $?"
  M_
: "$ec alias:M_: $?"
  }
  : "$ec definition of function:test $?"
: 'Viewing definitions of string "test"'
declare -p test
  : "$ec declare: $?"
type -a test
  : "$ec type: $?"
: 'Executing function:test'
test
  : "$ec function:test $?"
#M_# line 25
  #: "$ec alias:M_: $?"
: 'Second duplicate definition of function:test'
function test(){
  shopt -s expand_aliases
: "$ec shopt: $?"
  alias M_='m=("${l[@]}")'
: "$ec alias: $?"
  wait -f
: "$ec wait: $?"
  type -a M_
: "$ec type: $?"
  M_
: "$ec alias:M_: $?"
  }
  : "$ec duplicate re-definition of function:test $?"

[liveuser@localhost-live]$


[liveuser@localhost-live]$ ./test-script.sh
+ ec=exit-code,
+ : 'First duplicate definition of function:test'
+ : 'exit-code, definition of function:test 0'
+ : 'Viewing definitions of string "test"'
+ declare -p test
./test-script.sh: line 18: declare: test: not found
+ : 'exit-code, declare: 1'
+ type -a test
test is a function
test ()
{
shopt -s expand_aliases;
: "$ec shopt: $?";
alias M_='m=("${l[@]}")';
: "$ec alias: $?";
wait -f;
: "$ec wait: $?";
type -a M_;
: "$ec type: $?";
M_;
: "$ec alias:M_: $?"
}
test is a shell builtin
test is /usr/bin/test
+ : 'exit-code, type: 0'
+ : 'Executing function:test'
+ test
+ shopt -s expand_aliases
+ : 'exit-code, shopt: 0'
+ alias 'M_=m=("${l[@]}")'
+ : 'exit-code, alias: 0'
+ wait -f
+ : 'exit-code, wait: 0'
+ type -a M_
M_ is aliased to `m=("${l[@]}")'
+ : 'exit-code, type: 0'
+ M_
./test-script.sh: line 13: M_: command not found
+ : 'exit-code, alias:M_: 127'
+ : 'exit-code, function:test 0'
+ : 'Second duplicate definition of function:test'
free(): double free detected in tcache 2
Aborted (core dumped)
[liveuser@localhost-live]$

double free SIGSEGV and SELinux AVC denial

[Wiley Young]

Attachments:
SELinux is preventing false from read access on the fifo_file fifo_file.

*  Plugin catchall (100. confidence) suggests   **

If you believe that false should be allowed read access on the fifo_file fifo_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'false' --raw | audit2allow -M my-false
# semodule -X 300 -i my-false.pp

Additional Information:
Source Contextsystem_u:system_r:kernel_generic_helper_t:s0
Target Contextsystem_u:system_r:kernel_t:s0
Target Objectsfifo_file [ fifo_file ]
Sourcefalse
Source Path   false
Port  
Host  localhost-live
Source RPM Packages   
Target RPM Packages   
SELinux Policy RPMselinux-policy-targeted-38.8-2.fc38.noarch
Local Policy RPM  selinux-policy-targeted-38.8-2.fc38.noarch
Selinux Enabled   True
Policy Type   targeted
Enforcing ModeEnforcing
Host Name localhost-live
Platform  Linux localhost-live 6.2.9-300.fc38.x86_64 #1 SMP
  PREEMPT_DYNAMIC Thu Mar 30 22:32:58 UTC 2023
  x86_64
Alert Count   57
First Seen2023-06-03 10:54:17 PDT
Last Seen 2023-06-03 16:27:59 PDT
Local ID  92ff0f54-5203-4d65-abd4-b95016ca1bd5

Raw Audit Messages
type=AVC msg=audit(1685834879.63:14893): avc:  denied  { read } for  pid=3635649 comm="false" path="pipe:[49647210]" dev="pipefs" ino=49647210 scontext=system_u:system_r:kernel_generic_helper_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=fifo_file permissive=0


Hash: false,kernel_generic_helper_t,kernel_t,fifo_file,read

[liveuser@localhost-live ddf]$ reset; strace ./test-script.sh
execve("./test-script.sh", ["./test-script.sh"], 0x7ffcacd166e0 /* 55 vars */) = 0
brk(NULL)   = 0x55e7b268f000
arch_prctl(0x3001 /* ARCH_??? */, 0x7ffc3ff20130) = -1 EINVAL (Invalid argument)
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=67519, ...}, AT_EMPTY_PATH) = 0
mmap(NULL, 67519, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f5db94bb000
close(3)= 0
openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 }\2\0\0\0\0\0"..., 832) = 832
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
newfstatat(3, "", {st_mode=S_IFREG|0755, st_size=2234072, ...}, AT_EMPTY_PATH) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5db94b9000
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
mmap(NULL, 1957168, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f5db92db000
mmap(0x7f5db9301000, 1429504, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x26000) = 0x7f5db9301000
mmap(0x7f5db945e000, 315392, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x183000) = 0x7f5db945e000
mmap(0x7f5db94ab000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1d) = 0x7f5db94ab000
mmap(0x7f5db94b1000, 32048, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f5db94b1000
close(3)= 0
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5db92d8000
arch_prctl(ARCH_SET_FS, 0x7f5db92d8740) = 0
set_tid_address(0x7f5db92d8a10) = 3634879
set_robust_list(0x7f5db92d8a20, 24) = 0
rseq(0x7f5db92d9060, 0x20, 0, 0x53053053) = 0
mprotect(0x7f5db94ab000, 16384, PROT_READ) = 0
mprotect(0x55e7b1656000, 4096, PROT_READ) = 0
mprotect(0x7f5db94fd000, 8192, PROT_READ) = 0
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
munmap(0x7f5db94bb000, 67519)   = 0
getrandom("\xcb\xa4\x15\x1e\x26\xb7\x98\xad", 8, GRND_NONBLOCK) = 8
brk(NULL)   = 0x55e7b268f000
brk(0x55e7b26b) = 0x55e7b26b
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=224366320, ...}, AT_EMPTY_PATH) = 0
mmap(NULL, 224366320, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f5dabc0
close(3)= 0
execve("/usr/bin/bash", ["bash", "-x", "./test-script.sh"], 0x55e7b16573a8 /* 0 vars */) = 0
brk(NULL)   = 0x55e48376d000
arch_prctl(0x3001 /* ARCH_??? */, 0x7fff1b17c750) = -1 EINVAL (Invalid argument)
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc

`verb=(--) declare -ax verb` causes an ENOTSOCK segfault

[Wiley Young]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
uname output: Linux localhost-live 6.2.9-300.fc38.x86_64 #1 SMP
PREEMPT_DYNAMIC Thu Mar 30 22:32:58 UTC 2023 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu

Bash Version: 5.2
Patch Level: 15
Release Status: release

Description:
   `verb=(--) declare -ax verb` causes bash to crash and closes the active
terminal tab. strace output includes this error: "getpeername(0,
0x7ffc74d185d0, [16])= -1 ENOTSOCK (Socket operation on non-socket)"

Repeat-By:
  Occurs every time. xfce4-terminal 1.0.4 on Fedora 38

Thank you, you wizards,
  Wiley

xmalloc error involving functrace, int trap and ps4

[Wiley Young]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
uname output: Linux localhost-live 6.2.9-300.fc38.x86_64 #1 SMP
PREEMPT_DYNAMIC Thu Mar 30 22:32:58 UTC 2023 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu

Bash Version: 5.2
Patch Level: 15
Release Status: release

Hello,
  A strange error. I don't know what it means exactly, but I'm fairly
positive I don't have 18 exabytes on this computer...?
  Thank you,
Wiley

Repeat-By:
  ...running ./findscan-debug which sources ./gardning-debug. Press enter
once at the DEBUG prompt, and at the next prompt press Ctrl-C. Commenting
out `set -T` or the INT trap will hide the bug again.



+ set -T
+ source /home/liveuser/xmal/gardning-debug_7.bash
++ PS4='\e[0;104m+ At:[$( printf "%2d" ${#BASH_SOURCE[@]} )]$( cut -c -8
<<< ${BASH_SOURCE[0]##*/} )($( printf "%4d" ${LINENO} )) \e[m > \e[0;93m'
+ At:[ 2]gardning(  16)  > trap _trp_int INT
+ At:[ 2]gardning(  22)  > trap _dbg_pmt DEBUG
+ At:[ 2]gardning(  24)  > _dbg_pmt
+ At:[ 3]gardning(  20)  > read -rp '+ [read]()...  : 317222  ...?'
+ [read]()...  : 317222  ...?
+ [read]()...  printf "%2d" ${#BASH_SOURCE[@]}
 ...?^C/home/liveuser/xmal/gardning-debug_7.bash: interrupt trap: line 2:
unexpected EOF while looking for matching `)'
/home/liveuser/xmal/gardning-debug_7.bash: xmalloc: cannot allocate
18446744073709551611 bytes
[liveuser@localhost-live xmal]$ vim
./xmalloc_xtrace-logs/xmalloc_cannot_allocate_29



#!/bin/bash
# findscan-debug
set -x
set -T
source /home/liveuser/xmal/gardning-debug_7.bash



# gardning-debug
# shellcheck shell=bash

#declare -n nBL=BASH_LINENO nBS=BASH_SOURCE nF=FUNCNAME nL=LINENO
#PS4='\e[0;104m+ At:[$( printf "%2d" ${#nBS[@]} )]$( : 21594 )$( cut -c -8
<<< ${nBS[0]##*/} )($( printf "%4d" ${nL} )) In:<$( printf "%-8s"
${nF[0]:-""})> Fr:[$( printf "%2d" $(( ${#nBS[@]} - 1 )) )]$( cut -c -8 <<<
${nBS[1]##*/} )($( printf "%4d" ${nBL[0]} )) \e[m > \e[0;93m'

PS4='\e[0;104m+ At:[$( printf "%2d" ${#BASH_SOURCE[@]} )]$( cut -c -8 <<<
${BASH_SOURCE[0]##*/} )($( printf "%4d" ${LINENO} )) \e[m > \e[0;93m'

function _trp_int {
  trap - DEBUG INT
  kill -s INT "$$"
}
trap _trp_int INT

function _dbg_pmt {
  #read -rp "+ [read]${BASH_SOURCE[1]##*/}(${LINENO[0]})...
 ${BASH_COMMAND}  ...?"
  read -rp "+ [read]${nBS[1]##*/}(${nBL[0]})...  ${BASH_COMMAND}  ...?"
}
trap _dbg_pmt DEBUG

: 317222

Stdout from arg group of Debug trap redefines PS4

[Wiley Young]

Hi,

[liveuser@localhost-live scf]$ reset; ./findscan rm_stale foo bar -ab /tmp
|& cat -n

Beginning at line 217 of `cat`s numbering of this xtrace output log, the
read prompt from the Debug trap prints some info for a few lines, and then
one line before #218, the PS4 prompt is displayed again, if the
highlighting patterns are to be believed.

PS4 prior read as...

   214 + At:[ 4]gardning( 361) In:<_dbg_pmt> Fr:[ 3]gardning( 382)  > set -x

At line (( 218 - 1 )) PS4 reads as...

+ At:[DEBUG trap 30013
   218  ( -3 ):./findscan:0:main  ( -2 ):./findscan:128:source  ( -1
):./gardning.bash:444:_xtrace_  ( -0 ):./gardning.bash:382:_fun_trc  ( +1
):./gardning.bash:46:_fun_trc:62
   219  _dbg_pmt
   220  ( -4 ):./findscan:0:main  ( -3 ):./findscan:128:source  ( -2
):./gardning.bash:444:_xtrace_  ( -1 ):./gardning.bash:382:_dbg_pmt  ( -0
):./gardning.bash:351:_fun_trc  ( +1 ):./gardning.bash:46:_fun_trc:62
   221  6a7

The string 'DEBUG trap 30013' is the stdout of a command on line 382 of
gardning.bash:

  167 + At:[ 3]gardning( 382) In:<_xtrace_> Fr:[ 2]gardning( 444)  > echo
DEBUG trap 30013
   168 DEBUG trap 30013

Line "218" of the second PS4 value is a function trace printed above at
line 172:

   169 + At:[ 3]gardning( 382) In:<_xtrace_> Fr:[ 2]gardning( 444)  >
_fun_trc
...
   173 ( -3 ):./findscan:0:main  ( -2 ):./findscan:128:source  ( -1
):./gardning.bash:444:_xtrace_  ( -0 ):./gardning.bash:382:_fun_trc  ( +1
):./gardning.bash:46:_fun_trc:62

The strings from lines "219" and "220" are shown in the xtrace log at lines
179 and 184, respectively.

After line 221, xtrace seems to become somehow disabled, and a series of
environment diffs are printed through the rest of the file.

I am shocked, shocked to find that there is drinking going on in this
establishment!

Cheers,
Wiley

scripts and xtrace files attached

:-/  Thank you!!!
 1  set -aCuTE
 2  ++ [[ n == y ]]
 3  ++ printf %b '\e[m'
 4  ++ : './gardning.bash:12 ./findscan:128'
 5  ++ FUNCNEST=32
 6  ++ close_ps4='\n\e[0;104m+[${#nBS[@]}]${nBS[0]##*/}( ${nL} ) [$(( 
${#nBS[@]} - 1 ))]${nBS[1]##*/}( ${nBL[0]} )${nF[0]} [$(( ${#nBS[@]} - 2 
))]${nBS[2]##*/}( ${nBL[1]} )${nF[1]} [$(( ${#nBS[@]} - 3 ))]${nBS[3]##*/}( 
${nBL[2]} )${nF[2]} [$(( ${#nBS[@]} - 4 ))]${nBS[4]##*/}( ${nBL[3]} )${nF[3]} 
\e[m\n|=\t=|> \e[0;93m '
 7  ++ far_ps4='\e[0;104m+ At:[$( printf "%2d" ${#nBS[@]} )]$( : 21594 )$( 
cut -c -8 <<< ${nBS[0]##*/} )($( printf "%4d" ${nL} )) In:<$( printf "%-8s" 
${nF[0]:-""})> Fr:[$( printf "%2d" $(( ${#nBS[@]} - 1 )) )]$( cut -c -8 <<< 
${nBS[1]##*/} )($( printf "%4d" ${nBL[0]} )) $( set -x )\e[m > \e[0;93m'
 8  + At:[ 2]gardning(  32) In:<> Fr:[ 1]findscan( 128)  > 
PS4='\e[0;104m+ At:[$( printf "%2d" ${#nBS[@]} )]$( : 21594 )$( cut -c -8 <<< 
${nBS[0]##*/} )($( printf "%4d" ${nL} )) In:<$( printf "%-8s" ${nF[0]:-""})> 
Fr:[$( printf "%2d" $(( ${#nBS[@]} - 1 )) )]$( cut -c -8 <<< ${nBS[1]##*/} )($( 
printf "%4d" ${nBL[0]} )) $( set -x )\e[m > \e[0;93m'
 9  + At:[ 2]gardning(  32) In:<> Fr:[ 1]findscan( 128)  > export 
PS4
10  + At:[ 2]gardning(  35) In:<> Fr:[ 1]findscan( 128)  > export 
FUNCNEST close_ps4 far_ps4
11  + At:[ 2]gardning(  38) In:<> Fr:[ 1]findscan( 128)  > : '<>: 
Debug functions & traps'
12  + At:[ 2]gardning(  67) In:<> Fr:[ 1]findscan( 128)  > declare 
-fx _fun_trc
13  + At:[ 2]gardning(  68) In:<> Fr:[ 1]findscan( 128)  > declare 
-t _fun_trc
14  + At:[ 2]gardning(  77) In:<> Fr:[ 1]findscan( 128)  > declare 
-fx exit
15  + At:[ 2]gardning(  78) In:<> Fr:[ 1]findscan( 128)  > declare 
-t exit
16  + At:[ 2]gardning( 127) In:<> Fr:[ 1]findscan( 128)  > declare 
-fx _trp_int
17  + At:[ 2]gardning( 128) In:<> Fr:[ 1]findscan( 128)  > declare 
-t _trp_int
18  + At:[ 2]gardning( 132) In:<> Fr:[ 1]findscan( 128)  > trap ': 
"${nBS[0]}:${nL} ${nBS[1]}:${nBL[0]}"; _trp_int; : "${nBS[0]}:${nL} 
${nBS[1]}:${nBL[0]}"' INT
19  + At:[ 2]gardning( 135) In:<> Fr:[ 1]findscan( 128)  > : 'Some 
standard data- & file-maintenance functions'
20  + At:[ 2]gardning( 211) In:<> Fr:[ 1]findscan( 128)  > : '<> 
Debug: "Full xTrace" variables and functions'
21  + At:[ 2]gardning( 246) In:<> Fr:[ 1]findscan( 128)  > declare 
-fx _xt_hush
22  + At:[ 2]gardning( 247) In:<> Fr:[ 1]findscan( 128)  > declare 
-t _xt_hush
23  + At:[ 2]gardning( 269) In:<> Fr:[ 1]findscan( 128)  > declare 
-fx _mkv_pre
24  + At:[ 2]gardning( 270) In:<> Fr:[ 1]findscan( 128)  > declare 
-t _mkv_pre
25  + At:[ 2]gardning( 285) In:<> Fr:[ 1]findscan( 128)  > declare 
-fx _mkv_now
26  + At:[ 2]gardning( 286) In:<> Fr:[ 1]findscan( 128)  > declare 
-t _mkv_now
27  + At:[ 2]gardning( 329) In:<> Fr:[ 1]findscan( 128)  > declare 
-fx _mkv_dlt
28  + At:[ 2]gardning( 330) In:<> Fr:[ 1]findscan( 128)  > dec

Re: Help fixing NativeMessaging host: read 32-bit message

[Wiley Young]

> It is politics. All human activity is political in nature.

Writing for portability is about building a widget that will appeal to a
larger group of customers.

Thanks for your thoughts.

Wiley

'${#@}' expands to an integer

[Wiley Young]

Here's some code as observed "in the wild:"

  `[[ ${#@} -ne 0 ]] && ...`

Perhaps the parser is reading this as an incomplete parameter
transformation? It seems from context that the original intent was simply...

  `[[ $# -ne 0 ]] && ...`

As it happens, the effect appears to be the same either way, but unless I'm
missing something, as syntax ${#@} appears to be undefined. Possibly not a
bug, therefore?

$ set -- a b c d
$ echo "$#"
4
$ echo "$@"
a b c d
$ echo "$#@"
4@
$ echo ${#@}
4

,0 , ,0@ ,0 ,'0'
$ echo ,$# ,$@ ,$#@ ,${#@} ,${#@Q} ,"${#@}"
+ echo ,0 , ,0@ ,0 ','\''0'\''' ,0
,0 , ,0@ ,0 ,'0' ,0
$ set --
+ set --
$ echo $#
+ echo 0
0
$ [[ ${#@} -ne 0 ]]; echo $?
+ [[ 0 -ne 0 ]]
+ echo 1
1
$ [[ ${#} -ne 0 ]]; echo $?
+ [[ 0 -ne 0 ]]
+ echo 1
1

Wiley

git amend commit with backticks on cli causes tty to crash

[Wiley Young]

Hi,
  I'm seeing this behavior on Fedora 38. Possibly it's just some user error
again, since i'm figuring out how to use vim and git at a slightly above
novice level. :-)

#+++
$ uname -a
Linux localhost-live 6.3.7-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Jun
 9 15:21:11 UTC 2023 x86_64 GNU/Linux
$ vim --version | head -n 3
VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Jun 05 2023 00:00:00)
Included patches: 1-1607
Modified by 
$ cat ~/.vimrc | grep -v ^'"'
set number
filetype plugin indent on
set tabstop=2
set shiftwidth=2
set expandtab
autocmd BufWritePost * execute '! if [[ -d ./.git ]] ; then git commit -S
-a --file=- --verbose ; fi'
$ git --version
git version 2.41.0
$ bash --version
GNU bash, version 5.2.15(1)-release (x86_64-redhat-linux-gnu)
$ xfce4-terminal --version
xfce4-terminal 1.0.4 (Xfce 4.18)
#+++

The first time I saw this bug, tty3 crashed and isn't available any more in
/dev/pts . Partially reproducing the bug, ttys have crashed but they become
available for use again when I press Ctrl-Shift-t from xfce4-terminal.

#+++
[liveuser@localhost-live ~]$ tty
/dev/pts/4
[liveuser@localhost-live ~]$ ls /dev/pts
0  1  2  4  ptmx
#+++

The original pre-amend commit message was 'LiveUsb1: At error handling, add
if block to `source ./functions.bash`'. From within vim (and tty6), I'd
place an additional '#' at line 30 and press ':w'.

#+++
 30 # <> debug string ##
 31
 32 unset -f er_x rm_oa
 33 function er_x(){ : ; local exit_code="$?" ; echo -e Error: "$@" >&2 ;
exit "${exit_code}"; }
 34 ## rm_oa: '--' is placed at fn call
 35 function rm_oa(){ :
"./LiveUsb1" 653L, 20976B written
:!if [[ -d ./.git ]] ; then git commit -S -a --file=- --verbose ; fi
(reading log message from standard input)
#+++

After pasting in the faulty commit message, pressing [enter] and [Ctrl-d],
git shows a standard message:

#+++
LiveUsb1: At error handling, add if block to `source ./functions.bash`
[main e02d0aa] LiveUsb1: At error handling, add if block to `source
./functions.bash`
 1 file changed, 1 insertion(+), 1 deletion(-)

Press ENTER or type command to continue
#+++

I'd press [enter], vim would return to normal viewing mode and pressing
':q!' would close vim. Then I'd try (on tty5) to amend the commit message
by starting a string with a single quote and adding newlines within, based
on my understanding that git reads the first line of a commit messages a
something akin to a an email subject line, and then after an empty line,
the rest of the message is parsed by git as the "details" or "body" section
of the commit message.

#+++
[liveuser@localhost-live ~]$ git -S --amend -m 'LiveUsb1: Add `source
./functions.bash`
>
> LiveUsb1: At error handling, in if-fi block at line 23
>
#+++

But of course, I forgot the second single quote! Press [Ctrl-d].

#+++
bash: unexpected EOF while looking for matching `''
#+++

Add one single quote, press [Ctrl-d}; no response. Press [enter] and
[ctrl-d]:

#+++
bash: unexpected EOF while looking for matching `''
#+++

Press [ctrl-d] again and tab (tty 5) crashes.

#+++
[liveuser@localhost-live ~]$ ls /dev/pts
0  1  2  4  6  ptmx
[liveuser@localhost-live ~]$ tty
/dev/pts/4
# in xfce4-terminal: [ctrl]-[shift]-t
[liveuser@localhost-live ~]$ ls /dev/pts
0  1  2  4  5  6  ptmx
#+++

Wiley
"The bashful never learn, and the short tempered cannot teach." -- Talmud

A few suggestions for the GNU Manual

[Wiley Young]

Hi,
 Regarding the "Invoking Bash" page,
https://www.gnu.org/software/bash/manual/html_node/Invoking-Bash.html

It might be more consistent and therefore perhaps more clear for all of the
newbies out there if the description of "--restricted" also began with
"Equivalent to -r," as the very next description does.
"--restricted

Make the shell a restricted shell (see The Restricted Shell
).

--verbose

Equivalent to -v. Print shell input lines as they’re read."

Also, a few lines later, there's the phrase, "There are several
single-character options that may be supplied at invocation which are not
available with the set builtin."

Within that list there's the item,
"-r

Make the shell a restricted shell (see The Restricted Shell

)."
However, restricted mode is listed on the "Set Builtin" page:
https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html

"-r

Enable restricted shell mode. This option cannot be unset once it has been
set."
Cheers,
Wiley

Assignment to RO variable

[Wiley Young]

So this behavior of `bash`s seems like a bug to me. I stumbled across it by
accident.

>From within a stack of x3 functions called from a case within a for loop,
when trying to assign a value to a read-only variable, `printf` and `read`
both fail with exit codes of 1, and the functions, `case` and `for`
commands all complete.  When trying effectively the same thing with a
simple assignment syntax, `x=z`, when the assignment fails, the functions
return, `case` fails to complete and `for` returns an exit code of 1.

It's probably a pretty rare use case, though. I tried this out on Android
12 on a Nokia in Termux and Fedora 38 on an HP in XFCE; that's all I've got
for the time being. There isn't any pressing need to look into this one;
I'm just curious. A reproducer's attached.

Thanks & Happy summer,
Wiley

###
$ cat ro-var-in-fn.sh
#!/bin/bash -x

reset
readonly x=y
declare -p x SHELLOPTS BASHOPTS
: "hyphen: $-"

a(){ : go a; b $1; : end a;}
b(){ : go b; c $1; : end b;}
c(){
  : go c
  declare -p x

  case "$1" in
1 )
  false
  : "exit, false: $?"
  ;;
2 )
  printf -v x '%s' $1
  : "exit, printf: $?"
  ;;
3 )
  read -r x <<< $1
  : "exit, read: $?"
  ;;
4 )
  x=$1
  : "exit, var assignment: $?"
  ;;
5 )
  echo $1
  ;;
  esac
  : "exit, case: $?"
  : end c
}

declare -pf a b c

for ii in {1..5}
do
  a $ii
  : "exit, a $ii: $?"
done
: "exit, for loop: $?"

###

Re: [bug #66460] A documentation correction regarding an array nameref???

[Wiley Young]

"The nameref attribute cannot be applied to array variables."

  Some thoughts on English language

  Perhaps "attribute" could be more explicitly defined? ...as something
like, 'a characteristic [ given to | assigned to | applied to | associated
with | defining a ] parameter (or a parameter's utility?)'

  Active voicing could describe the relationship between parameters and
attributes a little more accurately. Something like, 'parameters can
receive attribute designations' 'Attributes can [ limit | define ] the
[ functionality | use ] of a parameter'

  Or possibly it's just something to do with how the various attributes as
a group interact? 'Some attributes are mutually exclusive: a parameter
marked as an array cannot also [ be marked as a | receive the ] namref
(attribute), etc...'

2 cents,
Wiley


On Mon, Nov 18, 2024, 23:10  wrote:

> Send bug-bash mailing list submissions to
> bug-bash@gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.gnu.org/mailman/listinfo/bug-bash
> or, via email, send a message with subject or body 'help' to
> bug-bash-requ...@gnu.org
>
> You can reach the person managing the list at
> bug-bash-ow...@gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bug-bash digest..."
>
>
> Today's Topics:
>
>1. Re: redirection / process substitution fails to read a file
>   descriptor (Chet Ramey)
>2. Re: history-search-* and undo lists (Grisha Levit)
>3. Re: [PATCH] lib/readline/doc makefiles clean targets
>   (Grisha Levit)
>4. [bug #66460] A documentation correction regarding an array
>   nameref??? (Harry Clauson)
>5. Re: [bug #66460] A documentation correction regarding an
>   array nameref??? (Andreas Kähäri)
>
>
> --
>
> Message: 1
> Date: Mon, 18 Nov 2024 16:04:51 -0500
> From: Chet Ramey 
> To: bug-bash@gnu.org
> Cc: chet.ra...@case.edu
> Subject: Re: redirection / process substitution fails to read a file
> descriptor
> Message-ID: 
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> On 11/17/24 6:25 PM, Robert Elz wrote:
>
> > The use for testing for errors is also occasionally useful - a
> redirection
> > error will cause the shell to exit (non-interactive shell) so  > be a kind of shortcut for
> >   test -r file || { printf >&2 message; exit 2; }
> > (or similar) (and output directions test that the file either exists or
> > can be created, and is writeable).
>
> No, it usually doesn't. If a redirection error occurs with a special
> builtin, POSIX says a non-interactive shell should exit. However,
> just running
>
> < file
>
> where file doesn't exist or isn't readable, won't cause a non-interactive
> shell to exit.
>
> --
> ``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/
> -- next part --
> A non-text attachment was scrubbed...
> Name: OpenPGP_signature.asc
> Type: application/pgp-signature
> Size: 203 bytes
> Desc: OpenPGP digital signature
> URL: <
> https://lists.gnu.org/archive/html/bug-bash/attachments/20241118/0d31cfb6/attachment.sig
> >
>
> --
>
> Message: 2
> Date: Mon, 18 Nov 2024 22:22:10 -0500
> From: Grisha Levit 
> To: chet.ra...@case.edu
> Cc: bug-bash 
> Subject: Re: history-search-* and undo lists
> Message-ID:
>  kqjrnqjb03c-wb-0dbrnnu...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Tue, Nov 5, 2024 at 11:20 AM Chet Ramey  wrote:
> >
> > On 10/18/24 4:22 PM, Grisha Levit wrote:
> > > There's some issue with undo list handling in history-search-*
> commands:
> > >
> > > Doing a successful search with a line that has an undo list causes the
> > > undo entries from that list to leaked:
> >
> > Thanks for the report. Please try this with the latest devel branch push.
>
> Yup, can confirm much fewer fuzzing hits now.
>
> But here's a remaining one in combination with history-expand-line:
>
> HISTFILE= INPUTRC=/ bash --norc -in <<< \
> $'X\n\e[A!X\e^\e[A'
> =
> ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 32 byte(s) in 1 object(s) allocated from:
> #2 alloc_undo_entry lib/readline/undo.c:75:23
> #3 rl_add_undo  lib/readline/undo.c:92:10
> #4 maybe_make_readline_line bashline.c:2804:7
> #5 set_up_new_line  bashline.c:2832:3
> #6 history_expand_line  bashline.c:2896:7
> #7 _rl_dispatch_subseq  lib/readline/readline.c:941:8
>
>
> HISTFILE= INPUTRC=/ bash --norc -in <<< \
> $'X\n\cPX\e[A!X\et\e^\exhistory-search-forward\n\e1\cO'
> =
> ERROR: AddressSanitizer: heap-

Re: bug-bash Digest, Vol 264, Issue 31

[Wiley Young]

That email I read. :-(

On Sat, Nov 16, 2024, 20:58  wrote:

> Send bug-bash mailing list submissions to
> bug-bash@gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.gnu.org/mailman/listinfo/bug-bash
> or, via email, send a message with subject or body 'help' to
> bug-bash-requ...@gnu.org
>
> You can reach the person managing the list at
> bug-bash-ow...@gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bug-bash digest..."
>
>
> Today's Topics:
>
>1. redirection / process substitution fails to read a file
>   descriptor (Mike Peters)
>2. Re: redirection / process substitution fails to read a file
>   descriptor (Greg Wooledge)
>3. Re: bug-bash Digest, Vol 264, Issue 28 (Wiley Young)
>4. Re: bug-bash Digest, Vol 264, Issue 28 (G. Branden Robinson)
>5. Re: bug-bash Digest, Vol 264, Issue 28 (Oğuz)
>6. Re: redirection / process substitution fails to read a file
>   descriptor (Lawrence Velázquez)
>
>
> --
>
> Message: 1
> Date: Sat, 16 Nov 2024 16:35:05 -0600
> From: Mike Peters 
> To: bug-bash@gnu.org
> Subject: redirection / process substitution fails to read a file
> descriptor
> Message-ID: 
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
>
> Configuration Information [Automatically generated, do not change]:
> Machine: aarch64
> OS: darwin23.4.0
> Compiler: clang
> Compilation CFLAGS: -DSSH_SOURCE_BASHRC
> -DDEFAULT_LOADABLE_BUILTINS_PATH='/opt/homebrew/Cellar/bash/5.2.37/lib/bash:/usr/loc$
> uname output: Darwin Mikes-Mac-Mini.local 23.3.0 Darwin Kernel Version
> 23.3.0: Wed Dec 20 21:30:27 PST 2023; root:xnu-10002.$
> Machine Type: aarch64-apple-darwin23.4.0
>
> Bash Version: 5.2
> Patch Level: 37
> Release Status: release
>
> Description:
>  Process substitution does not generate properly when pulling from
> another file descriptor, although it works when pulling from a file
> directly. In the below sample shell session, it is expected that
> `<(
> Repeat-By:
>  > echo foobar > test.txt
>  > echo `< <(  foobar
>  > exec 3  > cat <&3
>  foobar
>  > exec 3  > echo `< <(<&3)`
>
>  >
>
>
>
> Mike Peters
>
>
>
>
>
> --
>
> Message: 2
> Date: Sat, 16 Nov 2024 21:35:43 -0500
> From: Greg Wooledge 
> To: Mike Peters 
> Cc: bug-bash@gnu.org
> Subject: Re: redirection / process substitution fails to read a file
> descriptor
> Message-ID: 
> Content-Type: text/plain; charset=us-ascii
>
> On Sat, Nov 16, 2024 at 16:35:05 -0600, Mike Peters wrote:
> > Description:
> > Process substitution does not generate properly when pulling
> from another file descriptor, although it works when pulling from a file
> directly. In the below sample shell session, it is expected that
> `<(
>
> > Repeat-By:
> > > echo foobar > test.txt
> > > echo `< <( > foobar
>
> This is one of the most convoluted things I've seen in a long time.
> You've got a command substitution with < as its command, which is
> equivalent to $(cat ...) as a bash extension.  The argument of  is a process substitution with a *second* instance of < being used
> as a command.
>
> So, going from the innermost layer outward, you have a process
> substitution which reads a file's contents and dumps it to the
> procsub's FD (the way cat would), and this FD is being treated as
> a filename by a command substitution's  the data to the commsub's internal pipe.  The commsub read the
> content from the procsub FD and is replaced by that content, which
> happens to be the string "foobar".  This is passed as an argument
> to echo.
>
> > > exec 3 > > cat <&3
> > foobar
>
> OK.  This part is straightforward.  Note that you used a command, cat,
> to write output.  You didn't simply type <&3 without a command.
>
> > > exec 3 > > echo `< <(<&3)`
> >
> > >
>
> Here, you've got a process substitution with <&3 inside it.  I can
> only guess what this is going to do.  It doesn't follow the standard
> form of < filename which would be treated like cat filename, even though
> it begins with a < character.
>
> I'm guess

Re: bug-bash Digest, Vol 264, Issue 28

[Wiley Young]

| From: Martin D Kealey

|   "In the general case I agree; man

| pages should be reference

| manuals, not tutorials"

  We should value others' contributions.
  Most people, when they read something that they don't yet understand, if
they wish to understand it, will seek out a more accessible text.
  You lost me at "envisaged." Sorry, it didn't have anything to do medieval
plate armor helmets.
  Wiley

Re: String substitution bug

[Wiley Young]

Writing's more difficult than reading, and writing can be expensive.

Synoptic reading, traditionally, is considered the "highest form" of
reading (according to "How to Read a Book") (Hate mail to them, please, not
me.). Writing from some definable point of view is inevitable.

It might be worthwhile to assemble a list of books on shell, already on the
market, that people at differing experience levels might find more
accessible than the strict technical language of the man page.

Textbook reviews, maybe, or something like that.

Wiley

Re: SHELLOPTS environment variable causes shell options to cascade

[Wiley Young]

On Jan 05 2025, Tobi Laskowski wrote:

> "It may be safe, however, it is a bit tedious...

Wow. I remember once I corrected an obvious flaw in a major project's CICD
bash scripts involving quoting and the trap builtin. You'd have thought I'd
have tried to chop somebody's fingers off.

Wiley

Patch on shellmath.sh from bash-doc v.5.2.32, r.1.fc41

[Wiley Young]

Hi,
  Please say something if this patch should be sent someplace else.
  Shellmath's "runTests.sh" script returned x8 failing tests. This patch
addresses all eight errors as well as shellcheck's various complaints. The
full test suite now passes. These specific changes have been addressed:

* doc/bash/examples/shellmath/shellmath.sh
  + Remove trailing spaces and tabs.
  + Workaround of problematic use of "10#$fractionalSum" syntax by
replacing it with an admittedly awkward
"${fractionalSum//[^-]}10#${fractionalSum//[^0-9]}" expansion syntax. For
example, `echo $(( 10#-3 ))` fails while `echo $(( -10#3 ))` succeeds.
  + Changed a parameter expansion on line ~546 to remove just a hyphen
rather than any initial character.
  + The new expansion syntax obviated the need for a code block at line
~485; comment amended.
  + Per shellcheck:
+ "SC2295 (info): Expansions inside ${..} need to be quoted separately,
otherwise they match as patterns.", at lines 668, 670 and 1066
+ "SC2086 (info): Double quote to prevent globbing and word
splitting.", at lines 562, 1046 and 1051.
  + for SC2086, lines 165, 166 are false positives (re use of `eval`).
+ "SC2059 (info): Don't use variables in the printf format string. Use
printf '..%s..' "$foo"," at line 91.
+ "SC2004 (style): $/${} is unnecessary on arithmetic variables," at
line 826.

The original set of testing errors:
'''
$ bash ./runTests.sh
...
ok  Line 55: String 3.8add 1.9 1.9
shellmath.sh: line 518: ((: 10#: invalid integer constant (error token is
"10#")
shellmath.sh: line 530: ((: integerSum < 0 && 10#: invalid integer constant
(error token is "10#")
shellmath.sh: line 533: ((: integerSum > 0 && 10#: invalid integer constant
(error token is "10#")
shellmath.sh: line 539: ((: integerSum == 0 && 10#: invalid integer
constant (error token is "10#")
shellmath.sh: line 546: ((: 10#: invalid integer constant (error token is
"10#")
shellmath.sh: line 550: ((: 10#: invalid integer constant (error token is
"10#")
FAIL (-2)  Line 56: String -3.8add -1.9 -1.9
ok  Line 59: String 2.195add 1.105 1.09
shellmath.sh: line 518: ((: 10#: invalid integer constant (error token is
"10#")
shellmath.sh: line 530: ((: integerSum < 0 && 10#: invalid integer constant
(error token is "10#")
shellmath.sh: line 533: ((: integerSum > 0 && 10#: invalid integer constant
(error token is "10#")
shellmath.sh: line 539: ((: integerSum == 0 && 10#: invalid integer
constant (error token is "10#")
shellmath.sh: line 546: ((: 10#: invalid integer constant (error token is
"10#")
shellmath.sh: line 550: ((: 10#: invalid integer constant (error token is
"10#")
FAIL (-2)  Line 60: String -2.195add -1.105 -1.09
ok  Line 63: String 2.014add 1.005 1.009
shellmath.sh: line 518: ((: 10#: invalid integer constant (error token is
"10#")
shellmath.sh: line 530: ((: integerSum < 0 && 10#: invalid integer constant
(error token is "10#")
shellmath.sh: line 533: ((: integerSum > 0 && 10#: invalid integer constant
(error token is "10#")
shellmath.sh: line 539: ((: integerSum == 0 && 10#: invalid integer
constant (error token is "10#")
shellmath.sh: line 546: ((: 10#: invalid integer constant (error token is
"10#")
shellmath.sh: line 550: ((: 10#: invalid integer constant (error token is
"10#")
FAIL (-2)  Line 64: String -2.014add -1.005 -1.009
ok  Line 66: String 3.31462add 1.905 1.40962
ok  Line 67: String 2.01462add 1.005 1.00962
shellmath.sh: line 518: ((: 10#: invalid integer constant (error token is
"10#")
shellmath.sh: line 530: ((: integerSum < 0 && 10#: invalid integer constant
(error token is "10#")
shellmath.sh: line 533: ((: integerSum > 0 && 10#: invalid integer constant
(error token is "10#")
shellmath.sh: line 539: ((: integerSum == 0 && 10#: invalid integer
constant (error token is "10#")
shellmath.sh: line 546: ((: 10#: invalid integer constant (error token is
"10#")
shellmath.sh: line 550: ((: 10#: invalid integer constant (error token is
"10#")
FAIL (3)  Line 70: String 2.5   subtract 5.2 2.7
shellmath.sh: line 539: ((: integerSum == 0 && 10#: invalid integer
constant (error token is "10#")
shellmath.sh: line 546: ((: 10#: invalid integer constant (error token is
"10#")
shellmath.sh: line 550: ((: 10#: invalid integer constant (error token is
"10#")
FAIL (-2)  Line 71: String -2.5   subtract 2.7 5.2
shellmath.sh: line 518: ((: 10#: invalid integer constant (error token is
"10#")
shellmath.sh: line 530: ((: integerSum < 0 && 10#: invalid integer constant
(error token is "10#")
shellmath.sh: line 533: ((: integerSum > 0 && 10#: invalid integer constant
(error token is "10#")
shellmath.sh: line 539: ((: integerSum == 0 && 10#: invalid integer
constant (error token is "10#")
shellmath.sh: line 546: ((: 10#: invalid integer constant (error token is
"10#")
shellmath.sh: line 550: ((: 10#: invalid integer constant (error token is
"10#")
FAIL (3)  Line 72: String 2.5   add 5.2 -2.7
ok  Line 75: String 1.5  add 0.6 0.9
ok  Line 76: String 1.5  add .6 .9
shel

An inconsistency of the outputs of help builtin

[Wiley Young]

Testing how bash's help builtin responds to each character.

For some reason, while `help -d 'c'` prints the same thing as `help -c
'c*'` (note the asterisk), the same is not true when the character is
left-bracket: `help -c '[*'.  This issue persists on bash 5.3 beta.

# Input:
[liveuser@fedora ~]$
fn ()
{
  help -d "$1" 2> /dev/null \
| sed -e '/^Shell commands matching keyword/d' -e '/^$/d' \
| wc;
};
for init in {a..z} '%' '(' '.' ':' '[' '{';
do
  str_a=${init};
  str_b="${init}*";
  out_a=$( fn "${str_a}" );
  out_b=$( fn "${str_b}" );
  if [[ ${out_a} != "${out_b}" ]];
  then
mismatches+=( "${init}" );
  fi;
done;
declare -p mismatches;
unset {str,out}_{a,b} mismatches

# Output:
declare -a mismatches=([0]="[")

# With and without asterisks at (awk-style) field 3
[liveuser@fedora ~]$ help -d '[' | sed -e '/^Shell commands matching
keyword/d' -e '/^$/d' | wc
  1   5  37
[liveuser@fedora ~]$ help -d '[*' | sed -e '/^Shell commands matching
keyword/d' -e '/^$/d' | wc
  2  12  78

# With and without \wc\ at the end of the pipeline.
[liveuser@fedora ~]$ help -d '[' | sed -e '/^Shell commands matching
keyword/d' -e '/^$/d'
[ - Evaluate conditional expression.
[liveuser@fedora ~]$ help -d '[*' | sed -e '/^Shell commands matching
keyword/d' -e '/^$/d'
[ - Evaluate conditional expression.
[[ ... ]] - Execute conditional command.

Thanks,
  Wiley

Re: bug-bash Digest, Vol 265, Issue 40

[Wiley Young]

On Fri, 20 Dec 2024 08:09:40 -0500, Greg Wooledge wrote:
> Assuming you meant -d not -c:
Good eye.

> Why did you expect them to be the same?

  A surprisingly hard question. Um, well, this report was from something I
noticed a few months ago.

  As I recall, `help -d '('` returns information about the string '((',
rather than anything about subshells, so it seemed like a trailing
glob-asterisk was assumed.

  Yeah, looking further, it makes sense that it would return on a positive
match. That's how most programs seem to be.

~ $ help -d ti
time - Report time consumed by pipeline's execution.
times - Display process times.
~ $ help -d time
time - Report time consumed by pipeline's execution.

  Wiley

Re: SHELLOPTS environment variable causes shell options to cascade

[Wiley Young]

On Wed, 8 Jan 2025 08:44:06 +1000,
Martin D Kealey wrote:

> I invite anyone to provide an example of how

If the documentation changes at all, I think just a "See also..." might be
enough.

Wuley

Re: Suggestion of wording for portion of man page

[Wiley Young]

On Sat, Jan 18, 2025 at 9:00 AM Greg Wooledge wrote:

> So, if a sentence is ambiguous, then your assertion that it "can't not
be read that way" must be false.

I'm sorry you didn't get it on the first read through, Greg. Just think of
how those professionals felt when they spun their wheels for hours over
some three odd words in the documentation, and then filed a bug report only
to get put down for their willingness to help out.

This is why propositional logic is done using symbols.

Wiley
- "All our yesterdays light the way." - Shakespeare

Re: Suggestion of wording for portion of man page

[Wiley Young]

"I would have preferred short papers that were a pleasure to read. However,
as Peter Medawar (1979) truthfully has said, “Most scientists do not know
how to write.” - Per Brinch Hansen, "Evolution of Operating Systems," 200,
pg.2
http://brinch-hansen.net/papers/2001b.pdf

"The basic goal was to promote portability ... by developing a clear,
consistent, and _unambiguous_ standard." -- POSIX-2024, Frontmatter
https://pubs.opengroup.org/onlinepubs/9799919799/

"Quote your strings."

Wiley

Re: Suggestion of wording for portion of man page

[Wiley Young]

Delving into the free Writing 101 lessons here

On Sat, Jan 18, 2025 at 4:16 AM  Lawrence Velázquez wrote:
> " I find Wiley's main thesis -- that this sentence reads as a sort
of topic sentence that implicitly prefixes "alphabetic" to every
subsequent use of "character" -- to be pretty contrived.

No, it isn't that the sentence could be read that way, it's that the
sentence can't not be read that way. It's ambiguous. Our individual
intuitions are fallible of whether people could read something some or
other way. The reality is that there are dictionaries and grammar rules
that everyone has to some extent - but not fully - used to learn English.
According to the definitions and grammar rules of English such an
interpretation is valid, which means that people will read it that
way, especially considering the scale.

"Character" is one of the 500 most common words in English, with 29 or 30
separate non-obsolete meanings.

Etymology: "classical Latin -- ambiguus -- undecided, doubtful, wavering,
of which the issue is in doubt, of double or mixed form, hybrid,
indeterminate, having more than one possible meaning, untrustworthy,
unreliable (< ambigere to dispute, quarrel, contend, to be undecided or
uncertain, doubt, to call in question, argue about." -- OED

In code, ambiguity is reduced by using syntax.  In English, ambiguity is
reduced by using naming. The names in current use within the man page lack
consistency.

People understand reality as stories (...and as metaphors). Each thing in
the man page is an element in the story of how Bash operates. The word
"character," for example, as a jargon term signifying "an abstraction,"
lacks a specific definition as such within the man page. If you expect for
people to know about that "abstraction" meaning, as something separate from
the 30 other real meanings, then they should be informed of that.

"Word," "set," "function" and "name" are some other good examples, in the
top 500. "Operator" and "command" are in the top 2,000.

O the Humanities.

Wiley

- "All our yesterdays light the way." -- Macbeth

Re: Suggestion of wording for portion of man page

[Wiley Young]

Unicode, of course. Good point.

Well, however an amendment might occur, "Each character in the expanded
value of parameter is tested against pattern" to my ear reads as referring
to alphabetic characters, as per sentence one, however they may appear in
binary. It does also make some sense that a PE for case modification just
might limit itself to only considering byte strings that resolve to
alphabetic characters, including Unicode ones.

But sentence six is an emphatic concern if you ask me, for how "character"
reads as "alphabetic character". Also how sentences five and six can be
read as contradictory.

So ${foo^x} is a PE dedicated to case modification that tests the first
character of the string that $foo expands into, whatever type of character
that might be. But why would it not alter the first alphabetic character if
the first character in the string is not alphabetic?  That the first
character in a string would be an alphabetic one is an assumption, one that
seems to be in use.  Neither assumption - that the first character would be
an alphabetic one, or that the algorithm would look for the first
alphabetic character - is clearly stated. That ambiguity could be resolved.

"First character in the expanded value," means something like "the group of
bytes that prints at place zero as counted from the beginning of the entire
byte string..." which is the result of the expansion of 'parameter.'

Wiley


On Thu, Jan 16, 2025 at 7:24 PM Lawrence Velázquez  wrote:

> On Thu, Jan 16, 2025, at 8:05 PM, Wiley Young wrote:
> > In Parameter Expansions / Case Modification:
> >
> > [S1]
> >   The first sentence reads, "alphabetic characters," which can imply that
> > wherever else in the paragraph the word "characters" is used, that the
> > intended meaning is "alphabetic characters," which is not the case. It
> can
> > be read as something like a declaration of a specific conversation topic.
> > This multiplicity of meaning in a single word, "characters," can be
> thought
> > of as similar to a namespace collision.
>
> It's never once occurred to me to read it this way.  I think you're
> overstating the potential confusion here.
>
>
> > [S3]
> >   The third sentence makes no distinction between alphabetic characters
> and
> > ASCII characters, although in practice such a distinction exists.
> >
> >   $ yy='./scripts_install-ups'
> >   $ echo ${yy^s}
> >   ./scripts_install-ups
> >   $ yy='scripts_install-ups'
> >   $ echo ${yy^s}
> >   Scripts_install-ups
> >
> >   The third sentence could read more clearly with the inclusion of one
> > word: "ASCII" (changes are underlined).
> >
> >   Before:
> > 3) Each character in the expanded value of parameter is tested
> against
> > pattern, and, if it matches the pattern, its case is converted.
> >   After:
> > 3) Each _ASCII_ character in the expanded value of parameter is
> tested
> > against pattern, and, if it matches the pattern, its case is converted.
> >
> >   Without the inclusion of the word "ASCII," sentence three (as well as
> > sentence six, below) can easily be read incorrectly as applying only to
> > "alphabetic characters" as a result of the implied topic declaration in
> > sentence one.
>
> This suggestion is far more misleading than the existing text.  It
> implies that non-ASCII characters are skipped, but they are not.
>
> $ LC_ALL=en_US.UTF-8
> $ str=$'err\u00F3neo'
> $ echo "$str" "${str^^}"
> erróneo ERRÓNEO
>
>
> > [S5]
> >   Sentence five speaks of "the ^ operator" and "the , operator" - however
> > this use of English language is again unclear. There are four meaningful
> > syntactical forms involved in this Parameter Expansion:
> >
> >   , ^ ,, ^^
> >
> >   They are composed of varying combinations of two raw constituent ASCII
> > characters:
> >
> >   , ^  (\x2c and \x5e)
> >
> >   There's an overlap, when the text reads, "the ^ operator" it can be
> read
> > as referring to either a specific and meaningful syntactical form, (^),
> or
> > a raw constituent ASCII character, (^). It appears that the latter
> meaning
> > is intended. Otherwise, the descriptions would contradict each other of
> the
> > single-character PE operators in both sentence five and the second half
> of
> > sentence six. Elsewhere in the manual the word "operator" is also used.
> > From a partial search, it app

Suggestion of wording for portion of man page

[Wiley Young]

In Parameter Expansions / Case Modification:

[S1]
  The first sentence reads, "alphabetic characters," which can imply that
wherever else in the paragraph the word "characters" is used, that the
intended meaning is "alphabetic characters," which is not the case. It can
be read as something like a declaration of a specific conversation topic.
This multiplicity of meaning in a single word, "characters," can be thought
of as similar to a namespace collision.

[S3]
  The third sentence makes no distinction between alphabetic characters and
ASCII characters, although in practice such a distinction exists.

  $ yy='./scripts_install-ups'
  $ echo ${yy^s}
  ./scripts_install-ups
  $ yy='scripts_install-ups'
  $ echo ${yy^s}
  Scripts_install-ups

  The third sentence could read more clearly with the inclusion of one
word: "ASCII" (changes are underlined).

  Before:
3) Each character in the expanded value of parameter is tested against
pattern, and, if it matches the pattern, its case is converted.
  After:
3) Each _ASCII_ character in the expanded value of parameter is tested
against pattern, and, if it matches the pattern, its case is converted.

  Without the inclusion of the word "ASCII," sentence three (as well as
sentence six, below) can easily be read incorrectly as applying only to
"alphabetic characters" as a result of the implied topic declaration in
sentence one.

[S5]
  Sentence five speaks of "the ^ operator" and "the , operator" - however
this use of English language is again unclear. There are four meaningful
syntactical forms involved in this Parameter Expansion:

  , ^ ,, ^^

  They are composed of varying combinations of two raw constituent ASCII
characters:

  , ^  (\x2c and \x5e)

  There's an overlap, when the text reads, "the ^ operator" it can be read
as referring to either a specific and meaningful syntactical form, (^), or
a raw constituent ASCII character, (^). It appears that the latter meaning
is intended. Otherwise, the descriptions would contradict each other of the
single-character PE operators in both sentence five and the second half of
sentence six. Elsewhere in the manual the word "operator" is also used.
>From a partial search, it appears that the word tends to be used much more
often to refer to specific meaningful syntactical forms rather than raw
ASCII characters.

  declare -a control_operators=(  [0]="||" [1]="&" [2]="&&" )
  declare -a parameter_transformation_operators=(  [0]="U"  [1]="u" [2]="L"
)

  Sentence five could read more clearly as (changes underlined):

  Before:
5) The ^ operator converts lowercase letters matching pattern to
uppercase; the , operator converts matching uppercase letters to lowercase.

  After:
5) The _operators_ _containing_ _ASCII_ _^_ _characters_ _convert_
lowercase letters matching pattern to uppercase, and _operators_
_containing_ _ASCII_ _,_ _characters_ convert matching uppercase letters to
lowercase.

[S6]
  Sentence six could benefit from a change similar to that of sentence
three.

  Before:
6) The ^^ and ,, expansions convert each matched character in the
expanded value; the ^ and , expansions match and convert only the first
character in the expanded value.
  After:
6) The ^^ and ,, expansions convert each matched character in the
expanded value; the ^ and , expansions match and convert only the first
_ASCII_ character in the expanded value.


  I hope this suggestion helps.

cHEERS,
  Wiley

Re: Suggestion of wording for portion of man page

[Wiley Young]

On Sat, 18 Jan 2025, Lawrence Velázquez wrote:

> Ironic that someone who's spilled so much text about the importance
of clear communication is now blaming a reader for misunderstanding
an unclear sentence.
>

Exactly. Thanks for catching that.

Wiley

Re: Difference in POSIX regular expression for bash's '=~' operator and POSIXLY_CORRECT grep -E

[Wiley Young]

>
> For accuracy, under POSIX, `grep` indeed is required to always print whole
lines, however GNU `grep` has...

  -o, --only-matching
  Print only the matched (non-empty) parts of a matching
  line, with each such part on a separate output line.


...and BSD `grep` has...

  -o, --only-matching
Prints only the matching part of the lines.

GNU and BSD `grep` are common on newer distros; the POSIX (not to use '-o')
specification is useful for portability and older installations.


~ $ echo foo | grep -o o
o
o
~ $ grep --version
grep (GNU grep) 3.12


Wiley


On Tue, 20 May 2025 16:20:46 -0400, Greg Wooledge wrote:


> > grep always prints whole lines.  It doesn't just print the matching part
> > of a line.