On Mon, Feb 24, 2025 at 8:22 AM Martin D Kealey <mar...@kurahaupo.gen.nz> wrote:
> > > On Mon, 24 Feb 2025 at 13:48, Phi Debian <phi.deb...@gmail.com> wrote: > >> I also forgot to mention that C99 introduced this >> >> There may be no gaps >> in the numbers of arguments specified using '$'; for example, if >> argu‐ >> ments 1 and 3 are specified, argument 2 must also be specified >> some‐ >> where in the format string. > > > That rule is necessary in C because of the many ways that varargs can: > different kinds of values can potentially occupy differing numbers of > consecutive bytes in the space used to store as parameters. (I would say > "in the call stack", except that's not how ISO-9899 defines things, even > though it is how most implementations work in practice.) > > In the shell, we already have an argv with consistently sized elements, so > randomly indexing into it does not pose any particular challenge. So I > wouldn't expect that rule to be necessary, in the sense that it doesn't > offer any flexibility to the implementation. > That's true, but yet it define a kind of idiom regarding printf that I agry a shell don't have to follow (and it doesn't in my ksh93 patch) but still could be considered. > -Martin > > PS: Hmmm, well I guess repetition could be implemented by simply shifting > off as many args as there are conversions, and that would be a simple way > to get consistent repetition whether conversions are numbered or not, but > it feels perverse and I don't like it - though maybe I'll change my mind > when I've thought it over. > Not sure I get it, but if you mean $ printf '%1$s %1$s %1$s\n" q w e r t y Should produce q q q r r r I don't agry, or I would say this is not the current ksh93 behavior $ printf '%1$s %1$s %1$s\n' q w e r t y q q q w w w e e e r r r t t t y y y Still ksh93 can produce your output (perverted indeed) $ printf '%1$s %1$s %1$s%3$Z\n' q w e r t y q q q r r r So while ksh can produce both output (flexible) your algo would prevent the former output, so you loose flexibility > PPS: I wouldn't actually shift the list of course; I'd just track a > striding index offset instead. >
