Re: [sr #111166] ngettext syntax

Chet Ramey Fri, 21 Feb 2025 11:52:33 -0800

On 2/21/25 1:37 PM, Phi Debian wrote:

    Given the following, which POSIX says is unspecified:

    printf '%s %3$s %s\n' A B C D

    ksh93-u+m prints "A D", which is just wrong. No matter how you mix numbered
    and unnumbered specifications, or whether you implement numbered
    specifications at all, you can't just drop it.


Well mine gives


$ echo $KSH_VERSION
Version AJM 93u+m/1.1.0-alpha+b5087279 2025-01-15

$ printf '%s %3$s %s\n' A B C D
A C B
D


I got that behavior with Version AJM 93u+m/1.1.0-alpha 2022-07-31.

I just updated my version using macports and I get the same behavior as
you with Version AJM 93u+m/1.0.10 2024-08-01. So it looks like Martijn
was working on it.

Which is just right I guess unless I am misled somewhere.
Yet mixing numbered and unumbered specification is questionable as you said, but so is the re-use of format string when reaching excess args... we are in the invent area here :-)


No, reusing the format string is required by POSIX. The only question is
the conditions under which you do that.

The more C like could be (fully numbered) latest ksh93 gives
$ printf '%3$s %2$s %1$s\n' A B C D
C B A
   D
Still the D is the args fmt re-use, but output is similar to C (modulo D)


You're not going to be able to give up format re-use. Everyone seems to
agree on the behavior when all of the format conversions are numbered.

and bash 5.3.0(1)-beta gives
$ printf '%3$s %2$s %1$s\n' A B C D
bash: printf: `$': invalid format character
Which indeed is not an invalid format or should I say is a plausible format specification.


Of course it does. I haven't implemented any support yet.

     > I like also to have %d (and all integer format) accept a valid integer
     > expression as argument (printf '%d' 1+1 ; i=1 ; printf '%d' i+1 etc...)
     > again a very low prio, but it is clean, I know that a simple
    $((...)) can
     > do this, but it is 5 char of line cluttering for each % integer
    format, for
     > not that much clarity.

    It decreases clarity. If you have an argument '1+1', your proposal
    makes it depend on the conversion specifier. Right now, there's no
    ambiguity: 1+1 is a string, and $(( 1+1 )) is 2, regardless of whether
    or not the conversion specifier accepts an integer argument.

For me clarity means that %d expect an integer expression value (ala C even though, there will be voice saying BASH is not C :-) so %d arg fetch must fetch not a string but a string that is an integer expression really removing $((...))


It's not an expression context. That's why $((...)) is available.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    c...@case.edu    http://tiswww.cwru.edu/~chet/

OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [sr #111166] ngettext syntax

Reply via email to