Re: Zero-length indexed arrays
On Thu, Dec 16, 2021, at 11:45 PM, Lawrence Velázquez wrote:
> Did you mean to say that ${#FOO[*]} causes an error? Because
> ${FOO[*]} does not, à la $*:
>
> [...]
>
> Like ${FOO[*]}, ${FOO[@]} and $@ are exempt from ''set -u''.
Perhaps you're using an old bash, like the one shipped with macOS?
% /bin/bash --version | head -n 1
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin18)
% /bin/bash -uc ': "${FOO[*]}"'
/bin/bash: FOO[*]: unbound variable
% /bin/bash -uc ': "${FOO[@]}"'
/bin/bash: FOO[@]: unbound variable
If so, there's not much anyone here can do about it.
--
vq
Re: Zero-length indexed arrays
On Thu, Dec 16, 2021, at 11:01 PM, Dale R. Worley wrote:
> A bit ago I was debugging a failing script at work. It turns out that
> when you say
> FOO=(x y z)
> then the variable FOO is an array and is defined. But when you say
> FOO=()
> then the variable FOO is an array (because ${#FOO[*]} substitutes an
> integer viz. 0) but it is *not* defined (because ${FOO[*]} generates an
> error when "set -u" is in effect).
Did you mean to say that ${#FOO[*]} causes an error? Because
${FOO[*]} does not, à la $*:
% bash --version | head -n 1
GNU bash, version 5.1.12(1)-release (x86_64-apple-darwin18.7.0)
% bash -uc ': "${FOO[*]}"'
% bash -uc ': "${#FOO[*]}"'
bash: line 1: FOO: unbound variable
> It turns out that this can matter, if you do something like this:
>
> set -u# for safety
> ...
> if ...
> then
> FOO=(...)
> else
> FOO=()
> fi
> ...
> FOO_PLUS=("${FOO[@]}" x y z w)
I have to assume you meant something else here as well. This example
never causes any errors.
% cat foo.bash; echo
set -u
if [[ -n "${1+set}" ]]; then
FOO=(a b c)
else
FOO=()
fi
FOO_PLUS=("${FOO[@]}" x y z w)
declare -p FOO_PLUS
% bash foo.bash
declare -a FOO_PLUS=([0]="x" [1]="y" [2]="z" [3]="w")
% bash foo.bash woot
declare -a FOO_PLUS=([0]="a" [1]="b" [2]="c" [3]="x" [4]="y" [5]="z"
[6]="w")
Like ${FOO[*]}, ${FOO[@]} and $@ are exempt from ''set -u''.
--
vq
Zero-length indexed arrays
A bit ago I was debugging a failing script at work. It turns out that
when you say
FOO=(x y z)
then the variable FOO is an array and is defined. But when you say
FOO=()
then the variable FOO is an array (because ${#FOO[*]} substitutes an
integer viz. 0) but it is *not* defined (because ${FOO[*]} generates an
error when "set -u" is in effect).
I really don't like this. But it is according to the manual (because
FOO has no index that has a value), and no doubt there are scripts out
there that depend subtly on this case.
It turns out that this can matter, if you do something like this:
set -u# for safety
...
if ...
then
FOO=(...)
else
FOO=()
fi
...
FOO_PLUS=("${FOO[@]}" x y z w)
Dale
Space vs. non-space separators in COMP_WORDBREAKS
If I have a function like
function _complete_something {
printf -v __ '%q ' "$@"
logger -p debug -t something "Args: $__"
logger -p debug -t something "$(declare -p COMP_WORDS)"
}
And in COMP_WORDBREAKS I have '=' included in the assignment.
And I execute this command:
complete -F _complete_something something
After I type something like this
something --option=/something[TAB]
I'll also get = in one of the arguments.
This seems to mean that separators specified in COMP_WORDBREAKS that
aren't spaces are also passed as an
argument and stored in COMP_WORDS. This surprised me a bit, and I
think it would be helpful if this behavior gets documented as well.
Tested with 5.1.12.
--
konsolebox
Re: Gnu Bash Manual - Getting the Array Size
On 12/16/21 1:33 PM, fatiparty--- via Bug reports for the GNU Bourne Again
SHell wrote:
>
> Have been reading the Gnu Bash Manual "6.7 Arrays" and there is no mention of
> ${#name[*]} to get the array size.
"${#NAME[SUBSCRIPT]}' expands to the length of
'${NAME[SUBSCRIPT]}'. If SUBSCRIPT is '@' or '*', the expansion is the
number of elements in the array."
--
``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/
Gnu Bash Manual - Getting the Array Size
Have been reading the Gnu Bash Manual "6.7 Arrays" and there is no mention of
${#name[*]} to get the array size.
