Re: Preventing Bash Variable Confusion

[Robert Elz]

    Date:        Wed, 29 Jan 2020 13:57:48 -0500
    From:        Greg Wooledge <wooledg@eeg.ccf.org>
    Message-ID:  <20200129185748.GF1350@eeg.ccf.org>

  | A script is supposed to be a self-contained entity, as much as possible.
  | It isn't supposed to be part of some web of tangled dependencies.

In general I agree, but sometimes it simply helps to have a bunch
of basic functions that can be used over and over, rather than
(trying to) reinvent the world every week.   Whether they're accessed
via ". file" embedded in the script, or ":r /../..." performed in
an editor doesn't really matter.

What matters is that we tend to forget what we have done before, and
simply use it ... it always worked previously, why not now?

Further, such functions aren't necessarily broken, sometimes we need
to retain state from one call to another, and that requires somewhere
to save that state - unless we're going to use external files, that
means non-local variables.   I have a mod (not yet, and perhaps never,
incorporated, as the demand for it doesn't seem to exist) that adds
to the NetBSD sh "static local" variables in functions (local -S) which
look just like local vars from outside, but each time the function is
called start with the value that the variable had when the function last
returned (or currently has in the case of directly or indirectly recursive
functions that are currently active in the call stack).   The effect is
that when used as "local -S var=0" the assignment to "var" (on that line)
is performed only the first time the function (or more correctly, that
particular command - it is executable after all, not a declaration) is
run.   Next time through "var" will be given the value it had last time.

  | You mean "builtin" instead of "command" in every one of those cases,
  | right?

For bash, probably - "command" to be more portable.   All "command" does
(aside from turning off any "special builtin" properties, and when given no
options) is avoid function lookups.   It isn't important here that the
command being run happens to be built in (so we don't need the property
of bash's "builtin" command that it fails if the command isn't built in).

  | Well, if you're using maliciously broken "library functions"

Not maliciously (though I'll admit my example looked like that, just
because that kind of example was easier), just ones that turn out to
do unexpected things.

  | in a bash script, the problem is, the malicious library can also
  | override the "command" command and the "builtin" command.

Yes, it could - but I think that would (or should) be detected fairly
easily.   And we don't need to postulate that level of deviousness.

kre