Antw: [EXT] Re: declare XXX=$(false);echo $?

>>> Martin D Kealey schrieb am 03.12.2022 um 02:26 in Nachricht : ... > Found in the real code (intended to trigger a bug): >> declare ERRORS=0 ARGS=$(getopt -o "$S_OPTS" -l "$L_OPTS" -n "$0" -- >> "$@") >> > if [ $? -ne 0 ]; then >> usage >> fi >> > > That is a well-known a

Antw: [EXT] Re: declare XXX=$(false);echo $?

chricht <878rjpahfz@hobgoblin.ariadne.com>: > Chet Ramey writes: >> On 12/2/22 5:28 AM, Ulrich Windl wrote: >>> Surprisingly "declare XXX=$(false);echo $?" outputs "0" (not "1") >>> There is no indication in the manual page that &qu

declare XXX=$(false);echo $?

Surprisingly "declare XXX=$(false);echo $?" outputs "0" (not "1") There is no indication in the manual page that "declare" ignores the exit code of commands being executed to set values. Actually I's consider it to be a ASH bug, not a documentation bug. Found in the real code (intended to trigger

Antw: Re: [EXT] Re: manual page missing ${parameter-replacement}

>>> Lawrence Velázquez schrieb am 22.11.2022 um 05:06 in Nachricht : [...] >> Despite of that only ":-" is typeset in bold; shouldn't "${" and "}" be >> typeset in bold, too? > > I don't know. It seems like boldface is used to highlight the parts > that are unique to each form. AFAIK, bold mea

Antw: [EXT] Re: manual page missing ${parameter-replacement}

schrieb am 21.11.2022 um 08:49 in Nachricht <99ac660c-3f76-4461-92b6-605c27c02...@app.fastmail.com>: > On Mon, Nov 21, 2022, at 2:20 AM, Ulrich Windl wrote: >> I think the bash manual page lacks some important detail of parameter >> substitution, namely: >> "Bash tests f

manual page missing ${parameter-replacement}

I think the bash manual page lacks some important detail of parameter substitution, namely: "Bash tests for a parameter that is unset or null. Omitting the colon results in a test only for a parameter that is unset." (found in https://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-E

"unset x[0], a BASH bug?"

Hi! Considering the example given in https://unix.stackexchange.com/a/648243/320598 I think it may be a bug, or an inappropriately documented feature. Basically: % x=(1 2 3) % echo "${#x[@]}"; echo "${x[@]}" 3 1 2 3 % unset x[0] % echo "${#x[@]}"; echo "${x[@]}" 2 2 3 % unset x[0] % echo "${#x[@

Antw: Re: "set -u" and empty arrays

>>> Chet Ramey schrieb am 13.05.2019 um 21:44 in Nachricht : > On 5/9/19 7:07 AM, Ulrich Windl wrote: >> Bash Version: 4.3 >> Patch Level: 48 >> Release Status: release >> >> Hi! >> >> Is this intended with "set -u": >>

"set -u" and empty arrays

Bash Version: 4.3 Patch Level: 48 Release Status: release Hi! Is this intended with "set -u": # set -u # declare -a INSTANCES # echo ${INSTANCES[*]} bash: INSTANCES[*]: unbound variable # INSTANCES=() # echo ${INSTANCES[*]} bash: INSTANCES[*]: unbound variable # echo ${INSTANCES[@]} bash: INSTANC

Antw: Re: `${PARAMETER:OFFSET}' does not work for negative offset

I realized that ":-2" is ambiguous: Default value or substring? A SPC does disambiguate (now I know). I still wonder why the manual page does not change "${parameter:offset}" and "${parameter:offset:length}" to "${parameter: offset}" and "${parameter: offset:length}", respectively. Or change the

`${PARAMETER:OFFSET}' does not work for negative offset

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