131–136 of 136 posts
Earlier quoted context omitted.
Not being snarky, why not python over perl? what makes perl better for scripts?
By the time you figure out which env you need to be using with python, you’ll forget why you needed it.
Earlier quoted context omitted.
If you are comparing Awk vs Perl for scripts, I'd prefer Perl (or Python). This post is about short one-liners for ad hoc use cases. I prefer sed/awk over Perl for such cases. Though, if you already know Perl, you could continue using it instead of having to learn more tools.
Do all systems still come with Perl baked in these days? If so I could see reaching for that over awk/sed. If I have to install a runtime I may as well just reach for Python
Sed and Awk are part of POSIX, and maybe more importantly also part of Busybox. They're almost always available when Perl is available, while the reverse is not true.
I love awk, and I find myself reaching for it a fair bit. One of the main things I use it for is “sed with state,” so for things like matching on a line, but only if it was preceded by some other line. I find this to be really useful for creating one-off linters, for example I made one recently to check all our migration files for CREATE INDEX without CONCURRENTLY on a particular set of very large tables where it wou…
One of these days I need to get around to learning awk. In the meantime, I've learned some of the deeper, stateful, features of sed. For instance, you mentioned wanting to only output a line if it was preceded by another. Here's a sed command that does so: sed -ne 'x' -e '/PREV/ {x; /CURR/ p; x}' > echo -e "PREV\nCURR\nCURR\nCURR\nPREV\nRED" | sed -ne 'x' -e '/PREV/ {x; /CURR/ p; x}' CURR This uses sed's hold buffer.…
Saddens me to see people selling crappy "e-books" or whatetver on text processing on HN. Compared to the older generations that used UNIX, the level of knowledge is lacking. IMHO.
This book from Tim Oreilly is an old favourite and has one of the nuttiest explanations of the hold space. See page 375.
https://www.oreilly.com/openbook/utp/UnixTextProcessing.pdf
https://web.archive.org/web/20230514225639if_/https://www.or...
As a NetBSD user, I found this books useful; all the utilities explained in it are still in the NetBSD userland.
Earlier quoted context omitted.
Why is that cringe? They genuinely probably came across awk before perl (I know I did, I read "The AWK Programming Language" and then went on to "The C Programming Language"). Having that said, awk is great and it's been the same for decades and available on every system (the same can't really be said about perl).
>> awk is great and it's been the same for decades and available on every system (the same can't really be said about perl). The only issue with AWK is that there are many implementations and they are not always compatible with one another: https://www.gnu.org/software/gawk/manual/html_node/Other-Ver... I have ported AWK scripts from legacy Unix systems to Linux and ran into incompatibilities that required some adjus…
There are other variants, yes, but in virtually every case these are fully POSIX compliant and/or have a POSIX mode.
(And in truth, gawk is the only non-fully-POSIX awk I've encountered --- it extends standard AWK with asort and the "'" formatting modifier (which prints localised htousands separators in numeric data).
Programmes written for any one awk, if using POSIX features only, will run on any awk.
Many small / embedded systems (think routers, stock Android, or any POSIX-only Unix variant) must have awk, but often don't include Perl.
You'll also find variants of Perl, though the relative stasis of that language make this less an issue now than in the '90s and aughts.
What is better? Starting with awk or sed?
(I have a set of scripts I use to parse NOAA's weather web page to plain text, and ended up resorting to both sed and awk in the process, and haven't yet tried to simplify that to a single script.)
Sed is usually used for simple text substitutions and manipulations.
Awk has built-in record and array concepts, as well as more standard programming constructs (loops, if/then, case/switch, printf, and external system interfaces (launching and/or reading from external programmes).
My view is that the tools overlap considerably, but also complement one another strongly.
Earlier quoted context omitted.
I sincerely doubt unless you are writing shell all day every day that you will get a decently complex working one liner out faster than GPT4.
Right, but you are bending the argument to your will. What is a "decently complex one liner"? If it's decently complex, then it's probably not a one liner, so indeed chatgpt may be faster. If it's a one liner, then it's probably not complex, so I would be quite confident in being faster than chatgpt. The reality is, 99.9% of one liners are just series of pipes and filters to extract specific fields from an output, an…
SQL is a great example too where I will use an AI even though it’s not necessary. I’ve probably written many tens or hundred thousands of lines of SQL in my life and I would still prefer to just toss my requirements into an AI and have it write the query for me so I don’t have to cross reference things and look up syntax. Easier to do that and iterate on it once or twice than comb through some bigquery or Postgres docs because I can’t remember that particular flavor of sql today