diff options
Diffstat (limited to 'gnome-users-guide/gnome-users-guide-1.4/C/newbies.sgml')
| -rw-r--r-- | gnome-users-guide/gnome-users-guide-1.4/C/newbies.sgml | 719 |
1 files changed, 719 insertions, 0 deletions
diff --git a/gnome-users-guide/gnome-users-guide-1.4/C/newbies.sgml b/gnome-users-guide/gnome-users-guide-1.4/C/newbies.sgml new file mode 100644 index 0000000..e53263b --- /dev/null +++ b/gnome-users-guide/gnome-users-guide-1.4/C/newbies.sgml @@ -0,0 +1,719 @@ +<appendix id="newbies" label="A"> + <title> If you are new to Linux/UNIX</title> + + <para> One of the goals of GNOME is to make your system easy to use, + without requiring you to learn the syntax of most UNIX commands. + However, there are some basic UNIX notions that you have to be + familiar with, even while using the easy graphical interface + provided by GNOME. For the convenience of new users, these basics + are collected in this appendix. If you need further information on + UNIX, you should read the documentation which came with your + system; there are also a number of books and on-line guides + available for all versions of UNIX. + </para> + + <para> The following guide applies to all versions of UNIX and + UNIX-like operating systems, including both the commercial Unices + such as <systemitem>Solaris</systemitem> and open-source operating + systems such as <systemitem>FreeBSD</systemitem> and + <systemitem>Linux</systemitem>. Some of the material here is based + on <citetitle>Linux Installation and Getting Started</citetitle> + guide, by Matt Welsh, Phil Hughes, David Bandel, Boris Beletsky, + Sean Dreilinger, Robert Kiesling, Evan Liebovitch, and Henry + Pierce. The guide is available for download or online viewing from + the <ulink url="http://www.linuxdoc.org" type="http">Linux + Documentation Project</ulink> or from the <ulink + url="http://www.oswg.org">Open Source Writers Group</ulink>. + </para> + <sect1 id="new-users"> + <title>Users</title> + <para> UNIX is a multiuser operating system: it + was designed to allow many users to work on the same computer, + either simultaneously (using several terminals or network + connections) or in turns. Under UNIX, to identify yourself to + the system, you must log in, which entails entering your + <emphasis>login name</emphasis> (the name the system uses to identify + you) and your <emphasis>password</emphasis>, which is your personal key + for logging in to your account. Because only you know your + password, no one else can log in to the system under your user + name. Usually people choose their first or last name or some + variation of it as their login name, so that if your real name + is Sasha Beilinson, your login might be <systemitem>sasha</systemitem>. + </para> + <para> Each user has a separate place to keep his files (called + his <emphasis>home directory</emphasis>). UNIX has a system of + permissions (see <xref linkend="permissions">), so that on a + properly configured UNIX system a user can't change other users' + or system files. This also allows every user to customize + various aspects of the system — in particular, GNOME + behavior — for himself, without affecting other users. + </para> + <para> On any UNIX system there is also a special user, called + <emphasis>system administrator</emphasis>, with the login name + <systemitem>root</systemitem>. He has <emphasis>full</emphasis> + control over the system — including full access to all the + system and users' files. He has the authority to change the + passwords of existing users and add new users, install and + uninstall software, and so on. The system administrator is + usually the person responsible for proper functioning of the + system, so if you have some problems, you should ask him. + </para> + <important> + <title>IMPORTANT</title> + <para> + Even if you are the only user on your computer (for example, + if the computer is your personal workstation), so that you are + also the system administrator, it is important that you create + a user account and use it for daily work, logging in as root + only when necessary for system maintenance. Because root can + do anything, it is easy to make mistakes that have + catastrophic consequences. Picture the root account as a + magic hat that gives you lots of power, with which you can, by + waving your hands, create or destroy entire cities. Because + it is easy to wave your hands in a destructive manner, it is + not a good idea to wear the magic hat when it is not needed, + despite the wonderful feeling. + </para> + </important> + </sect1> + <sect1 id="new-file"> + <title>Files and filenames</title> + <para> + Under most operating systems (including UNIX), there is the + concept of a <emphasis>file</emphasis>, which is just a bundle of + information given a name (called a + <emphasis>filename</emphasis>). Examples of files might be + your history term paper, an e-mail message, or an actual + program that can be executed. Essentially, anything saved on + disk is saved in an individual file. + </para> + <sect2 id="new-filenames"> + <title>Filenames</title> + <para> + Files are identified by their filenames. For example, the file + containing your conference talk might be saved with the filename + <filename>talk.txt</filename>. There is no standard format for file + names as there is under MS-DOS and some other operating systems; in + general, a filename can contain any character (except the / + character–see the discussion of path names below) and is + limited to 256 characters in length. + </para> + <important> + <title>IMPORTANT</title> + <para> + Unlike MS-DOS, the filenames in UNIX are case-sensitive: + <filename>myfile.txt</filename> and + <filename>MyFile.txt</filename> are considered as two + different files. + </para> + </important> + <para> + You should also be aware of several UNIX conventions; while they are + not mandatory, it is usually a good idea to follow them. + <itemizedlist> + <listitem> + <para> It is customary to use the format + <filename>filename.extension</filename> for filenames, where the + extension indicates the file type; for example, the + extension <filename>txt</filename> is usually used for plain + text files, while the extension <filename>jpeg</filename> is + used for graphics in JPEG format, and so on. In + particular, the <application>Nautilus File + Manager</application> (<application>Nautilus</application>) + uses extensions to determine file type. You can view all + the file extensions recognized by + <application>Nautilus</application> by choosing the + <guimenuitem>File types and Programs</guimenuitem> capplet in the + <guimenu>Document Handlers</guimenu> section of the + <application>Control-center</application>. Note that the standard + convention in UNIX is that the + <emphasis>executables</emphasis> (i.e., the program + files) have no extension at all. + </para> + </listitem> + + <listitem> + <para> Files and directories whose names begin with a dot + (.) are usually <emphasis>configuration + files</emphasis>, that is, files which keep settings and + preferences for various applications. For example, GNOME + keeps all its settings in various files in the directories + <filename>.gnome</filename> and + <filename>.gnome-desktop</filename> in the user's home + directory. Since most of the time you do not need to + edit these files manually, or even know their precise + names and locations, <application>Nautilus</application> + usually doesn't show these files. You can change this + setting using the <guimenuitem>Preferences</guimenuitem> dialog. + </para> + </listitem> + + <listitem> + <para> Files with names ending with tilde (~) are + usually backup files created by various + applications. For example, when you edit a file + <filename> myfile.txt</filename> with + <application>emacs</application>, it + saves the previous version in the file + <filename>myfile.txt~</filename>. Again, you can control whether + you want Nautilus File Manager to show these files or not + in <guimenuitem>Preferences</guimenuitem> dialog. + </para> + </listitem> + </itemizedlist> + </para> + </sect2> + <sect2 id="new-wildcards"> + <title> Wildcards</title> + + <para>When entering commands from the command line, you can use + so-called <emphasis>wildcards</emphasis> instead of an exact + filename. The most common wildcard is *, which matches any + sequence of symbols (including an empty string). For example, + the command <command>ls *.txt</command> will list all the files with + the extension <filename>txt</filename>, and the command <command>rm + chapter*</command> will remove all files with the names starting with + <filename>chapter</filename> (<command>ls</command> and + <command>rm</command> are UNIX + commands for listing and removing files). Another useful + wildcard is ?, which matches any single symbol: for example, + <command>rm chapter?.txt</command> will remove files + <filename>chapter1.txt, chapter2.txt</filename> , but not + <filename>chapter10.txt</filename> + </para> + </sect2> + + <sect2 id="quoting"> + <title>Using spaces, commas, etc. in file names</title> + <para> + As was mentioned above, a file name may contain not only + letters and numbers, but also spaces, commas, etc. - any + characters other than slash (/). However, if you are using + commands typed on the command line, you should be careful when + dealing with such files. For example, if you have a file named + <filename>My file</filename>, and you want to delete it, + typing <command>rm My file</command> will not give the desired + effect: the command <command>rm</command> will assume that you + want to remove files <filename>My</filename> and + <filename>file</filename>. At best, it will give you an error + message; at worst (if you do have a file named + <filename>My</filename>) it will remove a wrong file. The + right way to do this is to enclose the file name in single + quotes: <command>rm 'My File'</command>. The same should be + done for file names containing any symbols that are normally + considered as "separators", or have some special meaning; this + includes comma (,), star (*), question mark (?), and more. To + be on the safe side, quote in this way all file names that + contain anything other than letters, numbers, and + dots. </para> + <para> + Of course, if you are only using graphical tools such as Nautilus + File Manager, than you do not need to worry about this: to + delete file <filename>My file</filename>, just drag it to the + trash can. + </para> + </sect2> + + </sect1> + <sect1 id="new-dirs"> + <title>Directories and paths</title> + <sect2 id="new-dirstruct"> + <title>Directory structure</title> + <para> + Now, let's discuss the concept of directories. A + <emphasis>directory</emphasis> is a collection of files. It + can be thought of as a "folder" that contains many different + files. Directories are given names, with which they can be + identified. Furthermore, directories are maintained in a + tree-like structure; that is, directories may contain other + directories. The top level directory is called the "root + directory" and denoted by <filename>/</filename>; it contains + all the files in your system. + </para> + <sect3 id="new-path"> + <title>Pathnames</title> + <para> + A <emphasis>pathname</emphasis> is a file's "full name"; it + contains not only filename but also its locaion. It is + made up of the filename, preceded by the name of the + directory containing that file. This, in turn, is preceded + by the name of directory containing <emphasis>that + directory</emphasis>, and so on. A typical pathname may + look like <filename>/home/sasha/talk.txt</filename> which + refers to the file <filename>talk.txt</filename> in the + directory <filename>sasha</filename> which in turn is a + subdirectory in <filename>/home</filename>. + </para> + <para> + As you can see, the directory and filename are separated by + a single slash (/). For this reason, filenames themselves + cannot contain the / character. MS-DOS users will find this + convention familiar, although in the MS-DOS world the + backslash (\) is used instead. The directory that contains a + given subdirectory is known as the <emphasis>parent + directory</emphasis>. Here, the directory + <filename>home</filename> is the parent of the directory + <filename>sasha</filename>. + </para> + <para> + Each user has a home directory, which is the directory set aside for + that user to store his or her files. Usually, user home directories + are contained under <filename>/home</filename>, and are named for the + user owning that directory, so that the home directory of user + <systemitem>sasha</systemitem> would be + <filename>/home/sasha</filename>. + </para> + </sect3> + </sect2> + <sect2 id="new-relative"> + <title>Relative directory names</title> + <para> + At any moment, commands that you enter are assumed to be + <emphasis>relative</emphasis> to your current working + directory. You can think of your working directory as the + directory in which you are currently ``located''. When you + first log in, your working directory is set to your home + directory — for user sasha, it would be + <filename>/home/sasha</filename>. Whenever you refer to a + file, you may refer to it in relationship to your current + working directory, rather than specifying the full pathname of + the file. + </para> + <para> + For example, if your current directory is + <filename>/home/sasha</filename>, and you have a file there called + <filename>talk.txt</filename>, you can refer to it just by its file + name: a command like <command>emacs talk.txt</command> issued from the + directory <filename>/home/sasha</filename> is equivalent to + <command>emacs /home/sasha/talk.txt</command> + (<application>emacs</application> is an extremely powerful editor for + text files; new users may prefer something simpler, such as + <application>gnotepad</application>, but for power user, + <application>emacs</application> is indispensable). + </para> + + + <para> + Similarly, if, in <filename>/home/sasha</filename> you have a + subdirectory called <filename>papers</filename> and, in that + subdirectory, a file called <filename>fieldtheory.txt</filename>, you + can refer to it as <filename>papers/fieldtheory.txt</filename>. + </para> + <para> If you begin a filename (like + <filename>papers/fieldtheory.txt</filename>) with a character + other than /, you're referring to the file in terms relative + to your current working directory. This is known as a relative + pathname. On the other hand, if you begin a filename with a + /, the system interprets this as a full pathname — that + is, a pathname that includes the entire path to the file, + starting from the root directory, /. Use of the full pathname + is known as an <emphasis>absolute pathname</emphasis>. + </para> + </sect2> + <sect2 id="new-path-conv"> + <title>Pathname conventions</title> + <para> + Here are some standard conventions you can use in paths: + </para> + <para> + <filename>~/</filename> — user's home directory + </para> + <para> + <filename>./</filename> — current working directory + </para> + <para> + <filename>../</filename> — parent of the current directory + </para> + <para> + For example, if sasha's current directory is + <filename>/home/sasha/papers</filename>, he can refer to the file + <filename>/home/sasha/talk.txt</filename> as + <filename>~/talk.txt</filename> or as <filename>../talk.txt</filename>. + </para> + </sect2> + </sect1> + <sect1 id="permissions"> + <title>Permissions</title> + <para> + Every file on your system has an <emphasis>owner</emphasis> — one + of the users (usually the one who created this file), and a system of + <emphasis>permissions</emphasis>, which regulate access to this + file. + </para> + <para> + For ordinary files, there are 3 types of access permissions: + read, write, and execute (the latter only makes sense for + executable files). They can be set independently for 3 + categories of users: the file owner, the users in the group + owning the file, and everyone else. Discussion of groups of + users goes beyond the scope of this document; the other two + categories are self-explanatory. <!--Which groups of users? I + don't think the other two categories are self-explanatory. Would + help if there was some exposition here which explicitly states + who belongs where.-->So, if the permissions on a file + <filename>/home/sasha/talk.txt</filename> are set to read and + write for user sasha, who is the file owner, and read only for + everyone else, only sasha will be able to modify this file. + <!--How about adding something in parentheses here, like (Since + sasha created the file <filename>talk.txt</filename>, sasha has + the widest range of rights to access the file.)... or something + like that?--> + </para> + + <para> + All newly created files carry some standard permissions, + usually read/write for user and read only for + everyone else. You can view the permissions using the Nautilus File + Manager, by right-clicking on the file, choosing + <guimenuitem>Show Properties</guimenuitem> in the pop-up menu, and then the + <guilabel>Permissions</guilabel> tab. Using this dialog, you can also + change the permissions — just click on a square + representing the permission to toggle it. Of course, only the + file owner or the system administrator can change the + permissions of a file. Advanced users can also change the default + file permissions which are assigned to newly created + files—see the manual pages for your default shell (usually + <command>bash</command>, + <command>csh</command> or <command>tcsh</command>) and look for the command + <command>umask</command>. + </para> + + <para> + A file can also have some special permission properties such + as UID, GID, and "sticky" bit. They are for experienced users + only — do not change them unless you know what you are + doing. (If you are curious: these permissions are typically + used on executable files to allow the user to execute + <emphasis>some</emphasis> commands + which read or modify files to which the user himself doesn't + have access.) + </para> + + <para> Similar to files, the directories also have + permissions. Again, there are 3 possible + permissions: read, write, and execute. However, they have + different meaning: namely, "read" permission for a directory + means permission to list the contents of the directory or + search for a file; "write" means permission to create and + remove files in the directory, and "execute" means permission + to access files in the directory. + </para> + <para> + Note that the permissions granted to a file depend on the + permissions of the directory in which the file is located: in + order to be able to read a file, a user needs to have the read + permission for the file itself and "execute" permission + for the directory that contains it. So, if user sasha doesn't + want anybody else to see his files, he can achieve this by + removing the execute permission on his home directory for all + other users. This way, no one but himself (and, of course, + root) will be able to read any of his files, no matter what + the permissions of individual files are. + </para> + <para> Detailed explanation of the permission system can be + found, for example, in the info page for the GNU "File + Utilities" package. You can view this info page using GNOME Help + browser. + </para> + </sect1> + + <sect1 id="syslinks"> + <title>Symbolic links</title> + <para> + In addition to regular files, UNIX also has special files + called <emphasis>symbolic links</emphasis> (or + <emphasis>symlinks</emphasis> for short). These files do not + contain any data; instead, they are just "pointers," or + "shortcuts" to other files. For example, sasha can have a + symlink named <filename>ft.txt</filename> pointing to the file + <filename>papers/fieldtheory.txt</filename>; this way, when a + program tries to access the file <filename>ft.txt</filename>, + the file <filename>papers/fieldtheory.txt</filename> will be + opened instead. As you can see from this example, the symlink + and the target file can have different names and be located in + different directories. + </para> + <para> Note that deleting, moving, or renaming the symlink file + has no effect on the target file: if sasha tries to delete the + file <filename>ft.txt</filename>, it is the symlink that will + be deleted, and the file + <filename>papers/fieldtheory.txt</filename> will remain + unchanged. Also, the permissions of the symlink are + meaningless: it is the permissions of the target file that + determine whether a user has the access to it. + </para> + + <para> Symlinks can also point to directories. For example, on + the GNOME FTP server (<systemitem>ftp.gnome.org</systemitem>), + there is a file <filename>/pub/GNOME/latest</filename>, which at + the time of this writing is a symlink to directory + <filename>/pub/GNOME/gnome-1.0.53</filename>. By the time you + read this, the latest version of GNOME is likely to change, and + the GNOME maintainers will change the symlink correspondingly, + so that it will point to + <filename>/pub/GNOME/gnome-1.2</filename> or something similar. + </para> + </sect1> + <sect1 id="new-mount"> + <title>Mounting and unmounting drives</title> + <para> + As we mentioned earlier, the directories on a UNIX system are + organized in a tree, with the top level directory being + <filename>/</filename>. Unlike some other operating systems such as + MS-DOS, there are no special names for files on your floppy disk or + CD-ROM: <emphasis>all</emphasis> the files accessible to your system + must appear in the main directory tree starting with + <filename>/</filename>. + </para> + <para> + Thus, before you can access files on a floppy diskette or a + CD-ROM, you must give to your system a command to incorporate + the contents of this diskette into the main directory tree, + which is referred to as <emphasis>mounting</emphasis> the + diskette. Typically the contents of the CD-ROM will appear under + the name <filename>/mnt/cdrom</filename>; the floppy diskette + under <filename>/mnt/floppy</filename> (these are called the + <emphasis>mount points</emphasis> and are defined in the special + configuration file, <filename>/etc/fstab</filename>). Accessing + a drive in this fashion doesn't mean that the system will copy + all the files from the CD to the directory + <filename>/mnt/cdrom</filename>. Instead, it means that the + directory <filename>/mnt/cdrom</filename> + <emphasis>represents</emphasis> the CD-ROM: When a program tries + to access, say, a file called + <filename>/mnt/cdrom/index.html</filename>, the system will look + for file <filename>index.html</filename> on the CD-ROM. + </para> + <para> + So, in short: before you can use files on a drive, you must + "mount" it. Similarly, <emphasis>before removing the disk from + the drive, you must unmount it.</emphasis> + </para> + <para> + When using GNOME, you usually do not have to worry about + mounting and unmounting: GNOME scans the appropriate + configuration file and places the icons for all drives on your + desktop. Double-clicking on any of these icons automatically + mounts the corresponding drive (if it was not already mounted) + and starts the file manager in the appropriate directory. + Similarly, if you right-click on the drive icon and choose the + command <guimenuitem>Unmount Volume</guimenuitem> from the pop-up + menu, GNOME automatically unmounts it before ejecting. You can + also mount a drive by right-clicking on the desktop and choosing + <guimenuitem>Disks | cdrom</guimenuitem> from the pop-up menu, + or by using the disk mount applet. + </para> + <para> + Note that you can't unmount a drive if it is being used by some program; + for example, if you have a terminal windows open in a directory on the + drive you're trying to unmount. So, if you get the error message "Device + busy" while trying to unmount a drive, make sure that none of your open + applications is accessing a file or directory on this drive. + </para> + <para> + However, GNOME cannot prevent you from ejecting the disk using the + physical eject button on the drive itself — in this case, + <emphasis>it is your responsibility to unmount the drive</emphasis> + before doing so. For CD and Zip drives, the system blocks the eject + button on the drive while the drive is mounted; for floppy drives this + is technically impossible. + </para> + + <important> + <title>IMPORTANT</title> + <para> + If you eject a floppy disk using the eject button on the drive without + first unmounting it, you may lose your data! + </para> + </important> + + <para> Some systems are running a special program, called the + automount <emphasis>daemon</emphasis> (you do not need to know + what a daemon is), + which automatically mounts a drive when a disk is inserted and unmounts a + drive if it hasn't been used for a specified period of time. In + this case, you will probably never need to worry about + mounting/unmounting drives yourself. + </para> + <para> + Allowing users to mount and unmount drives carries some security risks, + so many systems are configured so that only root can mount or unmount + drives. This is the most probable cause of error messages while trying + to mount a drive. In this case, discuss this matter with your system + administrator. + </para> + <para> + If the computer is your personal workstation or home computer, + so that you are not worried about security, you can give mount + permission to ordinary users. The easiest way to allow this is + to use the application + <application><emphasis>linuxconf</emphasis></application> (which + can only be run by root). Just select the drive you want to + access in the <guilabel>Access local drive</guilabel> section. + In the <guilabel>Options</guilabel> tab select the + <guilabel>User Mountable</guilabel> option. Your drive will now + be mountable by users. + </para> + <para> + If <application><emphasis>linuxconf</emphasis></application> is not + available, then you must manually edit the file + <filename>/etc/fstab</filename> to include user access. This is done + by adding the "user" attribute to the drive. For example: + </para> + <para> + If your fstab file contains a line like this: + </para> + <programlisting> +/dev/cdrom /mnt/cdrom iso9660 exec,dev,ro,noauto 0 0 + </programlisting> + <para> + add the word "user" to the fourth column: + </para> + <programlisting> +/dev/cdrom /mnt/cdrom iso9660 user,exec,dev,ro,noauto 0 0 + </programlisting> + </sect1> + + <sect1 id="devices"> + <title>Drives and devices</title> + <para> + Under UNIX, the word "device" is used for all peripheral + devices connnected to your computer; this includes hard drives, + floppy and CD-ROM drives, audio and video cards, serial and + parallel ports, and much more. Each device has a name, such as + <filename>/dev/hda</filename>. The most common device names are + listed below. + </para> + <itemizedlist> + <listitem><para> + <filename>/dev/hd*</filename> (where *=a,b,c, …): + these are IDE devices, such as hard drives, CD-ROM drives + and ZIP drives. <filename>/dev/hda</filename> denotes the + master drive on the first IDE controller (usually your first + hard drive, <filename>C:</filename> under Windows), + <filename>/dev/hdb</filename> is the slave drive on the fist + controller (this can be a second hard drive or a CD-ROM), + and so on. See also the <link linkend="zippartition">note</link> below + about ZIP drives. + </para></listitem> + + <listitem><para> + <filename>/dev/sd*</filename> (where *=a,b,c, …): + these are SCSI devices, usually hard drives. + </para></listitem> + </itemizedlist> + + <note> + <title>NOTE</title> + <para>If the acronyms IDE and SCSI are new to you, here is a + brief explanation: there are two types of interfaces for hard + drives and other similar devices: IDE (and its cousins such as + EIDE, ATAPI, etc.) and SCSI. SCSI provides better performance, + but is more expensive, so it is only used on + servers. If you are not sure what kind of drives you have, most + probably it is IDE. </para> + </note> + <itemizedlist> + <listitem><para> + <filename>/dev/fd*</filename> (where *=0,1, etc) are floppy + drives; <filename>/dev/fd0</filename> is the first drive (it + corresponds to <filename>A:</filename> under Windows), + <filename>/dev/fd1</filename> is the second + (<filename>B:</filename>), etc. + </para> + </listitem> + <listitem><para> + <filename>/dev/lp*</filename> (where *=0,1, etc) are + parallel ports; most commonly, these ports are used to + connect a printer to the + computer. <filename>/dev/lp0</filename> corresponds to + <filename>LPT1</filename> under Windows, + <filename>/dev/lp1</filename> to <filename>LPT2</filename>, + etc. + </para> + </listitem> + <listitem><para> <filename>/dev/ttyS*</filename> (where *=0,1, + etc) are serial ports; these ports are commonly used for + connnecting a mouse or a + modem. <filename>/dev/ttyS0</filename> corresponds to + <filename>COM1</filename> under Windows, + <filename>/dev/ttyS1</filename> to <filename>COM2</filename>, + etc. + </para> + </listitem> + <listitem><para> + <filename>/dev/audio</filename> and + <filename>/dev/dsp</filename> — these two device + names are used for your audio card (they are not equivalent, + since they are used for different types of audio files). + </para> + </listitem> + </itemizedlist> + <para> + In addition, it is a common practice to have symlinks + <filename>/dev/floppy, /dev/modem</filename> and + <filename>/dev/cdrom</filename> pointing to the actual device + name corresponding to your floppy drive, modem, and CD-ROM drive + respectively. + </para> + <para> + You rarely need to use these device names. In particular, if you + want to access a file on a drive, you do not use the device name + (such as <filename>/dev/fd0</filename>); instead, you first + mount the device so that its contents shows as a subdirectory + (for example, <filename>/mnt/floppy</filename>) in the main + directory tree, and then use this directory for accessing + files; see <xref linkend="new-mount"> for more information. About + the only time when you actually need to use the device names is + when you are configuring some newly installed program. For + example, a fax program can ask you for the device name for your + modem (in which case you can either give it the actual device + name, such as <filename>/dev/ttyS1</filename>, or just use the + symlink <filename>/dev/modem</filename>). + </para> + <para> And just for fun: there is also a device + <filename>/dev/null</filename> which acts as a "black hole": you + can send to it any information, and it never returns. So if you do + not want to be bothered by error messages, re-direct them to + <filename>/dev/null</filename> -:). + </para> + + <sect2 id="partitions"> + <title>Partitions</title> + <para> + Note that it is possible to subdivide a hard + drive (or a similar device) into parts which for all practical + purposes behave as independent disks, even though physically + they reside on the same disk. These parts are called + "partitions" (under Windows, the name "logical disk" is + used). For example, you can partition your hard drive into + several partitions, and install different operating systems in + different partitions; you can reformat each partition + independently of the others. This partitioning of the hard + drive is usually done during the installation of the operating + system; refer to your installation guide for more + information. + </para> + <para> + If your hard drive has been partitioned, then each partition + is considered as a separate device. For example, if your hard + drive is <filename>/dev/hda</filename>, then the first + partition on this drive would be referrred to as + <filename>/dev/hda1</filename>, the second as + <filename>/dev/hda2</filename>, and so on. + </para> + <warning id="zippartition"> + <title> Partitioning of ZIP disks</title> + + <para> For reasons unknown to us, the pre-formatted + ZIP disks sold in stores or formatted using Iomega's ZIP + tools under Windows are partitioned in a strange way: + they have only one parition (of Windows type, of course), + but this partition has number 4. Thus, if your ZIP drive is + <filename>/dev/hdc</filename>, the correct device name you + should use for such disks is <filename>/dev/hdc4</filename>. + </para> + </warning> + </sect2> + </sect1> +</appendix> |