First steps around the system
Andy Bates in comp.os.linux.misc, on "intuitive interfaces", slightly defending Macs
"Now I know someone out there is going to claim, 'Well then, UNIX is intuitive, because you only need to learn 5000 commands, and then everything else follows from that! Har har har!'"
Base Debian GNU installation
If you have ever tried any of the commercial Linux distributions (such as Red Hat, Mandrake or SuSE), then the first thing you'll notice about Debian is that you don't get the X Window System or a fancy desktop during the installation (although the new "d-i" installer will perform hardware auto-detection for you). In essence, you don't get any more than a minimum of system software installed.
The commercial Linux companies have set, would you guess it, their commercial interests as a priority, and the whole
Debian, on the other hand, is a non-profit organization that sticks to it's original manifesto and can easily afford itself the luxury of pursuing technical excellence before "market time". For those and other reasons that will come to surface along our journey, you'll see that
Finally, when you get to understand how close to the hardware a Unix user is, and how simple (even trivial) it is to perform hardware configuration in Debian, you'll laugh at anyone who judges or picks Linux distributions to use based on the amount of
With &DEB;, all you get Login: prompt. We'll move from there on.
Shell and filesystem
When you log in to the system (authenticate typically with your user name and password at the shell programs. In general, shell programs serve as agents between the user and the system (accept commands, return output) and are all, infact, more or less sophisticated programming languages.
Computer software is based on files. Files live in directories (/) and serves as an entry point to the filesystem. For example, /home/mirko/.profile (called .profile which resides in the directory /home/mirko/. In this example, mirko/ is obviously a subdirectory of home/, and home/ is a subdirectory of / — the root directory.
Files beginning with a dot (such as .profile from just above) are called dotfiles. They usually contain configuration settings for various programs and are — as such — considered of secondary interest and usually omitted in directory listings. It's the magic dot (.) at the beginning that makes them "invisible", but only for the purpose of not adding noise to the output, and definitely not in hope of "hiding" files.
Each file in Unix belongs to one user and one user group. Additionally, there are file modes (or /home/) and system temporary directories (/tmp and /var/tmp).
Unix filesystem permissions
Although, in the traditional concept, a file or directory belongs to one user and one group,
various advancements have become available over time. Most notably, these include
Access Control List and Role-based Access Control solutions.
ACLs allow files (and directories, of course) to have potentially different permissions for every
system user or group. RBAC systems allow users to be assigned "roles", and thus granted access to
role-related files.
It's important to note, however, that the traditional concept — although trivial in principle
— offers extraordinary flexibility and whole-heartedly satisfies all general needs.
Concerning the filesystem "navigation", there's a concept of
In addition, with Unix, you generally don't need to invent the directory locations for the system software you want to install. Software is installed to pre-determined locations, which is a superior scheme. Some of the directories you need to know about are:
/home - users' home directories
/etc - system-wide configuration files
/bin, /usr/bin, /usr/local/bin - directories with executable files (that is, programs you can run). bin comes from binary, not a dust bin
/lib, /usr/lib, /usr/local/lib - shared libraries needed to support the applications
/sbin, /usr/sbin, /usr/local/sbin - directories with executables supposed to be run by the Superuser
/tmp, /var/tmp - temporary directories, watch out as /tmp is, by default, cleaned out on each reboot
/usr/share/doc, /usr/share/man - complete system documentation
/dev - system device files. In Unix, hardware devices are represented as files
/proc - "virtual" directory (it doesn't really exist on the disk) containing files through which you can query or tune Linux kernel settings
Why software is installed to pre-determined locations is easy to explain:
Unix and Unix filesystems allow
seemingly standard directories and subdirectories to be mounted to completely different places
— local disk partitions, network partitions, or RAM disks, to name a few.
When you need to manage location of files and directories with finer granularity, then
Unix symbolic and hard links, &LNK3;, or
In the above list of directories, you might have noticed a pattern. For example, there's bin/ directory in all /, /usr/ and /usr/local/.
Directories and files found in the root directory (/) are all official distribution files (those from &DEB; or other packages, depending what Unix are we talking about), and infact those that are essential for the system to boot up. This is kind of a historic leftover, from times when systems were booted using the "root" tape, and then had another, "user" tape mounted on /usr/. This technique is, for its usefulness, still used today with all properly set-up Unix systems (well, except maybe &HURD;, if you consider it being part of the same league).
Directories and files in /usr/ are also official distribution files, but are not essential for the system to boot up. A large majority of software belongs to this group.
Finally, directories in /usr/local/ contain locally installed software (which does not come from the official Operating System distribution), hence the separate location and name "local".
There's also the share/ directory that you can see floating around; it contains files which are hardware platform-independent and are the same on all supported architectures.
Manipulating software packages
Now, recall
To see what exactly is each of the programs used for, you could run apt-cache show . If the output scrolls out of your screen too fast, help yourself with the Shift+PageUP/DOWN keys. If the retrieveable area is still too small, run the command with a buffer: apt-cache show (to exit the "pager" program apt-cache, Shift+PageUP/DOWN, less).
For a list of all installed packages, run dpkg -L , such as dpkg -S , such as dpkg -S /bin/bash.
To remove a package, run apt-get --purge remove . The
Sometimes it's not that easy to guess package names, so you'll need to search for them (based on key words). To do so, use apt-cache search , such as
Let's now make use of those programs we installed a moment ago.
Administrative account wrapper
Run command always use a regular system account, and only execute specific privileged commands by using a
Create a non-privileged account now by running the adduser mirko command. Once you've done that, run echo "mirko ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers. The
Having done that, log out completely (by exiting all shells, which means typing Ctrl+d in all active terminals). Then log back in under the newly created, non-privileged username.
To see the sudo and you will not log-in as the superuser any more.
We will use sudo nano .
Unix text editors
Most of Unix system configuration is kept in plain text files, so you'll definitely want to pick your favourite nano now to see its simplicity for yourself. (Keep in mind that the "^" character, needed to access nano's menus, represents the Control / Ctrl key on your keyboard.)
The category of professional text editors, however, is reserved for the two old rivals - Richard Stallman's GNU Emacs and Bram Moolenaar's Visual IMproved (or the old traditional vi). Apart from having ultra fast keystrokes, macros, abbreviations, editing modes, syntax highlighting and keyword completion, Vim can literally solve it's way out of a maze (take a look at /usr/share/doc/vim/macros/maze/ once). Another vi's advantage is it's installed on about every Unix system you can think of. References to the relevant Vim tutorial pages are given at the end of the Guide.
If you have no idea which editor to use, try using nano. Then, once later, you might get around to installing lots of text, even if you'll probably prefer GUIs at first), and learning Vim or GNU Emacs is an absolute necessity.
So invoke sudo update-alternatives --config editor now, and select your favourite
text editor of the moment. (Once selected, this editor will be invoked when the generic
editor command is run).
From now on, we'll assume you know how to open a file, change it and save the changes back to disk.
Basic system commands
You can't start wandering around the Unix system without being introduced to the basic available commands first. Now that you're using an unprivileged account and can't ruin your &DEB; installation any more, we'll take a tour of system file and directory manipulation commands.
To change directory, use the echo $PWD. Try and see where each of the commands
cd /etc,
cd ..,
cd ../.., and
The special tilde character (cd ~ and cd /home/mirko would be equivalent. In addition, if mirko wanted to reach ante's home directory, he would only have to type cd ~ante. (This ability to reach user's home directory using a syntax independent of actual system setup is another winning concept in Unix).
The dash($OLDPWD environment variable do the same thing; they re-position you to the previous working directory. Running the command multiple times would cycle between two most recently used paths.
You can check out the contents of a directory with the ls -al /etc, or
ls -al /
(-a is needed to make — those that start with a dot and are considered "hidden", remember? -l displays the output in list format).
Create new files in your home directory using a text editor — use nano . Alternatively, you could use a variant of the command which is not dependent of the current working directory — nano ~/ for example. Try removing (deleting) the created files with
Briefly note that the previous examples used your keyboard as the input and your monitor as the output device. It's important to understand that Unix can redirect such data ls -al / | grep bin. The output of the ls -al / command will be piping (a special case of redirection, where output is redirected to a program) is, you guess it, denoted by the |") character.
If you'd like to redirect the output of a command to a file (instead of to the next command, as the above pipe would do), use the > or >> redirects; the difference is the double >> appends content to a file without truncating (erasing, roughly) it first. Try say, ls -al / > /tmp/dirlisting.
Sometimes you want the output to appear on both the screen, and saved in a file. This is Unix and it's easily done: ps aux | tee /tmp/ps-aux.listing. We can mention that, in a same way, the output can be "duplicated" to another console (yours or, subject to access permissions, one belonging to a different user). For those who wonder how to get the output on a printer, let's just say
Some other times, you need to create an empty file. For example, try touch , > or >> . The difference is that, if the file already existed, echo > test2 but they don't figure their file isn't exactly empty — it is of size 1 byte and contains 1 ASCII character which represents "newline" (this happens due the echo command appending a newline to the end, unless -n option is given to it).
You now know four command line methods to create a file; try testing your friends'
knowledge.
To save a copy of your interactive (user input-output) session in a file named Ctrl+d on an empty line. As we've said earlier,
When you type say, /bin/ls program becomes a process (a running program). We'll cover processes thoroughly in a separate chapter but, for the moment, let's just say the program you run is assigned a unique
Check system memory information with
Additional and interesting programs related to system and memory status that you could install are
To see a list of
Note that /etc/mtab, and "prettifies" it a little before display. In turn, /etc/mtab should contain content that is essentially the same as /proc/mounts, but this is not always the case (for example, if /etc/ was mounted read-only at time when mount wanted to update the file).
Unless you're really adventureous, you won't happen to see output from the mount command being incorrect, but remember that only /proc/mounts tells the definite truth.
Now, let's say you wanted to execute commands
Use Ctrl+c, the generic "break" signal).
Run
To bring the idea to yet another level, let's say you had a complex chain of commands saved in a file, and wanted to execute the whole file at once (in "batch" mode, as people would say). This is, of course, easily doable with the piping principle mentioned above. Let's first run echo -e "uptime; echo\nfree; echo\ndf" > commands to create our "batch" file. (Additionally, run cat commands to see how the file really looks like and to understand the effect of the newline character cat commands | sh, or sh < commands, or just sh commands. What's more, if you set an executable bit on the batch file (chmod +x commands) and added an appropriate "shebang" line to the file (by opening it and inserting #!/bin/bash at the top), you could run it by invoking ./commands or, more generally, /path/to/commands.
Unix programs come in many variants. They usually have a large set of supported options and successfully interact with each other, effectively multiplying their feature lists. Actually, somewhere I read an interesting thought — that an Unix program can be considered successful if it becomes used in situations never predicted by its author. All of the programs I mentioned above are crucial to Unix and are successful. Their full potential greatly exceeds basic usage examples we provided.
System documentation and reference
&DEB; is a free and open system. All the issues that might pose a problem for you are already documented and explained somewhere. Surely a milestone in your Unix experience is learning where those information sources are, how to interpret their contents, and generally, how to help yourself in predicted and unpredicted situations without someone handholding you.
Unix documentation is extensive and easily available. Most of it is written by the software authors themselves (and not by the nearest marketing department) so you actually have the privilege of communicating to the authors' themselves. The
The process starts with yourself reading the provided documentation to see what do the software authors have to say to you, and to pick a little of their mindset. Debian pays special attention to the documentation; if it's not available from the
In Debian, each package you install creates a /usr/share/doc/PACKAGE/ directory and places at least the package.
The other, very often used, part of the documentation are the system
To get a feeling of [] — in the synopsis line), but at least one directory name to create is mandatory (required). In some manpages, mandatory options are enclosed in <less/greater-than> symbols (like <-s size>).
See the keep reading — and given enough material you'll naturally come to understanding!
Sometimes you only want a general and short, one-line description of a program. See
If you feel you need to ask the community a question, you can either use the various
IRC is your best bet to go over "runtime" issues. Install the /join #debian once you're connected to the server. There are always hundreds of people present on the channel; if your questions are meaningful and don't require people to answer in essays, they'll probably be helpful to you. Spend time on the channel, learn from other people's questions and answers, and don't add to the channel noise. Exit /quit. Mind you, the sole possibility of presenting your question before the technically proficient audience is a great privilege and, of course, you must follow some minimum of the protocol: it's not required that you are familiar with the subject (if that was the case, you wouldn't be asking a question in the first place), but do read Eric Raymond's &LNK5; to increase your chances of recieving useful answers.