bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 4.4 change in behavior from 4.3: how to catch unset when using ${#le


From: L. A. Walsh
Subject: Re: 4.4 change in behavior from 4.3: how to catch unset when using ${#length}
Date: Mon, 24 Oct 2016 16:32:14 -0700
User-agent: Thunderbird



Chet Ramey wrote:
On 10/21/16 5:41 PM, L. A. Walsh wrote:
[previously] one could have the illusion of this working w/o complaint -- and returning 0 when the array was 0-len or unset, or the array length, otherwise:
 echo address@hidden:-0}
But I note it only seemed to work in arrays, and in 4.4 gets a
syntax error:
 echo address@hidden:-0}   bash: address@hidden:-0}: bad substitution

Because it is a syntax error, and if it were not it would be ambiguous.
The ${param:-word} word expansion takes a parameter, not another word
expansion, as the object to be expanded.
----
   I don't understand the ambiguity.  If param= "address@hidden", then it
is clear to me that the user wants the length of an array named "obj".
If it doesn't have the [@|*], then the user wants the # of characters
in "obj".  It seems both cases have clearly defined meanings.

   In either case, if the variable isn't set, or if array is unset, then
the length cannot be set.  If the length is not set, the the text to the
right of the ':-' is substituted.

   Alternatively, neither ${#unset} nor address@hidden should generate
errors (i.e. if the length operator is defined on "unset" variables, then
no error would be generated).  However, if one has "undefined-warnings"
turned on, both of those trigger an undefined warning.
   If one doesn't have the "undefined-warnings" turned on, then the
"#" operator says that the length of an undefined variable or array
is '0': a dubious result, unless one claims that the '#' "handles" an
undefined(unset) variable and returns its length as '0'.

If you want '#' to return '0' for undefined/unset objects (vars or arrays),
then it shouldn't trigger the "-u: unset variable" exception -- in the same
way one can safely test those names with ${object:-} and not trigger
the "unset-variable exception".

Either way would work for me -- returning 0 and not triggering the error,
or having "#" return "undef/unset" if used with an unset object which could
then be tested as part of a ${object:-} type expansion.

   It seems the ambiguity results from the length operator not returning
results consistent with triggered "unset" errors, no?









reply via email to

[Prev in Thread] Current Thread [Next in Thread]