Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0001771 [Issue 8 drafts] Shell and Utilities Editorial Enhancement Request 2023-08-07 19:22 2023-10-10 09:34
Reporter calestyo View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Applied   Product Version Draft 3
Name Christoph Anton Mitterer
Organization
User Reference
Section Utilities / printf
Page Number 3269
Line Number 111019
Final Accepted Text See Note: 0006470
Summary 0001771: support or reserve %q as printf-utility format specifier
Description Hey.

Hope that hasn't been asked for before and rejected, at least I couldn't find anything about it.

I propose considering to either support (in the sense of: conforming implementations must support it) or reserve (in the sense of: *if* a conforming implementation uses that format specifier, *then* it must be for the given purpose) the %q format specifier for the printf-utility as used e.g. by GNU printf or bash.

bash specifies it as:
> %q causes printf to output the corresponding argument in a
> format that can be reused as shell input.

GNU printf as:
> %q ARGUMENT is printed in a format that can be reused as shell in‐
> put, escaping non-printable characters with the proposed POSIX
> $’’ syntax.

I'm afraid I don't have access to that many other shells like from BSDs or so, but from what I saw after looking at some manpages, %q seems not to be generally supported, although not used for other purposes either.
(There are experts around here, who can probably tell much better about this.)


I'm also not sure how exactly it should be implemented:

1) One way would be to allow any quoting that is understood by the given shell,... this would for example allow $'...' quotes to be used, even now where they're (not yet) supported by POSIX. And of course any other custom quoting styles used by a shell might then be produced by that.

I guess it's obvious that (1) would be rather bad with respect to interoperability.


2) The better way would IMO be to allow only any quoting styles supported by POSIX.
An open question, to which I have no proper answer, would be whether any preference should be given or perhaps even any obligations should be made (like newline needed to being given as $'\n' or the like, but not literally).


The motivation for supporting %q is that it's IMO generally useful to have an out-of-the-box mechanism to safely quote input so that it may be reused as shell input.
Desired Action see above
Tags applied_after_i8d3, issue8
Attached Files

- Relationships
related to 0001774New Support ' <apostrophe> as a format specifier flag character in utilities 

-  Notes
(0006416)
chet_ramey (reporter)
2023-08-07 19:36

 1) is more or less moot; by the time %q comes anywhere near standardization, the $'...' quoting syntax will be part of an approved edition; and since that's the case, 2) is fine.
(0006417)
calestyo (reporter)
2023-08-07 19:46

 Well (1) would have been less because of $'...' but more to allow shells using any other custom quoting syntax in the produced %q-output.

But I really don't think POSIX should allow/encourage this :D
(0006418)
geoffclare (manager)
2023-08-08 08:46

 The C standard reserves all lower case letters in conversions for the printf() function, for future standardisation. It would not be a good idea to add a conversion specifier to the printf utility in POSIX that might end up clashing with printf() in future.

So if this is added (in Issue 9), it should be %Q not %q.
(0006420)
calestyo (reporter)
2023-08-08 14:28

 A I see... lower case letters for conversion specifiers are apparently reserved for future use in 7.31.11 Input/output <stdio.h>.

But POSIX already specifies %b for the printf utility, and on a quick search I couldn't find any reference in the C standard that this would be reserved.
Also there seem to be other (lower case) conversion specifiers, not standardised but still used by implementations (sigh), e.g. glib/uClibc/musl have: 'm'


Well %Q is already used by bash as follows:
> %Q like %q, but applies any supplied precision to the argument
> before quoting it.

But I guess that would be still compatible with %q.
GNU printf does not seem to use %Q.

%q is probably already used in many real world scripts... not sure how easy it would be to have the C folks exclude q (and perhaps also b) from their reservation?
(0006421)
geoffclare (manager)
2023-08-08 15:04

 > But POSIX already specifies %b for the printf utility

I don't know the history behind the choice of %b. An uppercase letter would have been a better choice, ensuring no possibility of a future clash with the C standard. We should avoid making the same mistake (if that's what it was) again.

> Also there seem to be other (lower case) conversion specifiers ..., e.g. glib/uClibc/musl have: 'm'

True, but those are in the C library printf() function, and it is reasonable to expect the C committee to check for existing uses in printf() implementations before choosing a new lowercase letter to standardise. I doubt they would do the same for printf utility implementations.

> %q is probably already used in many real world scripts

