Irregularities when using -v, -z, -n

[eduardo-chibas]

> Sent: Friday, July 30, 2021 at 1:42 AM
> From: "Greg Wooledge" <greg@wooledge.org>
> To: help-bash@gnu.org
> Subject: Re: Irregularities when using -v, -z, -n
>
> On Thu, Jul 29, 2021 at 01:21:02PM +0000, Leonid Isaev (ifax) wrote:
> > On Thu, Jul 29, 2021 at 03:04:49PM +0200, eduardo-chibas@caramail.com wrote:
> > > How does manual never give examples of how to use things !
> > > 6.4 Bash Conditional Expressions
> >
> > You are welcome to submit documentation improvements...
>
> Inflating the bash(1) man page even further with thousands of examples
> is not likely to be accepted.
>
> The man page is primarily a reference, not a tutorial.  The correct
> place for basic examples is in a tutorial or guide.  There are many of
> these.

Most of the experience needed can never exist in the reference.  And
nobody has any interest in writing guides on what needs to be learned
for specific tasks.  As the seat of our experience is mostly within
us, I cannot see how users could ever benefit without having been
disciples of a guru.

> Unraveling things a bit, most of the OP's troubles would go away if
> they would simply initialize their variables with default values up
> front, instead of trying to determine retroactively whether they
> already assigned a value to the variable during option processing.

One of the problems is the many functionalities available.  One is able
to perform things in multiple ways, but one figures out the limitations
once you try more complicated things.  As you have outlined, history is
the culprit of many problems, particularly when changes to old stardards
remain static, rather than improved to the situations that are arising
today.  For instance, the requirement for quoting resulted in a bad deal
for all of us, but because they were incorporated in posix standards,
it will require enormous effort to go beyond them in future.

> I thought they had learned this already under the lisa-asket persona,
> but I couldn't find the specific message.  There were far too many
> to comb through.

Seems you will continue with your bullshit instead of not responding.
We all are able to make bullshit personas than we'll ever admit.
Is it wrong?  And suppose they are actual people with that name, what
difference in you does it make knowing that?  You just get angry
when people do not understand or have more questions.  Definitely
not an adequate person for helping users.

> All of these questions -- -v, -z, -n, is a variable already set, what
> if it's an array, what if... -- all of these are symptoms of the
> fundamental problem that they're doing things backwards.
>
> f() {
>     local a=0 b=0 file=
>
>     local OPTIND=1 OPTARG opt
>     while getopts abf: opt; do
>       case $opt in
>           a) a=1;;
>           b) b=1;;
>           f) file=$OPTARG;;
>           *) printf 'usage: f [-ab] [-f file]\n' >&2; return 1;;
>       esac
>     done
>     shift "$((OPTIND-1))"
>
>     printf 'After doing options, a=<%s> b=<%s> file=<%s>\n' "$a" "$b" "$file"
>     printf 'Remaining arguments:'
>     (($#)) && printf ' <%s>' "$@"
>     echo
> }
>
> The local variables a, b and file are initialized with default values
> before the option processing starts.  Therefore, there is no need to
> check whether they're "set" after the loop has finished.  They're always
> set to something, either a default value, or a different value, depending
> on which options are given to the function.
>
> All one needs to do after that is look at the *values* of the variables,
> and do whatever is appropriate for this function.

I mainly done that from seeing examples here and there, with most people doing
things wrong.  Do you think that I did not look into what others discuss, ending
up copying code and do the same mistakes.  Some discussions get long and 
complicated
and do not read everything from start to finish.