On 8/29/22 5:48 AM, Martin D Kealey wrote:
The Shell persists because it has one killer feature: it does double duty
as a scripting language and as an interactive command language. But we're
kidding ourselves if we think that no other language could fill that gap:
Python has a respectable interac
On Mon, 29 Aug 2022 at 09:14, Dmitry Goncharov
wrote:
> On Sunday, August 28, 2022, Andreas Schwab wrote:
> > Note that the next revision of the C standard removes support for K&R
> > declarations
>
> The code will continue to compile, won't it?
>
I expect "gcc -std=c23" will reject such code.
Not that I fundamentally disagree with this (JSON) proposal, but I'd rather
see the effort put into support for nested arrays (like ksh has), and
generally having a more forward-looking view of Bash as an evolving
language.
I would see this proceeding somewhat like the transition from Perl4 to
Per
On Sun, Aug 28, 2022 at 08:47:24PM -0400, Dale R. Worley wrote:
> The "obvious" way to support Json in Bash would be a utility that parses
> Json and produces e.g. a Bash associative array, and conversely a
> utility that reads a Bash associative array and produces Json. The real
> limitation is t
On Sun, Aug 28, 2022 at 7:47 PM Dale R. Worley wrote:
> The "obvious" way to support Json in Bash would be a utility that parses
> Json and produces e.g. a Bash associative array, and conversely a
> utility that reads a Bash associative array and produces Json. The real
> limitation is that it's
The "obvious" way to support Json in Bash would be a utility that parses
Json and produces e.g. a Bash associative array, and conversely a
utility that reads a Bash associative array and produces Json. The real
limitation is that it's difficult to have a subprocess set Bash's
variables. As far as
On Sunday, August 28, 2022, Andreas Schwab wrote:
> On Aug 28 2022, Greg Wooledge wrote:
>
> > On Sun, Aug 28, 2022 at 10:47:38AM -0400, Yair Lenga wrote:
> >> Hi,
> >>
> >> I've noticed Bash code uses "old-style" C89 declarations:
> >> * Parameters are separated from the prototype
> >> * Variabl
First, thanks for taking the time to read and provide your thoughts. This
is the real value of the discussion/
Second: I'm NOT trying to argue that there isn't valid use for
combining bash/curl/jq, Nor do I suggest adding JSON as first class object
to bash (Python/node/Perl/Groovy are way ahead .
He has a point, though. To have some of the functionality of jq inside Bash
may be very useful.
If he can supply a patch, why not?
Philip Orleans
On Sun, Aug 28, 2022, 3:22 PM John Passaro wrote:
> interfacing with an external tool absolutely seems like the correct answer
> to me. a fact worth m
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.
It occurred to me to provide references for previous discussion
along these lines, but it turns out there isn't very muc
On Sun, Aug 28, 2022, at 4:05 PM, G. Branden Robinson wrote:
> At 2022-08-28T15:52:55-0400, Lawrence Velázquez wrote:
>> On Sun, Aug 28, 2022, at 2:56 PM, G. Branden Robinson wrote:
>> > How about next July, when JSON is as exactly old as the Bourne shell
>> > was when JSON was deployed?
>>
>> I d
At 2022-08-28T15:52:55-0400, Lawrence Velázquez wrote:
> On Sun, Aug 28, 2022, at 2:56 PM, G. Branden Robinson wrote:
> > How about next July, when JSON is as exactly old as the Bourne shell
> > was when JSON was deployed?
>
> I do not find "well *actually* JSON is old too!!!" to be particularly
>
On Sun, Aug 28, 2022, at 2:56 PM, G. Branden Robinson wrote:
> At 2022-08-28T14:11:25-0400, Lawrence Velázquez wrote:
>> I do not think bash needs to sprout functionality to support every
>> data-exchange format of the month.
>
> This sentiment is illustrative of the logarithmic memory scale of
> g
interfacing with an external tool absolutely seems like the correct answer
to me. a fact worth mentioning to back that up is that `jq` exists. billed
as a sed/awk for json, it fills all the functions you'd expect such an
external tool to have and many many more. interfacing from curl to jq to
bash
At 2022-08-28T14:11:25-0400, Lawrence Velázquez wrote:
> I do not think bash needs to sprout functionality to support every
> data-exchange format of the month.
This sentiment is illustrative of the logarithmic memory scale of
grognards. The Bourne shell was first released as part of Version 7
Un
On Sun, Aug 28, 2022, at 2:29 PM, Yair Lenga wrote:
> I do not think that JSON (and REST) are "data exchange format of the
> month". Those are established formats that are here to stay. Like YAML.
> Those are "cornerstones" of cloud computing/configuration. I do not have to
> argue for them, they c
I do not think that JSON (and REST) are "data exchange format of the
month". Those are established formats that are here to stay. Like YAML.
Those are "cornerstones" of cloud computing/configuration. I do not have to
argue for them, they can speak for themselves.
As for using external utilities: t
On Sun, Aug 28, 2022, at 1:17 PM, Yair Lenga wrote:
> Yes, you are correct - (most/all of) of those examples "K&R".
>
> However, given bash's important role in modern computing - isn't it time to
> take advantage of new language features ?
Why? What benefit would that actually provide?
> this ca
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. To emphasize, the goal is
> NOT to "compete" with Python/Javascript (and other full scale language) -
> just to make it e
Yes, you are correct - (most/all of) of those examples "K&R".
However, given bash's important role in modern computing - isn't it time to
take advantage of new language features ? this can make code more readable,
efficient and reliable. Users who are using old platforms are most likely
using a "
On Aug 28 2022, Greg Wooledge wrote:
> On Sun, Aug 28, 2022 at 10:47:38AM -0400, Yair Lenga wrote:
>> Hi,
>>
>> I've noticed Bash code uses "old-style" C89 declarations:
>> * Parameters are separated from the prototype
>> * Variables declared only at the beginning of the function
>> * No mixed de
On Sun, Aug 28, 2022 at 10:47:38AM -0400, Yair Lenga wrote:
> Hi,
>
> I've noticed Bash code uses "old-style" C89 declarations:
> * Parameters are separated from the prototype
> * Variables declared only at the beginning of the function
> * No mixed declaration/statements
> * No block local variab
Interesting point. Using (optional) separate array can also address the
problem of "types" - knowing which values are quoted, and which one are
not. This can also provide enough metadata to convert modified associative
table back to JSON.
On Sun, Aug 28, 2022 at 9:51 AM Alex fxmbsw7 Ratchev
wrote
Hi,
I've noticed Bash code uses "old-style" C89 declarations:
* Parameters are separated from the prototype
* Variables declared only at the beginning of the function
* No mixed declaration/statements
* No block local variables
intmax_t
evalexp (expr, flags, validp)
char *expr;
int flag
On Sun, Aug 28, 2022, 15:46 Yair Lenga wrote:
> Sorry for not being clear. I'm looking for feedback. The solution that I
> have is using python to read the JSON, and generate the commands to build
> the associative array. Will have to rewrite in "C"/submit if there is
> positive feedback from oth
Sorry for not being clear. I'm looking for feedback. The solution that I
have is using python to read the JSON, and generate the commands to build
the associative array. Will have to rewrite in "C"/submit if there is
positive feedback from others readers. Yair.
On Sun, Aug 28, 2022 at 9:42 AM Alex
On Sun, Aug 28, 2022, 15:25 Yair Lenga wrote:
> Hi,
>
> Over the last few years, JSON data becomes a integral part of processing.
> In many cases, I find myself having to automate tasks that require
> inspection of JSON response, and in few cases, construction of JSON. So
> far, I've taken one of
Hi,
Over the last few years, JSON data becomes a integral part of processing.
In many cases, I find myself having to automate tasks that require
inspection of JSON response, and in few cases, construction of JSON. So
far, I've taken one of two approaches:
* For simple parsing, using 'jq' to extrac
28 matches
Mail list logo
