If you’ve ever had to administer anything like Linux, BSD, Solaris, or similar, you know just how powerful command line can be. Almost any POSIX operating system can be wholly administered from command line. Even Microsoft has started to catch up on administration with advances in Powershell. Command line gives a much easier experience automating and administrating a system at the expense of a harder learning curve.
The command line itself isn’t a tool, but a toolkit. Tools can be different, they can be added, or they can be removed depending on the system, but a given tool is only as useful as its purpose. A hammer doesn’t do much for you when all you have on hands are screws. The nicest bit driver doesn’t help much when you have a tight clearance. Use the right tool for the right job, but make sure to have the right toolkit too.
Command Line for Administration
For administration, command line is basically required to advance. Windows technicians often hit a wall because they neglect learning more about command line and Powershell. The reason command line becomes so important is that it strips out a level of abstraction that can mask ignorance. You are forced to confront what you actually know about the workings of the system.
Basically every Linux or BSD server is going to be running SSH for administration purposes. SSH allows you to connect in as if you’re sitting in front of the machine’s terminal. If you don’t know command line and rely on a GUI on Linux or BSD, you need to either go on site, set up X forwarding somehow (if you don’t know command line, this is going to be hard), or have some other solution to connect in. Adding a GUI introduces a number of security concerns as well for a production server. Most services don’t have a GUI to manage their settings either, even if you decide to push X. You need the command line to manage a Linux or BSD server.
MacOS is in its own weird spot with Apple’s newer security changes, but if you have an MDM set up correctly, MacOS is largely the same as BSD. There are a lot of caveats to this setup and way more than would fit the scope of this article.
Administering Windows
Windows 10 or Server 2016 and above are at the point where you can use the command line exclusively to administer basically any OS setting or operation as well as most Microsoft enterprise products. Certain features for Exchange are only practical via Powershell for many less common operations. This is a trend I expect Microsoft to continue pushing especially with their previous introduction of Server Core which doesn’t have a GUI at all (and amazingly doesn’t need to be rebooted every month).
Most RMM tools offer some kind of command line tool. If you’re administering many machines and need to make a registry change, do you want to call the client or do it from command line? Most Windows remote control solutions take over the session or get expensive for licensing, so you need to either wait for the client to leave (depending on company policy) or get their permission to do work. By not knowing a basic command line tool, you lose out on simplifying your life and theirs.
As you learn more commands and how processes in the operating system work, you can chain these commands together to do more advanced features. You can search the forest for the specific domain to turn on AD recycle bin or to restart the entire networking stack in a specific way. The limitation becomes what tools you know and how well you understand the system.
Command Line for Automation
Once you can do a specific process, you may want to do it again. Certain one-liners may not be worth scripting, but they are if you have to do them a lot. The power of automation comes from it saving time or reducing complexity. My most used script is one which just runs sfc and dism. Automation doesn’t have to complex to reduce complexity for administration.
The first requisite to most automation is learning a scripting language. If you’re administering the same systems you want to automate, you want to learn a language which is relevant to your environment. Every Server 2003 and later system has roughly the same command prompt. Windows 10 and derivatives have Powershell at a usable version. Every MacOS machine has Perl and Bash available. Linux is a bit more flexible, but there’s a good chance Bash is there as well as another scripting language like Perl or Python.
When you learn the command line in Windows, you’re learning the basic components of making a batch script and/or the basics of Powershell. When you do the same in Linux, you learn to make a Bash script. You just have to be able to put the pieces together and any language specific pieces and you can begin saving time by automating mind-numbing tasks. If you have to rename a folder through of files to add a suffix to each one, do you want to do that by hand or with a command? If this process is common, do you want to need to redo it each time, or script it to be reused at will?
Command line usage is the basic currency of a functional script for most system automation. You just glue the rest of the process together with the requisite logic and variables. Bash, Powershell, and similar can all be used to write scripts which go outside of scripting and systems administration, but they aren’t the best at it. That being said, they are all programming languages in their own right.
Command Line for General Usage
The right application of command line can make your life much easier, even if you aren’t in IT. Knowing how to fix basic problems means you can get back to what you want or need to do without having to waste time or money getting someone to fix it for you. I’d much rather use Powershell to remove Windows 10 apps than fight with the store. Certain basic tasks just get that much easier and enable you to go from being a user to a power user.
If you have to rename a hundred files formulaically, do you want to do it by hand or use a basic script? If you need to debug a crash and you know what to look for, do you want to try and open the log and search or use something like grep or find to return only the relevant pieces? A GUI method may work, but when you understand the process, you can save time and frustration doing it from command line. These sorts of tricks are what makes a user become a power user.
I don’t need to open a text editor and highlight lines to delete exactly 54 lines from a block in text, I open vim, navigate where I need, and hit d54, enter, ZZ, enter from escape mode. This of course is a useless exercise if you don’t run into these types of problems. Command line can make general OS usage much more efficiently, but sometimes, it’s easier to just use the GUI for less common tasks.
When Does Command Line Not Work Well?
Some environments can work completely from command line without any impact on functionality and workflow efficiency, such as server environments. Some of the more idealistic Linux crowd I’ve met has moved their workstation entirely to a GUI free environment (SVGAlib or DirectFB) to avoid even having the temptation of using a GUI. While I respect the sheer amount of work put in to make this endeavor even close to functional, it also reads a bit as throwing the baby out with the bathwater.
I personally use a tiling window manager which enables me to launch each and every program with keyboard shortcuts. Options and appearance all need to be configured from editing a config file or similar for the environment. But, what if I want to change the appearance of a Gnome application or similar? I’m just going to pull open the appropriate configuration utility and click what I need. I could theoretically do it from command line, but that becomes a waste of time and effort. Sometimes, a mouse just makes things easier.
The right task calls for the right tool, and sometimes the program isn’t designed with command line in mind. You can work around it sometimes by changing configs or registry entries depending on platform, but sometimes it’s less cognitively taxing and time consuming to just click an option. I’m only going to change a font size permanently roughly once on a given setup, and I don’t need it to help clients, so, I don’t need to learn how to accomplish it from command line outside of morbid curiosity.
The Right Tools for the Right Tasks
The difference between command line and GUI for many tasks is like the difference between a very full standard toolkit and a smaller, more limited specialty set. The specialty set may not have as many tools, or be as useful, or even as good of quality as the standard set, but a tiny jewelers screwdriver set is going to be much better for small projects than your expensive buy it for life PH1 and higher set. Your nice metric set may fit standard (imperial) with the right tricks, but it’s not going to be as efficient as just using a standard set.
Command line will make your life easier for many administration and automation tasks, but it isn’t going to be the best set of tools for every single task. Learn command line for what it makes easier rather than for the sake of a misguided purism towards the power of command line. Command line is extremely powerful for many, many tasks, but even if it can do everything, it may not be the best tool set for every task.
The reverse applies as well. A GUI isn’t going to be as efficient for many tasks command line can do in seconds. Command line provides a set of tools that very little else can deliver. The big difference is you need to spend more time learning what everything does to leverage it, but it makes you a better user and a better administrator. Learn command line, but learn where command line is limited to become the best technician you can be, or go from a user to a power user. It takes me seconds to rename a thousand files, how long does it take you?
Image by Donald Clark from Pixabay