Here’s a short puzzler for GNU/Linux command line nerds:
Why, indeed? To clarify things a little bit:
time is a reserved keyword in Bash and unless you explicitly call the
/usr/bin/time program, Bash will execute its internal timing command (see http://www.gnu.org/s/bash/manual/html_node/Pipelines.html#Pipelines, http://linux.die.net/man/1/time, and http://www.gnu.org/s/bash/manual/html_node/Shell-Builtin-Commands.html#Shell-Builtin-Commands). Well, at least that was what I thought until I encountered the example above some time ago, when I was trying to accomplish something on the command line.
Apparently, if the
time is not the first token on the command line then the built-in timing function of Bash is not executed. So if you want to change the collation as well as use the built-in timing function you have to do the following:
Another question that comes to mind: Does changing LC_COLLATE lead to some special execution environment? Does it change how Bash interprets its reserved keywords and built-ins? Well, to examine another example, take this:
help is also a Bash built-in, but if you go and create a dummy
/usr/bin/help and then try to run (e.g. in your home directory)
LC_ALL=C help alias, you are going to see that Bash executes the built-in
help and does not try to run the program in
It seems like the
time built-in has a very special situation and this creates a quirk in Bash semantics. This is not somehing that will bite you regularly, but if you thing Bash as a programming language and the command line as its REPL (Read-Eval-Print-Loop) environment (such as the REPLs for Lisp, Ruby, Python, Scala, etc.), then such inconsistencies in the semantics of a programming environment can be pretty surprising and sometimes even annoying.
*: Thanks to Debian developer Recai Oktaş for this example test.