Define it as local and keep it.

Where regular expression is read from a variable and -e argument is not
provided, the resulting call may end up being interpreted as grep
argument,  This can be pretty dangerous, eg. if the variable expands to
`--help`, grep help is shown and grep exits with zero, which would be
interprered as match.  Another example is when the variable expands to
a valid grep parameter; this would mean that next argument would be
interprered by grep as the regex, and if the argument after that would
be missing, grep would read stdin, resulting in data messup or grep
waiting
indefinitely.

See also:

    https://github.com/koalaman/shellcheck/issues/1342

Turns out to be concise and safe enough to become the preferred one.

This also changes format; the 'K: V' format is problematic as it makes
it hard to separate from other directives.  'K=V' is now the only
accepted format.

Note that essential functions should be as fast as possible so they
probably should not inspect their arguments.

This should have been all along; if SHELLFU_PATH is not preferred,
one cannot override it eg. in test runs.

Decorate them and treat each argument as separate message (line)

There's no real reason to have it public.

SC2039 - We simply have to use `local` whenever it's possible, and
although it's not defined in POSIX, most common shells do support it
(well, at least Dash, Bash and Zsh).

SC1090 - Sourcing non-constant file is pretty much the main idea of
Shellfu, so avoiding that part does not make sense.

These variables are not specific to shellfu internals but in all ways
specific to pretty.sh module.  The prefix is mostly historical cruft.

Let's clean that up.

This was never intended to be public (and never documented).

shellfu-get (whose only job is to print one of hardcoded strings depending
on $1) and shellfu.sh should be as light as possible.  Most of this code
is only useful (and intended) for library exploration, which is domain
of shellfu-doc.

A neat side-effect is, that in its new home, we don't have to be so
fussy about performance and footprinting, so we can afford luxury such
as putting code into functions and documenting them, using $1 for first
argument, using shellfu libraries(!)...

Needless to say, this is an incompatible CLI change (or it would have
half the effect), so we take the opportunity to re-do the CLI to match
the new home.

Without -r, sequences like '\t' are translated, which we basically never
want.

It's rather useless in load-time, since the environment is often
tailored since then (e.g. SHELLFU_PATH is the most obvious example).

By far most realistic use case is import; even those related sub-commands
are always used along with import anyway.

Introduced by fefce4a0, typo invalidated catfun and ffdoc

A little improved module finder now

 *  ignores non-directories (incl. non-existent),
 *  sends path to debug before visit,
 *  and is safe against paths with spaces,

but as a side effect

 *  invokes find per (valid directory) path.

A more conventional hierarchy

Since it's normal e.g. for a dependency to import the same module as
upstream, the warning only created unnecessary noise.