Getting Started with the Linux Shell

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  thisGetting Started with the Linux Shell I don't see Linux, I see Gnome. Linux for me looks more like this;Getting Started with the Linux Shelland 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 lsls -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.


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.

Comments (0)

    No comments yet

You must be logged in to comment.

Sign In / Sign Up