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.
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 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.
--
``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
