3 ms·
> I wanted to write some wrappers for the standard commands that automatically did all this via `jq`. If you're not already aware of it, you may wish to check
by follower 3y ago
> I wanted to write some wrappers for the standard commands that automatically did all this via `jq`.
If you're not already aware of it, you may wish to check out `jc`[0] which describes itself as a "CLI tool and python library that converts the output of popular command-line tools, file-types, and common strings to JSON, YAML, or Dictionaries. This allows piping of output to tools like jq..."
The `jc` documentation[1] & parser[2] for `ls` also demonstrates that reliable & cross-platform parsing of even "basic" commands can be non-trivial.
[0] https://github.com/kellyjonbrazil/jc https://github.com/kellyjonbrazil/jc
[1] https://kellyjonbrazil.github.io/jc/docs/parsers/ls https://kellyjonbrazil.github.io/jc/docs/parsers/ls
[2] https://github.com/kellyjonbrazil/jc/blob/4cd721be8595db52b620cc26cd455d95bf56b85b/jc/parsers/ls.py#L187 https://github.com/kellyjonbrazil/jc/blob/4cd721be8595db52b6...
- pmarreck 3y agoThis is interesting, but I like neither the TUI nor the fact that it's written in Python, lol. My idea was to have namespaced wrappers for the commands which were designed to generate output as JSON and/or accept input as JSON. So for example "ls" would have a wrapper "qls" (queryable ls) or maybe "jsls" (json LS), etc. But in thinking about it, many questions remain- Would some of the structs or struct elements have types, like "file_path" or "file_name" for example? Like for example they do: > $ jc dig example.com | jq -r '.[].answer[].data' and my API would be more like: > $ jsdig example.com -- '.[].answer[].data' (which would then pass those additional arguments to "jq -r" without having to pipe) The core idea is that you can have seamless integration of structured pipe data with regular piped data without having to change shells.