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 Ubuntu, 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 all hardware auto-detection for you). In essence, you don't get any more than a minimum of system software installed.
With &DEB; and the basic installation with you X window system, you will get a minimal system with the black console and a 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, in fact, more or less sophisticated programming languages.
Computer software is based on files. Files live in directories (folders), which are located on virtual or physical, local or network disk partitions. In Unix, every system has a /) 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
the POSIX Access Control Lists or Role-based Access Control solutions.
ACLs allow files and directories 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 that doesn't use ACLs or RBAC still
still offers quite acceptable flexibility and satisfies 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
There's also a program called
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. Add it to the sudo
group by running /etc/sudoers, is configured to
grant admin privileges to the group members.
Alternatively, you can run echo "mirko ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers to grant admin privileges
to specific user "mirko". The same effect of this oneline command can, of course, be achieved by opening the file in a text
editor, adding the line and saving it.
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.
This section has turned into an action-packed bunch; get into the right mindset and let's roll!
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, cd ~, cd $HOME or 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 reposition 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. Note that some interesting variants are possible with this that are equal in effect, such as > /tmp/dirlisting ls -al.
Important thing to say is that each process started usually starts with three data streams open; they're called the standard input, standard output and standard error, identified by system "file descriptor" numbers 1, 2 and 3 respectively. This is where the ">" redirects and "|" pipes come to play -- — they influence those descriptors. For example, ls -al / > /tmp/dirlisting (or "1>" instead of just ">") redirects standard output from the screen into a named file; ls -al 2> /tmp/errors redirects any error output to a different file; ls -al / | grep bin redirects standard input from a keyboard to the output of the previous command. In addition, you can of course mix these, such as ls -al / | grep bin > /tmp/stdout 2> /tmp/stderr, and, depending on the shell you use, you can use ">&" to redirect all output (stdout and stderr) at once. In a typical, non-redirected session, the location for all three channels is /dev/tty, a "magical" file that always corresponds to your current console or terminal.
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.
Let's cover some more stuff.
One of them is the shell history. The commands you type, provided that they do not start with a space, are
saved in shell history. The history can be viewed with
Pressing
There's another cool trick allowing you to correct previous line (that is, replace "- " with " -").
For example, if you typed
The shell history of executed commands is saved to a history file (usually ~/.bash_history)
when the shell program cleanly exits, and is thus preserved between sessions.
To prevent history from being written, you can terminate the shell forcibly
with
Shells also support a nice model called "aliases". You can alias any text to a shorter form, and you can then access
the alias, the unaliased command (in case of the same name) and append extra arguments. Here's how: you define an
alias with a syntax ~/.bash_profile for the Bash shell. Note that aliases
are not the only way of packing multiple or long commands in an easily-accessible shorter form — you can do the
same (and more) with shell script files, in which you type commands exactly as if you were executing them on the command line.
Your ~/bin/ directory is the right place for this, as the programs copied there will
be automatically searched by the shell when you log in (see ~/.bash_history for how it happens).
Shells also support the function called "backticks", invoked with the `` quotes. Text within backticks is executed as a
separate command first, and its output is inserted in the original command, which is then executed.
For example, to display current date, you can simply run
Another thing to mention is searching for files and executing commands on them. Let's say you wanted to search for all
MP3 files in your home directory. You'd do this with cd; find . -name '*.mp3'. The first argument to
"mv `find -name '*.mp3'` /some/directory.
However, most MP3 files have spaces and various non-standard characters in their names, so this command would crash and
burn. Besides just not working (because it would treat "abc def" as two files, "abc" and "def"), a specially crafted filename
could cause wreak and havoc. For example, part of the MP3 filename " -f " would actually be understood as the --force
argument to "mv". So the first line of defense is to use "--" after "mv", which instructs the command that everything that
follows is just the list of filenames, not command options. But the problem of spaces and special characters in the filename
would still bite us, because the shell has a variable called "IFS" which treats spaces and newlines as separators. So to
eliminate the whole issue, the proper and superior way to do this, one that is not vulnerable to file names or anything
else is as follows: find -iname '*mp3' -print0 | xargs -0 mv -t /some/directory. The "-print0" option to
"find" will use "\0" (the null character) as record separator; option "-0" to xargs will make xargs understand that, and
xargs will then run the specified command with found filenames as arguments. Xargs would append all filenames at the end of
the specified command, even honoring maximum line lengths (so you avoid the "Argument list too long" errors). If the command
you're invoking does not support multiple filenames, or you want to run it on a file by file basis, pass "-n 1" option to
xargs. Finally, if the filename is supposed to be inserted in the middle of the xargs command line (and not automatically at the
end), use "{}" to mark the point of insertion.
OK, fine. Unix programs come in many variants, and with many options (as you have been demonstrated in this section ;-). They usually have a large set of supported options and successfully interact with each other, effectively multiplying their feature lists. I've read somewhere an interesting thought — that a 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, and it is implicitly assumed you should look up their documentation (
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 (although on some IRC channels, there are now bots that collect logs and publish them online, and thus having the same problem as mailing lists). 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.