`time` needs to be the one to exec the command because they need to know when the command they are timing starts. Therefore, `time` cannot use pipes, as by then, the command being timed would've already started!

`jc` doesn't need to know anything about the command producing the output - just the format of the output. So using a pipe and stdin makes a lot of sense.

Yes, that works, there are examples on the page like:

    $ jc dig example.com | jq -r '.[].answer[].data'
    93.184.216.34

It uses the first argument to infer the command output type.

Is "redundancy" that you have to provide --dig?

I can imagine `jc` having some detection built in, from which it determines the command/content it's being parsed. Doesn't seem to have it, yet, and I'm generally no big fan of "magic" like this, but it would remove the redundancy.

Having it as a pipe, allows for much more, though.

   some_expensive_command > out.log
   jc --expensive-cmd < out.log

Or

   hourly_dig.sh > example_com_records_$(date +%F+%s)
   cat example_com_records_* | jc --dig

Hi there - author of `jc` here. I originally intended to have auto-detection but put that on the backburner to focus on creating parsers, especially after introducing the magic syntax.

I did implement auto-detection for `/proc` file parsers so you can just do:

    $ cat /proc/foo | jc --proc

or

    $ jc /proc/foo

But you can specify each procfile parser directly if you want to as well.