Elegant, but not something you should ever use outside of ad-hoc situations.
I think this is more comprehensible, and is also more robust because it actually specifies the field you're looking for rather than just any line with quotes:
gawk -F'"' '/^ name:/ {print $2}' appVersion.gradle
(hacker news is clobbering the spaces after ^)
Awk is such a weird tool--it's powerful and so few people know how to leverage it.
Yesterday, someone in chat wanted to extract special comments from their source code and turn them into a script for GDB to run. That way they could set a break point like this:
void func(void) {
//d break
}
awk -F'//d[[:space:]]+' \
'NF > 1 {print FILENAME ":" FNR " " $2}' \
source/*.c
source/main.c:105 break
source/lib.c:23 break
(One of the other cases I've heard for using Awk is for deploying scripts in environments where you're not permitted to install new programs or do shell scripting, but somehow an Awk script is excepted from the rules.)
Awk, like vim, is a tool I love dearly that I absolutely would never recommend someone else learn. It’s like a form of mental illness but it’s so lodged in my brain and I’ll give it up when they put me in the grave.
Off-topic, but I _love_ the "sidenote" format for footnotes. I've been meaning to implement that in my own blog for a while, now. I'll check out the source for inspiration.
Do not do this in awk when the same in sed would be easier to read.
But also do not match this data format in the first quote. Match "name:" instead if that is what you mean. This makes the intention clear.
For matching text, just use grep is that is what most people would expect:
grep -m 1 "name:" appVersion.gradle | grep -o "[0-9.]"
Yeah, this just proves to me that the intuitive shell tools are way better. I'll keep all the heads, tails, cuts, and trs, etc.
Wonderful. My old license plate was awk sed.
As others here pointed out: this is bad awk.
I think good awk scripts lie somewhere between "This is atrociously overfit to this file" and "this is so general you should have done it in python/perl/etc".
Of course there are legitimate uses for both super-specific and super-general awk scripts, but finding the right compromise is what makes a good awk script. You want your script to be concise yet robust to changes in the input files. Also, readability and maintainability are really important if you plan to add it to an important script.
Short awk != good awk.
> This is really such a gorgeous piece of code. Clever and poetic.
I suppose that is subjective, but I think this is terrible code.
The fact that someone had to write a lengthy blogpost to figure out what it was doing should be an obvious warning against it.
Write code for readability / comprehensibility.
Too much text to explain what could have been explained clearly in 3-4 sentences. Making simple things complicated and then writing a long essay with dramatic phrases is a disservice to awk.
Awk strikes me as a marvelous text parsing tool that too few understand.
$0=$2 sounds a lot like my wallet recently...
takes 2 dollars and spends it!
Here are some more learning resources:
* https://backreference.org/2010/02/10/idiomatic-awk/ — how to write more idiomatic (and usually shorter and more efficient) awk programs
* https://learnbyexample.github.io/learn_gnuawk/preface.html — my ebook on GNU awk one-liners, plenty of examples and exercises
* https://www.grymoire.com/Unix/Awk.html — covers information about different `awk` versions as well
* https://earthly.dev/blog/awk-examples/ — start with short Awk one-liners and build towards a simple program to process book reviews