On Wed, Sep 06, 2023 at 09:03:29AM -0400, Chet Ramey wrote: > On 9/5/23 10:13 PM, William Bader wrote: > > Has bash ever had a change before that would break valid scripts? > > Yes, but I try to keep those to a minimum. > > > Could the printf format change be settable by a variable or by an option > > like the -e/-E in echo? > > It could, sure. Anything is possible. > > > Is it necessary for bash printf to match C printf? > > No. That's the heart of it. > > > I suppose that it is already decided. > > The austin group has decided what they'd like to do, and what they'd like > implementors to do. The question is whether or not people go along with it.
The Austin Group decided merely: If we do nothing now for Issue 8, then Issue 9 WILL have a conflict between printf(1) and printf(3). If we reach out to all developers now, we can start the discussion, and then by the time Issue 9 comes around (several years from now), we may have enough consensus to do any number of things: - Do nothing; printf(1) and printf(3) have incompatible %b - Declare that %b has implementation-defined behavior (shell authors have the choice on whether %b has old or new behavior) - Declare that %b is no longer standardized (but implementations can still provide it as an extension, using their choice of behavior) - Standardize %#s to do the same thing as %b used to do - Standardize 'printf -c %b 1' which parses its format string according to C23 rules (output "0b1"), while 'printf %b 1' remains the old way (output "1") - Your suggestion here (if enough shell writers agree on what to do, then Issue 9 can do that) But for that work, Issue 8 has to do something - it marks %b obsolescent, merely so that we have the option (not the mandate) to change its behavior in the future. It may turn out that there is enough resistance that the answer is no change to behavior, and we could even remove the obsolescent tag in Issue 9 (that is, make it formal that printf(1) and printf(3) intentionally diverge on %b). But marking something obsolescent in Issue 8 doesn't require any current shell to change, while still encouraging the discussion in case they do want to change. Adding %#s as a synonym to %b seems easy enough to do, regardless of what Issue 9 decides to do to %b, so the Austin Group mentioned that as a non-normative idea in the wording for Issue 8. But they are not requiring shell authors to implement it (even though GNU Coreutils has already expressed willingness to do it in /bin/printf). Meanwhile, implementing 'printf -c' to mean "interpret my format string according to C23 semantics" is also a viable idea, but one not mentioned in the current incantation of the Austin Group bug. But that's why the bug has a 30-day review period, to collect feedback comments on how it can be better worded before Issue 8 is finalized. -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org
