printf does not implement `%Q`, and does not properly handle `%q`

[Skyb0rg007]

There are a few incompatibilities between brush's printf and that of bash.
I understand from #854 that some of these issues can only be fixed through upstreaming to uucore, so I only highlight errors here that I believe can be fixed without changes to uucore.

Issue 1: %Q is not implemented

The printf code special-cases on %q: it can also match %Q with no changes (%Q only differs when it comes to handling precision).

Issue 2: %q does not accept (and ignore) specifiers

The implementation should ignore all precision specifiers: instead of checking fmt == "%q", it should check that fmt[0] == '%' && fmt[fmt.len()-1] == 'q' (or something similar).

Issue 3: %q performs the wrong quoting for strings with spaces

The %q specifier should use backslashes to escape characters instead of using single quotes.

Issue 4: %#q is not implemented

The current quoting method (always using single quotes) is the alternate quoting mechanism.
Handling the full parsing of the %q format is likely annoying without upstream support, but just matching %#q is hopefully not too bad.

Transcript

$ brush -c 'printf "%q\n" "foo bar"'
'foo bar'
$ bash -c 'printf "%q\n" "foo bar"'
foo\ bar

$ brush -c 'printf "%2q\n" "foo bar"'
error: printf: printf: printf parsing error: %2q: invalid conversion specification
$ bash -c 'printf "%2q\n" "foo bar"'
foo\ bar

$ brush -c 'printf "%#q\n" "foo bar"'
error: printf: printf: printf parsing error: %#q: invalid conversion specification
$ bash -c 'printf "%#q\n" "foo bar"'
'foo bar'

$ brush -c 'printf "%Q\n" "foo bar"'
error: printf: printf: printf parsing error: %Q: invalid conversion specification
$ bash -c 'printf "%Q\n" "foo bar"'
foo\ bar

[reubeno]

Thanks for the detailed report, @Skyb0rg007!

Issue 1

%Q is not implemented

Good call-out. Agreed that we can safely treat "%Q" the same as "%q".

Issue 2

%q does not accept (and ignore) specifiers

The current hack "special case" was intentionally scoped to avoid getting into parsing the format string, at least for now. To handle most additional cases, we'd need to get into this. The logic you suggest would silently match against something like "%s %q". For now, I'd rather let those cases go through to uucore. At the worst, at least for %q, the wrong quoting will come back but it won't omit the other formatted components.

Issue 3

%q performs the wrong quoting for strings with spaces

If you're seeing single-quoted strings come back from %q, then it's because uucore (our upstream dependency) is the one that's formatting it. It does implement %q but doesn't use backslash-escaping. The reason we specially handle %q was to use backslashes instead. The example you provide didn't match our special case because it's got a \n at the end and we're doing a straight-up == comparison. We could consider adding "%q\n" as a special case if there's evidence that will address some legitimate issues you or other users are hitting. The main reason we ended up adding the existing special cases was to unblock some common bash-completion code paths.

Issue 4

%#q is not implemented

That's a good call-out; I wasn't aware of the alternate form. Since uucore already seems to support single-quote-style %q, I suppose we could search/replace %#q => %q before calling into it. That would miss more interesting use like %#4q, though.

Ultimately we should really see if there's a way to collaborate upstream to avoid these brittle special cases. At minimum it would be great if we could find a way to extend it for our own purposes with additional "custom" (for bash/brush) format strings without needing to outright fork-and-maintain it.

[reubeno]

...and in case it wasn't clear above, we really appreciate you looking so closely into this issue as to understand why the code was doing the odd things it was doing 😄

[Skyb0rg007]

One option is to inline the parse_spec_and_escape function. Then you can match fixed-length specifiers like %q, %Q, %#q, %#Q, and %n at any point in the format string.