(no title)
dietrichepp | 3 months ago
ls -l | awk '{print $3}'
That’s typical usage of Awk, where you use it in place of cut because you can’t be bothered to remember the right flags for cut.But… Awk, by itself, can often replace entire pipelines. Reduce your pipeline to a single Awk invocation! The only drawback is that very few people know Awk well enough to do this, and this means that if you write non-trivial Awk code, nobody on your team will be able to read it.
Every once in a while, I write some tool in Awk or figure out how to rewrite some pipeline as Awk. It’s an enrichment activity for me, like those toys they put in animal habitats at the zoo.
PopAlongKid|3 months ago
Before I learned Perl, I used to write non-trivial awk programs. Associative arrays, and other features are indeed very powerful. I'm no longer fluent, but I think I could still read a sophisticated awk script.
Even sed can be used for some fancy processing (i.e scripts), if one knows regex well.
nerdponx|3 months ago
Sort of! A lot of AWK is easy to read even if you don't remember how to write it. There are a few quirks like how gsub modifies its target in-place (and how its default target is $0), and of course understanding the overall pattern-action layout. But I think most reasonable (not too clever, not too complicated) AWK scripts would also be readable to a typical programmer even if they don't know AWK specifically.
Brian_K_White|3 months ago
I then re-wrote it in awk out of curiosity and it looked almost the same.
Crazy bash expansion syntax and commandline parser abuse was replaced by actual proper functions, but the whole thing when done was almost a line by line in-place replacement, so almost the same loc and structure.
Both versions share most of the same advantages over something like python. Both single binary interpreters always already installed. Both versions will run on basically any system any platform any version (going forward at least) without needing to install anything let alone anything as gobsmacking ridiculous as pip or venv.(1)
But the awk version is actually readable.
And unlike bash, awk already pretty much stopped changing very much decades ago, so not only is it forward compatible, it's pretty backwards compatible too.
Not that that is generally a thing you have to worry about. We don't make new machines that are older than some code we wrote 5 years ago. Old bash or awk code always works on the next new machine, and that's all you ever need(2).
There is gnu vs bsd vs posix vs mawk/nawk but that's not much of a problem and it's not a constantly breaking new-version problem but the same gnu vs posix differences for the last 30 years. You have to knowingly go out of your way to use mawk etc.
(1) bash you still have for example how everything is on bash 5 or at worst 4, except a brand new Mac today still ships with bash3, and so you can actually run into backwards compatibility in bash.
(2) and bash does actually have plugins & extensions and they do vary from system to system so you do have things you either need to avoid using or run into exactly the same breakage as python or ruby or whatever.
For writing a program vs gluing other programs together, really awk should be the goat.
benjaminogles|3 months ago
Plain text accounting program in awk https://github.com/benjaminogles/ledger.bash
Literate programming/static site generator in awk https://github.com/benjaminogles/lit
Although the latter just uses awk as a weird shell and maintains a couple child processes for converting md to html and executing code blocks with output piped into the document
packetlost|3 months ago
nmz|3 months ago
sudahtigabulan|3 months ago
Even you remember the flags, cut(1) will not be able to handle ls -l. And any command that uses spaces for aligning the text into fixed-width columns.
Unlike awk(1), cut(1) only works with delimiters that are a single character. Meaning, a run of spaces will be treated like several empty fields. And, depending on factors you don't control, every line will have different number of fields in it, and the data you need to extract will be in a different field.
You can either switch to awk(1), because its default field separator treats runs of spaces as one, or squeeze them with tr(1) first:
lelanthran|3 months ago
You don't have to use fields.
abhgh|3 months ago
tetris11|3 months ago
very fast, highly underrated language
I'm not sure how good it would be for pipelines, if a step should fail, or if a step should need to resume, etc.
meken|3 months ago
ketanmaheshwari|3 months ago
This pipeline may be significantly reduced by replacing cut's with awk, accommodating grep within awk and using awk's gsub in place of tr.
dietrichepp|3 months ago
(IMO, easier still to configure your editor to support breakpoints, but I’m not the one who chose to do it this way.)
nmz|3 months ago
stevekemp|3 months ago
unknown|3 months ago
[deleted]
RGBCube|3 months ago
https://nushell.sh - try Nushell now! It's like PowerShell, if it was good.
electricEmu|3 months ago
MIT licensed.
https://learn.microsoft.com/en-us/powershell/scripting/insta...
simoncion|3 months ago
So, I'm curious. What's the Nushell reimplementation of the 'crash-dump.awk' script at the end of the "Awk in 20 Minutes" article on ferd.ca ? Do note that "I simply won't deal with weirdly-structured data." isn't an option.
anthk|3 months ago
ryapric|3 months ago
esafak|3 months ago