Hello lejeczek,
On Wed, 19 Apr 2023 08:10:16 +0200 lejeczek <peljasz@xxxxxxxxxxx> wrote:
> On 19/04/2023 08:04, wwp wrote:
> > Hello lejeczek,
> >
> >
> > On Wed, 19 Apr 2023 07:50:29 +0200 lejeczek via CentOS <centos@xxxxxxxxxx> wrote:
> >
> >> Hi guys.
> >>
> >> I cannot wrap my hear around this:
> >>
> >> -> $ unset _Val; test -z ${_Val}; echo $?
> >> 0
> >> -> $ unset _Val; test -n ${_Val}; echo $?
> >> 0
> >> -> $ _Val=some; test -n ${_Val}; echo $?
> >> 0
> >>
> >> What is this!?
> >> How should two different, opposite tests give the same result
> >> Is there some bash option which affects that and if so, then what would be the purpose of such nonsense?
> > Surround ${_Val} with double quotes (as you should) and things will be different:
> >
> > $ unset _Val; test -n "${_Val}"; echo $?
> > 1
> >
> > Now you get it? :-)
> >
> >
> I don't know, am not sure, I remembered it differently, did not think enclosing quotes were necessary(always?) for that were {}
{} does not prevent this (at least not in bash):
$ FOO="a b"
$ test -z $FOO
bash: test: a: binary operator expected
$ test -z ${FOO}
bash: test: a: binary operator expected
Because after $FOO or ${FOO} variable expansion, bash parsed:
test -z a b
'b' is unexpected, from a grammar point of view.
Quoting is expected, here:
$ test -z "$FOO"
<no error>
When FOO is unset, apparently it's a different matter, where you end up
with $?=0 in all unquoted -n/-z cases, interestingly. I could not find
this specific case in the bash documentation. That may not be portable
to other shells, BTW. I only use {} when necessary (because of what
bash allows to do between {}, plenty!, or when inserting $FOO into a
literal string that may lead the parser to take the whole string for a
variable name: echo $FOObar != echo ${FOO}bar).
Regards,
--
wwp
https://useplaintext.email/
Attachment:
pgpxuXD5w4VrJ.pgp
Description: OpenPGP digital signature
_______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx https://lists.centos.org/mailman/listinfo/centos
