> Every programmer worth their salt must learn Perl, Bash and using these command line utils. There are chances you are writing lots of code which just doesn't have to get written.
I have written a rather lot of sh (I target POSIX sh, not bash) and I'm decently familiar with common cli tools (coreutils, moreutils, etc.). IME awk+sed cover most of the "fancy" text manipulation just fine; what am I missing out on if I skip perl?
Perl was made to ensure you don't have to learn the dozens of things you'd have to learn and slap together with all sorts of adhoc hacks. Everything comes in one package. The full language can't be captured in this comment, of course. But compared to Bash, you get a C like syntax(Bash comes from Algol, you have to learn a new syntax), you get error handling, full master set regexes, heredocs, qw, associative arrays, arrays, built-in string manipulation, unix interfaces, DB drivers, first class integration with command line tooling etc etc.
Think of it like a unix native language. Like the immediate extension to the operating system itself.
Apart from that Perl is very stable, fast, and very deeply committed to backwards compatibility. You can be sure the scripts you wrote years back will run on new Perls.
awk+sed are simple match-do engines, you can't do counting(atleast not easily), you can't do other myriad stuff like working with >2-3 files at one time(iterating simultaneously, in sub-loops etc).
If you are dealing with large files, in Perl its fairly simple to build a index by doing one go on the whole file, then use the key to map to the value where you want to go in the file using seek/tell(with pack/unpack), This makes frequent look ups very computationally cheap. In awk/sed you can't do error handling, you can't do reading and writing to multiple files at the same time et al easily atleast. In Perl, you get dbm drivers and functions install so its relatively straight forward to build look up applications of all kinds.
Perl also comes with OO, so if your code gets lengthier you can can fit it into neat design patterns.
Last but not the least. Perl has CPAN. Its just one of those things. Only real competition to CPAN till date is NPM. Not even Java/Python have a library ecosystem as large as Perl.
If you need something more robust or sophisticated than sh(1)& cie, it's best to head up to a statically typed language instead -- I tend to favor go, in part because of the cross-compilable fat binary thing. The lack of static typing is especially annoying when things are getting beefy enough to consider moving away from sh(1).
For prototyping, if you know Perl already, why not; but even there, I personally reach out to sh(1) & friends instead.
I have written a rather lot of sh (I target POSIX sh, not bash) and I'm decently familiar with common cli tools (coreutils, moreutils, etc.). IME awk+sed cover most of the "fancy" text manipulation just fine; what am I missing out on if I skip perl?