3 ms·

dig example.com | jc --dig Seems a bit redundant. Maybe it should be the other way round? jc dig example.com Similar to how you do time dig example.

• chii 4y ago
  `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.
• DougBTX 4y ago
  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.
• berkes 4y ago
  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
  • kbrazil 4y ago
    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.