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

2023-07-03 Thread tlaronde
Le Mon, Jul 03, 2023 at 01:36:54PM +0200, ??? a écrit : > On Mon, Jul 03, 2023 at 06:13:45AM +, David Holland wrote: > > On Fri, Jun 30, 2023 at 05:51:13PM +0200, tlaro...@polynum.com wrote: > > > For this one I will go with the established behavior, but what should I > > > do when someone

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

2023-07-03 Thread наб
On Mon, Jul 03, 2023 at 06:13:45AM +, David Holland wrote: > On Fri, Jun 30, 2023 at 05:51:13PM +0200, tlaro...@polynum.com wrote: > > 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"? > If you don't

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

2023-07-03 Thread David Holland
On Fri, Jun 30, 2023 at 05:51:13PM +0200, tlaro...@polynum.com wrote: > 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"? If you don't support embedded nulls in the strings you're handling (and most

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

2023-06-30 Thread Martin Neitzel
KRE> It depends upon the usage. But if you're processing escapes, you KRE> need to also process \\ to mean a literal '\' of course, [...] Not necessarily -- '\134' would be good enough :-) Just joking, of course. The weekend is nigh. Martin

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

2023-06-30 Thread Robert Elz
Date:Fri, 30 Jun 2023 17:51:13 +0200 From:tlaro...@polynum.com Message-ID: | So what is established behavior in this case It depends upon the usage. But if you're processing escapes, you need to also process \\ to mean a literal '\' of course, and once you have

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

2023-06-30 Thread tlaronde
Le Fri, Jun 30, 2023 at 03:37:18PM +, David Holland a écrit : > On Wed, Jun 28, 2023 at 06:32:10PM +0200, tlaro...@polynum.com 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 >

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

2023-06-30 Thread David Holland
On Wed, Jun 28, 2023 at 06:32:10PM +0200, tlaro...@polynum.com 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

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

2023-06-28 Thread RVP
On Wed, 28 Jun 2023, Martin Husemann 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. Couple of ways to do

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

2023-06-28 Thread наб
On Wed, Jun 28, 2023 at 12:45:55PM -0400, Mouse wrote: > >>> "\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." > >> [...] > > I beg to differ: since due to this very unfortunate "variable

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

2023-06-28 Thread tlaronde
Le Wed, Jun 28, 2023 at 06:58:57PM +0200, Roland Illig a écrit : > Am 28.06.2023 um 12:57 schrieb tlaro...@polynum.com: > > But isn't it incorrect? POSIX 2018 says: > > > > '"\ddd", where ddd is a one, two, or three-digit octal number, shall be > > written as a byte with the numeric value

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

2023-06-28 Thread tlaronde
Le Wed, Jun 28, 2023 at 04:24:20PM +, RVP a écrit : > On Wed, 28 Jun 2023, tlaro...@polynum.com wrote: > > > But you can't: from the syntax given, \777 is a perfectly valid \77 > > octal sequence followed by the character '7'. > > > > That would be a very surprising way to resolve the

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

2023-06-28 Thread tlaronde
Le Wed, Jun 28, 2023 at 12:45:55PM -0400, Mouse a écrit : > >>> "\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." > >> [...] > > I beg to differ: since due to this very unfortunate "variable

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

2023-06-28 Thread Roland Illig
Am 28.06.2023 um 12:57 schrieb tlaro...@polynum.com: > But isn't it incorrect? POSIX 2018 says: > > '"\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.' The main intended takeaway from this sentence is

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

2023-06-28 Thread Mouse
>>> "\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." >> [...] > I beg to differ: since due to this very unfortunate "variable length" > feature, your scanner has to read char by char, it can

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

2023-06-28 Thread tlaronde
Le Wed, Jun 28, 2023 at 06:06:38PM +0200, Martin Husemann a écrit : > On Wed, Jun 28, 2023 at 05:59:10PM +0200, tlaro...@polynum.com wrote: > > "\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." > > >

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

2023-06-28 Thread RVP
On Wed, 28 Jun 2023, tlaro...@polynum.com wrote: But you can't: from the syntax given, \777 is a perfectly valid \77 octal sequence followed by the character '7'. That would be a very surprising way to resolve the ambiguity which is present here. There are others when it comes to octal

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

2023-06-28 Thread Martin Husemann
On Wed, Jun 28, 2023 at 05:59:10PM +0200, tlaro...@polynum.com wrote: > "\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 >

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

2023-06-28 Thread tlaronde
Le Wed, Jun 28, 2023 at 05:26:55PM +0200, Martin Husemann a écrit : > On Wed, Jun 28, 2023 at 05:01:46PM +0200, tlaro...@polynum.com 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

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

2023-06-28 Thread Martin Husemann
On Wed, Jun 28, 2023 at 05:01:46PM +0200, tlaro...@polynum.com 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.

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

2023-06-28 Thread tlaronde
Le Wed, Jun 28, 2023 at 01:10:04PM +, RVP a écrit : > On Wed, 28 Jun 2023, tlaro...@polynum.com wrote: > > > But isn't it incorrect? POSIX 2018 says: > > > > '"\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

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

2023-06-28 Thread RVP
On Wed, 28 Jun 2023, tlaro...@polynum.com wrote: But isn't it incorrect? POSIX 2018 says: '"\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.' since 477 -> 777 are not byte values, shouldn't \777 be

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

2023-06-28 Thread tlaronde
When refactoring and rewriting the scanning/parsing code for inetd(8), I wanted to add, too, the possibility to pass octal escape sequences (hex were already added) in order to be less surprising and to, actually, support whatever an admin is acustomed to use when invoking utilities. Since this