Chris Shumway Rewritten by basics The following chapter will cover the basic commands and functionality of the FreeBSD operating system. Much of this material is relevant for any Unix-like operating system. Feel free to skim over this chapter if you are familiar with the material. If you are new to FreeBSD, then you will definitely want to read through this chapter carefully. After reading this chapter, you will know: How Unix file permissions work. What processes, daemons, and signals are. What a shell is, and how to change your default login environment. How to use basic text editors. How to read manual pages for more information. Unix FreeBSD, being a direct descendant of BSD Unix, is 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 You can use the -l command line argument to &man.ls.1; to view a long directory listing that includes a column with information about a file's permissions for the owner, group, and everyone else. Here is how the first column of ls -l 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 hierarchy The FreeBSD directory hierarchy is fundamental to obtaining an overall understanding of the system. The most important concept to grasp is that of the root directory, /. This directory is the first one mounted at boot time and it contains the base system necessary to prepare the operating system for multi-user operation. The root directory also contains mount points for every other file system that you may 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 noauto option. Consult the &man.fstab.5; manual page for more information on the format of the /etc/fstab file and the options it contains. A complete description of the filesystem hierarchy is available in &man.hier.7;. For now, a brief overview of the most common directories will suffice. Directory Description / Root directory of the filesystem. /bin/ User utilities fundamental to both single-user and multi-user environments. /boot/ Programs and configuration files used during operating system bootstrap. /boot/defaults/ Default bootstrapping configuration files; see &man.loader.conf.5;. /dev/ Device nodes; see &man.intro.4;. /etc/ System configuration files and scripts. /etc/defaults/ Default system configuration files; see &man.rc.8;. /etc/mail/ Configuration files for mail transport agents such as &man.sendmail.8;. /etc/namedb/ named configuration files; see &man.named.8;. /etc/periodic/ Scripts that are run daily, weekly, and monthly, via &man.cron.8;; see &man.periodic.8;. /etc/ppp/ ppp configuration files; see &man.ppp.8;. /mnt/ Empty directory commonly used by system administrators as a temporary mount point. /proc/ Process file system; see &man.procfs.5;, &man.mount.procfs.8;. /root/ Home directory for the root account. /sbin/ System programs and administration utilities fundamental to both single-user and multi-user environments. /stand/ Programs used in a standalone environment. /tmp/ Temporary files, usually a &man.mfs.8; memory-based filesystem (the contents of /tmp are usually NOT preserved across a system reboot). /usr/ The majority of user utilities and applications. /usr/bin/ Common utilities, programming tools, and applications. /usr/include/ Standard C include files. /usr/lib/ Archive libraries. /usr/libdata/ Miscellaneous utility data files. /usr/libexec/ System daemons & system utilities (executed by other programs). /usr/local/ Local executables, libraries, etc. Also used as the default destination for the FreeBSD ports framework. Within /usr/local, the general layout sketched out by &man.hier.7; for /usr should be used. Exceptions are the man directory is directly under /usr/local rather than under /usr/local/share. Ports documentation is in share/doc/port. /usr/obj/ Architecture-specific target tree produced by building the /usr/src tree. /usr/ports The FreeBSD ports collection (optional). /usr/sbin/ System daemons & system utilities (executed by users). /usr/share/ Architecture-independent files. /usr/src/ BSD and/or local source files. /usr/X11R6/ X11R6 distribution executables, libraries, etc (optional). /var/ Multi-purpose log, temporary, transient, and spool files. /var/log/ Miscellaneous system log files. /var/mail/ User mailbox files. /var/spool/ Miscellaneous printer and mail system spooling directories. /var/tmp/ Temporary files that are kept between system reboots. /var/yp NIS maps. The filesystem is best visualized as a tree, rooted, as it were, at /. /dev, /usr, and the other directories in the root directory are branches, which may have their own branches, such as /usr/local, and so on. root filesystem There are various reasons to house some of these directories on separate filesystems. /var contains the directories log/, spool/, and various types of temporary files, and as such, may get filled up. Filling up the root filesystem is not a good idea, so splitting /var from / is often favorable. Another common reason to contain certain directory trees on other filesystems is if they are to be housed on separate physical disks, or are separate virtual disks, such as Network File System mounts, or CDROM drives. filesystems mounted with fstab During the boot process, filesystems listed in /etc/fstab are automatically mounted (unless they are listed with the noauto option). The /etc/fstab file contains a list of lines of the following format: device /mount-point fstype options dumpfreq passno device A device name (which should exist), as explained in Disk naming conventions above. mount-point A directory (which should exist), on which to mount the filesystem. fstype The filesystem type to pass to &man.mount.8;. The default FreeBSD filesystem is ufs. options Either rw for read-write filesystems, or ro for read-only filesystems, followed by any other options that may be needed. A common option is noauto for filesystems not normally mounted during the boot sequence. Other options are listed in the &man.mount.8; manual page. dumpfreq This is used by dump to determine which filesystems require dumping. If the field is missing, a value of zero is assumed. passno This determines the order in which filesystems should be checked. Filesystems that should be skipped should have their passno set to zero. The root filesystem (which needs to be checked before everything else) should have it's passno set to one, and other filesystems' passno should be set to values greater than one. If more than one filesystems have the same passno then &man.fsck.8; will attempt to check filesystems in parallel if possible. filesystems mounting The &man.mount.8; command is what is ultimately used to mount filesystems. In its most basic form, you use: &prompt.root; mount device mountpoint There are plenty of options, as mentioned in the &man.mount.8; manual page, but the most common are: -a Mount all the filesystems listed in /etc/fstab. Exceptions are those marked as noauto, excluded by the -t flag, or those that are already mounted. -d Do everything except for the actual system call. This option is useful in conjunction with the -v flag to determine what the mount is actually trying to do. -f Force the mount of an unclean filesystem (dangerous), or forces the revocation of write access when downgrading a filesystem's mount status from read-write to read-only. -r Mount the filesystem read-only. This is identical to using the rdonly argument to the -o option. -t fstype Mount the given filesystem as the given filesystem type, or mount only filesystems of the given type, if given the -a option. ufs is the default filesystem type. -u Update mount options on the filesystem. -v Be verbose. -w Mount the filesystem read-write. The -o option takes a comma-separated list of the options, including the following: nodev Do not interpret special devices on the filesystem. This is a useful security option. noexec Do not allow execution of binaries on this filesystem. This is also a useful security option. nosuid Do not interpret setuid or setgid flags on the filesystem. This is also a useful security option. filesystems unmounting The &man.umount.8; command takes, as a parameter, one of a mountpoint, a device name, or the -a or -A option. All forms take -f to force unmounting, and -v for verbosity. Be warned that -f is not generally a good idea. Forcibly unmounting filesystems might crash the computer or damage data on the filesystem. -a and -A are used to unmount all mounted filesystems, possibly modified by the filesystem types listed after -t. -A, however, does not attempt to unmount the root filesystem. 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 99999, and wrap around back to the beginning when you run out. TT shows the tty the program is running on, and can safely be ignored 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. a displays information about all the running processes, not just your own. u displays the username of the process' owner, as well as memory usage. x displays information about daemon processes, and ww 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 required almost 30 MB of RAM, but is currently only using 9 MB. &man.top.1; automatically updates this display every two seconds; this can be changed with the s option. 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 email 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 actual program that executes 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 communications are called signals, and you can communicate with daemons (or with any running process) by sending it a signal. There are a number of 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, realize 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 do not 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 web server, 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 behavior, 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. 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 ax 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 In common most with Unix commands, &man.kill.1; will not print any output if it is successful. 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. 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 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 tcsh, the improved C-shell. Many other shells are available from the FreeBSD Ports Collection, such as zsh 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 have 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. 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 -s 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 editors A lot of configuration in FreeBSD is done by editing text files. 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. A device is a term used mostly for hardware-related activities in a system, including disks, printers, graphics cards, and keyboards. When FreeBSD boots, the majority of what FreeBSD displays are devices being detected. You can look through the boot messages again by viewing /var/run/dmesg.boot. For example, acd0 is the first IDE CDROM drive, while kbd0 represents the keyboard. Most of these devices in a Unix operating system must be accessed through a special file called device nodes, which are located in the /dev directory. When adding a new device to your system, or compiling in support for additional devices, a device driver often-times needs to be created. On systems without DEVFS, device nodes are created using the &man.MAKEDEV.8; script as shown below: &prompt.root; cd /dev &prompt.root; sh MAKEDEV ad1 This example would make the proper device nodes for the second IDE drive when installed. The device file system, or devfs, provides access to kernel's device namespace in the global filesystem namespace. Instead of having to create and modify device nodes, devfs maintains this particular filesystem for you. See the &man.devfs.5; man page for more information. devfs is used by default in FreeBSD 5.0. manual pages The most comprehensive documentation on FreeBSD is in the form of manual 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 -k 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. Free Software Foundation FreeBSD includes many applications and utilities produced by the Free Software Foundation (FSF). In addition to manual 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 ?.