Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

printf %q broken with size specifier #1477

Open
samliddicott opened this issue Apr 21, 2020 · 7 comments
Open

printf %q broken with size specifier #1477

samliddicott opened this issue Apr 21, 2020 · 7 comments

Comments

@samliddicott
Copy link

korn man page printf section says:
%q A %q format can be used instead of %s to cause the resulting string to be quoted in a manner than can be reinput to the shell.

$ printf '%q\n' "a'b"
$'a'b'

$ printf '%.2q\n' "a'b"
$'

definitely not suitable for re-input to the shell.

GNU Coreutils printf %q refuses to accept size specifiers for %q:
$ /usr/bin/printf '%.2q\n' "a'b"
/usr/bin/printf: %.2q: invalid conversion specification

bash has the same bug. Their response is "programmer error" "Don't do that" but I think the error is with the bash maintainers, and like the GNU Coreutils maintainers they should not let bash do that. If the shell maintainers who know about this bug won't "not do that" how can their users who don't know about it be expected to "not do that"?

%q should not renege on it's guarantees of suitability for re-use by the shell.

@jghub
Copy link

jghub commented Apr 21, 2020

first of all, this repo is no longer under active development, please see #1475 for a possible longterm alternative where to raise ksh issues in the future.

but to answer your question here nonetheless:

  1. I would agree that primarily %q is only useful and makes sense w/o a width qualifier.

  2. bash accepts the width qualifier just like ksh (but the output format is different, omitting the $' ...' encapsulation, so in your second example bash output is a\ ...)

  3. it seems a matter of taste, whether to view this behaviour (of either bash or ksh) as a bug. I would tend to also reply "don't do that (if you are not really really sure that you want it ...)". I admit that I never would have thought of providing a width qualifier with %q... but OTOH it might be that in some context for whatever reasons some user wants to get a leading substring from the quoted pattern (to paste it together with something else or whatever) and can achieve that with the width qualifier (rather than afterwards via explicit string subsetting).

so making ksh's printf change behaviour by erroring out in the presence of a width qualifier seems not a good idea in my view.

@jelmd
Copy link

jelmd commented Apr 21, 2020

The output is correct, w.r.t what gets requested: max. 2 byte of the string to be printed ($'a'b').

@jghub
Copy link

jghub commented Apr 21, 2020

sure. the question is "bug or feature" considering the declared purpose of the %q format -- that was the point the OP made.

@jelmd
Copy link

jelmd commented Apr 21, 2020

q refers to Quoted string, s to String, d to Decimal, ... Format specifiers are optional, allows one to format alias mangle the related operand. If one says, "I want max. 2 bytes of it", ksh just follows standards and prints not more than 2 bytes of it. Nothing wrong here.

@jghub
Copy link

jghub commented Apr 21, 2020

as said, I tend to agree but it remains matter of taste. and as the OP pointed out, gnu coreutils decided to handle it differently, seemingly (not tested myself)

@jelmd
Copy link

jelmd commented Apr 21, 2020

GNU tools, bash, ... - did they ever read any specs before implementing things [halfhearted] ? ;-)

@jghub
Copy link

jghub commented Apr 21, 2020

good point. let's leave it at that :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants