If anything, though, that's a good reason for a tool like this to exist rather than have every script that depends on these tools use their own, often hacky, parsing of the output.
[1] "WARNING: apt does not have a stable CLI interface. Use with caution in scripts."
{"filename":"drwxr-xr-x 16 root root 4096 Oct 4 11:21 ."}
instead of {"filename":".","flags":"drwxr-xr-x","links":16,"owner":"root","group":"root","size":4096,"date":"Oct 4 11:21"}
with LANG=US. This makes it really hard to trust such a tool.Any custom parser of ls output would potentially have the same problem. Of course, it can be improved though – for example by looking at LANG – and it would be nice for such improvements to get into `jc`, so that other tools can rely on it at least more than doing the parsing directly themselves.
It's not unheard of for tools to require `C` locale for proper parsing:
$ LC_ALL=C ls -l | jc --ls
This is one of many inherent issues with using unstructured text as an API. That's why I believe there should be a JSON (or at least some other widely used format[1]) option for tools that have output that would be useful in scripts.[0] https://github.com/kellyjonbrazil/jc#locale
[1] formats should have good library support across many languages and nice filter/query capabilities from the command-line