7 min read linux

Learn How to Learn Linux: Part I

Many people, whether they like to admit it or not, have struggled at some point or another in the process of learning Linux. Even the people that are reading this that think that they’re done learning GNU/Linux the OS, are still going to have to be learning within the GNU/Linux OS forever.

What do I mean by this? One may become familiar with things like static vs dynamically compiled binaries, the ELF binary structure, the difference between user-space and kernel-space. This type of knowledge is what I would consider knowledge of Linux itself, and we'll refer to it as "conceptual knowledge" of Linux.

On the other hand, there is a completely different kind of fluency in Linux that refers to the ability, for example, to clean and explore tabular data like a CSV in Linux or to fluidly “slice & dice” log files via the command line to summarize runtime errors in Linux. This knowledge isn't about a component of Linux but rather refers to a type of pragmatic "know-how" one posseses. We'll call this type of knowledge "procedural knowledge" of Linux.

These two types of knowledge people may have in various capacities based on how they use Linux. For example, a data scientist may have a ton of procedural knowledge of Linux from time spent doing data science at the command-line but lack a core understanding of how Linux itself works. On the other hand, someone with a Computer Science degree that took some classes on operating systems may have a deep understanding of how Linux works internally but have minimal command-line fluency or operational competancy.

In order to say that you "know Linux" in the general sense, however, you're going to want a healthy dose of both. You need a robust ability to get things done in an efficient manner in Linux (preferably at the command line), and you're going to need a decent understanding of what's going on undernearth the hood as you perform these tasks.

Now there's really no one place to acquire this competancy. A classroom may teach you the conceptual knowledge you need but typically procedural knowledge is acquired through blood sweat and tears at a terminal. Likewise, some people may have put in the hours at the command line but are still feeling like they are missing some core knowledge of Linux internals and how things work under the hood.

The purpose of this article is to meet you where you are, wherever you are in your journey in learning Linux, and give you the tools to round out your knowledge of Linux. The good news is that the path I'm going to suggest is the same for everyone, and you can build off of whatever knowledge you have in a meaningful way to do this.

What is this single remedy to learning Linux? It's not a mysterious answer, but rather the man pages. Before you say "that's silly I already know about the man pages!" I implore to you consider the two ideas. How the man pages are a part of a much larger and extremely ambitious documentation project in Linux is not exactly obvious. Additionally – and more importantly, why the man pages are the crux of learning Linux is even less obvious.

Throughout Parts I & II of this article series I'm going to try and illustrate this second point: why the man pages are the crux of learning Linux. In doing so we're going to cover a lot of of the first point. Namely, to outline the general attempt Linux has made at being the first operating-system whose entire manual comes included with the operating system itself and use this to your advantage. Starting to get curious? Keep reading.

Unix Programmer’s Manual I: An attempt at documentation

Dennis Richie & Ken Thompson’s work was published in tandem with the Unix operating system itself, the two sharing a birthday of November 3, 1971.

The original Unix Programmer’s manual included a small amount of system call and executable manuals and was far from comprehensive manual of the Unix I OS. Additionally, the entire thing was distributed as a printed document and had to be ordered and mailed out!

Also worth noting was that at this time, there was no man command due to the lack of a need for a way to view the manual pages on the computer. This will soon change.

Unix Programmer’s Manual II: A fully documented operating system is born

By the time the second Unix Programmer’s Manual had come out the entire manual was now available on networked repositories.

With the digital publication of the man pages and the rendering capabilities developed in themancommand which to more or less rendered roff files that had, in the past, been sent to physical printers instead to a tty for interactive navigation using a pager, Unix v2 was now the the first OS that had ever attempted to be fully self-documenting and provide that documentation in some fashion with the OS itself. Unix v2 came as a complete package.

What began as workplace pain point that Richie & Thompson had begrudgingly started prior to the release of the original Unix had been imbued with a enough passion and discipline by the time the second release had come out it had basically matured into the direct descendent of the man pages we look at today.

In addition to the new network-hosted repositories with Unix II was a new command: man. The man command formatted the text for the screen and displayed them using what is called a pager, which is the program that allows you to scroll up and down the man pages or search through them using a search phrase while displayed on the screen. The default pager on most modern Linux distributions is less but most is a common, more feature rich alternative.

