News for hackers. Stuff that matters.
Re:The State of the Awk (2020) by anthk on Thursday January 19, 2023 @06:35AM (#34439227)
Anything too big to be coded with AWK should be done in Perl. Nothing bad about that. Perl it's almost a sed/awk/sh replacement when shell scripting based code gets clunky.
Re:The State of the Awk (2020) by jabl on Thursday January 19, 2023 @07:05AM (#34439445)
IMHO the nice thing about sed&awk is that a quick cheatsheet that covers most usage fits nicely on one page. Perl, in contrast, is more a 'proper' language and the Camel book is a pretty chunky tome. If you're going through all the trouble of learning a language in that space, you might as well go with something like python. Though admittedly python isn't a very good sed/awk replacement.
Re:The State of the Awk (2020) by kqr on Thursday January 19, 2023 @07:35AM (#34439643)
Who said you had to learn the entirety of Perl? I've been using Perl as an awk replacement for soon five years and I barely know a lick of Perl outside of what I need to use it as awk. If you use it that way, it's a much smaller language.

(That said, I do still have the tabs of perldata, perlobj, perlmod, and perlop open because I want to learn it better.)

Re:The State of the Awk (2020) by rtpg on Thursday January 19, 2023 @08:47AM (#34440181)
What does this look like in practice? Does Perl have a similar control flow syntax to awk?
Re:The State of the Awk (2020) by jrumbut on Thursday January 19, 2023 @10:22AM (#34441244)
It actually does (to an extent). There are BEGIN and END blocks (not used that much in regular scripting but they exist). There are also a bunch of perl command flags that can make things more awk-ish or sed-ish.

This random blog post gives something of the flavor.

https://lifecs.likai.org/2008/10/using-perl-like-awk-and-sed...

Re:The State of the Awk (2020) by kqr on Thursday January 19, 2023 @10:50AM (#34441597)
There's one fairly obvious error in that article: the fields are $F[0] etc, not @F[0]. Otherwise yes, that's a good way to make Perl look like awk. I personally translate awk concepts to more idiomatic Perl (I had no idea about -MEnglish, for example) but the concepts are still the same.
Re:The State of the Awk (2020) by jrumbut on Thursday January 19, 2023 @12:52PM (#34443271)
You're right, but it will still work as written.
Re:The State of the Awk (2020) by 082349872349872 on Thursday January 19, 2023 @07:15AM (#34439504)
Speaking of sed/awk/sh, in this case precomposing the awk with a sed preprocessor (in a sh pipeline) will give you both data structures (awk) and capture groups (sed).
Re:The State of the Awk (2020) by tyingq on Thursday January 19, 2023 @07:37AM (#34439661)
> awk '/foo=([0-9]+)/ { print $1 }'

The equivalent Perl isn't that far off from the above.

perl -nE '/foo=([0-9]+)/ && say $1'

Re:The State of the Awk (2020) by recuter on Thursday January 19, 2023 @08:04AM (#34439852)
Absolutely nothing should be done with Perl, it is 2023.

If you're jonesing for a sed replacement (it even has capture groups) try: https://github.com/chmln/sd

Worth being aware of:

https://github.com/theryangeary/choose

https://github.com/nushell/nushell

Re:The State of the Awk (2020) by zajio1am on Thursday January 19, 2023 @10:43AM (#34441503)
So obscure tools that are not packaged even in Debian?
Re:The State of the Awk (2020) by recuter on Thursday January 19, 2023 @12:19PM (#34442856)
22k stars is not really that obscure not that it matters. I didn't realize we are forever limiting ourselves to tools written in the 70s and 80s my apologies.

Would you consider trying something other than Perl once it is no longer packaged for you? Because it is an x-language, bereft of life.

Re:The State of the Awk (2020) by nrclark on Thursday January 19, 2023 @01:20PM (#34443619)
Use the tools you like. It's nobody's place to tell you what tools to use, and the reverse of that is also true.

For a lot of us, we want to develop scripts (and skills) that are portable across different environments. There are limited hours in a workday, and I get the most value out of learning (and using) tools that I can find on the servers / build-machines / workstations that I have to use every day. Those machines run Ubuntu, Debian, Rocky, and RHEL.

Yes, it's a slow process to get new packages into mainstream distros. That's not a bad thing, because those packages have to be maintained for a very long time. Stability is a virtue here.

There are some ecosystems (I'm looking at you, Javascript) where anything older than a year might as well be abandonware. It's great that there are some fast-moving areas in our industry, and also great that there are slow-moving areas.

Don't make the mistake of assuming something is bad just because it's feature-complete. You might be surprised at how feature-rich something like Awk really is.

If your argument boils down to "Awk and Bash are ugly and outdated", I'd encourage you to think more flexibly about the tools you choose. There's nothing wrong with learning the basics of a widespread tool that you are guaranteed to find anywhere.

Re:The State of the Awk (2020) by recuter on Thursday January 19, 2023 @01:35PM (#34443785)
Perl is not bad because it is feature complete. Perl might even be good, except that it is dead.

> if your argument boils down to "Awk and Bash are ugly and outdated"

Not at all. However, Awk was written almost 50 years ago. The awk book is good and the thing is installed most everywhere so if you're already invested in it and it does everything you want, keep using it of course. But it just might be possible to improve on a tool after half a century.

I simply shared new tools, that if you like awk, might really be up your ally. They might not be packaged with your favorite package manger anytime soon but you can grab them with cargo - if that's not portable enough so be it. No harm no foul.

Re:The State of the Awk (2020) by anthk on Thursday January 19, 2023 @02:55PM (#34444800)
Perl comes with OpenBSD's base. With pledge(4) and unveil(4) support.
Re:The State of the Awk (2020) by zajio1am on Thursday January 19, 2023 @10:40AM (#34441458)
Why? Perl has cryptic syntax, while AWK has syntax that is easily understood by anyone that has experience with common programming languages like C, C++, Java.

If you find unknown syntax construct in Perl code, it is hard to identify what it is, but if you find unknown function in AWK, you can just google its name.

Also, AWK is mandated by POSIX, so one can assume it is installed, while Perl is optional.

Re:The State of the Awk (2020) by anthk on Thursday January 19, 2023 @02:53PM (#34444774)
> Perl has cryptic syntax,

Perldoc perlintro. Have you seen real life Perl outside of oneliners?

Re:The State of the Awk (2020) by fomine3 on Thursday January 19, 2023 @09:51PM (#34448611)
Perl and awk are on the same level for cryptic syntax IMO, unless Perl isn't abused
Re:The State of the Awk (2020) by ykonstant on Thursday January 19, 2023 @11:44AM (#34442366)
Maybe, but what comex and I are talking about isn't too big to be coded in Awk; it is a very (extremely) common pattern that Awk just makes more difficult than it needs to be.
Re:The State of the Awk (2020) by b3morales on Thursday January 19, 2023 @11:49AM (#34442438)
I don't regularly use either language, but I prefer to use Ruby for this: https://robm.me.uk/2013/11/ruby-enp/

Example from that article

    $ echo "foo\nbar\nbaz" | ruby -ne 'BEGIN { i = 1 }; puts "#{i} #{$_}"; i += 1'
output

    1 foo
    2 bar
    3 baz
Re:The State of the Awk (2020) by alganet on Thursday January 19, 2023 @12:48PM (#34443226)
A capture group is not "too big", sed has them. It's a reasonable feature request for a small tool.

sh, awk and sed are fine. They are easy, small, powerful tools that are easy to compile and understand.

Perl, python, nushell, etc. The options listed here are great if you're writing cute snippets on the terminal or hacking together some higher level automation.

These more elaborate tools, however, are terrible if you're trying to be lean in the build/bootstrap process and have a small set of auditable, easy-to-compile tools.

The graph on this page illustrate the bootstraping problem well: https://bootstrappable.org/projects/mes.html

These small 50+ years UNIX tools that have zero build dependencies are around for a reason: they are small and have zero build dependencies.