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

Perl first commit: a “replacement” for Awk and sed

github.com

Post reply on HN
Print view View original

121–130 of 261 posts

Re: Perl first commit: a “replacement” for Awk and sed

#121

Post by timthorn »

stubish wrote: post #55
imiric wrote: post #42

Earlier quoted context omitted.

> Automation was glued together in one of these with a series of grep, awk, sed, ls, test, commands glued together. Anything more complicated was written in C and called from one of these things. This doesn't sound that horrific to me. It's the classic Unix approach of building small tools that do one thing well, and composing them in novel ways to solve problems. For any problem that can't be solved this way you wri…

At the time, before everything became Linux, all these tools and the shells used to glue them together were an incoherent mess. Was your glue sh, ksh, csh, tcsh, bash or something uncommon like zsh? Did your grep, awk and sed use the same regexp syntax as your text editor? Single letter command line options, all meaning something different to each tool. Dozens of domain specific languages (shells, awk, sed etc.) mean…

> And you needed it in your head, because finding the information you needed in the massive single document man file reference was a pain

That's what the O'Reilly books were for, especially the Nutshell series.

Re: Perl first commit: a “replacement” for Awk and sed

#122

Post by jghn »

timthorn wrote: post #121
stubish wrote: post #55

Earlier quoted context omitted.

At the time, before everything became Linux, all these tools and the shells used to glue them together were an incoherent mess. Was your glue sh, ksh, csh, tcsh, bash or something uncommon like zsh? Did your grep, awk and sed use the same regexp syntax as your text editor? Single letter command line options, all meaning something different to each tool. Dozens of domain specific languages (shells, awk, sed etc.) mean…

> And you needed it in your head, because finding the information you needed in the massive single document man file reference was a pain That's what the O'Reilly books were for, especially the Nutshell series.

I remember capturing every password at my university via "methods". Because we had a printer quota. In the summer when everyone was gone I printed out all the man pages (all the mans, the system libraries, etc) so I'd have a nice reference book. I made sure to make it so no one was charged any money.

The one thing people can't possibly fathom if they started coding after the mid-late 90s was how much we relied on the printed medium.

Re: Perl first commit: a “replacement” for Awk and sed

#123

Post by fuzztester »

sidlls wrote: post #38
explaininjs wrote: post #22

Earlier quoted context omitted.

Google Trends has sed crossing over perl about 5 years ago. Awk seems insignificant, which matches my expectation. (I’ve used sed but never awk, I don’t even know what it does) Worth noting “sed” is “thirst” in Spanish, which has the potential to throw off the data, especially worldwide. https://trends.google.com/trends/explore?date=all&geo=US&q=p...

awk is a fantastic command line application that is useful for filtering, basic computations and transformations that other basic utilities (e.g. cut, sort, etc.) + grep don't (readily/easily) provide. I suppose it might be a bit archaic these days, but for someone familiar with it, it's often faster to compose an awk command than to write even a very quick/short script in, e.g., python or perl, for certain things.

>awk is a fantastic command line application that is useful for filtering, basic computations and transformations that other basic utilities (e.g. cut, sort, etc.) + grep don't (readily/easily) provide.

All true.

But awk is also a programming language, not just a command line application or utility.

It has conditionals, loops, regexes, file handling, string handling, (limited) user-definable functions, hashes (associative arrays), reporting abilities and more.

In fact, the name of the original book about awk is The Awk Programming Language.

Re: Perl first commit: a “replacement” for Awk and sed

#124

Post by kristopolous »

tannhaeuser wrote: post #118
kristopolous wrote: post #105

Earlier quoted context omitted.

POSIX, right. POSIX sucks. POSIX anything is stuck 30 years ago. Nobody in 2023 really uses POSIX awk on some commercial UNIX like IBM AIX, they use GNU awk, that's the modern one I'm talking about https://www.gnu.org/software/gawk/manual/html_node/index.htm...

What are you talking about? There is no POSIX awk implementation, just a language spec and nawk AKA the one true awk. As shipped on Mac OS, whereas Debian ships mawk in addition to gawk. gawk is just much slower and unfortunately also buggy (crashes on a non-"C" locale with complex regexpes).

Right, "the one true awk" corresponds to a book written in 1988, very explicity. https://github.com/onetrueawk/awk

I was incorrect about 30 years. It's actually 35.

You were the one that that said POSIX awk to begin with, I was using your terms. I understand what you meant, why don't you?

As far as shitting on the GMU tools, I don't think I've seen someone do that in decades, especially just referencing the bottom of the man page like that.

As far as speed, I don't know how you're using these tools, but if gawk is your bottleneck and not i/o, there's probably smarter ways to do things.

This is not a productive conversation. You can live life however you want and if you're happy than I'm happy. We are definitely at an impasse. I'm off to bed.

Re: Perl first commit: a “replacement” for Awk and sed

#125

Post by fuzztester »

