On Fri, Feb 21, 2025 at 3:08 PM Chet Ramey <chet.ra...@case.edu> wrote:
> On 2/20/25 11:44 PM, Phi Debian wrote: > > > > > > On Thu, Feb 20, 2025 at 11:41 PM Chet Ramey <chet.ra...@case.edu > > <mailto:chet.ra...@case.edu>> wrote: > > > > A response to the question about printf supporting %n$ conversion > > specifications I posted to savannah. > > > > > > Thanx @chet, I didn't knew this thread. The thread say ksh93 is buggy, > > that's not what I observe with latest patches, but at time of the thread > it > > was probably buggy. > > Yesterday? > > > 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 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 :-) 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) 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. > > Yet it doesn't prevent an attempt to make it better, low priori I rekon, > > but if someone want to cut a patch there is no reason to veto it. Old > > script will still work, and new script could benefit it. > > It will happen, but not in bash-5.3. > I like that :-) > > > > 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 $((...)) At the moment %d fetch a string, applying an internal sh_eval(string) should be doable... but if that doesn't happen, no big deal... :-) So the ambiguity you are talking about is the problamatic of scanning the format string, and recognise the d, i, o, u, x, or X conversion char and accept the input args is a integer expresion 'string' :-) I would say it is an internal ambiguity, but at the user level it is not insane to think the string could be an integer expresion, at the moment is must be string that is a valid integer... why limiting the check to integer vs integer expression ? Cheers,
