help-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Koichi Murase
Subject: Re: All bash variables that can be used as temp variables?
Date: Sat, 28 Jan 2023 02:21:40 +0900

2023年1月28日(土) 0:33 Peng Yu <pengyu.ut@gmail.com>:
> If you know a variable can be used (under what condition), then you
> can just list it.

So, (despite that I see the phrase "All bash variables that ..." in
the subject of this thread), you are expecting us to tell something
they happened to know accidentally regardless whether that is the
complete list or not? In that case, without checking any reference,
what come to my mind immediately are these:

* You have mentioned REPLY, but there is also a similar variable
MAPFILE set by mapfile/readarray. It's obviously unused when you do
not use mapfile/readarray or if you always specify an array name to
them. There is also COMPRELY that are supposed to be set by
programmable completion functions, which is unused when you do not use
the completions of interactive sessions.

* READLINE_* wouldn't be used when you do not use `bind -x'.
Similarly, COMP_* wouldn't be used when you do not use programmable
completions.

* It is impossible to use the variables specified to be readonly even
if one tries to do it.

* Also it is useless to try to use the variables that would be
frequently updated by Bash, such as $_, BASH_COMMAND, etc. COLUMNS and
LINES can also be updated in an uncontrolled timing when an external
process terminates (with shopt -s checkwinsize) or when Bash receives
SIGWINCH, etc.

* There are still many other variables.

But, all of the above thoughts are far from the complete list and not
the exact conditions. It might be possible to think about the exact
conditions for every variable, but it would become a very long story
and would take much time. I'm not so motivated to write a ``book''
about the exact conditions for all Bash special variables for you to
use already-used variables.in a non-sense way.

> But there may be other variables that can also be used. For example,
> probably BASH_VERSION, as I seldom need to check the bash version
> because I just use the version that works. If it has any problem with
> the version that I use, I will use another version.

So you are requesting undocumented version-specific behavior of each
Bash version?

> But there is no
> description of whether it will be changed back to its original value
> in the manual. So I don't know if I can assume so.

As far as we care about compatibility with different Bash versions, we
should not rely on an undocumented behaviors because these can be
changed in future versions. If you don't care it,  you probably
wouldn't get desired answers here because the answers obtained here
are usually supposed to be valid in different versions rather than the
specific version you use.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]