Figure 1-7. MATE desktop with menu
If you are serious about really getting started with Kali and working with it, you may
want to spend some time playing with the different desktop environments. It’s impor‐
tant that you are comfortable and can get around the interface efficiently. If you have
a desktop environment that gets in your way or is hard to navigate, you probably
don’t have a good fit for you. You may try another one. It’s
easy enough to install
additional environments. When we get to package management a little later, you’ll
learn how to install additional packages and, as a result, desktop environments. You
may even discover some that aren’t included in this discussion.
Using the Command Line
You will find over the course of this book that I have a great fondness for the com‐
mand line. There are a lot of reasons for this. For one, I started in computing when
terminals didn’t
have what we call
full screens
. And we certainly didn’t have desktop
environments. What we had was primarily command lines. As a result, I got used to
typing. When I started on Unix systems, all I had was a command line so I needed to
get used to the command set available there. The other reason
for getting comfortable
with the command line is that you can’t always get a UI. You may be working
Using the Command Line | 15
remotely and connecting over a network. This may get you only command-line pro‐
grams without additional work. So, making friends with the command line is useful.
Another reason for getting used to the command line and the locations of program
elements is that GUI programs may have failures or may leave out details that could
be helpful. This may be especially true of some security or forensics tools. As one
example, I much prefer to use The Sleuth Kit (TSK), a collection of command-line
programs,
over the web-based interface, Autopsy, which is more visual. Since
Autopsy sits on top of TSK, it’s just a different way of looking at the information TSK
is capable of generating. The difference is that with Autopsy, you don’t get all of the
details, especially ones that are fairly low level. If you are just learning how to do
things, understanding what is going on may be far more
beneficial than learning a
GUI. Your skills and knowledge will be far more transferable to other situations and
tools. So, there’s that too.
A UI is often called a
shell
. This is true whether you are referring to the program that
manages the desktop or the program that takes commands that you type into a termi‐
nal window. The default shell in Linux is the
Bourne Again Shell
(bash).
This is a play
on the Bourne Shell, which was an early and long-standing shell. However, the
Bourne Shell had limitations and missing features. As a result, in 1989, the Bourne
Again Shell was released. It has since become the common shell in Linux distribu‐
tions. There are two types of commands you will run on the command line. One is
called a
built-in
. This is a function of the shell itself and it doesn’t call out to any other
program—the shell handles it. The other command you will
run is a program that sits
in a directory. The shell has a listing of directories where programs are kept that is
provided (and configurable) through an environment variable.
Keep in mind that Unix was developed by programmers for pro‐
grammers. The point was to create an environment that was both
comfortable and useful for the programmers using it. As a result,
the shell is, as much as anything else,
a programming language and
environment. Each shell has different syntax for the control state‐
ments that it uses, but you can create a program right on the com‐
mand line because, as a programming language, the shell will be
able to execute all of the statements.
In short, we’re going to spend some time with the command line because it’s where
Unix started and it’s also powerful. To start with, you’ll want to get around the filesys‐
tem
and get listings of files, including details like permissions. Other commands that
are useful are ones that manage processes and general utilities.
