This is gross.sh

This is not my beautiful house

Shell scripts, those little utility scripts that we write to make our life just a little easier... Let's face it: they're ugly.

I've spent quite a while combing through various Github repos, testing out other people's projects, and building my own scripts in an attempt to make the output of tasks on the command line look a little bit better for me. Whether you're writing a full-blown application stack, or just making small utilities that automate simple tasks, you should strive to make them look as good as they function.

Have you ever gone back to something that you did 10 years ago and wonder what in the hell you were thinking? Have you ever pulled down a project and none of the scripts/functions had a single comment describing what anything does?

Yeah. As it turns out, formatting, structure, and commenting are all pretty important. I wish that someone had told me this back when I started working with computers. I never wrote anything to be legible to another person, but in retrospect, I should have. That “other person” could be me [in the future], a co-worker, a manager, or even a client. Pairing good code habits with pretty output is always the eventual goal, so let's see what we can do to make that happen. While I'm not going to talk about the how of putting together shell scripts, I'm going to outline what works for me in making scripts that work and will continue to work a decade later.

Of note: My personal and professional background is in Visual Communications, which is just a fancy term for “Designer.” I went to art school. I designed packaging, signage, logos, brochures, and all of those types of things. When the world started embracing the Internet, I took it upon myself to learn how to make webpages. Lots of things have changed since the late ‘90s and I’ve had to adapt with the times. I now do IT, backend administration, build and code sites, and occasionally write scripts to make my life easier.

Well, how did I get here?

We used to do these info sessions at work, where the development team would all get together and one of us would talk about some tech/language/whatever that we were using or learning about. One of these sessions was (mostly) about why you should switch your current default Bash shell over to Zsh. (presented by @stevehansell)

Now, I’ll admit that I never really understood why someone would care about changing their shell. It just wasn't something that I gave much thought to most of the time. I would pop open Terminal.app when I needed to do a simple task and close it when I was done. While I didn't really appreciate the scope of what Steve was trying to illustrate at the time, I did listen and commit some of it to memory. And that was always the rub... I was using the command-line for SIMPLE tasks.

Fast-forward to a few years later, when I started getting a little more into things that forced me to use the command line – collaborating on larger projects using Git/Github, Docker, etc. At some point I downloaded iTerm2 as a Terminal.app replacement and subsequently switched over to the Zsh shell after reading something about it in an article somewhere. Some of this was starting to feel too familiar, kind of like I had heard about all of this before...

Same as it ever was

Coming from a creative background, I could never leave "good enough" alone. I used to tweak the startup screens, icons, and interfaces (back in Mac OS 9/early OS X) to the point of making the original UI almost unrecognizable. Sure, I'd break things often, but man... it sure looked cool. Along the same lines of making new desktop pictures, installing screensavers that replicate the look from "The Matrix," and tweaking desktop icons – over the years a lot of custom stuff started to fall out of favor with me. Maybe it was having kids or life just getting in the way, but constantly tweaking a GUI just wasn't a thing that I worried about all that much anymore.

But hot damn, here was this command line thing that I was using all day long that looked SO BORING.

boring

Even using iTerm2 and Zsh, it wasn't much more interesting. A new shell that does more stuff, sure. But it was still kinda meh.

zsh

Into the blue again

Enter Oh-My-Zsh – here was the thing that I needed. (Yeah, Steve. I know that you talked about both Zsh and Oh-My-Zsh way back when. I should have listened.) Not only does it make my life easier (auto-completion, path expansion, spell checking, etc.), it has plugins so that I can add more crap! And you can customize it! And there are iTerm2 profiles! And there's this Zsh theme called Powerline! ... And on and on and on. Without getting into the gory details of my way too overcomplicated .dotfiles setup, let's just say that at some point I ended up with this staring me in the face for most of the day:

zsh pl2k shell

And it's customizable! And I can set it up on a new machine super quick! And I can see if I'm local/remote, my current path, OS, battery level, execution time, Git details, etc...

Which leads me to the whole point of writing this in the first place — My lack of firsthand knowledge of the command line fostered an interest in learning how to write scripts to make my system do things. I'm not, nor ever have been, a trained CS guy. But I have always been interested in networking, Linux, and other computer-related things that let me tinker and build things the way that I like them.

To think that this all started with switching my shell away from Bash.

Into the blue again, into the silent water

Having a functional local setup is important, for sure. But wasn't I going to talk about setting up scripts and making the output look good? Yes and no. Since I tend to ramble on, I'm going to split this journey up into several articles. And keep in mind, what I'm doing might not be the best way to accomplish any of this, but it's where I'm at right now.

I'm always open to better suggestions on how to do any of the things that I'm advocating for here. I likely have not been privy to things that a trained CS person might do in any of these cases, but I'm open to hearing about any best practices that I may or may not be doing. I'd love to hear how other people handle doing this stuff on their end. Since I wish I had something of a primer when I first started getting into writing scripts, I'm going to be writing this for an absolute beginner.

This is part one in a multi-part series, sorta cross-posted over at Curiosity Motive.
While you're here, you might as well go ahead and read part two.