The same is true for many cases in the past where POSIX standardised a different syntax from existing practice, e.g. sort -k 1,1 instead of sort +0 -1. Over time, application writers switch over to using the new syntax.

> not sure how easy it would be to have the C folks exclude q (and perhaps also b) from their reservation?

Too late now for C23, but might be worth suggesting some exclusions for their next revision.
(0006422)
calestyo (reporter)
2023-08-08 17:10

 I don't have really any contacts to the JTC1/SC22/WG14 guys.. is there some easy accessible mechanism to bring up such suggestion with them?

Other than that, I'd be fine with both approaches:
- either concentrate on %Q straight away
- first ask C guys whether they'd be willing to assign %q for our needs (not sure whether there'd be any bigger use for the printf() family of functions to have the %q defined as we'd want it for the printf-utility)
(0006423)
eblake (manager)
2023-08-08 18:45

 C23 will be standardizing %b for binary literal output (0b1000 being the value 8, for example), and has recommended that %B be used for the same thing but with upper case (0B1000). Issue 8 does not have to deal with that because it is pinned to C17, but we WILL have to resolve that conflict in the future.
(0006424)
jsm28 (reporter)
2023-08-08 20:40

 Lowercase letters are used in C standard printf (C23 plus past TRs) as follows:

%a floating
%b binary
%c character
%d integer
%e floating
%f floating
%g floating
%h short
%i integer
%j intmax_t
%k TR 18037 (Embedded C) signed accum
%l long
%m not used in standard printf, but used in scanf in TR 24731-2, and in POSIX syslog
%n write number of written characters through pointer
%o octal
%p pointer
%q not used in standard, but pre-standard use to mean "quad" (long long) probably makes it unsuitable for adding to the C standard
%r TR 18037 (Embedded C) signed fract
%s string
%t ptrdiff_t
%u unsigned integer
%v not used in standard, available for future additions
%w %wN intN_t / int_leastN_t, %wfN int_fastN_t
%x hexadecimal
%y not used in standard, available for future additions
%z size_t

That is, the only good choices for characters not used at all in standard C and not likely to conflict with extensions or scanf use are 'v' and 'y', meaning that when standard C starts using one of those, it should also reserve the other for starting multi-character sequences for future use in standard printf. (Of course some future standard printf features may use sequences starting with 'w' that don't conflict with the existing uses of that letter.)
(0006425)
calestyo (reporter)
2023-08-08 20:53

 Seems others that have followed C printf-style conversion specifiers, have also already used letters that were previously "free" in C, e.g. Python uses "r" in an incompatible way.

And if C does assign upper case letters at need, then there's not much point IMO in using %Q over %q.
(0006439)
Don Cragun (manager)
2023-08-31 16:10

 On page 2793 line 92597-92599 section echo, add a sentence after the example:
However, this usage of %b with the printf utility is now obsolescent, and applications desiring escape sequence processing on non-XSI implementations should instead place escape sequences (other than \c) to be processed in the format string of the printf utility.


On page 3269 line 111000-111019 section printf, add OB shading to list item 7 (b conversion)

On page 3271 line 111104 section printf, change:
The %b conversion specification is not part of the ISO C standard; it has been added here as a portable way to process <backslash>-escapes expanded in string operands as provided by the echo utility. See also the APPLICATION USAGE section of [xref to echo] for ways to use printf as a replacement for all of the traditional versions of the echo utility.
to:
The %b conversion was originally added as a portable way to process <backslash>-escapes expanded in string operands as provided by the echo utility on XSI implementations. However, it will conflict with the next version of the ISO C standard, which is adding it for binary output of integers, and has consequently been marked obsolescent.


After page 3275 line 111227 section printf, add two paragraphs to FUTURE DIRECTIONS:
A future version of this standard may change the %b conversion to a binary conversion in alignment with the next version of the ISO C standard. It is recommended that implementations treat the "%#s" conversion specification, which is undefined by this standard, as a synonym for the current "%b" behavior; this can then be added in a future version of this standard once there is existing practice.


A future version of this standard may add a %q or %Q conversion (or both) to convert a string argument to a quoted output format that can be reused as shell input.
(0006440)
eblake (manager)
2023-08-31 17:48
edited on: 2023-08-31 17:49

 A related issue of supporting "printf %\'i 1000" for outputting "1,000" (in the right locale) was split off into 0001774; we did not feel it appropriate to include it in the Future Directions text changes of this bug.
(0006441)
eblake (manager)
2023-08-31 18:33

 https://debbugs.gnu.org/65659 [^] for a patch (GPL license) to GNU Coreutils printf that implements the %#s aliasing idea
(0006442)
eblake (manager)
2023-08-31 22:00

 As long as we are documenting things, Emanuele Torre pointed out that:

Also note that, in ksh93, %B is already used for something else.
It interprets its argument as a variable name, and dereferences it:
`printf %B PWD' is similar to `printf %s "$PWD"' (assuming PWD is a
string variable).

