[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Feature Request: scanf-like parsing

From: Greg Wooledge
Subject: Re: Feature Request: scanf-like parsing
Date: Mon, 25 Jan 2021 12:53:15 -0500
User-agent: Mutt/1.10.1 (2018-07-13)

On Mon, Jan 25, 2021 at 12:13:25PM -0500, Chet Ramey wrote:
> This is good advice. If the double-quoting the @K transformation performs
> is not what you need, use the @Q transformation to get something closer.

Those don't do the same thing, though.

unicorn:~$ declare -A aa=([a key]="a value" [$'\n\nx\n']=foo)
unicorn:~$ printf %s\\n "${aa[@]@K}"
"a key" "a value" $'\n\nx\n' "foo" 
unicorn:~$ printf %s\\n "${aa[@]@Q}"
'a value'

One gives both keys and values in a single string, while the other gives
only values (but as multiple strings).

I must say that the way @K works is surprising.  I would have expected
it to expand to a list of multiple strings (the way "$@" does, and without
the internal quoting).  I guess it's designed to support the new
name=( key1 value1 key2 value2 ...)  syntax, which I haven't used yet,
so I don't know where all the sharp edges are.

... thinking ...

It looks like @K serializes an indexed or associative array's contents
into a string.  That's a useful operation for sure.  It allows you to
do things like export an array through the environment and reconstruct
it in a child process, albeit not seamlessly.

Previously, I've seen people try to write hacks to do this by taking
the output of "declare -p myarray" and stripping off the part up to
and including the array's name.  @K is a much cleaner way, as it gives
just the contents, not the variable's name or flags.

It's still surprising, though, which means it'll probably show up on
my FAQ at some point, whenever people start trying to use it.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]