Re: printf(1), sh(1), POSIX.2 and octal escape sequences

[tlaronde%polynum.com@localhost]

Le Wed, Jun 28, 2023 at 05:26:55PM +0200, Martin Husemann a écrit :
> On Wed, Jun 28, 2023 at 05:01:46PM +0200, tlaronde%polynum.com@localhost wrote:
> > But you can't: from the syntax given, \777 is a perfectly valid \77
> > octal sequence followed by the character '7'.
> 
> No, from the Posix text you quoted it clearly is a three digit ocatl
> sequence, and its value is out of range.

Since you are not either an english native speaker, Would you mind
explaining me how you parse the POSIX sentence:

"\ddd", where ddd is a one, two, or three-digit octal number, shall be
written as a byte with the numeric value specified by the octal number."

? Because I parse it as: an octal escape sequence can be \d, or \dd or
\ddd; and the result is a byte value.

You seem to parse it as: an octal sequence is always three digit \ddd,
but translated in a "three digit" byte value; this doesn't make sense
for me, because if you specify that it is a byte, you specify the range
[0, 255], and the number of digits has nothing to do with it.

It this is your interpretation, this is not what printf(1) does:

$ printf '\11|\n'
	|
	
$ printf '\74\n'
<

and you might try the BEL if your terminal supports it for a single
digit case. This is variable length. If printf doesn't take '|' or
'\n' because it can not be an octal, why would it take \777 that
can't be the value of a byte?

So why assume that an incorrect three digit octal should be interpreted
when a correct two digit octal followed by a character (that happens to
correspond, in ASCII, to a digit) is a valid string in this case?
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C