About one-liners
It's not that I don't see the utility for one-liners, it's just my own mindset that seems to prevent me to use them.
On one hand, I often explain to other (non-Perl) developers how useful can be a one liner, but on the other hand I tend not to use them even when I could.
There are several reasons for that, in asceding order:
- I tend to document everything. This could be seen as a fault of mine, but I tend to see it as an advantage. Of course you cannot (and really don't want) to comment on a single line script!
- one-liners are quite hard to test and to deploy. Because we all run tests against our program, especially before deploying them in production!
- I don't have enough room space in my brain to remember all magic variables! $., $, and friends...
- Often I want to change the result depending on other run-time contexts, and therefore I find more useful to have a program driven by parameters (or configuration) than having to slightly change my one-liners.
- Git history helps more than the shell one. Having a whole set of scripts and history about when, why and how they have been created and used helps me more than searching thru the shell history.
- I don't want to impress anyone. One reason some developers use one-liners is to impress colleagues. Quite frankly, I don't care about it.
Despite the above, I'm not against Perl one liners, and I see how powerful and useful they can be.
It's just I'm more comfortable with my text editor in front of me.
Perl and PostgreSQL passionate and advocate, Open Source human being since a while.
Perl one-liners are a tool for people who spend most of their time not in a text editor, but in a shell. Over the years as I've spent more and more time having to come up with one-off solutions for the problem of the day, I've spent more and more time hacking up simple, one-time-use scripts. But there's a better way...
Instead, I've started writing things that get me almost all the things I need to solve the problem of the day: A simple script that reads data from the database (one for each kind of proprietary database I have), another script that reads from a news feed, another that looks at logs. Now, when the problem of the day crops up, I can use these pre-built tools to find the solution, tying them together with a bit of shell script (of which Perl one-liners are a part). Instead of writing a script, which, if I'm doing it right, takes an hour or two, I combine the parts I already have into an answer in 15 minutes.
The documentation for the tools is already there. The integration of the tools is the shell. The shell is an integration platform for tools that work with character streams.
If you're regularly using awk and sed, then Perl one-liners are a good evolution of that. If you're not regularly using awk and sed, consider reading about them, as they are wonderfully useful in their way.
Shell as glue for Perl...nice! I always thought Perl was the glue for all the other stuff.
Besides, I agree, maybe living within my editor made me think the more about stand-alone scripts than one liners.
Again, I see the importance one liners have, it is just that very often I find myself requiring more tuning than that of repeating a single few Perl commands.
But hey, the importance is that the work is done with Perl!
There's no reason you can have it both ways (at least in some respect).
You can put your shell history in a git repository (true, this is not the same thing as putting a single script file).
You can use an editor to edit command-line, e.g. C-x C-e.
You can use something like M-x shell in Emacs, then later on save the whole session in a file (in a git repo) to document things, it even shows you the evolution of building up a working one-liner *with* the outputs.
You can put your good one-liners in a script later (just chuck it in a file and prefix it with #!/bin/bash, for example).