Re: bug-bash Digest, Vol 237, Issue 30

[Yair Lenga]

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 "snapshot" of tools - e.g., old gcc, make, ... etc. I doubt that
many users are trying to install a new bash in a system that was
built/configured 15 years ago.

Many Java/python/C++ projects that want to move forward do it as part of
the "major" release, in which they indicate Java 7 (or java java 8) support
will be phased out. Same for C++ and python.


On Sun, Aug 28, 2022 at 12:00 PM <bug-bash-request@gnu.org> wrote:

> Send bug-bash mailing list submissions to
>         bug-bash@gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.gnu.org/mailman/listinfo/bug-bash
> or, via email, send a message with subject or body 'help' to
>         bug-bash-request@gnu.org
>
> You can reach the person managing the list at
>         bug-bash-owner@gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bug-bash digest..."
>
>
> Today's Topics:
>
>    1. Bash Coding style - Adopting C99 declarations (Yair Lenga)
>    2. Re: Light weight support for JSON (Yair Lenga)
>    3. Re: Bash Coding style - Adopting C99 declarations (Greg Wooledge)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 28 Aug 2022 10:47:38 -0400
> From: Yair Lenga <yair.lenga@gmail.com>
> To: bug-bash <bug-bash@gnu.org>
> Subject: Bash Coding style - Adopting C99 declarations
> Message-ID:
>         <CAK3_KpO6z=EGjYwhxLVZ=
> iO-ANtWp9VxaXjvac0ELnp2tM4xFw@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> 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 flags;
>      int *validp;
> {
>   intmax_t val;
>   int c;
>   procenv_t oevalbuf;
>
>   val = 0;
>   noeval = 0;
>   already_expanded = (flags&EXP_EXPANDED);
>
>
> ---
> Curious as to the motivation of sticking to this standard for new
> development/features. Specifically, is there a requirement to keep bash
> compatible with C89 ? I believe some of those practices are discouraged
> nowadays.
>
> Yair
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 28 Aug 2022 10:51:33 -0400
> From: Yair Lenga <yair.lenga@gmail.com>
> To: Alex fxmbsw7 Ratchev <fxmbsw7@gmail.com>
> Cc: bug-bash <bug-bash@gnu.org>
> Subject: Re: Light weight support for JSON
> Message-ID:
>         <
> CAK3_KpPV5XnwbCTXAcmktVgQaheguBM1Y7BOwA7J6YGpvWOjFg@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> 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 <fxmbsw7@gmail.com>
> wrote:
>
> >
> >
> > On Sun, Aug 28, 2022, 15:46 Yair Lenga <yair.lenga@gmail.com> 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 others readers. Yair.
> >>
> >
> > ah, cool
> > i just have a suggestion, .. to store the keys in a separate array, space
> > safe
> >
> > On Sun, Aug 28, 2022 at 9:42 AM Alex fxmbsw7 Ratchev <fxmbsw7@gmail.com>
> >> wrote:
> >>
> >>>
> >>>
> >>> On Sun, Aug 28, 2022, 15:25 Yair Lenga <yair.lenga@gmail.com> 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 two approaches:
> >>>> * For simple parsing, using 'jq' to extract elements of the JSON
> >>>> * For more complex tasks, switching to python or Javascript.
> >>>>
> >>>> 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 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.
> >>>>
> >>>> Proposal:
> >>>> * Minimal - Lightweight "json parser" that will convert JSON files to
> >>>> bash
> >>>> associative array (see below)
> >>>> * Convert bash associative array to JSON
> >>>>
> >>>> To the extent possible, prefer to borrow from jsonpath syntax.
> >>>>
> >>>> Parsing JSON into an associative array.
> >>>>
> >>>> Consider the following, showing all possible JSON values (boolean,
> >>>> number,
> >>>> string, object and array).
> >>>> {
> >>>>     "b": false,
> >>>>     "n": 10.2,
> >>>>     "s: "foobar",
> >>>>      x: null,
> >>>>     "o" : { "n": 10.2,  "s: "xyz" },
> >>>>      "a": [
> >>>>          { "n": 10.2,  "s: "abc", x: false },
> >>>>          {  "n": 10.2,  "s": "def" x: true},
> >>>>      ],
> >>>> }
> >>>>
> >>>> This should be converted into the following array:
> >>>>
> >>>> -------------------------------------
> >>>>
> >>>> # Top level
> >>>> [_length] = 6                            # Number of keys in
> >>>> object/array
> >>>> [_keys] = b n s x o a            # Direct keys
> >>>> [b] = false
> >>>> [n] = 10.2
> >>>> [s] = foobar
> >>>> [x] = null
> >>>>
> >>>> # This is object 'o'
> >>>> [o._length] = 2
> >>>> [o._keys] = n s
> >>>> [o.n] = 10.2
> >>>> [o.s] = xyz
> >>>>
> >>>> # Array 'a'
> >>>> [a._count] =  2                   # Number of elements in array
> >>>>
> >>>> # Element a[0] (object)
> >>>> [a.0._length] = 3
> >>>> [a.0._keys] = n s x
> >>>> [a.0.n] = 10.2
> >>>> [a.0.s] = abc
> >>>> [a.0_x] = false
> >>>>
> >>>> -------------------------------------
> >>>>
> >>>> I hope that example above is sufficient. There are few other items
> that
> >>>> are
> >>>> worth exploring - e.g., how to store the type (specifically, separate
> >>>> the
> >>>> quoted strings vs value so that "5.2" is different than 5.2, and
> "null"
> >>>> is
> >>>> different from null.
> >>>>
> >>>
> >>> did you forget to send the script along ? or am i completly loss
> >>>
> >>> a small thing i saw, a flat _keys doesnt do the job..
> >>>
> >>> I will leave the second part to a different post, once I have some
> >>>> feedback. I have some prototype that i've written in python - POC -
> that
> >>>> make it possible to write things like
> >>>>
> >>>> declare -a foo
> >>>> curl http://www.api.com/weather/US/10013 | readjson foo
> >>>>
> >>>> printf "temperature(F) : %.1f Wind(MPH)=%d" ${foo[temp_f]},
> ${foo[wind]}
> >>>>
> >>>> Yair
> >>>>
> >>>
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 28 Aug 2022 11:47:21 -0400
> From: Greg Wooledge <greg@wooledge.org>
> To: bug-bash@gnu.org
> Subject: Re: Bash Coding style - Adopting C99 declarations
> Message-ID: <YwuOCdmE13VlyQ0C@wooledge.org>
> Content-Type: text/plain; charset=us-ascii
>
> 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 variables
> >
> > intmax_t
> > evalexp (expr, flags, validp)
> >      char *expr;
> >      int flags;
> >      int *validp;
> > {
> >   intmax_t val;
> >   int c;
> >   procenv_t oevalbuf;
> >
> >   val = 0;
> >   noeval = 0;
> >   already_expanded = (flags&EXP_EXPANDED);
>
> You're mistaken.  What you're seeing is the "K&R" coding style, which
> predates C89.
>
> I'm pretty sure that the decision to continue in this style well past
> the widespread adoption of C89 was because of a desire to use bash on
> systems that still had a K&R C compiler.  A lot of the oldest GNU projects
> followed this idea, in order to increase the number of commercial Unix
> systems on which they could be used.
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> bug-bash mailing list
> bug-bash@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-bash
>
>
> ------------------------------
>
> End of bug-bash Digest, Vol 237, Issue 30
> *****************************************
>