I salute whoever chooses to use this and runs into the assumptions made by this tool that turn out to be wrong.

Good point. This reminds me of the Linux (Unix?) "file" program, and whichever hero(es) maintain it.

I wonder how they will address versions…

`aws s3 ls | jc —-aws=1.2.3`

What a nightmare.

Aws cli isn't the best example because it supports outputting json natively.

I'd expect this to not be a huge problem in practice because this is mostly for those well established unix cli tools of which the output has mostly ossified anyway. Many modern and frequently updated tools support native JSON output.

> Aws cli isn't the best example because it supports outputting json natively.

The s3 sub command annoyingly doesn’t. Which I’m guessing is the reason the GP used that specifically.

Use “aws s3api list-objects-v2”

https://docs.aws.amazon.com/cli/latest/reference/s3api/

You can, but it’s not nearly as nice to use. For starters you have to manage pagination yourself.

What about

jc 'aws sts get-caller-identity' | jq [..]

That way the aws process can be a subprocess of jc, which can read where the binary is and get its version automatically.

jc already has this, see ‘jc dig example.com’ in examples. They call it ‘alternative magic syntax’, but IMO it should be the primary syntax, while piping and second-guessing the previous commands parameters and version should be used only in exceptional cases.

That can get thorny, because it adds another level of shell-quoting/escapes, and that is a notorious vector for security problems.

In theory, if it could load something like ‘plugins’ (for example as separate shell commands) some of the maintenance effort could be offloaded to ‘plugin’ authors.

`jc` supports plugins:

https://github.com/kellyjonbrazil/jc#parser-plugins