Re: [PATCH] compgen -V option (store output in array)
On 4/13/23 4:30 AM, Grisha Levit wrote: Since the predominant use case for compgen is generating output that then gets split back up into an array, it seems like it would be nice to have an option that avoids the extra steps (and their associated pitfalls) Thanks, this looks reasonable. -- ``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/
Re: [PATCH] compgen -V option (store output in array)
On 4/13/23 4:57 AM, Koichi Murase wrote:
2023年4月13日(木) 17:31 Grisha Levit :
Since the predominant use case for compgen is generating output that then
gets split back up into an array, it seems like it would be nice to have an
option that avoids the extra steps (and their associated pitfalls)
I have related but unsubmitted patches that I made before. I attach
them. This adds a new flag option `-z` that makes the output of
`compgen' separated by NUL This is useful when we want to process the
candidates of compgen (that may contain newlines as a part of a
candidate) using external commands such as `sort -z'.
Once you have -V, isn't -z superfluous? It's just
compgen -V varname options word
printf '%s\0' "${varname[@]}"
right? What am I missing?
--
``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/
'mapfile -O1 array' breaks '[[ -v array ]]'
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
Re: 'mapfile -O1 array' breaks '[[ -v array ]]'
On Mon, Apr 17, 2023 at 10:23:17AM -0700, Wiley Young wrote: > 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. It's not specifically the -O1 option. It's the fact that there's no element 0. unicorn:~$ unset a unicorn:~$ a[1]=foo unicorn:~$ [[ -v a ]]; echo "$?" 1 I believe [[ -v a ]] is equivalent to [[ -v a[0] ]]. I have never yet seen a justifiable reason to use [[ -v ]]. All I've ever seen come out of it are bugs and confusion.
Re: 'mapfile -O1 array' breaks '[[ -v array ]]'
On 4/17/23 1:23 PM, Wiley Young wrote:
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.
This is because when you use an array variable name without a subscript,
it's treated as equivalent to using a subscript of 0.
If you want to check whether array a has any set elements, you can use
[[ -v a[@] ]] or [[ ${#a[@]} > 0 ]].
--
``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/
Re: [PATCH] compgen -V option (store output in array)
2023年4月18日(火) 0:59 Chet Ramey :
> Once you have -V, isn't -z superfluous? It's just
>
> compgen -V varname options word
> printf '%s\0' "${varname[@]}"
>
> right? What am I missing?
You are right. Actually, when I implemented -z, I also initially
thought about the possibility to add an option to store results in a
specified array. Then, after looking at the codebase of
bash-completion and thinking about the actual use cases, I decided to
switch to the flag -z, but I actually don't remember the exact reason
I finally switched to -z. (Maybe it was because when I submit a patch
to bash-completion, it is easier to explain the code using mapfile,
which is already used in bash-completion, than using printf '%s\0',
which the maintainer might not be comfortable with).
I thought about it again and I now feel -V is better if one needs to
choose one from -V and -z.
--
Koichi
