The following issue has been SUBMITTED.
======================================================================
http://austingroupbugs.net/view.php?id=1202
======================================================================
Reported By: kre
Assigned To:
======================================================================
Project: 1003.1(2016)/Issue7+TC2
Issue ID: 1202
Category: Shell and Utilities
Type: Clarification Requested
Severity: Objection
Priority: normal
Status: New
Name: Robert Elz
Organization:
User Reference:
Section: XCU 4 -- printf
Page Number: 3113
Line Number: 104118 - 104120, 104123 - 104126
Interp Status: ---
Final Accepted Text:
======================================================================
Date Submitted: 2018-08-29 19:26 UTC
Last Modified: 2018-08-29 19:26 UTC
======================================================================
Summary: printf %.Nb with \c in arg (more than N chars into
arg) behaviour unclear
Description:
When a %b format conversion specification is used with printf(1)
and the associated string arg contains a \c escape sequence, the
operation is that the character preceding the \c is the last one
printed (printf exits after printing that character).
The specification says that in other words, but that's the effect,
and that's clear.
What is not clear is whether the \c from the arg string needs to
actually be "written" for it to have this effect.
Example:
printf '%.2bX' 'a string\c'
Does this print "a X" (the first 2 characters of the arg, and then
as the \c was not used, continue with the remainder of the format
(the literal X here).
Or does the presence of the \c in the arg string cause processing to
stop (even though the \c was not "printed") in which case "a " should
be printed.
I only really have the builtin printf's in shells to test (and not all
shells use a builtin for it) so there are perhaps more interpretations
than I have seen, but:
Most shells builtin printf's (and NetBSD's /usr/bin/printf) seem to
adopt the 2nd approach. bosh (the only one I have actually seen) picks
the first. I think both are reasonable interpretations, as the standard
is not currently clear.
The version of the FreeBSD shell I have to test ignores the precision with
%b format conversions, but that looks to have been fixed earlier this
month,
and from reading their sources, the behaviour now appears to be the "most
shells" style.
ksh93 is just plain weird (or the version I tested) - it allows precisions
on %b formats ('printf "%.2b" "abcd"' prints "ab" as it should, but if
there's a \c in the arg string, the precision seems to be ignored,
('printf "%.2b" "abcd\c"' printf "abcd"). That can't be anything but a
bug.
The text can almost be read to imply the "most shells" format, from the
words (line 104123)
Bytes from the converted string shall be written
which could be interpreted to mean that the arg string should have its
escape sequences converted to actual characters first, and then written
as if the %b was %s ... if that's done (which is what I think most shells
actually do) then the \c will be seen during the conversion step, and
will cause further processing to end.
But there is no particular reason to read the text that way, the
conversion
of the arg string, and the output of the bytes, could easily proceed in
parallel, with bytes from the arg string that are not to be written not
being
converted (doing so is really just a waste of time - certainly for all the
escapes except \c).
Desired Action:
Add a new sentence after the sentence which concludes on line 104120 ...
If the \c is not reached during the processing of the string
operand (because a precision argument limits the number printed)
it is unspecified whether the effects of the \c, just indicated
apply, or whether the \c is simply ignored.
though I actually would expect that would be re-written to be something
that means much the same, but is better written!
Alternatively, if bosh builtin printf happens to be the only printf which
behaves the way it does, the added sentence could say
Note that the presence of a \c in the operand string shall have this
effect even if output from the converted operand string terminates,
due to a precision argument, before the \c is reached.
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
2018-08-29 19:26 kre New Issue
2018-08-29 19:26 kre Name => Robert Elz
2018-08-29 19:26 kre Section => XCU 4 -- printf
2018-08-29 19:26 kre Page Number => 3113
2018-08-29 19:26 kre Line Number => 104118 - 104120,
104123 - 104126
======================================================================
