printf as a bash builtin vs an executable (behavior differences)

Question

I am trying to better understand printf so I read multiple pages on this command, but I also stumbled upon different behavior of %q directive. Namely, stated on this page:

What is the difference between printf of bash shell, and /usr/bin/printf? The main difference is that the bash built-in printf supports the %q format specifier, which prints escape symbols alongside characters for safe shell input, while /usr/bin/printf does not support %q.

---

It behaves different, but I may not fully understand what the sentence means. The following is different, yet I think equally effective:

info printf | grep -A 4 '%q'

An additional directive %q, prints its argument string in a format that can be reused as input by most shells. Non-printable characters are escaped with the POSIX proposed $'' syntax, and shell metacharacters are quoted appropriately. This is an equivalent format to ls --quoting=shell-escape output.

$ touch 'printf testing %q.delete'
# no output

$ \ls -l printf\ testing\ %q.delete
-rw-rw-r-- 1 vlastimil vlastimil 0 Jun 15 23:21 'printf testing %q.delete'

$ /usr/bin/printf '%q\n' printf\ testing\ %q.delete
'printf testing %q.delete'

$ printf '%q\n' printf\ testing\ %q.delete  # Bash builtin
printf\ testing\ %q.delete

---

Can anyone elaborate on these differences, maybe adding in which scenarios it is advised to use this or that one? Thank you.

Answer 1

The page you link is outdated. /usr/bin/printf is generally provided by coreutils, and in coreutils v8.25 support was added for %q to printf:

printf now supports the '%q' format to print arguments in a form that is reusable by most shells, with non-printable characters escaped with the POSIX proposed $'...' syntax.

coreutils v8.25 was released 2016-01-20, so at this point most desktop/server Linux systems would have support.

Answer 2

The main difference between Bash built-in and external printf is that Bash supports -v to assign the result to a variable. A command obviously cannot change shell variables in its parent.

Answer 3

Historically, each of these tools has been separately maintained (albeit with reference to standards and knowledge of each other). Assuming that we're referring to the /usr/bin/printf provided by Coreutils¹, the functionality is quite similar, as you've seen.

So we have two sort-of independent implementations of the same general idea, each with a long version history. There is only one good general conclusion from this information, that doesn't care about whether your system is upgraded and can be expected to remain correct in the future:

The main difference between the Bash built-in printf and external printf is that the Bash built-in printf is a Bash built-in, while the external printf is an external executable.

Of course, this has consequences:

• As Toby Speight says, the Bash builtin can implement shell-specific features (like the -v option) that are not possible for programs;

• a Bash script using a builtin avoids the overhead of spawning the printf executable (on the order of milliseconds, while the builtin can complete on the order of microseconds);

• the Bash builtin is only available in a Bash shell.

But these are, again, consequences of that general difference between builtins and programs. It has nothing in particular to do with printf.

Other shells may provide similar builtins. /usr/bin/printf is there as a fallback in case your shell doesn't have such a builtin. It's inherently slower (because a program has to start up) and harder to use explicitly (because you need to give the path name if you want to be sure of avoiding a builtin). But it offers greater (not perfect) compatibility - you can use it regardless of the shell, and it will work the same way regardless of the shell. Therefore, it's something you use when you need to.

_{¹ Nowadays, of course, it normally would be that. But anyone with sudo rights can compile something, name it printf and stick it in /usr/bin. Any distro maintainer can provide something different. And more practically, future systems might use a printf implementation from e.g. uutils by default instead.}

Answer 4

I think you're getting confused because of the statement "/usr/bin/printf does not support %q" in the first page you quoted. In fact, some versions of the external printf command do support the %q format specifier, but many do not. For example, on macOS, here's what I get when I try to use it:

$ /usr/bin/printf '%q\n' wibble
printf: illegal format character q

And on NetBSD:

$ /usr/bin/printf '%q\n' wibble
printf: %q: invalid directive

While on Linux, using the GNU coreutils version of /usr/bin/printf:

$ /usr/bin/printf '%q\n' wibble
wibble

You're apparently using the GNU version, so on your system it is supported (but it prefers slightly different quoting/escaping modes from bash's builtin).

Also, in your tests, you're including %q in the string (/filename) to be printed (i.e. printf testing %q.delete), but % sequences have no special meaning in those contexts; it's only in a printf format string that % introduces a format specifier.