Re: echo "enhancement" leads to confused legacy script tools...

[Linda W]

Henrik Nordstrom wrote:
> Note: As far as I can tell the echo tests in the configure script
> generated by autoconf-2.59 tests for quite many things but not \digit as
> far as I can tell. I have not yet looked into the CVS version.
>
> Regards
> Henrik
---
        Sorry, haven't been involved too much on this discussion,
I'm going to have limited time to look at this in the next day or
so.

        I'm willing to try the CVS versions of autoconf later on, but
can't promise when I'll get to it.  I can confirm, though, that
the bug I'm running into only happened when I rebuilt bash and
specified the --enable_xpg_default option.

        Personally, I don't believe allowing "\o[o[o]]" as an allowed
octal sequence is wise when xpg_default is enabled.  When "-e" is
required, it's not so problematic -- a use can't "accidentally" get
an octal sequence unless they have used "-e" -- and then they are (or should
be) aware that the string will be interpreted with "\" having special
meaning.  However, when extended interpretation is the default, the
requirement of having a "0" after a "\" reduces the number of
"special" strings making it less likely that some application will
accidentally enter "octal interpretation mode".

        It may seem a trivial difference, but the change means that
the number of "reserved" 2-byte sequences has doubled:
from:
        9 2-byte sequences (\a \b \c \f \n \r \t \v \\) and
        8 3-byte sequences (\00 \01 .. \07)
to:
        17 2-byte sequences (original + \0 \1 .. \7)
        or 18 if you count the addition of "x" for hex

Design thoughts:
If I wanted to provide maximum compatibility with existing applications,
it would be optimal to minimize the number of "reserved" 2-byte sequences
by requiring the leading "0 before an octal lead-in.  Even better,  IMO,
would be keeping with existing numeric constant interpretation from most
unix source code examples and require \0 as the prefix for octal and
\0xHH for hex.  That way "\xabsent" (for example) wouldn't cause a
surprise conversion to hex, while \0xabsent would seem to stand out
more as an indicator of a special embedded numeric (hex) constant.

It might be "late" to change the requirement to "\0" is required as
the leading for all numeric constants, but as has been stated here, no
application should be relying on "\1" being interpreted as "^A" if it
is desired that it be portable.

While it may seem somewhat "asymmetric", I'd be comfortable requiring the
"0" only in the case where the default was extended interpretation (i.e.
where "-e" isn't required).  As mentioned before, if a user explicitly
uses "-e", they they already need to be aware of special "\" processing,
so there would be less likelihood of "user surprise".

Linda