Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Awk Programming Language

awk.dev

Post reply on HN
Print view View original

71–80 of 159 posts

Re: The Awk Programming Language

#71

Post by geophile »

ahalbert wrote: post #64

I love using Awk, the only thing I miss is that it can't handle complex csv files. Does anyone know how to handle quoted CSV strings like > "foo","bar,baz"

I like the idea of Unix pipelines, but I hate all the sublanguages, awk being one of the biggest. I scratched my itch and built my own shell, marcel: https://github.com/geophile/marcel.

I mention this specifically, here, because of the CSV point. Marcel handles CSV, e.g. "read --csv foobar.csv" reads the foobar.csv file, parses the input (getting quotes and commas correct), and yields a stream of Python tuples, splitting each line of the CSV into the elements of the output tuples.

Marcel also supports JSON input, translating JSON structures into Python equivalents. (The "What's New" section of marcel's README has more information on JSON support, which was just added.)

Re: The Awk Programming Language

#73

Post by theonemind »

joeythedolphin wrote: post #28
kqr wrote: post #21

Earlier quoted context omitted.

This is exactly why I moved from AWK to Perl for these quick jobs a couple of years ago. If you stick to an AWK-like subset, Perl is also simple, fast and lightweight. If you want to grow your scripts (and you have a lot of discipline) Perl – in contrast to AWK – gives you enough noose to hang^W^W^W^Wthe tools you need.

Perl? Wow. Is that better than bash, python or even nodejs? Why write in Perl over these? Serious question, was propaghandized to hate Perl.

There's a limited problem domain where it's unquestionably the best. Perl beats awk and bash at their own game on their home turf. That's the best way to put it. It's faster, has more shortcuts, less warts, more power, and more readability when well written, and while aged and not huge by modern standards, CPAN (like pypi or npm) is incredible for a hyper-powered awk and bash mash-up for those tasks at the edge of of that limited problem domain. It's installed almost everywhere, so almost always available.

That stuff is just awkward and painful in Python by comparison.

Re: The Awk Programming Language

#74

Post by nmz »

benhoyt wrote: post #25

I was privileged to be one of the technical reviewers for this book. There's a fair bit of the original content (which is still great), but Kernighan's done a great job with some good restructuring and some significant updates, too. The early chapters are very hands-on, with something of a focus on "exploratory data processing", particularly with CSV files. Big data with AWK, you could say. Gawk and awk will soon hav…

It's nice that everyone is supporting this, I've written a portable awk module that takes control of the parsing and it is SLOW (and a little buggy). I'm a little bummed that nobody will use it but this is truly a step in the right direction.

I guess for the people that are still using nawk, you can set up an AWK envvar so you can { awk -f $AWKU/ucsv.awk -f https://github.com/Nomarian/Awk-Batteries/blob/master/Units/...

Re: The Awk Programming Language

#75

Post by lysium »

ahalbert wrote: post #64

I love using Awk, the only thing I miss is that it can't handle complex csv files. Does anyone know how to handle quoted CSV strings like > "foo","bar,baz"

They are planning built-in support for that, see that other comment https://news.ycombinator.com/item?id=36518146

Re: The Awk Programming Language

#76

Post by chasil »

bluetomcat wrote: post #16
siraben wrote: post #10

Awk is awesome! Glad that they are looking to modernize the book. It wasn't really necessary, all the code examples in the original edition of the book still run just fine, although some are somewhat dated, like printing ASCII bar graphs. They also had examples of writing VMs, parsers and interpreters in the book, which run on modern implementations.[0] The language has some quirks. To declare temporary variables, it…

Is there a particular benefit in writing a VM in AWK, placed in a big BEGIN block? Very similar code can be written in Perl or Python. Isn't the strength of AWK in its line-matching capability, being able to pattern-match a line against a block of code?

AWK runs everywhere. Perl and Python do not.

Busybox has their own independent AWK implementation.

https://busybox.net/ https://frippery.org/busybox/

Also see the first edition of the AWK manual online here:

https://archive.org/details/pdfy-MgN0H1joIoDVoIC7

Re: The Awk Programming Language

#77

Post by hermitcrab »

calvinmorrison wrote: post #50
benhoyt wrote: post #25

I was privileged to be one of the technical reviewers for this book. There's a fair bit of the original content (which is still great), but Kernighan's done a great job with some good restructuring and some significant updates, too. The early chapters are very hands-on, with something of a focus on "exploratory data processing", particularly with CSV files. Big data with AWK, you could say. Gawk and awk will soon hav…

Its a crying shame we never settled on a control character separated text format. There's a ascii control characters for record and field (unit) separators. A bit of user space support for that would have been great.

Some discussion of that here: https://news.ycombinator.com/item?id=31220841

To be really useful as a format it would just need for text editors to: -display something distinct for the field separator (some editors do this) -treat the record separator character like a carriage return (not aware of any editors that do this)

Re: The Awk Programming Language

#78

Post by calvinmorrison »

hermitcrab wrote: post #77
calvinmorrison wrote: post #50

Earlier quoted context omitted.

Its a crying shame we never settled on a control character separated text format. There's a ascii control characters for record and field (unit) separators. A bit of user space support for that would have been great.

Some discussion of that here: https://news.ycombinator.com/item?id=31220841 To be really useful as a format it would just need for text editors to: -display something distinct for the field separator (some editors do this) -treat the record separator character like a carriage return (not aware of any editors that do this)

Right. The issue is the user space support at the end of the day.

Re: The Awk Programming Language

#79

Post by bardak »

ducktective wrote: post #27

Also watch his recent interview on Computerphile: https://www.youtube.com/watch?v=GNyQxXw_oMQ And: Brian Kernighan adds Unicode support to Awk https://news.ycombinator.com/item?id=32534173

Honestly after watching a lot of Kernighan interviews and reading his original book on C he is a very great communicator. I wonder how different the software world would have been without him at Bell Labs. Would Unix and C have become as widely used as quickly?

Re: The Awk Programming Language

#80

Post by throw0101c »

hermitcrab wrote: post #77
calvinmorrison wrote: post #50

Earlier quoted context omitted.

Its a crying shame we never settled on a control character separated text format. There's a ascii control characters for record and field (unit) separators. A bit of user space support for that would have been great.

Some discussion of that here: https://news.ycombinator.com/item?id=31220841 To be really useful as a format it would just need for text editors to: -display something distinct for the field separator (some editors do this) -treat the record separator character like a carriage return (not aware of any editors that do this)

> To be really useful as a format it would just need for text editors to

This made me think of WordPerfect's "reveal codes" functionality. :)

(Word's "Reveal Formatting" is supposedly similar.)

Post reply on HN