So if a future version of POSIX does change %b to output binary literals "0b0" (rather than undocumenting it altogether and leaving it up to implementations if they provide it as an extension), we'll have to be careful about whether to make %B do "0B0" or remain up to the implementation.
(0006443)
kre (reporter)
2023-09-01 01:23
edited on: 2023-09-01 01:43

 This sentence in the proposed resolution (in Note: 0006439) is useless,
and likely even dangerous:

    However, this usage of %b with the printf utility is now obsolescent,
    and applications desiring escape sequence processing on non-XSI
    implementations should instead place escape sequences (other than \c)
    to be processed in the format string of the printf utility.

If it were possible to simply use the format of printf as the output
string (as suggested there) %b would never have been added in the first place.

It isn't, and suggesting that "implementations should instead" is disingenuous
at best.

Not only is \c not supported in the format string, nor are escapes that
produce \0 (a literal nul) and the way that octal numbers to represent
characters are are represented differs.

And no, to be useful, "the implementation" cannot simply alter the
format from the %b form to the printf format form, the whole point is
to allow automatic use of old sys-v format "echo" arg lists as the
arg to %b - if one has to modify them, one by one, to conform with what
printf wants, one might as well just change them to be normal printf
executions, and nothing like %b is (or ever was, if that is the aim) needed
at all.

Next, if this %b nonsense has taught us anything at all, it is that we cannot
presume that the C people will take any notice at all of anything defined here,
and consequently, even hinting that %q (or %Q) might be added at some future
time is folly indeed - however unlikely we might think it that C will ever
standardise either of those, I suspect that unless we convince them (first) to
reserve those conversions for our use, if we define them, then so will they,
eventually - with a different meaning.

Last for here, while it doesn't really matter, I don't see the (current anyway)
point of ever adding the proposed C %b format to printf(1) - as an output format
it is useless unless there is something that reads it, and while I am guessing
that the C people will be adding a similar format to scanf(3) POSIX has no
equivalent (and no good way to use it if it did, other than perhaps as a sh
builtin). Currently none of the standard utilities I'm aware of accept 0b0101
as an input (of 5) so I see no point whatever being able to output that format.
Avoiding confusion with printf(3) formats might be worthwhile, might be,
perhaps - but printf(1) is already different from printf(3), if not
actually conflicting - lots of what printf(3) requires is either not
supported at all, or is optional in printf(1). They are different.
(0006444)
kre (reporter)
2023-09-01 01:40

 On the general question of %q/%Q - I have an implementation for NetBSD's
printf, but there is no way I was ever going to implement the nonsense that
is the bash %q (the way it uses the precision is absurd), so I never bothered
to commit it (more differing variants helps no-one, better just to not
have it at all).

I didn't know (until this discussion) that bash now has %Q - that looks like
what I implemented, so now I might switch from %q to %Q and commit that.
That's a rational way to do things.

And wrt the printf(3) function chars that are available for use by printf(1)
'v' and 'y' are not really candidates, as C might define those, but we can
usurp any of 'h' 'j' 'l' 'n' 'p' 't' and 'z' (and probably 'w'). I don't
know what 'k' and 'r' are intended to do, so perhaps those too.

None of those make any sense (as C defines them) for printf(1), none are
(in the standard) supported to mean anything at all, so we could give meanings
to any of that set, for operations that printf(3) will never want to perform,
should we so desire.
(0006445)
geoffclare (manager)
2023-09-01 08:40

 > This sentence in the proposed resolution (in Note: 0006439) is useless,
> and likely even dangerous:
>
> However, this usage of %b with the printf utility is now obsolescent,
> and applications desiring escape sequence processing on non-XSI
> implementations should instead place escape sequences (other than \c)
> to be processed in the format string of the printf utility.

