Re: Light weight support for JSON

[tetsujin]

On 2022-08-29 11:43, Chet Ramey wrote:
> On 8/28/22 2:11 PM, Lawrence Velázquez wrote:
> > On Sun, Aug 28, 2022, at 9:24 AM, Yair Lenga wrote:
> > > Wanted to get feedback about the following "extensions" to bash that 
> > > will
> > > make it easier to work with simple JSON object.  (...)
> > > just to make it easier to build bash scripts that cover the very 
> > > common use
> > > case of submitting REST requests with curl (checking results, etc), 
> > > and to
> > > perform simple processing of JSON files.
> >
> > I do not think bash needs to sprout functionality to support every
> > data-exchange format of the month.
>
> Loadable builtins are the way to do this

In that case could I suggest providing a simplified, stable programming 
interface
for loadable builtins?  (I understand this is not a trivial thing, of 
course.)

As I understand it (having made a few loadable built-ins myself, but 
possibly a
bit ignorant/hazy on the details) - the process involves a fair bit of 
hands-on
with the nitty-gritty of the version of Bash you're building against. A 
loadable
needs to deal directly with implementation details of how Bash handles 
variables,
open file handles, etc., and resulting code (source and binary) is very 
sensitive
to changes in Bash.

For me personally I was struggling with questions like, how do I make a 
loadable
module that sets a variable? Sounds simple but it seems to require a 
fair bit of
attention to implementation details of the shell to get it right. What 
if it's a
local variable? What if it's an array or hash element? And so on.

I understand the hesitancy to support "format of the month" data formats
directly in the shell. Though I think JSON has proven itself to be 
rather
worth supporting, personally: to call it a "format of the month" is 
almost a bit
comical. It's been quite relevant for the last 15 years or so at least.

In principle, "extending" the shell to support some new data structure 
should be
a task we can delegate to an external program. (That is, basically, the 
ideal of
the Unix shell) In practice, though, if we use an external program to 
parse a
hierarchical format like JSON, it can't effectively communicate the 
result back
to the shell. To do so, it would need to encode the data, and the 
encoded data
would have roughly the same complexity as JSON. For the external tool to
actually simplify the process, the shell and the tool would have to 
share a
common language. (JSON could serve as such a language.) It would also 
help
greatly if the shell could internally handle hierarchical data in
variables. (That is a pretty basic problem facing any potential 
implementation
of a JSON parser for Bash: When the data is parsed, what does the parser 
do with
it? It can't store the result in a variable because variables aren't 
hierarchical.)