Getting Started with the Linux Shell

If you use Linux then at some point you're going to come face to face with the terminal or shell. This can be intimidating to newcomers - particularly those used to Windows; but if you want to use Linux in any depth, and especially if you want to use it professionally, then you need to learn to love the shell. I'm going to give you some tips to get started.

So, first things first: let's clear up some terminology. People often use the words "terminal", "shell", and "Bash" interchangeably; and I might fall into that trap a little here as well. If you want to know more background on the difference between a terminal and a shell then I recommend you watch my read about the Windows Terminal. And yeah, I know that's Windows and this is Linux... but the bit about terminals and shells is the same and there's no sense in me repeating myself.

The short version is that they're both parts of the command-line interface. The terminal is the actual application you interact with - the user interface. The shell is a bit on the back-end that processes your commands. Bash is a shell. It's one of many shells that exist, but it's the most common one you'll come across when you're using Linux; so often when you hear the words "terminal", "shell", or "Bash" they're all referring to that same command-line interface.

OK, but why should you learn to use it? Well, fundamentally I tend to think of Linux as a command-line operating system with extra graphical stuff bolted on top. When I look at this

I don't see Linux, I see Gnome. Linux for me looks more like this;

and yes I know that's a Bash prompt and Linux is really the kernel, but to me this is what Linux looks and feels like.
I most often use Linux on servers or embedded devices and they're usually command-line only because the graphical stuff would just be a waste of resources. If you're using Linux on a desktop you probably will have a graphical environment, but sooner or later you're going to have to change something or fix something and the only way to do it will be to crack open the terminal and get at the guts of your operating system.
The other reason it's useful to learn the shell is for automation or management at scale. Ince you get used to the command line it's much quicker to use and you can easily script your changes and deploy them to multiple systems at once; or you could write some automation to take care of recurring tasks for you. Something that's helpful to understand is that most of the commands you type are actually not parts of Bash itself, but are in fact external programs that you're running.
Let's look at a bit of basic directory navigation as an example. To see where you are in the directory structure type pwd for "print working directory". To change directory it's cd. To list the contents of the current directory the command is ls.  ls -l gives you a long listing which shows additional properties like timestamps, owners, and permissions. pwd and cd are built into Bash. ls is an external program that you're running when you type it.

You don't necessarily need to know which commands are built-in and which are external, but you can get a list of the built-in commands by typing help -d and then help followed by the name of the command for more information about it.

The important point here is that understanding that most commands are actually external programs will help you wrap your head around some of the apparent inconsistencies when using Linux. If you're coming from the Windows world you'll be used to a certain amount of consistency.

Windows is Windows. It's basically the same everywhere. Linux on the other hand can vary a bit. Each distribution packages up the Linux kernel with a ton of different application packages to give you a useful and fully-formed computing experience. Different distributions may choose to include different applications, and different people may further customise their own choices. What this means is you might find a command works on one Linux system, but not the other.

This flexibility is something that many people really like about Linux but it does mean a bit more care is needed if porting the script from one system to another, or if copy-pasting commands you found on the internet. What works on one person's system may not work on yours.

For example, although ls is really the universal standard at this point it is not the only option for listing directory contents. You could install and use exa instead. It behaves in much the same way but adds additional features like colour coding. You might find you prefer using  exa over ls, but if you write scripts using exa there's a good chance they won't work on another computer, whereas ls would. This also goes some way to explain some of the weird and quirky names used for commands.

If you've read about PowerShell you'll have seen that PowerShell cmdlets are all named very logically, which makes it reasonably straightforward to pick up. In the Linux world you basically need to know the name of the command you're looking for. The names often seem random and arbitrary. There is (usually) logic to them, but it might not be immediately apparent.

With PowerShell if you wanted to display the content of a file you would type Get- Content. With Bash you could type cat. Why cat? It's short for "concatenate". If you give it one file you're not concatenating you're just displaying the contents, but the cat command can output the resulting concatenation of multiple files, hence the name.