The reason this sentence is there is because it is expected that whenever we mark something obsolescent we give advice about what to use instead. It certainly is not a straightforward change from %b, but the printf format string is the least bad suggestion the standard can make for an alternative.
(0006446)
eblake (manager)
2023-09-01 12:00
edited on: 2023-09-01 12:03

 > And wrt the printf(3) function chars that are available for use by printf(1)
> 'v' and 'y' are not really candidates, as C might define those, but we can
> usurp any of 'h' 'j' 'l' 'n' 'p' 't' and 'z' (and probably 'w'). I don't
> know what 'k' and 'r' are intended to do, so perhaps those too.

Coreutils and bash already accept 'h' and 'l' (although they currently effectively ignore size; on a 64-bit platform, 'printf %hhd $((1<<63)' outputs -9223372036854775808; if you want to limit an integral value to one byte, you must mask it yourself).

Bash already accepts 'jd', 'td', and 'zd' (it ignores the effective type, and treats them the same as bare 'd'); while Coreutils rejects those.

Bash already accepts 'n'; it must pair to a valid variable name, and assigns into that variable, as in:
$ foo=bar
$ printf a%n foo
$ echo $foo
1

Use of 'p' is not accepted by bash or coreutils at present.

C2x defines a namespace starting 'w'; deviating from that definition will likely be confusing.
(0006447)
stephane (reporter)
2023-09-01 12:29
edited on: 2023-09-01 12:32

 Re: Note: 0006439 (currently accepted text):

> However, this usage of %b with the printf utility is now obsolescent, and applications desiring escape sequence processing on non-XSI implementations should instead place escape sequences (other than \c) to be processed in the format string of the printf utility.

That's not limited to \c. \octal sequences are also different between %b/echo and printf format, where it's \0ooo in the former and \ooo in the latter. And of course, to output arbitrary strings, %'s would also need to be escaped.

C is a language from the 70s written especially to rewrite Unix in a portable way (by the authors of Unix). POSIX is ISO/IEC/IEEE... standard for a standard portable (Unix-like) operating system. I'd expect POSIX to trump C, and that a C standard change that breaks POSIX should be rejected, especially when better alternatives such as ksh93's printf %..2d (extensible to any base) already exist.
(0006448)
geoffclare (manager)
2023-09-01 14:00

 > I'd expect POSIX to trump C, and that a C standard change that breaks POSIX should be rejected

The formal relationship between the standards is exactly the opposite. POSIX defers to C and in any conflict between them, C wins. However, there is no real conflict here, because POSIX printf() does not currently have a %b conversion, only the printf utility does. What we are trying to prevent in the resolution of this bug is a future inconsistency between the POSIX printf() function and printf utility, given that Issue 9 printf() will have a %b conversion for binary output of integers.
(0006449)
chet_ramey (reporter)
2023-09-01 14:17

 Re: https://www.austingroupbugs.net/view.php?id=1771#c6443 [^]

I assume the proposed resolution intended "should instead use" to apply to the "applications" rather than "implementations."
(0006450)
stephane (reporter)
2023-09-01 17:55

 Sorry, just realising now that kre had already made all the points I made above (plus more that I also agree with), that was a hasty reaction to the resolution text which to me sounds unacceptable.

Re: Note: 0006448, that change to C's printf is clearly in conflict with a long-established feature of the POSIX printf utility, and it's also unnecessary. My point is that there's a much better way for printf(1) and printf(3) to output numbers in arbitrary bases that has been in use for almost 30 years (in ksh93). I'd rather C and POSIX specify that rather than that new %b that conflicts with long-standing and established %b of printf, the only way at the moment we have of portably and reliably expanding C-like (unfortunately, not exactly) \x escape sequences.
(0006451)
kre (reporter)
2023-09-01 18:37

 Re Note: 0006445 -- I understand the desire to indicate what should be used
as an alternative to anything being phased out, that's a good thing.

But that's only when the alternative actually works for the purpose, and here
it simply doesn't.

Perhaps a better question might be why we'd even consider deprecating
any functionality, which is all of: widely supported, used by applications,
and has no current standard alternative. Surely the proper procedure in
that case is to specify something that can be used as the alternative first,
and deprecate once that is available.

It isn't as if there's any urgent need for %b in printf(1) to ever act
like %b in printf(3) - even after the latter actually exists.
(0006452)
stephane (reporter)
2023-09-01 19:02

 I'll also argue that deprecating printf %b in the resolution of a ticket that is about:

> support or reserve %q as printf-utility format specifier

