Not to piss on anyones parade here, but grepping something out of a json structure is one of the most asked questions for jq as well. Of course json is nice, but if the goal is to simplify data extraction, I’m not sure much will be gained by this.
As far as reducing the toolchain necessary to extract the same data, this is a welcome addition.
I’ve never been able to successfully write a jq command without having to Google it. It is something so complex and I don’t do it often, so I just forget everything.
I hope they figure out something with more I tuitive syntax, something SQL-like that people can write without having to look at a manual.
Anyways, AI is here… pretty soon we’ll just translate natural text to whatever overly complex language there is.
I’m sure I’ll get replies of people saying jq is easy. It isn’t for me, right now I can t even remember how to filter and create associations between objects. I think I’ll just start writing small python apps to process JSON. A bit longer but at least I can maintain it. The only issue is that Python is too heavy… I’ll figure something out.
I’ve been thinking for a while that what we actually need is a modern shell language. Like a mix between python and shell. Imagine if you had native support to read a JSON using shell.
Edit: oh shit. Said all of this and then saw the comment below talking about Nushell. Today is a good day.
While jc is a great tool, and I’m definitely a fan, I believe the real solution to the overarching problem lies in a paradigm shift: see nushell
I actually use both! It’s so nice to just
jc git log
and then work with the data using nushell :)Oh that’s smart! And then nushell just handles the data for you…I might try that!
Nushell is so great! I’ve been using it for a couple years. It has completely replaced my need for tools like grep, sed, awk, etc. and because it handles JSON and so many other data formats natively I rarely even need to think about parsing.
I’ve always struggled with actually retaining knowledge on how to use the myriad tools you’d usually need to extract/parse data (awk, sed and friends) and this was a game changer. I don’t quite daily drive it just yet but when I do need it, it’s vastly more ergonomic.
Thank you for bringing up nushell, had never heard of it
The author it trying to solve non-existing problem with the tool that does not meet requirements that he presented himself.
$ ifconfig ens33 | grep inet | awk '{print $2}' | cut -d/ -f1 | head -n 1
Yeah, it’s awful. But wait… Could one achieve this a simpler way? Assume we never heard about
ifconfig
deprecation (how many years ago? 15 or so?). Let’s see atifconfig
output on my machine:ens33: flags=4163 mtu 1500 inet 198.51.100.2 netmask 255.255.255.0 broadcast 255.255.255.255 inet6 fe80::12:3456 prefixlen 64 scopeid 0x20 ether c8:60:00:12:34:56 txqueuelen 1000 (Ethernet) RX packets 29756 bytes 13261938 (12.6 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 5657 bytes 725489 (708.4 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Seems that the
cut
part of pipeline is not needed because netmask is specified separately. The purpose ofhead
part is likely to avoid printing IPv6 address, but this could be achieved by modifying a regular expression. So we get:$ ifconfig ens33 | grep '^\s*inet\s' | awk '{print $2}'
If you know a bit more about
awk
than onlyprint
command, you change this to$ ifconfig ens33 | awk '/^\s*inet\s/{print $2}'
But now remember that
ifconfig
has been replaced with theip
command (author knows about it, he uses it in the article, but not in this example that must show how weird are “traditional” pipelines). It allows to use format that is easier to parse and that is more predictable. It is also easy to ask it not to print information that we don’t need:$ ip -brief -family inet address show dev ens33 ens33 UP 198.51.100.2/24
It has not only the advantage that we don’t need to filter out any lines, but also that output format is unlikely to change in future versions of
ip
whileifconfig
output is not so predictable. However we need to split a netmask:$ ip -brief -family inet address show dev ens33 | awk '{ split($3, ip, "/"); print ip[1] }' 198.51.100.2
The same without
awk
, in plain shell:$ ip -brief -family inet address show dev ens33 | while read _ _ ip _; do echo "${ip%/*}"; done
Is it better than using JSON output and
jq
? It depends. If you need to obtain IP address in unpredictable environment (i. e. in end-user system that you know nothing about), you cannot rely onjq
because it is never installed by default. On your own system or system that you administer the choice is between learningawk
and learningjq
because both are quite complex. If you already know one, just use it.Where is a place for the
jc
tool here? There’s no. You don’t need to parseifconfig
output,ifconfig
is not even installed by default in most modern Linux distros. Andjc
has nothing common with UNIX philosophy because it is not a simple general purpose tool but an overcomplicated program with hardcoded parsers for texts, formats of which may vary breaking that parsers. Before parsing an output of command that is designed for better readability, you should ask yourself: how can I get the same information in parseable form? You almost always can.I kinda love it in theory.
Will be trying this out.
I do find it funny however that awk is lumped together with these small use case tools like sed, grep, tr, cut, and rev, since awk can be used to replace all of these tools and is it’s own language.
I don’t think the emphasis should be on simplicity, but rather on understandability (which long awk commands are not either).
If you give someone a bash script, they should be able to know exactly what the code will do when they read the script without having to run it or cat out the source it might need to parse. Using ubiquitous tools that many people understand is a good step.
Sadly awk is installed by default in most distros and tools like jq and jc would require installation.
AWK is fucking awesome!
And there is also Nushell and similar projects. Nushell has a concept with the same purpose as jc where you can install Nushell frontend functions for familiar commands such that the frontends parse output into a structured format, and you also get Nushell auto-completions as part of the package. Some of those frontends are included by default.
As an example if you run
ps
you get output as a Nushell table where you can select columns, filter rows, etc. Or you can run^ps
to bypass the Nushell frontend and get the old output format.Of course the trade-off is that Nushell wants to be your whole shell while jc drops into an existing shell.
deleted by creator
I rather like this idea.
Basically take all of the “let’s all write parsers now” work of handling the plain text output of *nix coreutils and bundle all of that work into a single tool. JSON is then the structured output data format, which should then replace all of the parsing work with querying work, which should be nicer and easier.
Backwards compatible, kinda unix-y, optional and should play nice with existing tooling. I hope it works out!
deleted by creator