On 12/17/20 11:58 AM, Léa Gris wrote:
Le 17/12/2020 à 17:35, Chet Ramey écrivait :
One problem I see with it is that it assumes the introduction of word
splitting into mapfile, with the burden on the user to ensure that there
are exactly two resultant fields.
It is just meant to be a replacement to looping on:
IFS=<FieldSeparator> read -r -d <record delimiter> k v
So yes it has only two fields per record/line regardless, the first IFS
character will delimit the key from the value, and the value is allowed to
contain any of IFS except newline, unless the record delimiter is assigned
a different character.
The incentive behind this feature request is, to allow mapping key-values
pairs from a character stream/file, safely into a Bash's associative array
with a single built-in command.
Then these requirements suggest that the best way to proceed is to add a
loadable builtin to handle this case. You could start with the `csv' and
`cut' loadable builtins in bash-5.1, and could probably put together a `kv'
builtin in a couple of hours.
These days, people are going out of their way to parse key value pairs out
of foreign config files or result streams from jq processed JSON.
Maybe (it is clearly open to discussion), the associative array mapping
could be allowed to:
- skip blank/comment only lines (1)
- allow key without value
- optionally trim trailing comment (1)
All of this would be better added to a new builtin, since it's all
orthogonal to what mapfile provides.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
