Sounds a lot like Powershell, which returns rich objects instead of a text blob
Yup, powershell is mentioned in the references. Also, this tool can be used to bridge older unix commands into powershell objects (ConvertFrom-Json).
JC – JSONifies the output of many CLI tools
101–110 of 136 posts
Re: JC – JSONifies the output of many CLI tools
#102A 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…
This seems a general symptom of unix/POSIX command naming where commands have "always" been short names, and commands are expected to be short names.
It's something I appreciate about the powershell naming conventions. A lot of people mock the verbosity of the names of powershell commands and commandlets which require the "proper" name to be Verb-Noun qebab case monstrosities, but this was chosen for exactly the reasons of your pet peeve: short command names should be user aliases for work in a shell, and longer command names are great for avoiding namespace clashes in scripts and between users. The verbs and nouns create large (discoverable) namespaces.
For instance, this tool might be powershell named ConvertTo-ParsedJson. (ConvertTo-Json is an out of the box command that converts any powershell object to JSON.) It might suggest the user alias it by adding `Set-Alias -Name jc -Value ConvertTo-ParsedJson` but generally commands in powershell only offer such aliases as suggestions rather than defaults. (Though there are a lot of out of the box aliases for common powershell commands.)
It makes sense to me that powershell encourages long names first and allows and encourages users to have far more control over short aliases.
Re: JC – JSONifies the output of many CLI tools
#103Earlier 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.
Any metadata mechanism should be extensible IMO. For example sort and join care about ordering but they also care about column names.
Re: JC – JSONifies the output of many CLI tools
#104to 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.
on embedded rust is still much larger than c because rust links its stdlib statically.
Re: JC – JSONifies the output of many CLI tools
#105Re: JC – JSONifies the output of many CLI tools
#106Re: JC – JSONifies the output of many CLI tools
#107Earlier quoted context omitted.
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.
Yeah, I see now what you wrote. My coffeeless brain must have just seen "total ... of bytes". Carry on...
Re: JC – JSONifies the output of many CLI tools
#108Earlier 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…
That reminds me of something I've wanted for quite a while: A ringbuffer filetype. Similar to a named pipe file (see: fifo(7)[^1]), but without consuming the contents on read and automatically rotating out the oldest lines. Of course, there would be some complexities around handling read position as lines are being rotated out from under you. [1]: https://linux.die.net/man/7/fifo
> Of course, there would be some complexities around handling read position as lines are being rotated out from under you.
that seems solvable to me, but multiple simultaneous readers... that seems like it might be a bit more challenging...
Re: JC – JSONifies the output of many CLI tools
#109to 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 ;)
`jc` is available today as a compiled binary with all dependencies self-contained. The binaries and OS package installers are available under the GitHub Releases:
https://github.com/kellyjonbrazil/jc/releases
This is still python under the hood and not as small of a binary as I would like, but it does work.
Re: JC – JSONifies the output of many CLI tools
#110Is anyone aware of something similar but for the args? A database that maps a command to a schema for all it’s possible cli arguments?