On Fri, Feb 21, 2025 at 8:52 PM Chet Ramey <chet.ra...@case.edu> wrote:
> On 2/21/25 1:37 PM, Phi Debian wrote:
> >
>
> 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.
>
Actually this is my patch to ksh93 :-)
commit 87480ec207a56d7b17de722789437c8cc7827495
Author: Phi <phi.deb...@gmail.com>
Date: Wed May 17 03:51:20 2023 +0200
>
>
>
> 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.
>
I miss expressed myself I suppose, I don't want to give up the fmt reuse I
am the first to abuse it with a great interest, actually it is a powerfull
iterator.
I wanted to express that while trying to implement the %n$ you got to
depart C model because it C doesn't allow mix'n'match numbered and
unumbered specification, but at the same time the fmt reuse is a departure
from C, and bash is not C I hear many times, and I agry to, so meaning, if
we can invent fmt re-use we can invent %$n implementation, and in the same
vein we can invent mix'n'match numbered and unumbered departing C, that's
what I did for ksh93 and was accepted. The idea is to invent something
coherent.
In the ksh93 I decided that numbered are simply indexed access into the
args, while unumbered just walk on args possibly triping in an already
accessed to a numbered one so
$ printf '%3$s %s %2$s %s %1$s\n' A B C D E F G H
C A B B A
| | | | |
| | | | +-> %1$s indexed arg
| | | +---> %s 2nd non indexed
| | +-----> %2$s indexed arg
| +-------> %s 1st arg (non indexed)
+---------> %3$s indexed arg
F D E E D
G H H G
This way pure unumbered (no mixed indexed) works as before (as we used to)
Pure numbered (no unumbered) works as it does in C.
Mixed depart from C (as do fmt re-use) and the rule of thumb is easy to
remember, count unnumbered as they appears, and numbered as indexed, there
is one last catch, for fmt re-use, where to start the next iteration, well
I decided the next one arg in line for next fmt re-use is the max of
unumbered one and numbered one max index, i.e if there are 4 unumbered and
max index is 3 then the next fmt arg start is 5, and the other way around
if only 2 unumbered was used and max indexed is 4 then again next fmt start
is at 5.
This is one approach, other approach could be made, like refusing
mix'n'match, accepting only pure access (numbered or unumbered exclusivly)
Note that I used the same rule for numbered unumbered mix'n'match for the
implementation of %*.*s and %n$*w$.*p$s that is the use of num.prec
| | prec
| width
pos
Note the pos is not too intuitive but that's libc implementation, it comes
before num.prec.
$ printf '%3$*2$.*1$s\n' 2 4 6
6
$ printf '%3$*2$.*1$s\n' 2 4 67
67
$ printf '%3$*2$.*1$s\n' 2 4 678
67
$ printf '%3$*2$.*1$s\n' 2 4 678 3
67
$ printf '%3$*2$.*1$s\n' 2 4 678 3 5
67
$ printf '%3$*2$.*1$s\n' 2 4 678 3 5 7
67
7
$ printf '%3$*2$.*1$s\n' 2 4 678 3 5 78
67
78
$ printf '%3$*2$.*1$s\n' 2 4 678 3 5 789
67
789
$ printf '%3$*2$.*1$s\n' 2 4 678 3 5 7890
67
789
$
And the cherry on the pie mix'n'match with width.prec
$ printf '%3$*.*2$s\n' 4 2 6
6
$ printf '%3$*.*2$s\n' 4 2 67
67
$ printf '%3$*.*2$s\n' 4 2 678
67
$
This is completly useless nobody will use that, yet it is coherent, the
rules are predictable, it doesn't crash :-)
With ksh93 we start with a plain buggy implementation, so I suppose nobody
ever used it on purpose to get the buggy result, then allowing an
implementation that is correct for a given rule of thumb, don't produce
false positive error message.
Yet it allows simple usage like '%2$*1$.*1$s\n' where with==prec avoiding
the double arg width and prec so
$ printf '%2$*1$.*1$s\n' 2 45
45
$ printf '%2$*1$.*1$s\n' 2 456
45
$ printf '%2$*1$.*1$s\n' 2 456 3
45
$ printf '%2$*1$.*1$s\n' 2 456 3 4
45
4
$ printf '%2$*1$.*1$s\n' 2 456 3 45
45
45
$ printf '%2$*1$.*1$s\n' 2 456 3 456
45
456
$ printf '%2$*1$.*1$s\n' 2 456 3 4567
45
456
This later usage could be more common.
>
> > 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.
>
>
> >
> > 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.
>
But bash already have a conversion specifier ambiguity resolved
$ printf '%d\n' yo
bash: printf: yo: invalid number
0
$ printf '%x\n' yo
bash: printf: yo: invalid number
0
The beast of burden is already done in bash, it does scan the fmt string
recognise integer conversion specifier fetch the arg 'string' and apply an
integer validity test on it, this is on this last operation that the
validity check could be replaced by a airth_eval(string)
without it then $((...)) still is clutering the line
Again this is just a point of view, if this is never done, this is not a
problem, this is kind of cosmetic.
> It's not an expression context. That's why $((...)) is available.
>
It is not an expression context at the moment but could be one day, for now
it is an 'integer' context, so the error when the string is not an integer
(number), and nothing really define what is a context of an arg in a
command arg list, beside it is a string.
When I do
$ function f { echo $(($1)) ; }
$ f 1+1
2
This is perfecty valid f() really accept what you call an expression
context, while it is just a string that is internally view and used as an
arith expr.
If f() is capable to decide what arg could be an arith expresion why printf
could not ?
Hope the answer is not "because /bin/printf doesn't do that"
Again this is just a discution what could be some future, this is low prio,
or even no prio :-)
