In the real world though, often scripts are written for a very specific task to be performed in a specific environment

That's not my experience. My experience is that a script is often written for a very specific task, management finds out, and thinks it can be used for a bunch of similar tasks, and then you end up bolting on a few extra functions. And then s/he wants to run it on his/her windows box and complains that it doesn't work. Maybe I'm not in the real world yet, though as I've only had one job since I graduated.

I don't know where you get this notion, a typo is a typo, is a typo, no matter how you spin it. If you write code for any purpose and don't test it thoroughly then you are already in a heap of trouble. Using a module does not excuse one from testing.

No, a typo is not a typo in all circumstances. A typo in a literal string does not have the same gravity as a typo in code, but it also does not have the same testability. Typos in code most likely means the compiler will complain. Typos in strings will only be fixed if someone pays close attention. And typos in regular expressions may not be noticed until the odd scenario shows up where it fails. If, for example, your regular expression fails to handle a case with spaces in it, you would never know until you actually handed the code a path with a space in it. Not something I normally think about. However, my bet is that the authors and many users of File::Basename have vetted out pretty much all possible issues (or at least more issues than I could think of), so using the tested code means your code will just simply work more often.

You're right basename($path) is more concise than non-module solutions. But that is what comments are for.

Clear code is always better than clear comments. It's precisely because the compiler ignores the comments that the code is better: it's what is actually being done.

  # get the base name of the path.
  $path =~ m~^[\w/]+/(\w+)$~;
  $basename = $1;
[download]

Woops - doesn't handle spaces at all. No error checking, either. The comment is wrong.

  $basename = basename($path);
[download]

No need for comments because the code says exactly what it's doing. Now, the basename function may be doing something wonky, but that's what comments inside basename are for. The code that's calling it doesn't need comments.

Call me crazy, but what does it matter so long as you get the basename of the path?

What matters is getting the basename of a path, not extracting a substring from some text. Say so. That will make it much easier on the next person in reading the code. Even if that's you six months from now. Code that reads in the domain of the problem rather than the solution will be much more natural to follow for whoever gets to maintain it later. It is more resilient to changing requirements.

Yes, I know that you can't think of requirements changing. Perhaps you have a less creative mangement. Mine has thrown me enough curveballs so far past deadlines (sometimes even after we have shipped to manufacturing) that I need to be able to see around these corners to write code that can simply be tweaked to get whatever change is required. In this case, I could see a few changes. First one is that we actually want the directory the file is in along with it. In this scenario, the regular expression may win out on speed, but it starts getting just a wee bit more convoluted. Or you just do something like: $basename = File::Spec->catfile(basename(dirname($path)), basename($path));, or, probably better yet, File::Spec->catfile( (File::Spec->splitdir($path))[-2..-1] ). This latter one extends pretty easily to any depth.

Second possibility is that we want the basename, but we're going to put it into a new directory - so we want some arbitrary changes. Here the regular expression can work, but probably a little messy: $name = File::Spec->catfile( qw(some dir), basename($file) )

Of course, that extends further into wanting to get that other directory from some completely different source that isn't hardcoded into the program at all. Regular expressions here would need the e (eval) modifier to do it in one step, so you'd want to do it in two: regular expression to get the basename, then concat it with whatever the function returned. Oh, and don't forget the path separator (that's an easy bug to have with this method). Of course, using proper functions as a matter of course, even in what you might think of as throw-away programs, means you don't even have to think of the separator: File::Spec->catfile( get_path(), basename($path) )

Regex and split a sledgehammer? Let's see one or two lines of code as opposed to all the overhead of the previously mentioned modules. I'll take the one or two lines of code which offer far less overhead and operations than the module.

What I'll take is a good habit to take the person-years (or person-decades) of testing that File::Basename and File::Spec have received for free into my project such that I never have to concern myself with file system details again. It's a habit that serves me well whether it's in a small program or a large one.