Hello lejeczek, On Wed, 19 Apr 2023 08:10:16 +0200 lejeczek <peljasz at yahoo.co.uk> wrote: > On 19/04/2023 08:04, wwp wrote: > > Hello lejeczek, > > > > > > On Wed, 19 Apr 2023 07:50:29 +0200 lejeczek via CentOS <centos at centos.org> 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20230419/6fdb4cbf/attachment-0002.sig>