I’m not gonna’ lie to you, I’m a pretty lazy admin. As such, I look for ways to reduce the amount of typing I have to do routinely. And ways to not make mistakes that I made when I was young and needed the rupies. The more time I spend at the command line, the more I use these, so here goes (hope they help you in some way shape or form):
- Make your own bin and put stuff you use often in there. You can use any folder you like and just include it in the export PATH=$PATH line by throwing a : at the end and typing that path.
- A great example of this is stroke, the port scanning tool from Network Utility.app. I know, I know – there are way better port scanners out there, such as nmap. Scoff at me if you will (especially if you’re Fyodor) – but it’s just friggin’ easy to use and for generic troubleshooting it gets the job done without much fanfare… So I copy the stroke command out of the Network Utility.app bundle into my own bin and from there I can summon it with ease.
- Add the bin for other common tools to your PATH. For example, the ec2 tools, if you’ve been following along with that series of articles.
- Don’t rm, mv. So it’s more typing… But not so much if you build a shell script to do it. There’s a great example of that in the Shell Scripting Recipes book by Chris F.A. Johnson from Apress. Over time, pulling something out of the trash rather than having to go and find something from outside of your machine because you accidentally deleted it will save you time.
- Provided your machine is secure, use preshared keys with servers you log into routinely.
- Automate everything you can – launchd is your friend. Automation isn’t just for deployment folks. You automate your backups, your log rotations and other tasks, so why not automate as much as possible.
- But don’t overautomate. If it takes you longer than it will save over the lifecycle of a script, why bother. Also, automating items that are moving targets (eg – log review for 3rd party software that gets a lot of updates) can be questionable.
- Clone before you update, or update into a lab environment and then push to production. It doesn’t happen a lot but some vendors will release buggy patches. Rather than get spun into a scenario where you’re chasing down issues, just do testing due diligence in a lab and/or clone machines before you roll updates into a production environment.
- Don’t reinvent the wheel. Sure, you might like to compile your own software, but if you don’t need the options in the latest .01 release and it’s part of MacPorts then maybe it would be quicker to install from there. Maybe not… If you do like to compile stuff yourself, maybe post to MacPorts (after all, what goes around comes around). On the deployment side, why build your own packages even though a piece of software is distributed as a package… Ask yourself if you really think you can do a better job than the vendor does, while knowing that occasionally (regrettably) you’ll say yes.
- And of course, use the latest and greatest terminal features, such as tabbed terminal windows.
I’m sure others out there will have their own lists, but these are the big ones that pop up in my mind…