Can you trust it? Cli tool output is not exactly stable. I thought that's why libxo exists?
JC – JSONifies the output of many CLI tools
41–50 of 136 posts
Re: JC – JSONifies the output of many CLI tools
#42to 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.
Re: JC – JSONifies the output of many CLI tools
#43Great idea, but sounds like a maintenance nightmare to me. Not only that many users will complain that their favorite CLI tool isn't supported, but also a new release of any of the supported CLI tools might break the support without any kind of warning, as I don't think changes to the (human-readable) output are considered major changes.
It doesn't even need a new release. jc can already fail because of details like the system-language. With my local language, on a simple output of ls -l, it's parsing
{"filename":"drwxr-xr-x 16 root root 4096 Oct 4 11:21 ."}
{"filename":".","flags":"drwxr-xr-x","links":16,"owner":"root","group":"root","size":4096,"date":"Oct 4 11:21"}
Re: JC – JSONifies the output of many CLI tools
#44A slightly related pet-peeve: I don't like it when "random" commands "squat" the two-letter domain, or worse, the one-letter domain: t, jq, jc etc. In my perfect world (which, obviously doesn't exist), commands from tools "in the wild" are at least three letters long. With historical exceptions for gnutools: preferably they'd take the three-letter space, but two-letters (cd, ls, rm etc) is fine. Two letter space outs…
I don't believe it's really an issue in practice, your `jc` alias will just take the priority and you can easily add one for jsonquery -> `path/to/bin/jc`.
I think good short command names can help adoption (like for ripgrep, fd) but it's true that we should have a race to squat all the 2 letter names.
Re: JC – JSONifies the output of many CLI tools
#45to 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.
Agreed but I would change it with "any compiled language that has no external runtime" and common shared libs dependencies. I don't care that a utility is written in Go, Zig, C++ or Pascal ;)
Re: JC – JSONifies the output of many CLI tools
#46to 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.
I would welcome POSIX shell or at least bash as an alternative to a compiled C/Rust/Go binary.
But yeah, for these types of utilities, relying on an external language runtime like Python/Node is pretty rough.
Re: JC – JSONifies the output of many CLI tools
#47I 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 the user. JSON is a bad choice here because it is hard to read.
In my opinion, something formatted with pipes, quotes and spaces would be better:
eth0:
ip: 127.15.34.23
flags: BROADCAST|UNICAST
mtu: 1500
name: """"Gigabit" by Network Interfaces Inc."""
Regarding idea to output data in /proc or /sys in JSON format, I think this is wrong as well. This would mean that reading data about multiple processes would require lot of formatting and parsing JSON. Instead or parsing /proc and /sys directly, applications should use libraries distributed with kernel, and reading the data directly should be discouraged. Because currently /proc and /sys are just a kind of undocumented API.
Also, I wanted to note that I dislike jq utility. Instead of using JSONPath it uses some proprietary query format that I constantly fail to remember.
Re: JC – JSONifies the output of many CLI tools
#48Didn't know about this, the HN dividend pays out again! When wrestling with sed/awk in trying to parse results of a shell command, I've often thought that a shell-standard, structured outpout would be very handy. Powershell[0] has this, but it's a binary format - so not human-readable. I want something in the middle: human- and machine-readable. Without either having to do parsing gymnastics. jc isn't quite that shel…
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.
>> 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.
That seems unnecessary. Traditionally, shells have always used text streams. JSON is just text that follows a given convention. Couldn't what you are describing be implemented by setting environment variables or using command line flags?
For example:
PREFERRED_OUTPUT_FORMAT="JSON"
--output-format="JSON"
--input-format="JSON"
Tools that can generate and consume structured text formats are a good idea, but they should be flexible enough that they can even work with other tools that have not been written yet.
"This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface." --Doug McIlroy
Re: JC – JSONifies the output of many CLI tools
#49Earlier 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.
>> 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. That seems unnecessary. Traditionally, shells have always used text streams. JSON is just text that follows a given convention. Couldn't what you are describing be implemented by setting environment variables or using command line flags? Fo…
I don't follow. JSON is not really readable. I don't want to see JSON output ever except for script debugging. I want to see well formatted output. But at the same time I want to be able to write something like
ip a | filter "[].address like 192.*"
You suggesting that I should write `PREFERRED_OUTPUT_FORMAT=JSON ip a | filter "[].address like 192.*"` but that's really verbose and error-prone. It might work for scripts, but for ad-hoc shell I don't like this approach. Ideally programs should be able to communicate between pipes for their preferred formats.
Re: JC – JSONifies the output of many CLI tools
#50I 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…
>> something formatted with pipes, quotes and spaces would be better
How well would this format handle deeply nested structures? It seems like it would require a lot of space characters compared to nesting open and close characters: {} or () or []
How would escaping pipes, quotes, and spaces work to represent those character literals?
There are already numerous structured text formats: JSON, XML, S-expressions, YAML, TOML, EDN, and many more. Wouldn't this be yet another format? (https://xkcd.com/927/)