From the link: "The lone dot that ends a format can also prematurely end a mail message passing through a misconfigured Internet mailer (and based on experience, such misconfiguration is the rule, not the exception). So when sending format code through mail, you should indent it so that the format-ending dot is not on the left margin; this will prevent SMTP cutoff."

If you're of a certain age and read that and grimace as you immediately understand why this would happen, it does rather put into perspective the misery of dealing with, say, Webpack configuration.

> From the link: "The lone dot that ends a format can also prematurely end a mail message passing through a misconfigured Internet mailer (and based on experience, such misconfiguration is the rule, not the exception). So when sending format code through mail, you should indent it so that the format-ending dot is not on the left margin; this will prevent SMTP cutoff."

Did email clients not handle "dot stuffing" back then? That is, if a line begins with a single dot, the client would automatically insert another dot right before it. Then, at the receiving end, the client would remove the extra dot at the beginning of the line.

> Perl was basically written because Larry Wall found Awk's syntax to be a little too cryptic.

That seems ridiculous; where is it substantiated?

When Wall posted Perl to comp.sources.unix for the first time, he wrote "If you have a problem that would ordinarily use sed or awk or sh, but it exceeds their capabilities or must run a little faster, and you don't want to write the silly thing in C, then perl may be for you."

Or rather, not Larry Wall, but the apparent newsgroup moderator added that text, lifting it from the Perl manual page.

Thus he was pitching it as something that performs faster than awk and sed, with a greater range of capabilities.

On pp. 381-382, my copy of Programming Perl (1992 printing of first edition) says he was trying to build a configuration management system for 6 Vax and 6 Sun machines, and he needed to solve some problems like file replication across a 1200 baud link and approvals. So he installed B-news, the Usenet news software at the time. Then he was asked to generate some reports and:

> News was maintained in separate files on a master machine, with lots of cross references between files. Larry's first thought was "Let's use awk." Unfortunately, awk couldn't handle opening and closing of multiple files based on information in the files. Larry didn't want to have to code a special-purpose tool. As a result, a new language was born.

So that's why it's the Practical Extraction and Reporting Language. He wanted to extract data from files and generate reports.

That was a little tongue in cheek but there is a comment in the Camel book about how he wrote perl because he was scared of Awk's parser.

Could have been a joke. His writing (and talks, like the "State of" ones, is full of them, some of them a bit subtle too :)

Ugh I’d forgotten about Perl reports. Gave up on that circa 2001 when I discovered python!

I found awk after using perl (four was the new hotness) Before long I was trying to figure out just what in my daily work perl was suppose to be protecting me from

Does anyone out there still use format()? I've never used it in the my entire 18 years experience programming Perl.

>Also, Awk isn't great for making reports

Why?

IIRC there's no method of putting headers or footers on pages, nor page number without manually counting the lines yourself.

I could be wrong though. Awk is one of those tools like vi where you can use it for years and still be discovering new features.

>IIRC there's no method of putting headers or footers on pages, nor page number without manually counting the lines yourself.

Good point. The BEGIN and END patterns do work for global headers and footers, totals, etc., but not for per-page stuff. You can do it yourself with some extra awk code, but yes, you have to write it. Not difficult, though. I guess it was not designed to be a Crystal Reports-like reporting tool, with report bands and what not.

>I could be wrong though. Awk is one of those tools like vi where you can use it for years and still be discovering new features.

Agreed :) Not only new features, even new uses for existing features, because, although it is a sort of DSL or little language (but a programmable one), the area it is applicable to, pattern matching and data processing of many kinds, is vast.

As many others pointed out in this thread, the fact that the reading of input is built-in to it (whether from standard input or files given as command-line arguments), saves you a bit of boiler-plate code each time (cumulatively) you write an awk program using that feature. So does the pattern-action model, with those two defaults for missing pattern or action (match all lines, or print). And again as others have said, Perl, Ruby, etc. have that feature too (the first one).

Use the `pr' utility to paginate your output.