Is quite bad form. That makes that resolution likely to be overlooked by anyone having an interest in the matter.
(0006453)
geoffclare (manager)
2023-09-02 09:01

 > My point is that there's a much better way for printf(1) and printf(3) to
> output numbers in arbitrary bases that has been in use for almost 30 years
> (in ksh93). I'd rather C and POSIX specify that rather than that new %b

If this issue had come to light 6 months ago, it might have been possible to persuade the C committee to do that. Unfortunately, C23 is now set in stone.

> Perhaps a better question might be why we'd even consider deprecating
> any functionality, which is all of: widely supported, used by applications,
> and has no current standard alternative. Surely the proper procedure in
> that case is to specify something that can be used as the alternative first,
> and deprecate once that is available.

If we don't deprecate %b now, the alternative is to deprecate it in Issue 9 at the same time as adding %#s, and change %b in Issue 10, which would mean Issue 9 will have an inconsistency between the printf() function and the printf utility.

At least, those are the options if we honour the intention for draft 3 to have been feature-complete. I suppose we could also consider making this case an exception, given that we are "caught between a rock and a hard place", and add %#s in draft 4. There is already a patch for coreutils printf, but I think we would need buy-in from at least one other printf implementation to even consider doing that.
(0006457)
chet_ramey (reporter)
2023-09-05 16:24

 Is there anything except insisting that printf(1) and printf(3) handle the exact same set of format specifiers standing in the way of keeping %b as it is? That seems pretty dogmatic, consistency for its own sake.

I'm not going to throw away *that* much prior art. I can add %#s (and have), but I don't have any intention of changing %b.
(0006458)
kre (reporter)
2023-09-07 08:19

 It seems clear to me that no implementation is ever going to delete their %b
implementation, it is too entrenched. That means that even if POSIX were to
one day delete it from the standard, a likely response would be for a defect
report to be filed, requesting the addition of %b (as it is defined in I7, and
still in to be in I8) the day after any decision were made to remove it.

It would meet all the requirements - supported universally, well agreed
specification, and used by many applications - exactly the kind of thing
that should be in the standard.

Just avoid poking the bear, and creating controversy, for the sole purpose
of some kind of architectural purity (which we already don't have) between
printf(3) and printf(1). Drop the idea of listing %b as obsolete.

And given that, there's no need to even mention %#s, which is a poor choice
as an alternative for %b - %p would be a better idea, that one the C committee
cannot steal, as they have already given it a meaning, but one which is 100%
meaningless for printf(1), so is ideal to repurpose. But since we will be
keeping %b we don't need an alternative, so we can just keep %p in mind for
the future.

A better potential meaning for %#s (this paragraph isn't intended as anything
but to reinforce not suggesting it as an alias for %b - this is not currently
an actual suggestion, just a random thought) would be to use it to mean to
write a string of bytes, rather than a string of characters, the way that %s
used to be implemented (and still often actually is) before it was decided that
(almost) everything should be using characters, rather than bytes. Then %.1s
(for example) would mean to write one char from the arg string, %#.1s would
mean to write the first byte from the arg string (the same thing when chars and
bytes are equivalent, otherwise not).

Lastly, if you're looking for something to mark obsolete, because it makes a
conflict between printf(1) and printf(3), then %c would be the conversion to
select. In printf(3) %c takes an int, and writes that int as a character
(sure, in C, just an 8 bit codepoint, but still it is an int->character
conversion). In printf(1) %s is simply an alias for %.1s - except that with
%c it is unspecified whether an arg of '' causes %c to write \0 or nothing
(meaning applications cannot portably use %c if the arg string might be empty)
whereas for %.1s an arg of '' always generates nothing (so is always safe to
use). That is, %c as currently specified isn't actually useful for anything,
and we already have an alternative which works better.

But (sometime in the future) implementing the printf(3) version of %c, where
the arg is an integer (no need to restrict it to 8 bits) and writes the character from the current locale's character set with that code point,
would be useful, and would allow us to get rid of that disgusting hack of
first converting the code point to octal, and then using that octal number,
preceded by a \ as the format string (or a %b arg if \0 is the prefix) in
order to generate the character for a code point ... which only works for
8 bit characters.
(0006461)
calestyo (reporter)
2023-09-07 14:21

 I'd also think it would be pretty bad to undefined the current %b.

Especially as long is there is no guarantee that C won't ever use a certain patter - and it seems to me there is not.

From what I've had read in the C standard I'd have rather assumed they will only ever use lower case letters, but this is apparently not the case.

