hoary: Time sees every argument as a program to run.

[Kent Nyberg]

It seems like if time tries to run every arguments given to it as a program to
run, :(

[Colin Watson (cjwatson)]

Isn't that the entire point of 'time'?

[Oskar Alexanderson (oskara)]

The problem here is that bash has some time functionality in itself. Thus, time
is a reserved word in bash, and GNU time is never executed. Running
/usr/bin/time with options works flawlessly.

Adding an alias to your .bashrc solves the problem:

alias time='/usr/bin/time'

You could also make a link and use another name for it:

sudo ln -s /usr/bin/time /usr/bin/gtime

[Matt Zimmerman (mdz)]

I don't see a bug here; time is working as designed and documented.

[Adam Buchbinder (adam-buchbinder)]

time is *not* working as documented. This has been reported twice here on Launchpad and at least once on Debian.

Here's how I got bitten by the bug:

1. I've used "time ./program" to time single runs before. I wanted to get memory usage information this time.
2. I executed "man time" to find out about its options.
3. I ran "time" in accordance with those options. It then gave me a confusing error message, and I was about to file a bug when I found this report and understood what was going on. (The memory usage options don't work anyway, but that's not really the point.)

Where did I go wrong? I'm not the only person to have been bitten by this, so there's clearly something wrong. Whether the man page should be for the bash builtin, or some other solution, the current situation is unintuitive, if not flat-out misleading, and this report will keep getting duplicated because users will go through the same steps that I did and end up scratching their heads in the same way that I did.

[Malcolm Parsons (malcolm-parsons)]

If you want to use the full featured version of time, you need to explicitly use that one, not the bash builtin.
This is not a bug.

[Adam Buchbinder (adam-buchbinder)]

But how is the user supposed to know that time is a builtin? Are they expected to look at the man page, think it's a bug, open the bug tracking system, and find out that it's a bash builtin? If this bug has been filed this many times, doesn't it make sense to think that the documentation is misleading? Isn't it standard practice to, if one is using a command and wants to know more about it, look up the man page for the command and expect it to be *about* that command?

[Malcolm Parsons (malcolm-parsons)]

> But how is the user supposed to know that time is a builtin?
$ type time
time is a shell keyword

> Are they expected to look at the man page?

Extract from the time man page:

       Users of the bash shell need to use an explicit path in order to run the external time command and not the
       shell builtin variant. On system where time is installed in /usr/bin, the first example would become
            /usr/bin/time wc /etc/hosts

[Misbach (matt-misbach)]

While technically this can be viewed as not a bug, if enough people think it's a bug then it should be one. Perception is reality. Who would want to make the argument that we don't want to "fix" this and make it easier to understand by removing the confusion?