Have a parseable output is great. What would be more incredible is to have a parseable output with a schema definition and/or formal grammar of some sort.
JC – JSONifies the output of many CLI tools
71–80 of 136 posts
Re: JC – JSONifies the output of many CLI tools
#72Have a parseable output is great. What would be more incredible is to have a parseable output with a schema definition and/or formal grammar of some sort.
Schemas are provided on linked page near definitions of parsers.
Re: JC – JSONifies the output of many CLI tools
#73See also: * "Bringing the Unix philosophy to the 21st century (2019)" ( https://blog.kellybrazil.com/2019/11/26/bringing-the-unix-ph... ) - https://news.ycombinator.com/item?id=28266193 238 points | Aug 22, 2021 | 146 comments * "Tips on adding JSON output to your CLI app" ( https://blog.kellybrazil.com/2021/12/03/tips-on-adding-json-... ) - https://news.ycombinator.com/item?id=29435786 183 points | 11 months ago | 1…
If you're bringing that up, then this is the place to spread the word about my dream of a stdmeta file descriptor. https://unix.stackexchange.com/questions/197809/propose-addi... Just like we have stdout and stderr, header lines such as those produced by `ps` should be printed to stdmeta. Curl is the worse offender here, outputing meta lines to stderr instead of stdout. A stdmeta file descriptor would make it clear w…
If we're adding standard output fds, maybe it would be a useful time to define any mechanism for consumers of those fds to discern the total ordering of bytes written to the three of them.
Re: JC – JSONifies the output of many CLI tools
#74I think that JSON is a bad choice here. It is obvious that CLI commands should produce machine-readable output because they are often used in scripts, and accept machine-readable input as well. Using arbitrary text output was a mistake because it is difficult to parse, especially when spaces and non-ASCII characters are present. A good choice would be a format that is easily parsed by programs but still readable by t…
Hi there - `jc` author here. `jc` can also output in YAML format with the `-y` flag. It is fairly trivial to add other options in the future since `jc` just turns the text into objects which can be serialized to many different formats.
For example:
% jc -y date
---
year: 2022
month: Nov
month_num: 11
day: 3
weekday: Thu
weekday_num: 4
hour: 9
hour_24: 9
minute: 0
second: 22
period: AM
timezone: PDT
utc_offset:
day_of_year: 307
week_of_year: 44
iso: '2022-11-03T09:00:22'
epoch: 1667491222
epoch_utc:
timezone_aware: falseRe: JC – JSONifies the output of many CLI tools
#75dig 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.com
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 Or hourly_dig.sh > example_com_record…
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
$ jc /proc/foo
Re: JC – JSONifies the output of many CLI tools
#76Earlier quoted context omitted.
Shell would benefit from Content-Type/Accept headers. Like you can specify that cat accepts text and jq accepts Json. Then `ip a` would output corresponding type automatically.
Someone on this site suggested that programs open another filehandle along with stdout and stderr (stdjson) for their json output which struck me as a way to make this work in a backwards-compatible fashion.
Even just a generic stdmeta would go a long way to defining _what_ is being output. Curl is the worst about this.
https://unix.stackexchange.com/questions/197809/propose-addi...
Re: JC – JSONifies the output of many CLI tools
#77Can you trust it? Cli tool output is not exactly stable. I thought that's why libxo exists? https://github.com/Juniper/libxo
Another vote for something like libXo as the better solution. This thing is just passing the parsing problem of interacting with an unstable API to someone else and hoping they maintain theirs better than you would maintain yours.
Re: JC – JSONifies the output of many CLI tools
#78Earlier quoted context omitted.
If you're bringing that up, then this is the place to spread the word about my dream of a stdmeta file descriptor. https://unix.stackexchange.com/questions/197809/propose-addi... Just like we have stdout and stderr, header lines such as those produced by `ps` should be printed to stdmeta. Curl is the worse offender here, outputing meta lines to stderr instead of stdout. A stdmeta file descriptor would make it clear w…
If we're adding standard output fds, maybe it would be a useful time to define any mechanism for consumers of those fds to discern the total ordering of bytes written to the three of them.
WC has a "character" flag that really just counts bytes:
$ echo דותן | wc -c
9
$ foo 3>&1 > /dev/null | wc -cRe: JC – JSONifies the output of many CLI tools
#79Earlier quoted context omitted.
If we're adding standard output fds, maybe it would be a useful time to define any mechanism for consumers of those fds to discern the total ordering of bytes written to the three of them.
WC has a "character" flag that really just counts bytes: $ echo דותן | wc -c 9 Note that each letter is two bytes, and the newline is an additional byte. So you could pipe (or tree) to wc to count bytes. For a hypothetical stdmeta on fd 3, that might look like this (piping stdout to devnull): $ foo 3>&1 > /dev/null | wc -c
I'm not sure what you are answering. I am writing about the thing where some programs intentionally write different byte streams to stderr and stdout that will be interleaved a certain way if stdout and stderr turn out the be the same thing, but if the user wishes to distinguish which bytes were written to which stream, they can no longer recover the correct interleaving of the bytes.
Re: JC – JSONifies the output of many CLI tools
#80to make this great tool truly universal, it has to be written in c instead of python these days, then provide python|javascript|etc bindings if possible. I'd like to use it on embedded systems, where python is too large to fit. this tool can be widely deployed just like awk|sed|etc but it has to be in C for that.
Replace C with Rust.