em-bee wrote: post #69
version_five wrote: post #10

Earlier quoted context omitted.

My first thought when I saw this was that I'd like to see some stats on use of the three. I personally use sed and awk regularly and never perl, but I have no idea what is typical. I have a feeling that most people (amongst those who may have a use case) don't use any of them.

it's not about stats but simply that the space between simple shell scripts and complex systems that required "big" language, which used to be filled by perl has shrunk a lot because it is filled with many other languages that are better suited for larger systems than perl is. for most uses of perl today there are a dozen other suitable languages, including some that are older than perl but were not freely available…

>for most uses of perl today there are a dozen other suitable languages, including some that are older than perl but were not freely available at the time.

Can you name some? I'm guessing Rexx is one of those you mean.

Re: Perl first commit: a “replacement” for Awk and sed

#127

Post by csydas »

zenlot wrote: post #120
unpythonic wrote: post #11

When perl came out we were living in horrific times. You had the choice of either Bourne, C or Korn shell. Automation was glued together in one of these with a series of grep, awk, sed, ls, test, commands glued together. Anything more complicated was written in C and called from one of these things. Perl in one stroke collapsed the programming of C, text manipulation, the capabilities of all of the Unix utilities, an…

And now you can just use PowerShell which combines it all in one cross platform scripting language.

assuming that the security administrators of the systems you want to run the script on haven't followed Microsoft's 'recommendations' and basically made powershell unusable on the systems due to random GPOs ;)

PS is 'okay' as a scripting language, but it's very frustrating how Microsoft's security defaults seem to be dead-set on ensuring you can't use scripts on systems without jumping through a bunch of hoops. I get how MS got to this conclusion that it needs to be locked down, but it makes me think twice about pumping out a script since I know I might need to walk my colleagues through how to actually run the damn thing depending on what the Security Admins decided to lock down that week.

Re: Perl first commit: a “replacement” for Awk and sed

#128

Post by avar »

simcop2387 wrote: post #5

One thing to keep in mind is that this is not actually the first version of perl, it's the first public version of perl. A version 0 did exist at the JPL previously but it's likely lost to the ages at this point. EDIT: For the curious about the history, take a look at the perlhist documentation, https://perldoc.perl.org/perlhist it's got a lot of good info about the history of perl and it's releases.

Perl was born as an NSA project, this old HN thread has some good references: https://news.ycombinator.com/item?id=14069320

As for as I know the only "official" reference to that is the "classified" and "don't ask" in perlhist.

Re: Perl first commit: a “replacement” for Awk and sed

#129

Post by imiric »

j16sdiz wrote: post #109
imiric wrote: post #42

Earlier quoted context omitted.

> Automation was glued together in one of these with a series of grep, awk, sed, ls, test, commands glued together. Anything more complicated was written in C and called from one of these things. This doesn't sound that horrific to me. It's the classic Unix approach of building small tools that do one thing well, and composing them in novel ways to solve problems. For any problem that can't be solved this way you wri…

> This doesn't sound that horrific to me. It's the classic Unix approach of building small tools that do one thing well, and composing them in novel ways to solve problems. This works really well if your problem can be solved in one or two liners. It go bad very quickly when, say, you have two CSV files and want to join them the sql-way. In sed, you have to use positional variables and think about shell escaping. In…

> This works really well if your problem can be solved in one or two liners.

My personal comfort threshold is around the 100-line mark. It's even possible to write maintainable shell scripts up to 500 lines, but it mostly depends on the problem you're trying to solve, and the discipline of the programmer to follow best practices (use sane defaults, ShellCheck, etc.).

> It go bad very quickly when, say, you have two CSV files and want to join them the sql-way.

In that case we're talking about structured data, and, yeah, Perl or Python would be easier to work with. That said, depending on the complexity of the CSV, you can still go a long way with plain Bash with IFS/read(1) or tr(1) to split CSV columns. This wouldn't be very robust, but there are tools that handle CSV specifically[1], which can be composed in a shell script just fine.

So it's always a balancing act of being productive quickly with a shell script, or reaching out for a programming language once the tools aren't a good fit, or maintenance becomes an issue.

[1]: https://miller.readthedocs.io/

Re: Perl first commit: a “replacement” for Awk and sed

#130

Post by mulmen »

alexjplant wrote: post #85
racl101 wrote: post #37

Earlier quoted context omitted.

I probably didn't learn Perl because PHP superseded it for web stuff.

This. PHP was my first "real" programming language (which is a bit scary now that I think about it since it followed me learning QBasic and VB6) and by the time I was messing with it for web dev circa 2003 CGI scripts were on their way out. I suspect that it had something to do with CPanel/WHM-based shared hosting setups being reticent to deal with something as powerful as CGI and preferring to just run PHP in Safe M…

Ha! Cheers! My first language was VB.net and my first paying gig was porting a VB6 app. But my career really started when I took on Perl and Oracle. Good times indeed.
Post reply on HN