bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] printf: add %#s alias to %b


From: Eric Blake
Subject: Re: [PATCH] printf: add %#s alias to %b
Date: Wed, 6 Sep 2023 11:03:25 -0500
User-agent: NeoMutt/20230517

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]