Run these commands for a better demonstration:

    time echo | sleep 1

vs.

    /usr/bin/time echo | sleep 1

The former times the entire pipeline whereas the later only times the first command in the pipe.

This also gives the time of the entire pipeline (since the commands all begin together and only finish when the last command has completed):

echo | /usr/bin/time sleep 1

I'm pretty sure this is wrong.

As an example :

sleep 2 | /usr/bin/time sleep 1

This gives an output of "1 second" even though the entire pipeline took 2 seconds.

Ok you can wangle your way out of it. But if you're doing something like `grep "$something" | /usr/bin/time some_job` then generally you're fine.

Wouldn't the system/user time be wrong though?

The sleep sub-process of time is not part of the pipeline, however. It will exit after the requested time has passed.

It looks like

  /usr/bin/time foo |bar

would actually give the output of foo as input to bar, since the time statistics go to stderr.

Since it is not an error, what we really need is a stdmeta file descriptor:

http://unix.stackexchange.com/questions/197809/propose-addit...

I've been thinking a bit about this before and I think that not just one but a whole lot of additional streams would be useful. By default all commands would still use stdout and stderr only but you would be able to tell them to use other streams as well for their various data.

Furthermore, each stream should be possible to pipe to a different process if you wish independently of the other streams.

To a small degree this might be possible already with named pipes.

It is possible already - you can do `command 2>&4` to separate the output from one command in a pipeline into its own stream, then do `command2 <&4` to pull from the further down the pipeline.

I would like more pipes for each process.

This would allow many things, for example searching for multiple terms across all files in the whole file system in one go without opening each file more than once, and then grouping the different results together in accordance with the term that they matched.

Honestly this is one area where PowerShell kind of nailed it.

I still don't use it enough, but when it comes to scripting PS's objects beat the hell out of these

I just started playing around with IPC ideas with processes tellin each other which flags they would like: https://github.com/mrquincle/bipipes

I think socket pairs would be great for it.

Nothing implemented yet!

Just think of it as std dbg, not err

No, it wouldn't require special-case syntax. It could just pass it's argument to '/bin/sh -c'. You'd have to shell-escape the pipeline, though.

Yeah it does require special-case syntax. When using bash's built-in time, the command is executed exactly the same way as if you weren't using time, which means the command can set variables or define functions in the current shell. For example, you can say

  time foo=bar
  echo $foo

and it will correctly print out "bar". It can't do this if it executes the command in a subshell. Or similarly you can say `time cd /foo` and it will actually change the current working directory.

Yes, as a consequence, it also lets you do this:

    time {
      sleep 0.1
      sleep 0.2
    }
    # result is 0.3 seconds
 

which you obviously can't do with an external command. I wrote about that here:

https://lobste.rs/s/hwgt2h/usr_bin_time_not_command_you_thin...

The `time` syntax in combination with for loops or just shell functions is pretty useful as well.

That is merely an optimization though. You can simply

    time sh -c 'foo | bar'

But now you are timing the startup of `sh` as well.

...which (surprisingly) is a measurable amount. About 1 ms for `dash` and a whooping 9.5 ms for `bash` on a relatively slow CPU:

  pi@pi:~ $ time (for x in {1..1000}; do time echo | sleep 0.01; done 2>/dev/null)
  real    0m24.173s

  pi@pi:~ $ time (for x in {1..1000}; do time sh -c 'echo | sleep 0.01'; done 2>/dev/null)
  real    0m25.170s

  pi@pi:~ $ time (for x in {1..1000}; do time bash -c 'echo | sleep 0.01'; done 2>/dev/null)
  real    0m33.643s

1ms is on the order of process creation time, so not very relevant: The measured program itself requires process creation. Most programs run considerably longer than that (otherwise timing would not make much sense).

It's really not more than that: an optimization.

Wow — that is extremely surprising. I did not expect that behavior at all. Who the hell thought it was a good idea to let a builtin command absorb the pipe symbol?!

`/usr/bin/time -o foo_time.txt foo | bar`