Re: All bash variables that can be used as temp variables?

[Peng Yu]

On 1/27/23, Greg Wooledge <greg@wooledge.org> wrote:
> On Sat, Jan 28, 2023 at 02:39:35AM +0900, Koichi Murase wrote:
>> It is highly confusing, but as far as I understand, Peng is not
>> talking about practical scripting but persuing the theoretical corner
>> cases and possibilities of the language design.
>
> The problem is, bash isn't primarily a *language*.

That is your view. I have used bash as a language to handle everything
as much as I can. For whatever it can not do, I delegate it to other
languages.

> It's an implementation
> of an evolving standard that has its roots in a shell that was created
> in the late 1970s (Bourne), and strongly influenced by a derivative
> shell from the late 1980s (Korn), with a bit of csh thrown in as well,
> where that doesn't conflict with the other two.
>
> Nobody is going to turn bash into a full-featured programming language.

I am not saying it should be turned into a full-feature programing
language. But those full-fledged programming languages have many
drawbacks that bash doesn't have. One key problem I don't like about
those program languages (with the modules/packages on top) is that
they change too frequently. So that if I program something on them,
after a few years, I have to adapt my code to fit their changes. For
bash, that is much less likely to happen. Part of the reason is that I
made my own library in bash, as bash does not provide a library. In
this sense, it is actually a good thing about a language that does not
provide a library, this forces users to do something from scratch.

> That isn't the goal of the project.

It doesn't prevent people from using bash in that way.

> If Chet feels that new features are worth adding and supporting, then
> new features may be added.  Associative arrays, for example, are
> extremely useful, and were added in bash 4.0.
>
> However, existing features will generally not be changed, because
> that would break existing scripts.  Backward compatibility is *much*
> more important to the project than whatever aesthetic or theoretical
> considerations Peng Yu is fixated upon.

Nothing is absolute. The stability of bash is much superior to any
other programming languages. However, that doesn't mean it can never
be changed. It is just what can be changed and how it is changed.

Using bash variables for purposes that it is not originally considered
for breaks no backward compatibility. For the particular discussion in
this thread, I don't see the topic of backward compatibility is
relevant.

-- 
Regards,
Peng