I spent the better part of an hour trying to bang my head against Windows, gave up, and grabbed my Mac laptop, opened a terminal, and accomplished the end-goal in 10 minutes, which included writing my own hacky first-draft do_the_thing.bash file. More and more, my solutions (including production-ready solutions in some cases) start life as do_the_thing.bash, and eventually evolve into a proper script with error conditions, failure modes, self-checks to prevent multiple runs, etc. But mostly, they start as do_the_thing.bash, which I blame a developer friend for doing in front of me and thereby teaching me terrible habits.
My own personal goal, after I get back from my convention trip, is to throw away do_the_thing.bash and rewrite the entire process, soup to nuts, in python (including checking for ruby and installing it if needed, among other steps)(and yes, I know, but ruby is also a thing I should be learning, and I feel like this is a good test case for that). I'll be leaning heavily on my more advanced dev resources (aka, my friends Rachel and Matt), but this is the first project I feel really excited about trying on my own.
When I was just making the transition from Tech Support person to DBA, I was often convinced that it was faster and easier for me to just execute a given command directly, rather than building a tool that executed a command. But as I've grown and matured, I've been put in positions where the execution of a particular command isn't the issue; it's the repeated execution of some set of commands that must be automated, and so I've built up a repository of script fragments
For now, though, I'm all about do_the_thing.bash. Or do_the_thing.py, or do_the_thing.js, or whatever. First build a skateboard. Then build a bicycle. Then build a motorcycle. (As a life-long motorcycle rider, we can just stop there.)