[Top][All Lists]

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

Re: Light weight support for JSON

From: tetsujin
Subject: Re: Light weight support for JSON
Date: Mon, 29 Aug 2022 14:03:51 -0400
User-agent: Roundcube Webmail/1.4.3

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.)

reply via email to

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