The Power of Linux Scripts with Garrett Wilke

Reads Scripting on Linux with Garrett Wilke with red geometric background and a System76 logo

Garrett's Linux Background

Garrett's Linux journey began in 1998 with Mandrake Linux, a distro based on Red Hat Linux. At this stage, Linux was an enigma, and his initial attempts resulted in frequent system crashes. Frustrated, he often reverted to Windows due to his inexperience with Linux.

Over time, Garrett adopted a habit of distro-hopping, exploring various Linux distributions and Desktop Environments. He grappled with misconceptions, believing that each DE was tied exclusively to certain distros, making Linux appear overly complex.

His Linux education took a pivotal turn when he ventured into Arch Linux installation, following the Arch Wiki meticulously. Upon reboot, he confronted a blank TTY screen devoid of a graphical interface. It was this moment that sparked his realization: Linux offered the flexibility to install any Desktop Environment, transcending distro boundaries. Suddenly, the Linux landscape began to make sense, instilling in him a profound understanding of the "how and why."

You’ve become known as quite the script master at System76. What language are you scripting in and where did you learn that?

I create scripts using a few tools and languages, mostly Bash and Python scripts. I learned how to script using Bash first. After getting Arch installed, I wanted to see if there was a way to automate the install. I was afraid of breaking my install like I had done so many times in the past. I learned that a Bash script is just regular commands you run in the terminal shell, which I had used to install Arch. I created a script that setup Arch for my system with all of my settings. I would test the script in a VM and tweak it until it just worked. At the time, I didn't know how to handle errors and edge cases, so it just brute forced it's way through the install process without any room for other settings or setups. This method I used to initially learn is good if you have a single purpose, but very bad if you want something dynamic.

What is the benefit to making your scripts? The benefits to making scripts in general.

I think scripting feels somewhat ambiguous as a concept if you don't have a purpose for making one. There are so many things that can be done very easily with modern tools that you don't need to make a script to do these tasks, but there are still many things that do not have a tool created for it. The benefit of a script that does something useful does not have a metric by which to measure. It saves time and creates something that does a specific task, but it also gives a sense of accomplishment that you were able to automate something.

How can people learn to make scripts? 

I think the best way to learn how to make scripts is to first have a use case for making one to begin with. Once you have a use case, you can then focus your energy on creating a script that provides value to your workflow. A good example of a use-case scenario is digital arts. If you create websites, videos, music, or digital art in general, then you will most likely have tools that are command-line-based alternatives to your GUI application. Converting video formats to different sizes and bitrates can be done with a GUI, but there are also ffmpeg commands to accomplish the same thing. You can create a script that converts your videos to all formats and sizes that you will need for your work. The same can be said for digital images. Manually resizing images for different mediums can be tedious. A script can automate this process and create every size image you need for your website/storefront quickly.

See Garrett's tutorial on getting started with bash scripting.

Do you have to be a programmer? What kind of background do you need to have?

You do not need to be a programmer to learn how to write scripts. Most of the things I learned for scripting are simply commands I found in a search for how to do something. Once you know the command you need to accomplish a given task, you can then use that command in a script to automate the process. I would argue that creating a script removes the need to memorize various commands and flags/arguments required to use it. Simply create a script and you don't need to worry about how it works later in the future when you approach the task again.

Can you tell us about the coolest script you’ve written, not necessarily for work?

I think the coolest script I have written is for audio manipulation and conversion. Machine learning has produced so many really cool projects, from AI art generation to audio stem extraction. There are a few audio extraction tools out there. When I read the documentation for how to use these tools, the amount of effort required to read it and understand all of the options is very exhausting. I also fear that I will not remember all of the options available to me, thus repeating the process of reading the documentation all over again.

There is an audio extraction project called "demucs". The options for extracting audio stems are vast, ranging from how many stems you want to create, the quality of the extraction, the AI model used to extract the stems, and many other options/flags. Trying to remember all of these options can be difficult, and reading the docs every time you want to extract is very time-consuming.

I decided to read the entire documentation and list out all of the options available for the tool. Once I knew all of the options and how to use them, I wrote a script that asks the user what extraction methods they want to use, what AI model and quality, and then automatically extract the stems from the audio and name them accordingly. This script has made it incredibly simple for an audio engineer to use without needing to be a command line guru.

How can people connect with you?

Garrett@system76.com


Like what you see?

Share on Social Media