On 2026-06-23 17:06, Harald van Dijk wrote:
On 23/06/2026 16:15, Stephane Chazelas via austin-group-l at The Open
Group wrote:
On 2026-06-23 12:11, Vincent Lefevre via austin-group-l at The Open
Group wrote:
FYI, the printf command from the GNU Coreutils and zsh accept both
the
period and the decimal-point character of the current locale, while
ksh93 accepts only the decimal-point character of the current locale.
Note that for ksh93 and zsh, arguments for numeric conversion
specifiers can be taken as arithmetic expressions and both support the
"," C arithmetic operator, something not *allowed* by POSIX (recent
versions of ksh93 disable that when in posix mode).
The specification is mostly in 1.1.2.1 Arithmetic Precision and
Operations which says "The comma operator (section 6.5.17 of the ISO C
standard) is intentionally not included in the table. It need not be
supported by implementations." That note implies implementations are
permitted to support it as an extension. Such an extension would not
conflict with any script that only uses the standard operators, so I
think that implication is correct, implementations can support the
comma operator if they want?
Sorry for the confusion, I meant that POSIX doesn't allow printf
implementations to treat operands for numeric conversion specifiers as
arithmetic expressions.
For example,
printf %d 1+1
is required to output 1 on stdout and an error about an invalid number
on stderr and return with a failure exit status (which ksh93 does in
POSIX mode but not otherwise)
$ ksh93 -c 'printf "%d\n" 1+1'
2
$ ksh93 -o posix -c 'printf "%d\n" 1+1'
ksh93: printf: 1+1: bad number
ksh93: printf: warning: invalid argument of type d
1
Zsh's builtin printf remains non-compliant in sh emulation:
$ zsh -c 'printf "%d\n" 1+1'
2
$ zsh --emulate sh -c 'printf "%d\n" 1+1'
2
--
Stephane
