If you’ve been a computer user who actively or even periodically uses Linux for any amount of time there are a bunch of venerable old commands that you’ve certainly heard about. Tools and command line utilities that perfectly illustrate the ethos targeted applications that do one specific thing.
With my recent deep dive into Linux I’ve been trying to uncover more of these tools and trying to learn how to use most of them at least at a basic level. I have some experience with the command line from having run Linux servers for various personal and professional tasks for many years, but for the most part I’ve only learned specifically what was needed for those specific jobs without taking the time to deep dive the command line more fully.
On Linux “the command line” for most people is just another way of talking about the Bash shell (bash), an evolution of the Bourne shell (sh) originally implemented on UNIX systems back in the 1970s. Shells expose the guts of the operating system to a keyboard-and-screen based interface for the operator of a computer to be able to use the system. This interface goes back to some of the earliest days of interactive multi-user systems — pretty much as soon as we moved on to terminals with keyboards attached we started to see the appearance of these shell programs that could be used to interact with the (relatively) low-level elements of a computer without having to actually write any code.
A large number of Linux distributions use bash today as their default login shell, so as a Linux user it’s handy to know your way around bash and the way that it interacts with the rest of the command-line ecosystem. If you’ve used the terminal on MacOS that’s another Bourne-derived shell called Z-shell (zsh). If you’re familiar with the basics, it’ll be fairly easy to get around this terminal as well. Windows users don’t have a simple (included) way of using bash, but you can get it with gitbash or by installing a Linux distribution using the Windows Subsystem for Linux (WSL).
One of the biggest advantages to command line tools is the ability to use them in scheduled or scripted activities. This is something that I want to make sure keep in mind as I go through the process. Scripting is probably the biggest area of opportunity for me to be able to take advantage of the tools. It’s not quite “programming” but it also isn’t not programming.
Many of the “standard” command line tools, fit together like Lego bricks by using the same types of input/output mechanisms. This allows commands to be piped together, and have the output of one command flow through to the input of another, making the whole thing much more powerful by allowing the tools to all work together and saving us all time by not having to manually execute multiple commands in a row.
There is a certain ‘ethos’ about command line tools, like the I/O model above, there are ways that command line apps should behave. I’m still learning about exactly what that is, and how that works. If you’ve got any ideas or know of a good resource, feel free to reach out on Threads or Discord and let me know.