[salmo]

I'll also make the inflammatory statement that people should just use sed and awk in shell scripts and leave Perl for when they really want to write Perl.

It is weird to me the number of times 90's Linux Distros used Perl for things that are easy in awk, awk for things that are easy with cut, and other commands for things that are easy with POSIX shell baked-in facilities. I guess I'm just a shell snob.

[efaref]

cut usually doesn't do what you want it to do. Most of the time you want to split on sequences of whitespace (which may or may not be tabs, it's not easy to tell from the output of the program). cut doesn't let you do this, which is a shame, as it would've been a sensible default. It also does weird things like print out the whole row if there's no instance of the separator on the line.

So because you can't trust cut to do what you want, you'll probably reach for something like awk '{print $3}' instead.

[squiggleblaz]

Yeah, after I remembered that `cut` exists shortly before needing to grab some fields of an input, I thought "oh, I'll use `cut` instead of `awk`". And lo and behold, `cut` couldn't do the thing I wanted. Why learn two tools when one will do? The only reason I can think of is the principle of least privilege, but if you can convince me it applies, I'll convince you should write a single tool that adheres to it instead of using countless tools for any given transform/privilege pair.

[cutler]

Perl was invented to replace the shortcomings of hacking together sed + awk + shell, eg. multi-dimensional arrays.

[iso1631]

I tend to start writing in bash/sed and going on to regret it as the script gets more involved and needs a refactor in perl.

Most of the time the script doesn't get more complicated and it's fine with cut/sed/wc etc, but at some point it tips the balance and I grumble to myself.

[walshemj]

Only if the said script is less than a dozen lines