Putting aside the effort to implement, it might be important to think on how the h-data structure will be used by users. For me, the common use case will be to implement a simple, small "record" like structure to make it easier to write readable code. Bash will never be able to compete with Python/Node for large scale jobs, or for performance critical services, etc. However, there are many devops/cloud tasks where bash + cloud CLI (aws/google/azure) could be a good solution, eliminating the need to build "hybrids". In that context, being able to consume, process and produce data structures relevant to those tasks can be useful. Clearly, JSON and YAML are the most relevant formats.
As a theoretical exercise, looking for feedback for the following, assuming that implementation can be done. Suggesting the following: * ${var.k1.k2.k3} -> value # Should lookup an item via h-data, supporting the regular modifiers ('-', for default values, '+' for alternate, ...) * var[k1.k2.k3]=value # Set a specific key, replacing sub-documents, if any - e.g. removing any var[.k1.k2.k3.*] * var[k1.k2.k3]=(h-value) # set a specific key to a new h-value * ${var.k1.k2.k3.*} -> h->value # extract h-value string that represent the sub-document k1.k2.k3 The 'h-value' representation may be the same format that is currently used by the associative array. No need to reinvent here. Assuming the above are implemented, the missing pieces are "converters" to common formats: json, yaml, and possibly XML (yet, there is still a lot of those). In theory, following the 'printf' styles: * printjson [-v var] h-value * readjson var # or event var.k1 * printyaml [-v var] h-value * readyaml var # or event var.k1 To summarize: * Using '.' to identify the hierarchy of the h-data - extension to bash syntax. * Allow setting a "node" to new value, or new sub-document - may be extension * Converters to/from standard formats - can be extensions Looking for feedback Yair Date: Fri, 2 Sep 2022 09:38:35 +1000 From: Chris Dunlop <ch...@onthe.net.au> To: Chet Ramey <chet.ra...@case.edu> Cc: tetsu...@scope-eye.net, bug-bash@gnu.org Subject: Hierarchical data (was: Light weight support for JSON) Message-ID: <20220901233835.ga2826...@onthe.net.au> Content-Type: text/plain; charset=us-ascii; format=flowed On Wed, Aug 31, 2022 at 11:11:26AM -0400, Chet Ramey wrote: > On 8/29/22 2:03 PM, tetsu...@scope-eye.net wrote: >> It would also help greatly if the shell could internally handle >> hierarchical data in variables. > > That's a fundamental change. There would have to be a better reason to > make it than handling JSON. I've only a little interest in handling JSON natively in bash (jq usually gets me there), but I have a strong interest in handling hierarchical data (h-data) in bash. I admit I've only had a few cases where I've been jumping through hoops to manage h-data in bash, but that's because, once it's clear h-data is a natural way to manage an issue, I would normally handle the problem in perl rather than trying to force clunky constructs into a bash script. In perl I use h-data all the time. I'm sure if h-data were available in bash I'd be using it all the time there as well. Chris > >