On Sun, Feb 23, 2025 at 12:34 AM Robert Elz <k...@munnari.oz.au> wrote:
> Date: Sat, 22 Feb 2025 09:48:29 +0100 > From: Andreas Schwab <sch...@linux-m68k.org> > Message-ID: <87r03q5pr6....@linux-m68k.org> > > | On Feb 22 2025, Phi Debian wrote: > | > I forgot to mention your trick to nuke the fmt reuse still works > | > $ printf '%s %s %s %999$s' A B C D E F G > | > A B C > > Using %999$.0s rather than just %999$s was deliberate, it ensures that > if there happen to be 999 args, nothing is printed (the aim isn't to > do anything with the arg, just consider it used). Also, sticking a space > before it is not a good idea, your output would be "A B C " - and while > that might be what you wanted, it usually would not be. > Agry for the trailing useless space, I got bitten by it in the QA suite test I added for ksh93. In my implementation %999$s is enough to kill the fmt reuse, as I noted you should stick in there a majorant that you know will not happen 4096 is doable too. > > I should also mention that this isn't guaranteed to work according to > the POSIX spec - it says: > > ... > > Note, it says "consumed" not "referenced" there, an argument that does > not exist (as we're presuming, or perhaps hoping, is the case with the > 999th arg being selected) cannot really be said to be consumed, as it does > not exist. > > Further, this spec also violates Chet's rule: > > chet.ra...@case.edu said: > | There is no user who would think that using a numbered conversion > specifier > | is not an absolute position in the original argument list. > > ... I didn't paid attention to POSIX for this thing, because mainly, the idea was 'do not mix number/unnumbered, and whatever POSIX said, the few shell I checked before going ahead where simply buggy or refused such mix. In the ksh case, it was the most advanced one yet still bugged, so I decided to make something workable, mainly because I really needed numbered to work. Since there is no implementation approaching POSIX fuzzy description and fully operational, then my implementation isn't breaking anything in the real life. POSIX may reword the unumbered/numbered mix in my direction one day, if they go toward another one we will adapt, for now there is nothing that work regarding shells, and ksh93 was core dumping on bad combo, so now it doesn't core dump and now if propose something that has a logic that unless proving wrong, is still correct. As for @chet thing regarding fmt-reuse and numbered access, I choose to stop counting args at max(unumbered_occurences, highest_index) and re-use from there+1, and it sounds satisfactory. As you said, and I said many time, yes this thread is useless, but it has the virtue of brain dumping what's known at this time, for a future implementation that post bash 5.3 may consider. As far as I am concerned I really care is non mixed, and I am pretty sure the bash designer will implement a valid numbered access one day. > > And finally, to Andreas' comment which was what inspired me to continue > this relatively meaningless thread: > > | As long as NL_ARGMAX >= 999. > > Yes as you said there is no limit on the %num$, theorically, yet imposing a limit like this one would allow to know for sure how to nuke the fmt re-use, removing both the strtod() overflow, the malloc() failure on provisioning args, etc... a relativly modest limit of 4096 (NL_ARGMAX) could be a good idea. I think we covered most of the problematic for mix'n'match, so bash >5.2 can start their implementation with ideas. I would conclude with - When doing numbered don't focus only on %ndx$c only (ndx=index, c=conversion char) but remember that numbered width.prec do exist too. - if allowing mix and match numbered/unumbered then stays away from unumbered following a numbered mean the unumbered is last the numbered+1 this is tempting but wrong, i.e '%3$s %s' one would be tempted to say %s is equiv to %4$s, but the width.prec predate that, because then one must define what happen when index back, i.e '%4$s %s %2$s %s' what is the last %s? some will say 3, other will say 6, in all case it will be verbose doc to say something complicated, so my recommendation is to say non unnumbered start at 1 and increment at each unumbered, easy to remember and matching the case of fully unumbered and gaps are skipped over and ignored. With all this, bash designer, gentlemen start your engine!!! :-)
