On 8/28/22 1:17 PM, Yair Lenga wrote:
Yes, you are correct - (most/all of) of those examples "K".
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.
There's no actual
On Sun, Aug 28, 2022, at 1:17 PM, Yair Lenga wrote:
> Yes, you are correct - (most/all of) of those examples "K".
>
> 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 can
>>>> 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
> To: bug-bash@gnu.org
> Subject: Re: Bash Coding style - Adopting C99 declarations
> Message-ID:
> 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_EXPANDED);
>
> You're mistaken. What you're seeing is the "K" 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 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
> *
>
