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

[tlaronde%polynum.com@localhost]

Le Fri, Jun 30, 2023 at 03:37:18PM +0000, David Holland a écrit :
> On Wed, Jun 28, 2023 at 06:32:10PM +0200, tlaronde%polynum.com@localhost wrote:
>  > > If you want to write a two digit octal number you can not continue with
>  > > another ocatal digit. In C you could do "...\77" "7" and have it concat
>  > > the literals. In config files (without concatenation) you need some
>  > > other trick.
>  > 
>  > I beg to differ: since due to this very unfortunate "variable length"
>  > feature, your scanner has to read char by char, it can reject the third
>  > digit since it would yield an out of range byte value.
> 
> The behavior of escapes in C strings is widely used and well
> understood. Don't improvise.
> 
> There are such things as invalid inputs. Reject them with a reasonable
> diagnostic message instead of trying to guess what the user might have
> meant. Works out much better in the long run.

For this one I will go with the established behavior, but what should I
do when someone is passing, in octal or in hexa: "\000" ou "\x00"?

I have decided that this value will be reput, back, as an escape
sequence (possibly for an argument of some program), since if the
program "interprets" the escape sequence (as current inetd(8) does),
while manipulating internally, obviously, C strings, it will certainly
not provide what was intended... (supposing the user knows what he
wants, and this is, I admit, quite an optimistic view).

So what is established behavior in this case---and, BTW, most utilities
ignore errors with octal sequences (printf(1) for example).
-- 
        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