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

[L. A. Walsh]

Chet Ramey wrote:
> On 10/29/16 2:04 AM, L. A. Walsh wrote:
>
>   
> > You can claim a feature is a certain way because posix requires it
> > when you are operating in posix-only mode.
> >     
>
> Not actually true. I can claim bash implements a particular feature the
> way bash implements it. 
---
   True, but you cited POSIX as the reason.  You didn't cite some
bash-spec nor is it clear clear about what non-posix changes might be
acceptable into bash -- _if_ _any_. 

Is it the case that only POSIX compliant changes are acceptable for
inclusion in bash -- even in its non-posix mode?  I've never gotten that
as a project rule or guideline.  Perhaps I missed the announcement of
that requirement(?).

> You might not agree with it, but the beauty of
> open source is that you can take bash, go off, and use it as a base for
> `walsh'.
>   
---
   That would be difficult from what I've seen of the source, but
then that's probably why I didn't write it from scratch starting...? what
15, 20? years ago (meaning I don't even like the look of my code, sometimes
as little as 5 years ago, let alone 15-20 years ago, so its not
meant personally, or as applying to bash-code in particular).
> I'm not sure what you think this is going to demonstrate. Bash works as
> described in the man page.  The man page and the Posix standard happen to
> align on this feature.
>   
----
   I didn't say it was a bug to operate that way -- just that
if one followed the example in some other languages, the length
of an unset or undefined string is "undefined".  If that definition
was to be used (in the future) in non-posix-mode, then it would
make sense to be able to use ':[-=+]xxxx}' as a catch or fallback
for an attempt to use '#' with a value that is unset or undefined.

   I'm not disagreeing with how it is, but am trying to describing
a different way of being able to look at the problem that could
yield more useful information. 

   It's hard to give a valid length for the length of a line
between the square-roots of a negative number because such a length
isn't defined for natural numbers. 

   In the same way a string of undefined length, mathematically,
wouldn't normally be fixed at '0'.  Standards bodies have overridden
math in the past in doing things like defining π (pi) as 3.  Following
the standards are useful for _some_ things, but one could always
choose the option of returning "unset/undef" for a length
operator used on an "unset/undefined" variable when
standards-compliance is _disabled_ (e.g. posix mode is off). 

   It was meant as a suggestion to enable more convenient examination
and manipulation of a string variable.  It wasn't intended
to create a storm.  I've thought that Bo[u]rn[e] Again Shell
was, on some level, to provide convenience and features above
and beyond the minimal requirements set by standards, so please
don't take offense if I thought or expected more of bash
than was intended.

An aside:
I'm sure it's been stressful with more eyes on bash, lately,
and with those panicing about the security-sky falling because
bash had been more designed with convenience in mind that today's
hostile crackers (as it's often noted that security requirements
often are opposed to usability and easy-of-use features).  I certainly
don't fault useful programs for other people's insecurities about how
such programs can be abused.