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