[Top][All Lists]

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

Re: bug-bash Digest, Vol 238, Issue 2

From: Yair Lenga
Subject: Re: bug-bash Digest, Vol 238, Issue 2
Date: Sun, 4 Sep 2022 15:49:46 -0400

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
* Allow setting a "node" to new value, or new sub-document - may be
* Converters to/from standard formats - can be extensions

Looking for feedback

Date: Fri, 2 Sep 2022 09:38:35 +1000
From: Chris Dunlop <chris@onthe.net.au>
To: Chet Ramey <chet.ramey@case.edu>
Cc: tetsujin@scope-eye.net, bug-bash@gnu.org
Subject: Hierarchical data (was: Light weight support for JSON)
Message-ID: <20220901233835.GA2826797@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, tetsujin@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.



reply via email to

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