In this case, there aren't commas in the data I need. In general, you are right, but this isn't the general case. Treating everything like the general case is usually a lot of wasted effort. I know that the parts of the lines that matter to me won't have the separator character in it.

I'm not screwed to any degree even if there are commas in the data. This little script simply makes the report I needed this morning. It's not controlling medical equipment, nuclear reactors, or air traffic control. If it breaks, I don't lose any money and nobody dies. People don't lose their jobs and the sky does not fall. I'm not even committing the minor sin of uploading this to CPAN.

Perhaps your definition of "screwed" is different than mine, but a text report going a bit wonky just means I do the extra work later, if I need it. For now, I have the report I need, and a month from now if I even remember where I put this script and if I need something different, I'll change it.

Until then, I don't need a perfect or proper script. Joel Spolsky says in "Hard-Assed Bug Fixing" Fixing bugs is only important when the value of having the bug fixed exceeds the cost of the fixing it." Indeed, he goes on to show the economic disadvantage of too much programming.

The point of the exercise is not programming, but results. Anything beyond the results is wasted time, which is why, when I considered it (as noted in the original post), I didn't use a module, but I designed it so that if I change my mind, almost nothing changes. The flow is still the same, and some subroutines at the end of the program change how they do things, although not their interface. The rest of the program doesn't know how I parse a line: it just knows that it gets data. I don't need DBI to do this simple task, and right now I don't need another module.

If you want to spend a lot of quality time with your keyboard, that's fine. I prefer to get things done, and sometimes a "proper" program is just wasted time. Instead of doing everything "properly" from the start, just design things so you can go back and easily change the program later. Use the simplest solution to a part of problem, and stop when it works. Move on to the next part of the problem. Stop when that works. When you get the results you need, stop working. I may never use this script again, so any extra work is a waste. If I do use it again, and it breaks, then I fix it, but I only do it just in time and as needed.

I've met a lot of perfectionists, and in my opinion, most of them don't get that much done.