MAN(1)                     Manual pager utils                     MAN(1)
NAME         

       man - an interface to the system reference manuals

SYNOPSIS         

       man [man options] [[section] page ...] ...
       man -k [apropos options] regexp ...
       man -K [man options] [section] term ...
       man -f [whatis options] page ...
       man -l [man options] file ...
       man -w|-W [man options] page ...

DESCRIPTION         

       man is the system's manual pager.  Each page argument given to
       man is normally the name of a program, utility or function.  The
       manual page associated with each of these arguments is then found
       and displayed.  A section, if provided, will direct man to look
       only in that section of the manual.  The default action is to
       search in all of the available sections following a pre-defined
       order (see DEFAULTS), and to show only the first page found, even
       if page exists in several sections.

       The table below shows the section numbers of the manual followed
       by the types of pages they contain.

       1   Executable programs or shell commands
       2   System calls (functions provided by the kernel)
       3   Library calls (functions within program libraries)
       4   Special files (usually found in /dev)
       5   File formats and conventions, e.g. /etc/passwd
       6   Games
       7   Miscellaneous (including macro packages and conventions),
           e.g. man(7), groff(7)
       8   System administration commands (usually only for root)
       9   Kernel routines [Non standard]

       A manual page consists of several sections.

       Conventional section names include NAME, SYNOPSIS, CONFIGURATION,
       DESCRIPTION, OPTIONS, EXIT STATUS, RETURN VALUE, ERRORS,
       ENVIRONMENT, FILES, VERSIONS, CONFORMING TO, NOTES, BUGS,
       EXAMPLE, AUTHORS, and SEE ALSO.

This “man page” is an example of the manual page for the command man. I have bolded some sections to which I would like to direct your attention.

Here we see the 9 man sections enumerated. It also is quick to name some commonly used section names such as DESCRIPTION, OPTIONS, SEE ALSO, etc. We also see some of those section names in action in the man manpage itself: NAME, SYNOPSIS, and DESCRIPTION.

With the release of the Unix Programmer’s Manual v2 the follow traditions had been established:

  1. It is the responsibility of the operating system distributor to package and distribute the correct documentation with its corresponding software.
  2. The manual page corpus will be divided up into sections that cover the breadth of working within the operating system including configuration files, shell commands, and system calls. If the man pages were a book, these would be the chapters.
  3. Manual pages themselves are further divided up into familiar section names, most of which were already established this by this point including NAME, DESCRIPTION, SEE ALSO, etc.

While all of these are important concepts to appreciate as someone learning Linux, the most important of these "traditions" one might call them, is the first: that the operating system will come with a full set of a documentation. This is going to be the an essential fact to keep in the back of your mind always. Whenever in doubt about something in while operating in Linux, know that the answer lies in the palm of your hands.

Finding help documentation in Linux

There are 3 places you will typically see this tradition of the self-documented system evidenced when attempting to find information in Linux or other Unix-based operating systems.

  1. If a command line program, you will be able to append -h or --help to the command and get an abbeviated help document explaining how to use the command.
  2. Using the various sections or "chapters" of the man page corupus, which collectively include all man pages on a given system.
  3. The directories /usr/share and /usr/share/doc for programs that came with your Linux distribution along with /usr/local/share and /usr/local/share/doc for programs that you've installed.

We'll be covering (2) and (3) extensively in this article series. The first you should already be familiar with and if not there's not much more to be said in the context of help documentation except that it exists, so now you know! One additional tip, about (1) - for some commands --help will give an extended version of whatever -h spits out.

Another note, I would search for help in the order listed above. For commands, first try the --help documentation, should that not have the answer, check the man page, and if that does not have the answer to try the appropriate share directory.

There is one notable exception to this rule and that is regarding documentation for commands that come built-in to your shell. These commands are not installed, nor are they provided by your Linux distribution, but rather come compiled into your shell. Commands that fall in this category include those like cd, ls, dirs, and a decent amount of other commands. You can access documentation for these commands by using the help command: just type help [command] just like you would for a man page. For a full list of these commands just type help without any arguments.