Until C would give a rock solid promise to never ever use %#s or the likes, it makes not real sense to use that.

Same, IMO, for %Q vs. %q.
(0006470)
geoffclare (manager)
2023-09-07 15:43
edited on: 2023-10-05 15:08

 After page 3275 line 111227 section printf, add two paragraphs to FUTURE DIRECTIONS:
A future version of this standard is expected to add a %b conversion to the printf() function for binary conversion of integers, in alignment with the next version of the ISO C standard. This will result in an inconsistency between the printf utility and printf() function for format strings containing %b. Implementors are encouraged to collaborate on a way to address this which could then be adopted in a future version of this standard. For example, the printf utility could add a -C option to make the format string behave in the same way, as far as possible, as the printf() function.

A future version of this standard may add a %q conversion to convert a string argument to a quoted output format that can be reused as shell input.
(0006474)
stephane (reporter)
2023-09-08 07:03

 Re: Note: 0006470

> A future version of this standard may add a %q or %Q conversion (or both) to convert a string argument to a quoted output format that can be reused as shell input.

%Q is already used for something else in ksh93 (that's also the /bin/sh of Solaris or Illumos at least) and ast's printf:

$ ksh -c '"$0" "$@"' printf '%Q\n' 123456
1d10h
$ ksh -c '"$0" "$@"' printf --man 2>&1 | grep %Q
    %Q    Convert number of seconds to readable time.
(0006475)
stephane (reporter)
2023-09-08 07:52

 Re: Note: 0006474
> %Q is already used for something else in ksh93 (that's also the /bin/sh of Solaris or Illumos at least) and ast's printf:

For the record, that %Q has been there since as far back as ksh93i in 1999, but not documented until 2021 (https://github.com/ksh93/ksh/commit/814b5c6890b897d0e7b2625a16a6513aa5d2789b), [^] so it's unlikely many people will have used it.
(0006476)
stephane (reporter)
2023-09-08 07:59

 Re: bugnote: 6475

Sorry, correction, documented since 2018 (https://github.com/att/ast/commit/7d5f68716e9eb70be3a77037f15a03fb3a5a1526) [^] in ksh2020 based on beta ksh93v- from AT&T, now abandoned. The 2021 commit above was on the ksh93u+m based on ksh93u+, the currently community-maintained version of ksh93.
(0006518)
geoffclare (manager)
2023-10-05 15:10
edited on: 2023-10-05 15:11

 Note: 0006470 has been updated to change:
A future version of this standard may add a %q or %Q conversion (or both) to convert a string argument to a quoted output format that can be reused as shell input.
to:
A future version of this standard may add a %q conversion to convert a string argument to a quoted output format that can be reused as shell input.
(0006520)
philip-guenther (reporter)
2023-10-05 20:01

 I'll add my support for kre's comment 000645 and calestyo's 0006461. This community is demonstrating a lack of wisdom in making some weak claim to %q when the C standard committee has already demonstrated that their priority is to define format specifiers that are best for C regardless of the consequences on POSIX printf(1).

POSIX should only give printf(1)-specific format specifier meanings for format strings which are *already* defined for printf(3) with meaning that are useless/inappropriate for printf(1). Doing otherwise at this point is cartoon-slapstick levels of self-harm.
(0006521)
gabravier (reporter)
2023-10-05 21:04

 I should say that it does indeed seem as though the conflicts with C's printf seem pretty irreconcilable - I think the only plausible solution that avoids any possible future conflict is to just embrace the fact that printf(1) currently conflicts with C and go with the proposed "have a -C flag for a printf that behaves like the one from C" route.
In particular, I think a -C option should absolutely never add any formatting capabilities whatsoever over what C provides.

This should leave printf(1) (when invoked without -C) free to add whatever extensions it might want to later without worrying too much about the potential of C showing up with a newfangled format character that screws with what POSIX wants to do, like what has happened here with %b.
(0006522)
oguzismailuysal (reporter)
2023-10-06 05:09

 Re: Note: 0006521

That still burdens the shell developers with implementing otherwise useless printf(3) features (floating point conversion specifiers, the c conversion specifier, length modifiers, asterisk as field width and precision) for no good reason. I believe there is nothing to be gained from achieving feature parity between printf(1) and printf(3) and that it would be much more beneficial to divorce them and let the two progress on their own.
(0006523)
geoffclare (manager)
2023-10-06 08:13

 > POSIX should only give printf(1)-specific format specifier meanings for
> format strings which are *already* defined for printf(3) with meaning that
> are useless/inappropriate for printf(1).

That strategy doesn't solve the %b conflict for Issue 9, but adding a -C option (or something equivalent) does. Once we have that, it means we can also add %q without fear of it causing a problem in the event that a future C standard adds it (as gabravier already pointed out).

> That still burdens the shell developers with implementing otherwise
> useless printf(3) features

You have that backwards. It's up to the shell (and stand-alone printf) developers to decide what conversions they want to implement with -C. Issue 9 will then be able to standardise them as existing practice.

- Issue History
Date Modified Username Field Change
2023-08-07 19:22 calestyo New Issue
2023-08-07 19:22 calestyo Name => Christoph Anton Mitterer
2023-08-07 19:22 calestyo Section => Utilities / printf
2023-08-07 19:22 calestyo Page Number => 3269
2023-08-07 19:22 calestyo Line Number => 111019
2023-08-07 19:36 chet_ramey Note Added: 0006416
2023-08-07 19:46 calestyo Note Added: 0006417
2023-08-07 23:39 salewski Issue Monitored: salewski
2023-08-08 08:46 geoffclare Note Added: 0006418
2023-08-08 14:28 calestyo Note Added: 0006420
2023-08-08 15:04 geoffclare Note Added: 0006421
2023-08-08 17:10 calestyo Note Added: 0006422
2023-08-08 18:45 eblake Note Added: 0006423
2023-08-08 20:40 jsm28 Note Added: 0006424
2023-08-08 20:53 calestyo Note Added: 0006425
2023-08-31 16:10 Don Cragun Note Added: 0006439
2023-08-31 16:13 Don Cragun Final Accepted Text => See Note: 0006439.
2023-08-31 16:13 Don Cragun Status New => Resolved
2023-08-31 16:13 Don Cragun Resolution Open => Accepted As Marked
2023-08-31 16:14 Don Cragun Tag Attached: issue8
2023-08-31 17:46 eblake Relationship added related to 0001774
2023-08-31 17:48 eblake Note Added: 0006440
2023-08-31 17:49 eblake Note Edited: 0006440
2023-08-31 18:33 eblake Note Added: 0006441
2023-08-31 22:00 eblake Note Added: 0006442
2023-09-01 01:23 kre Note Added: 0006443
2023-09-01 01:40 kre Note Added: 0006444
2023-09-01 01:43 kre Note Edited: 0006443
2023-09-01 08:40 geoffclare Note Added: 0006445
2023-09-01 12:00 eblake Note Added: 0006446
2023-09-01 12:03 eblake Note Edited: 0006446
2023-09-01 12:29 stephane Note Added: 0006447
2023-09-01 12:30 stephane Note Edited: 0006447
2023-09-01 12:32 stephane Note Edited: 0006447
2023-09-01 14:00 geoffclare Note Added: 0006448
2023-09-01 14:17 chet_ramey Note Added: 0006449
2023-09-01 17:55 stephane Note Added: 0006450
2023-09-01 18:37 kre Note Added: 0006451
2023-09-01 19:02 stephane Note Added: 0006452
2023-09-02 09:01 geoffclare Note Added: 0006453
2023-09-05 16:24 chet_ramey Note Added: 0006457
2023-09-07 08:19 kre Note Added: 0006458
2023-09-07 14:21 calestyo Note Added: 0006461
2023-09-07 15:43 geoffclare Note Added: 0006470
2023-09-07 15:45 geoffclare Final Accepted Text See Note: 0006439. => See Note: 0006470
2023-09-08 07:03 stephane Note Added: 0006474
2023-09-08 07:52 stephane Note Added: 0006475
2023-09-08 07:59 stephane Note Added: 0006476
2023-10-05 15:08 geoffclare Note Edited: 0006470
2023-10-05 15:10 geoffclare Note Added: 0006518
2023-10-05 15:11 geoffclare Note Edited: 0006518
2023-10-05 20:01 philip-guenther Note Added: 0006520
2023-10-05 21:04 gabravier Note Added: 0006521
2023-10-06 05:09 oguzismailuysal Note Added: 0006522
2023-10-06 08:13 geoffclare Note Added: 0006523
2023-10-10 09:34 geoffclare Status Resolved => Applied
2023-10-10 09:35 geoffclare Tag Attached: applied_after_i8d3

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker