diff --git a/en_US.ISO8859-1/books/handbook/basics/chapter.sgml b/en_US.ISO8859-1/books/handbook/basics/chapter.sgml index b2e81b5cd7..661d608bd7 100644 --- a/en_US.ISO8859-1/books/handbook/basics/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/basics/chapter.sgml @@ -1,596 +1,885 @@ Chris Shumway Rewritten Unix Basics Synopsis basics The following chapter will cover the basic commands and functionality of the FreeBSD operating system. If you are new to FreeBSD, you will definitely want to read through this chapter before asking for help. Permissions Unix FreeBSD, having its history rooted in BSD Unix, has its fundamentals based on several key Unix concepts. The first, and most pronounced, is that FreeBSD is a multi-user operating system. The system can handle several users all working simultaneously on completely unrelated tasks. The system is responsible for properly sharing and managing requests for hardware devices, peripherals, memory, and CPU time evenly to each user. Because the system is capable of supporting multiple users, everything the system manages has a set of permissions governing who can read, write, and execute the resource. These permissions are stored as two octets broken into three pieces, one for the owner of the file, one for the group that the file belongs to, and one for everyone else. This numerical representation works like this: permissions file permissions Value Permission Directory Listing 0 No read, no write, no execute --- 1 No read, no write, execute --x 2 No read, write, no execute -w- 3 No read, write, execute -wx 4 Read, no write, no execute r-- 5 Read, no write, execute r-x 6 Read, write, no execute rw- 7 Read, write, execute rwx ls directories For the long directory listing by ls -l, a column will show a file's permissions for the owner, group, and everyone else. Here's how it is broken up: -rw-r--r-- The first character, from left to right, is a special character that tells if this is a regular file, a directory, a special character or block device, a socket, or any other special pseudo-file device. The next three characters, designated as rw- gives the permissions for the owner of the file. The next three characters, r-- gives the permissions for the group that the file belongs to. The final three characters, r--, gives the permissions for the rest of the world. A dash means that the permission is turned off. In the case of this file, the permissions are set so the owner can read and write to the file, the group can read the file, and the rest of the world can only read the file. According to the table above, the permissions for this file would be 644, where each digit represents the three parts of the file's permission. This is all well and good, but how does the system control permissions on devices? FreeBSD actually treats most hardware devices as a file that programs can open, read, and write data to just like any other file. These special device files are stored on the /dev directory. Directories are also treated as files. They have read, write, and execute permissions. The executable bit for a directory has a slightly different meaning than that of files. When a directory is marked executable, it means it can be searched into, for example, a directory listing can be done in that directory. There are more to permissions, but they are primarily used in special circumstances such as setuid binaries and sticky directories. If you want more information on file permissions and how to set them, be sure to look at the &man.chmod.1; man page. Directory Structures directory hierarchy Since FreeBSD uses its file systems to determine many fundamental system operations, the hierarchy of the file system is extremely important. Due to the fact that the &man.hier.7; man page provides a complete description of the directory structure, it will not be duplicated here. Please read &man.hier.7; for more information. Of significant importance is the root of all directories, the / directory. This directory is the first directory mounted at boot time and it contains the base system necessary at boot time. The root directory also contains mount points for every other file system that you want to mount. A mount point is a directory where additional file systems can be grafted onto the root file system. Standard mount points include /usr, /var, /mnt, and /cdrom. These directories are usually referenced to entries in the file /etc/fstab. /etc/fstab is a table of various file systems and mount points for reference by the system. Most of the file systems in /etc/fstab are mounted automatically at boot time from the script &man.rc.8; unless they contain the option. Consult the &man.fstab.5; manual page for more information on the format of the /etc/fstab file and the options it contains. + + Processes + + FreeBSD is a multi-tasking operating system. This means that it + seems as though more than one program is running at once. Each program + running at any one time is called a process. + Every command you run will start at least one new process, and there are + a number of system processes that run all the time, keeping the system + functional. + + Each process is uniquely identified by a number called a + process ID, or PID, and, + like files, each process also has one owner and group. The owner and + group information is used to determine what files and devices the + process can open, using the file permissions discussed earlier. Most + processes also have a parent process. The parent process is the process + that started them. For example, if you are typing commands to the shell + then the shell is a process, and any commands you run are also + processes. Each process you run in this way will have your shell as its + parent process. The exception to this is a special process called + init. init is always the first + process, so its PID is always 1. init is started + automatically by the kernel when FreeBSD starts. + + Two commands are particularly useful to see the processes on the + system, &man.ps.1; and &man.top.1;. The &man.ps.1; command is used to + show a static list of the currently running processes, and can show + their PID, how much memory they are using, the command line they were + started with, and so on. The &man.top.1; command displays all the + running processes, and updates the display every few seconds, so that + you can interactively see what your computer is doing. + + By default, &man.ps.1; only shows you the commands that are running + and are owned by you. For example; + + &prompt.user; ps + PID TT STAT TIME COMMAND + 298 p0 Ss 0:01.10 tcsh + 7078 p0 S 2:40.88 xemacs mdoc.xsl (xemacs-21.1.14) +37393 p0 I 0:03.11 xemacs freebsd.dsl (xemacs-21.1.14) +48630 p0 S 2:50.89 /usr/local/lib/netscape-linux/navigator-linux-4.77.bi +48730 p0 IW 0:00.00 (dns helper) (navigator-linux-) +72210 p0 R+ 0:00.00 ps + 390 p1 Is 0:01.14 tcsh + 7059 p2 Is+ 1:36.18 /usr/local/bin/mutt -y + 6688 p3 IWs 0:00.00 tcsh +10735 p4 IWs 0:00.00 tcsh +20256 p5 IWs 0:00.00 tcsh + 262 v0 IWs 0:00.00 -tcsh (tcsh) + 270 v0 IW+ 0:00.00 /bin/sh /usr/X11R6/bin/startx -- -bpp 16 + 280 v0 IW+ 0:00.00 xinit /home/nik/.xinitrc -- -bpp 16 + 284 v0 IW 0:00.00 /bin/sh /home/nik/.xinitrc + 285 v0 S 0:38.45 /usr/X11R6/bin/sawfish + + As you can see in this example, the output from &man.ps.1; is + organized in to a number of columns. PID is the + process ID discussed earlier. PIDs are assigned starting from 1, go up + to 65536, and wrap around back to the beginning when you run out. + TT shows the tty the program is running on, and can + safely be ignore for the moment. STAT shows the + program's state, and again, can be safely ignored. + TIME is the amount of time the program has been + running on the CPU—this is not necessarily the elapsed time since + you started the program, as some programs spend a lot of time waiting + for things to happen before they need to spend time on the CPU. + Finally, COMMAND is the command line that was used to + run the program. + + &man.ps.1; supports a number of different options to change the + information that is displayed. One of the most useful sets is + auxww. displays information + about all the running processes, not just your own. + displays the username of the process' owner, as well as memory usage. + displays information about daemon processes, and + causes &man.ps.1; to display the full command line, + rather than truncating it once it gets too long to fit on the + screen. + + The output from &man.top.1; is similar. A sample session looks like + this; + + &prompt.user; top +last pid: 72257; load averages: 0.13, 0.09, 0.03 up 0+13:38:33 22:39:10 +47 processes: 1 running, 46 sleeping +CPU states: 12.6% user, 0.0% nice, 7.8% system, 0.0% interrupt, 79.7% idle +Mem: 36M Active, 5256K Inact, 13M Wired, 6312K Cache, 15M Buf, 408K Free +Swap: 256M Total, 38M Used, 217M Free, 15% Inuse + + PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND +72257 nik 28 0 1960K 1044K RUN 0:00 14.86% 1.42% top + 7078 nik 2 0 15280K 10960K select 2:54 0.88% 0.88% xemacs-21.1.14 + 281 nik 2 0 18636K 7112K select 5:36 0.73% 0.73% XF86_SVGA + 296 nik 2 0 3240K 1644K select 0:12 0.05% 0.05% xterm +48630 nik 2 0 29816K 9148K select 3:18 0.00% 0.00% navigator-linu + 175 root 2 0 924K 252K select 1:41 0.00% 0.00% syslogd + 7059 nik 2 0 7260K 4644K poll 1:38 0.00% 0.00% mutt +... + + The output is split in to two sections. The header (the first five + lines) shows the PID of the last process to run, the system load averages + (which are a measure of how busy the system is), the system uptime (time + since the last reboot) and the current time. The other figures in the + header relate to how many processes are running (47 in this case), how + much memory and swap space has been taken up, and how much time the + system is spending in different CPU states. + + Below that are a series of columns containing similar information + to the output from &man.ps.1;. As before you can see the PID, the + username, the amount of CPU time taken, and the command that was run. + &man.top.1; also defaults to showing you the amount of memory space + taken by the process. This is split in to two columns, one for total + size, and one for resident size—total size is how much memory the + application has needed, and the resident size is how much it is actually + using at the moment. In this example you can see that Netscape has + needed almost 30MB of RAM, and is currently only needing 9MB. + + &man.top.1; automatically updates this display every two seconds; + this can be changed with the option. + + + + Daemons, signals, and killing processes + + When you run an editor it is easy to control the editor, tell it to + load files, and so on. You can do this because the editor provides + facilities to do so, and because the editor is attached to a + terminal. Some programs are not designed to be + run with continuous user input, and so they disconnect from the terminal + at the first opportunity. For example, a web server spends all day + responding to web requests, it normally does not need any input from + you. Programs that transport e-mail from site to site are another + example of this class of application. + + We call these programs daemons. Daemons were + characters in Greek mythology; neither good or evil, they were little + attendant spirits that, by and large, did useful things for mankind. + Much like the web servers and mail servers of today do useful things. + This is why the BSD mascot has, for a long time, been the cheerful + looking daemon with sneakers and a pitchfork. + + There is a convention to name programs that normally run as daemons + with a trailing d. BIND is the + Berkeley Internet Name Daemon (and the program you can is called + named), the Apache web + server program is called httpd, the line printer + spooling daemon is lpd and so on. This is a + convention, not a hard and fast rule; for example, the main mail daemon + for the Sendmail application is called + sendmail, and not maild, as you + might imagine. + + Sometimes you will need to communicate with a daemon process. These + commmunications are called signals, and you can + communicate with daemons (or with any running process) by sending it a + signal. There are a number if different signals that you can + send—some of them have a specific meaning, others are interpreted + by the application, and the application's documentation will tell you + how that application interprets signals. You can only send a signal to + a process that you own. If you try and send a signal to someone else's + process it will be ignored. The exception to this is the + root user, who can send signals to everyone's + processes. + + FreeBSD will also send applications signals in some cases. If an + application is badly written, and tries to access memory that it is not + supposed to, FreeBSD sends the process the Segmentation + Violation signal (SIGSEGV). If an + application has used the &man.alarm.3; system call to be alerted after a + period of time has elapsed then it will be sent the Alarm signal + (SIGALRM), and so on. + + Two signals can be used to stop a process, + SIGTERM and SIGKILL. + SIGTERM is the polite way to kill a process; the + process can catch the signal, realise that you want + it to shut down, close any log files it may have open, and generally + finish whatever it is doing at the time before shutting down. In some + cases a process may even ignore SIGTERM if it is in + the middle of some task that can not be interrupted. + + SIGKILL can not be ignored by a process. This is + the I don't care what you are doing, stop right now + signal. If you send SIGKILL to a process then + FreeBSD will stop that process there and then + Not quite true—there are a few things that can not be + interrupted. For example, if the process is trying to read from a + file that is on another computer on the network, and the other + computer has gone away for some reason (been turned off, or the + network has a fault), then the process is said to be + uninterruptible. Eventually the process will time + out, typically after two minutes. As soon as this time out occurs + the process will be killed. + . + + The other signals you might want to use are + SIGHUP, SIGUSR1, and + SIGUSR2. These are general purpose signals, and + different applications will do different things when they are + sent. + + Suppose that you have changed your web server's configuration + file—you would like to tell the web server to re-read its + configuration. You could stop and restart httpd, but + this would result in a brief outage period on your webserver, which may + be undesirable. Most daemons are written to respond to the + SIGHUP signal by re-reading their configuration + file. So instead of killing and restarting httpd you + would send it the SIGHUP signal. Because there is no + standard way to respond to these signals, different daemons will have + different behaviour, so be sure and read the documentation for the + daemon in question. + + Signals are sent using the &man.kill.1; command, as this example + shows. + + + Sending a signal to a process + + This example shows how to send a signal to &man.inetd.8;. The + &man.inetd.8; configuration file is + /etc/inetd.conf, and &man.inetd.8; will re-read + this configuration file when it is sent + SIGHUP. + + + Find the process ID of the process you want to send the signal + to. Do this using &man.ps.1; and &man.grep.1;. The &man.grep.1; + command is used to search through output, looking for the string you + specify. This command is run as a normal user, and &man.inetd.8; is + run as root, so the options + must be given to &man.ps.1;. + + &prompt.user; ps -ax | grep inetd + 198 ?? IWs 0:00.00 inetd -wW + + So the &man.inetd.8; PID is 198. In some cases the + grep inetd command might also occur in this + output. This is because of the way &man.ps.1; has to find the list + of running processes. + + + + Use &man.kill.1; to send the signal. Because &man.inetd.8; is + being run by root you must use &man.su.1; to + become root first. + + &prompt.user; su +Password: +&prompt.root; /bin/kill -s HUP 198 + + As is common with Unix commands, &man.kill.1; will not print any + output if it is successfully. If you try and send a signal to a + process that you do not own then you will see kill: + PID: Operation not + permitted. If you mistype the PID you will either + send the signal to the wrong process, which could be bad, or, if + you are lucky, you will have sent the signal to a PID that is not + currently in use, and you will see kill: + PID: No such process. + + + Why use <command>/bin/kill</command>? + + Many shells provide the kill command as a + built in command; that is, the shell will send the signal + directly, rather than running /bin/kill. + This can be very useful, but different shells have a different + syntax for specifying the name of the signal to send. Rather than + try to learn all of them, it can be simpler just to use the + /bin/kill ... + command directly. + + + + + Sending other signals is very similar, just substitute + TERM or KILL in the command line + as necessary. + + + Killing random process on the system can be a bad idea. In + particular, &man.init.8;, process ID 1, is very special. Running + /bin/kill -s KILL 1 is a quick way to shutdown your + system. Always double check the arguments you + run &man.kill.1; with before you press + RETURN. + + + Shells shells command-line In FreeBSD, a lot of everyday work is done in a command line interface called a shell. A shell's main job is to take commands from the input channel and execute them. A lot of shells also have built in functions to help everyday tasks such a file management, file globing, command line editing, command macros, and environment variables. FreeBSD comes with a set of shells, such as sh, the Bourne Shell, and csh, the C-shell. Many other shells are available from the FreeBSD Ports Collection that have much more power, such as tcsh and bash. Which shell do you use? It is really a matter of taste. If you are a C programmer you might feel more comfortable with a C-like shell such as tcsh. If you've come from Linux or are new to a Unix command line interface you might try bash. The point is that each shell has unique properties that may or may not work with your preferred working environment, and that you have a choice of what shell to use. One common feature in a shell is file-name completion. Given the typing of the first few letters of a command or filename, you can usually have the shell automatically complete the rest of the command or filename by hitting the TAB key on the keyboard. Here is an example. Suppose you have two files called foobar and foo.bar. You want to delete foo.bar. So what you would type on the keyboard is: rm fo[TAB].[TAB]. The shell would print out rm foo[BEEP].bar. The [BEEP] is the console bell, which is the shell telling me it was unable to totally complete the filename because there is more than one match. Both foobar and foo.bar start with fo, but it was able to complete to foo. If you type in ., then hit TAB again, the shell would be able to fill in the rest of the filename for you. environment variables Another function of the shell is environment variables. Environment variables are a variable key pair stored in the shell's environment space. This space can be read by any program invoked by the shell, and thus contains a lot of program configuration. Here is a list of common environment variables and what they mean: environment variables Variable Description USER Current logged in user's name. PATH Colon separated list of directories to search for binaries. DISPLAY Network name of the X11 display to connect to, if available. SHELL The current shell. TERM The name of the user's terminal. Used to determine the capabilities of the terminal. TERMCAP Database entry of the terminal escape codes to perform various terminal functions. OSTYPE Type of operating system. E.g., FreeBSD. MACHTYPE The CPU architecture that the system is running on. EDITOR The user's preferred text editor. PAGER The user's preferred text pager. MANPATH Colon separated list of directories to search for manual pages. Bourne shells To view or set an environment variable differs somewhat from shell to shell. For example, in the C-Style shells such as tcsh and csh, you would use setenv to set and view environment variables. Under Bourne shells such as sh and bash, you would use set and export to view and set your current environment variables. For example, to set or modify the EDITOR environment variable, under csh or tcsh a command like this would set EDITOR to /usr/local/bin/emacs: &prompt.user; setenv EDITOR /usr/local/bin/emacs Under Bourne shells: &prompt.user; export EDITOR="/usr/local/bin/emacs" You can also make most shells expand the environment variable by placing a $ character in front of it on the command line. For example, echo $TERM would print out whatever $TERM is set to, because the shell expands $TERM and passes it on to echo. Shells treat a lot of special characters, called meta-characters as special representations of data. The most common one is the * character, which represents any number of characters in a filename. These special meta-characters can be used to do file name globing. For example, typing in echo * is almost the same as typing in ls because the shell takes all the files that match * and puts them on the command line for echo to see. To prevent the shell from interpreting these special characters, they can be escaped from the shell by putting a backslash (\) character in front of them. echo $TERM prints whatever your terminal is set to. echo \$TERM prints $TERM as is. Changing your shell The easiest way to change your shell is to use the chsh command. Running chsh will place you into the editor that is in your EDITOR environment variable; if it is not set, you will be placed in vi. Change the Shell: line accordingly. You can also give chsh the option; this will set your shell for you, without requiring you to enter an editor. For example, if you wanted to change your shell to bash, the following should do the trick: &prompt.user; chsh -s /usr/local/bin/bash Running chsh with no parameters and editing the shell from there would work also. The shell that you wish to use must be present in the /etc/shells file. If you have installed a shell from the ports collection, then this should have been done for you already. If you installed the shell by hand, you must do this. For example, if you installed bash by hand and placed it into /usr/local/bin, you would want to: &prompt.root; echo "/usr/local/bin/bash" >> /etc/shells Then rerun chsh. Text Editors text editors editors A lot of configuration in FreeBSD is done by editing a text file. Because of this, it would be a good idea to become familiar with a text editor. FreeBSD comes with a few as part of the base system, and many more are available in the ports collection. ee The easiest and simplest editor to learn is an editor called ee, which stands for easy editor. To start ee, one would type at the command line ee filename where filename is the name of the file to be edited. For example, to edit /etc/rc.conf, type in ee /etc/rc.conf. Once inside of ee, all of the commands for manipulating the editor's functions are listed at the top of the display. The caret ^ character means the control key on the keyboard, so ^e expands to pressing the control key plus the letter e. To leave ee, hit the escape key, then choose leave editor. The editor will prompt you to save any changes if the file has been modified. vi editors vi emacs editors emacs FreeBSD also comes with more powerful text editors such as vi as part of the base system, and emacs and vim as part of the FreeBSD Ports Collection. These editors offer much more functionality and power at the expense of being a little more complicated to learn. However if you plan on doing a lot of text editing, learning a more powerful editor such as vim or emacs will save you much more time in the long run. For More Information... Manual pages man pages The most comprehensive documentation on FreeBSD is in the form of man pages. Nearly every program on the system comes with a short reference manual explaining the basic operation and various arguments. These manuals can be viewed with the man command. Use of the man command is simple: &prompt.user; man command command is the name of the command you wish to learn about. For example, to learn more about ls command type: &prompt.user; man ls The online manual is divided up into numbered sections: User commands. System calls and error numbers. Functions in the C libraries. Device drivers. File formats. Games and other diversions. Miscellaneous information. System maintenance and operation commands. Kernel developers. In some cases, the same topic may appear in more than one section of the online manual. For example, there is a chmod user command and a chmod() system call. In this case, you can tell the man command which one you want by specifying the section: &prompt.user; man 1 chmod This will display the manual page for the user command chmod. References to a particular section of the online manual are traditionally placed in parenthesis in written documentation, so &man.chmod.1; refers to the chmod user command and &man.chmod.2; refers to the system call. This is fine if you know the name of the command and simply wish to know how to use it, but what if you cannot recall the command name? You can use man to search for keywords in the command descriptions by using the switch: &prompt.user; man -k mail With this command you will be presented with a list of commands that have the keyword mail in their descriptions. This is actually functionally equivalent to using the apropos command. So, you are looking at all those fancy commands in /usr/bin but do not have the faintest idea what most of them actually do? Simply do: &prompt.user; cd /usr/bin &prompt.user; man -f * or &prompt.user; cd /usr/bin &prompt.user; whatis * which does the same thing. GNU Info Files Free Software Foundation FreeBSD includes many applications and utilities produced by the Free Software Foundation (FSF). In addition to man pages, these programs come with more extensive hypertext documents called info files which can be viewed with the info command or, if you installed emacs, the info mode of emacs. To use the &man.info.1; command, simply type: &prompt.user; info For a brief introduction, type h. For a quick command reference, type ?.