That's not a useful way to read a long text file, though; so you'd often be better off using less, which gives you the ability to scroll through the file using your arrow keys. It's "q" to quit by the way. But why the name less? The standard for command for scrolling through a file on pretty much every operating system is "more". That makes sense. Show me "more". The "more" commands only works forwards though. The author of "less" wanted something that worked backwards, too. So the name "less" comes from "more, but backwards". There's a sort of quirky logic to it but it's not something that would immediately spring to mind.

If you want to find a particular line in a file you'd likely use grep. If you wanted to find and replace text, one of the most common methods would be to use sed. So where do those names come from? grep is "Globally searched for a Regular Expression and Print matching lines". Yeah, you can see why we use grep instead. sed is "Stream EDitor".

It's all logical... but it's not intuitive. You will get used to it over time, but when you're starting out: Google is your friend. If something you find in Google doesn't work, try adding the name and version of your distribution to your search terms, as it may come with a different application package for the same task. Also remember that you might need to install the application, as with so many options available you don't get every single option installed by default. That's the upside to the apparently indecipherable mess of Linux commands. They're messy because there are loads of them; and for whatever task you're trying to do somebody has probably written a tool to do it.

Linux scripts are often much more concise as a result. Personally, I quite like PowerShell's standardised approach, because it's easy to learn; but it can be rather verbose. Another thing you'll need to do quite frequently with Linux is editing text files. Unlike Windows, which stores settings all over the place; Linux mostly just uses textual configuration files. This much simpler approach has a lot of benefits and it makes it easier to deploy or script changes for pretty much anything.

So how do you edit a text file from the command line? Now, a text editor is a text editor. For me it's just a tool to do a job. For some people it seems to be a religion of sorts. I haven't got time for that. I'm going to show you Vim, but feel free to use whatever you prefer. If you have a dearly held preference then this section of the isn't for you anyway.

Type vi then the name of the file you want to edit. Vim will open in command mode. In command mode your key presses are interpreted as commands. You can navigate and view the file, but if you want to enter new text you have to switch to insert mode by pressing "i". Now you can type and your keypresses will appear at the cursor location. To leave insert mode hit the escape key. To save your changes first make sure you're in command mode and then type ":w" and hit enter. To quit Vim it's ":q". If you've made changes and want to quit without saving them it's ":q!".

I've just thrown a few common commands at you and suggested Google as your best resource to find more, but chances are when you find something on Google you'll find one specific use case for the command and it might not match what exactly you're trying to do. So where do you find details about all of the different options that are available with each command, and how to use them properly?

That's where the "man" command comes in. "man" will display the manual for whatever command you type next. So to see the manual for Vim you could type "man vi". You could even type "man man" to see the manual for "man" itself. This is a great way to find out everything you need to know about a command and its options, although of course assuming you have a computer handy with a web browser you could just Google the same man page online and view it a bit more comfortably.

One-off admin jobs aside, at some point you'll want to use a script to automate a series of tasks. This is largely a case of listing your commands in a text file. Like most scripting languages there is support for variables, and conditional logic such as "if" statements. There are a couple of additional steps you need to take on Linux before your scripts will actually run, though; compared to that other operating system.

The first is the addition of a shebang on the first line of your script. It looks like this.

#!/bin/bash

It starts with a hash and exclamation mark, and gives a path to the intended command-line interpreter. Remember that Linux may come with multiple shells or interpreters, so this line tells the operating system which to use for running your script. The other thing you'll need to do is make the script executable. This is a quick permissions change you can do using chmod +x for executable; but without it you won't be allowed to run the script.

Speaking of permissions... most of the time your account won't have permission to make system-wide changes. Unless you're logged in as the root user, then even if you're using an administrator account your superuser permissions are not automatic - you have to explicitly invoke them. This provides some protection against malicious software because if it happens to run in your user context it doesn't automatically get access to your superuser powers, either.