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-requ...@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-requ...@gnu.org > > You can reach the person managing the list at > bug-bash-ow...@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.le...@gmail.com> > To: bug-bash <bug-bash@gnu.org> > Subject: Bash Coding style - Adopting C99 declarations > Message-ID: > <CAK3_KpO6z=EGjYwhxLVZ= > io-antwp9vxaxjvac0elnp2tm4...@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.le...@gmail.com> > To: Alex fxmbsw7 Ratchev <fxmb...@gmail.com> > Cc: bug-bash <bug-bash@gnu.org> > Subject: Re: Light weight support for JSON > Message-ID: > < > cak3_kppv5xnwbctxacmktvgqahegubm1y7bowa7j6ygpvwo...@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 <fxmb...@gmail.com> > wrote: > > > > > > > On Sun, Aug 28, 2022, 15:46 Yair Lenga <yair.le...@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 <fxmb...@gmail.com> > >> wrote: > >> > >>> > >>> > >>> On Sun, Aug 28, 2022, 15:25 Yair Lenga <yair.le...@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 <g...@wooledge.org> > To: bug-bash@gnu.org > Subject: Re: Bash Coding style - Adopting C99 declarations > Message-ID: <ywuocdme13vly...@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 > ***************************************** >