author = Havoc Pennington [email protected]
topics = file handling commands, directory handling commands, directory structure, file systems, etc.
This chapter describes how to manipulate files on your Debian GNU/Linux system, how those files are organized into filesystems, and how to use physical devices which store files (such as your hard disk).
Before describing any actual file-manipulation tasks, there are some general points to make about files. Let's look at some files on a Debian system:
Things to note:
You can think of a path as a route from the base of the tree (/) to the end of some branch (a file). You'll also hear people talk about the directory tree as if it were a family tree: thus subdirectories have "parents," and a path shows the complete ancestry of a file.
Don't worry if all this isn't completely clear yet. There are many examples to come.
To use your system you'll have to know how to create, move, rename, and delete files and directories. You'll do this from the shell prompt, which on Debian defaults to $. For the tutorials in this chapter, we'll assume you've already logged in, not as root, and that you're looking at the $ prompt.
The best way to learn is to try things. As long as you aren't root (and haven't yet created any important files), there's nothing you can mess up too seriously. So jump in - type each of these commands at the prompt and press enter:
pwd stands for Present Working Directory. You should see the name of the directory you're in on the screen - probably /home/yourname.
ls stands for "list," as in "list files." When you type ls, you should see a list of all the files in your present working directory. If you've just installed Debian, your home directory may well be empty. If your present working directory is empty, ls will not show anything on the screen.
cd means Change Directory. In this case, you've asked to change to the root directory. Type pwd again, and verify that you're presently working in the root directory. Type ls, and see what's in /.
Typing cd by itself takes you to your home directory - /home/yourname. Try pwd to verify this.
In your home directory, let's make a directory called practice. We'll use this directory to try out some other commands. You might type ls to verify that your new directory exists.
Change directory to practice.
Create a subdirectory of practice.
OK, things just got more complicated! cp is short for "copy." /etc/profile is just a random file on your system, don't worry about what it is for now. We've copied it to . - but what's .? . just means "the directory I'm in now," or present working directory. So we've created a copy of /etc/profile, and put it in our practice directory. Try typing ls to verify that there's indeed a file called profile in the present working directory.
more is used to view the contents of text files, such as /etc/profile. It's called more because it shows a page of the file at a time, and you press the space bar to see more. more will exit when you get to the end of the file, or when you type q (quit). You might try typing more /etc/profile as well, to verify that your copy looks just like the original.
As you might guess, mv stands for "move." We've moved the file profile from the current directory into the subdirectory we created earlier. Perhaps type ls and/or ls mysubdirectory to verify the move.
Change to the subdirectory.
mv is also used to rename files - by moving them to a new name. Thus there's no separate rename command. Note that the second argument to mv can be a directory to move the file or directory into, or a new filename. cp works the same way.
As usual, you can type ls to see the result of mv.
Just as . means "the directory I'm in now," .. means "parent of the current directory," in this case the practice directory we created earlier. Use ls to verify that that's where myprofile is now.
Change directories to the parent directory - in this case practice, where you just put myprofile.
rm means "remove" - this deletes myprofile. Be careful! Deleting a file on a GNU/Linux system is permanent - there is no undelete. If you rm it, it's gone, forever.
rmdir is just like rm, only it's for directories. Notice that rmdir only works on empty directories - if the directory contains files, you must delete those files first, or alternatively use rm -r in place of rmdir.
Oops! That didn't work. You can't delete a directory you're currently working in.
So move out of the current directory, and into its parent directory. Now you can type:
This will delete the last remnants of your practice session.
So now you know how to create, copy, move, rename, and delete files and directories. You also learned some shortcuts, like typing simply cd to jump to your home directory, and . and .. to refer to the current directory and its parent, respectively.
Now that you can navigate the directory tree, let's take a guided tour of the files and directories you created when you installed Debian. If you're curious, cd to each directory and type ls to see its contents. If the listing doesn't fit on the screen, try ls | more, where | is the "pipe" character, generally found on the same key with backslash.
Your home directory is where you put all your personal work, email and other information, and personal configuration preferences.
While not essential to get the computer operating,/usr does contain the applications you'll use to get real work done. Also in /usr you'll find the /usr/man, /usr/info, and /usr/doc directories - these contain manual pages, info pages, and other documentation, respectively. And don't forget /usr/games!
Clearly there are many more directories on the system, too many to describe every one. We'll get to some of them later in the manual.
For changing things, you'll usually want to confine yourself to your home directory and /etc. On a Debian system, there's rarely an occasion to change anything else, because everything else is automatically installed for you.
/etc is used to configure the system as a whole. You'll use your own home directory, a subdirectory of /home, for configuring your own preferences, and storing your personal data. The idea is that on a day-to-day basis you confine yourself to /home/yourname, so there's no way you can break anything. Occasionally you log in as root to change something in a system-wide directory, but only when absolutely necessary. Of course, if you're using Debian at a school or business and someone else is the system administrator, you won't have root access and will only be able to change your home directory.
GNU and Unix systems are set up to allow many people to use the same computer, while keeping certain files private or keeping certain people from modifying certain files. You can verify this for yourself:
You should be told "Permission denied." /etc/resolv.conf is an essential system configuration file - you aren't allowed to change or remove it unless you're root. This keeps you from accidentally messing up the system, and if the computer is a public one such as at an office or school, it keeps users from messing up the system on purpose.
Now type ls -l /etc/resolv.conf
This should give you output that looks something like this:
-rw-r--r-- 1 root root 119 Feb 23 1997 /etc/resolv.conf
The -l option to ls requests all that additional information. The info on the right is easy - the size of the file is 119 bytes, the date the file was last changed is Feb 23 1997, the file's name is /etc/resolv.conf. On the left side of the screen, things get a little more complicated.
First, the brief, technical explanation: the -rw-r--r-- is the mode of the file, the 1 is the number of hard links to this file (or the number of files in a directory), and the two root are the user and group owning the file.
So that was cryptic. Let's go through it slowly (except the hard links part - for that see The real nature of files: hard links and inodes, Section 4.8.1).
Every file has two owners - a user, and a group. The above case is a little confusing, since there's a group called root in addition to the root user. Groups are just collections of users who are collectively permitted access to some part of the system. A good example is a games group. Just to be mean, you might set up your system so that only people in a games group are allowed to play games.
A more practical example: say you're setting up a computer for a school. You might want certain files to be accessible only to teachers, not students, so you put all the teachers in a single group. Then you can tell the system that certain files belong to members of the group teachers, and that no one else can access those files. Here are some things you can do to explore groups on your system:
Typing this at the shell prompt will tell you what groups you're a member of. It's likely that you're a member of only one group, which is identical to your username. (FIXME: find what the explanation for this is)
This file lists the groups that exist on your system. Notice the root group (the only member of this group is the root user), and the group which corresponds to your username. There are also groups like dialout (users who are allowed to dial out on the modem), and floppy (users who can use the floppy drive). However, your system is probably not configured to make use of these groups - it's likely that only root can use the floppy or the modem right now. For details about this file, try typing man group.
Observe how every user's directory is owned by that user and that user's personal group. (If you just installed Debian, you may be the only user.)
In addition to being owned by one user and one group, every file and directory also has a mode, which determines who's allowed to read, write, and execute the file. There are a few other things also determined by the mode, but they're advanced topics so we'll skip them for now.
The mode looks like this in the ls output: -rw-r--r--. There are ten "spaces" here, but the mode actually consists of twelve bits (think of bits as switches which can be on or off). For now, we'll consider only nine of these bits: those that control read, write, and execute permissions for the user owning the file, the group owning the file, and everyone on the system (sometimes called "world"). Notice that three kinds of permission (read, write, execute) times three sets of people who can have permission (user, group, others) makes a total of nine combinations.
In the mode line, the first "space" gives the type of the file. The - in this case means it's a regular file. If it was d, we'd be looking at a directory. There are other possibilities too complex to go into now (see Types of files, Section 4.8.2).
The remaining nine "spaces" are used to display the 12 bits that make up the file's mode. The basic 9 bits (read, write, and execute for user, group, and other) are displayed as three blocks of rwx. So if all permissions are turned on, the mode will look like this: -rwxrwxrwx. (The remaining three bits are displayed by changing the x to s, t, S, or T, but this is a complex topic we're saving for later.)
In this context, "read", "write", and "execute" have the following meanings:
Since directories can never be executed, the execute bit has a different meaning. For directories, execute permission means permission to access files in the directory. Note that this interacts with write permissions: execute permissions must be set to be able to access files in a directory at all, so without execute permission on a directory, write permission is useless. Execute permission for directories is often called "search" permission, since it really has nothing to do with execution. "File access" permission would probably be a still better name, but no one uses it.
Directory modes are a little confusing, so here are some examples of the effects of various combinations:
The user, group, or other with these permissions may list the contents of the directory, but nothing else. The files in the directory can't be read, changed, deleted, or manipulated in any way. The only permitted action is reading the directory itself, that is, seeing what files it contains.
Write permission has no effect in the absence of execute permission, so this mode behaves just like the above mode.
This mode permits the files in a directory to be listed, and permits access to those files. However, files can't be created or deleted. Access means that you can view, change, or execute the files as permitted by the files' own permissions.
Files in this directory can be accessed, but the contents of the directory can't be listed, so you have to know what filename you're looking for in advance (unless you're a good guesser). Files can't be created or deleted.
You can do anything you want with the files in this directory, as long as it's permitted by the permissions on the files themselves.
Directory write permission determines whether you can delete files in a directory - a read-only file can be deleted, if you have permission to write to the directory containing it. You can't delete a file from a read-only directory, even if you're allowed to make changes to the file. File permissions have nothing to do with deleting files.
This also means that if you own a directory you can always delete files from it, even if those files belong to root.
Directory execute permission determines whether you have access to files - and thus whether file permissions come into play. If you have execute permissions to a directory, file permissions for that directory become relevant. Otherwise file permissions just don't matter; you can't access the files anyway.
If you have execute permission for the directory, file permissions determine whether you can read the contents of the file, change the file, and/or execute the file as a command.
FIXME: Are the next two paragraphs correct?
Finally, permission to change permissions on a file or directory is not affected by the permissions of that file or directory. Rather, you can always change the permissions on files or directories that you own, but not on files owned by someone else, as long as you are permitted access to the file. So if you can access a file you own at all (that is, you have execute permission in the directory containing it) then you can change its permissions.
This means that you can't permanently remove permissions from yourself because you can always give them back. Say you remove user write permission from a file you own, then try to change the file. It won't be permitted, but you can always give yourself write permission again and then change the file. The only way to lose the ability to change permissions back is to lose access to the file entirely.
FIXME: This isn't very thorough. However, it seems like it thorough would make it really long and involve making files as root to show the effects of different ownership, etc. and perhaps it's not worth it.
To change permissions, we'll use the chmod command.
There are a couple of new tricks here. First, you can use ; to put two commands on one line. You can type the above as:
$ cd
$ touch myfile
or as:
$ cd; touch myfile
and the same thing will end up happening.
Recall that cd by itself returns you to your home directory. touch is normally used to change the modification time of the file to the current time, but it has another interesting feature: if the file doesn't exist, touch creates the file. So we're using it to create a file to practice with. Use ls -l to confirm that the file has been created, and notice the permissions mode:
$ ls -l
-rw-r--r-- 1 havoc havoc 0 Nov 18 22:04 myfile
Obviously the time and user/group names will be different when you try it. The size of the file is 0, since touch creates an empty file. -rw-r--r-- is the default permissions mode on Debian (you can change this - see FIXME: add ref to umask).
This command means to add (+) execute (x) permissions for the user (u) who owns the file. Use ls -l to see the effects.
Here we've subtracted read permission from the group owning the file, and from everyone else (others, o). Again use ls -l to verify the effects.
Here we've set (=) user, group, and other permissions to read and execute. This sets permissions to exactly what you've specified, and unsets any other permissions. So all rx should be set, and all w should be unset. Now no one can write to the file.
a is a shortcut for ugo, or "all". So all the x permissions should now be unset.
We're removing the file, but without write permissions. rm will ask if you're sure:
rm: remove `myfile', overriding mode 0444?
You should respond by typing y and pressing enter. This is a feature of rm, not a fact of permissions - permission to delete a file comes from the directory permissions, and you have write permission in the directory. However, rm tries to be helpful, figuring that if you didn't want to change the file (and thus removed write permission), you don't want to delete it either, so it asks you.
What was that 0444 business in the question from rm? Recall that the permissions mode is a twelve-digit binary number, like this: 000100100100. 0444 is this binary number represented as an octal (base 8) number, which is the conventional way to write a mode. So you can type chmod 444 myfile instead of chmod ugo=r myfile. See Using numeric arguments with chmod, Section 4.8.4.1.
At this point it's probably a good idea to explain a little theory. In particular, the concept of a filesystem. [2] This is confusing, because it has several meanings.
Any physical device you wish to use for storing files must have at least one filesystem on it. This means a filesystem in the second sense - a hierarchy of files and directories, along with information about them. Of course, any filesystem has a type, so the third sense will come into play as well. If you have more than one filesystem on a single device, each filesystem can have a different type - for example, you might have both a DOS partition and a Linux partition on your hard disk.
It's important to distinguish the filesystem from the low-level format of the disk. In the DOS and Macintosh worlds, the filesystem is called the high-level format. When you format a disk using one of those operating systems, generally you both perform a low-level format and create a file system (high-level format). On GNU and Unix systems, one generally says simply "format" to mean low-level format, and "making a filesystem" to mean high-level format.
Formatting has to do with the particulars of the physical device, such as the exact physical location of your data on a floppy disk (on the edge or in the center of the disk for example). The filesystem is the level of organization you have to worry about - names of directories and files, their sizes, etc.
This section describes how to mount a floppy or Zip disk, the /dev directory, and distributing the directory tree over multiple physical devices or partitions.
As we said earlier, on a GNU/Linux system there's no necessary correspondence between directories and physical devices, as there is in DOS for example where each drive has its own directory tree beginning with a letter (such as C:\).
Instead, each physical device such as a hard disk or floppy disk has one or more filesystems on it. In order to make a filesystem accessible, it's assigned to a particular directory in another filesystem. To avoid circularity, the root filesystem (which contains the root directory /) is not contained by any other filesystem - you have access to it automatically when you boot Debian.
A directory in one filesystem which contains another filesystem is known as a mount point. A mount point is a directory in a first filesystem on one device (such as your hard disk) but which contains a second filesystem, perhaps on another device (such as a floppy disk). To access a filesystem, you must mount it at some mount point.
So, for example, you might mount a CD at the mount point /cdrom. This means that if you look in the directory /cdrom, you'll see the contents of the CD. The /cdrom directory itself is actually on your hard disk. For all practical purposes the contents of the CD become a part of the root filesystem, and when typing commands and using programs it doesn't make any difference what the actual physical location of the files is. You could have created a directory on your hard disk called /cdrom, and put some files in it, and everything would behave in exactly the same way. Once you mount a filesystem, there's no need to pay any attention to physical devices.
However, before mounting a filesystem, or to actually create a filesystem on a disk that doesn't have one yet, it's necessary to refer to the devices themselves. All devices have names, and these are located in the /dev directory. If you type ls /dev now, you'll see a pretty lengthy list of every possible device you could have on your Debian system.
Possible devices include:
To mount a filesystem, we want to tell Linux to associate whatever filesystem it finds on a particular device with a particular mount point. In the process, we might have to tell Linux what kind of filesystem to look for.
As a simple demonstration, we'll go through mounting a CD-ROM, such as the one you may have used to install Debian. You'll need to be root to do this, so be careful; whenever you're root you have the power to mess up the whole system, rather than just your own files. Also, these commands assume there's a CD in your drive; you should put one in the drive now.
If you haven't already, you need to either log in as root or gain root privileges with the su (super user) command. If you use su, enter the root password when prompted.
See what's in the /cdrom directory before you start. If you don't have a /cdrom directory, you may have to make one using mkdir /cdrom.
Typing simply mount with no arguments lists the currently mounted filesystems.
For this command, you should substitute the name of your CD-ROM device for CD device in the above command line. If you aren't sure, /dev/hdc is a good guess. If that fails, try the different IDE devices: /dev/hda, etc. You should see a message like:
mount: block device /dev/hdc is write-protected, mounting read-only
The -t option specifies the type of the filesystem, in this case iso9660. Most CDs are iso9660. The next argument is the name of the device to mount, and the final argument is the mount point. There are many other arguments to mount; see the man page for details. (For example, you could avoid the above message by specifying read-only on the command line.)
Once a CD is mounted, you may find that your drive tray will not open. You must unmount the CD before removing it.
Confirm that /cdrom now contains whatever is on the CD in your drive.
Look at the list of filesystems again, noticing that your CD drive is now mounted.
This unmounts the CD. It's now safe to remove the CD from the drive. Notice that the command is umount with no "n", even though it's used to unmount the filesystem.
Don't leave yourself logged on as root. Log out immediately, just to be safe.
The file /etc/fstab (it stands for "file system table") contains descriptions of filesystems that you mount often. These filesystems can then be mounted with a shorter command, such as mount /cdrom. You can also configure filesystems to mount automatically when the system boots. You'll probably want to mount all of your hard disk filesystems when you boot.
Look at this file now, by typing more /etc/fstab. It will have two or more entries that were configured automatically when you installed the system. It probably looks something like this:
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump > <pass>
/dev/hda1 / ext2 defaults 0 1
/dev/hda3 none swap sw 0 0
proc /proc proc defaults 0 0
/dev/hda5 /tmp ext2 defaults 0 2
/dev/hda6 /home ext2 defaults 0 2
/dev/hda7 /usr ext2 defaults 0 2
/dev/hdc /cdrom iso9660 ro 0 0
/dev/fd0 /floppy auto noauto,sync 0 0
The first column lists the device the filesystem resides on. The second lists the mount point, the third the filesystem type. The line beginning proc is a special filesystem explained in The proc filesystem, Section 4.8.3. Notice that the swap partition (/dev/hda3 in the example) has no mount point, so the mount point column contains none.
The last three columns may require some explanation.
The fifth column is used by the dump utility to decide when to back up the filesystem. FIXME: cross ref to dump
The sixth column is used by fsck to decide in what order to check filesystems when you boot the system. The root filesystem should have a 1 in this field, filesystems which don't need to be checked (such as the swap partition) should have a 0, and all other filesystems should have a 2. FIXME: cross ref to fsck, also, is the swap partition really a filesystem?
Column four contains one or more options to use when mounting the filesystem. Here's a brief summary (some of these probably won't make much sense yet - they're here for future reference):
How to use them - setting things up so you can access them nicely from userspace.
FIXME I'm actually not sure how to write this. What's in fstab on a default installation? Should we do the manual su root thing, or one of those EZ floppy mounting packages? Perhaps do something with group permissions? Or just the user option in fstab?
There are several ways to look at what's in a file; each one has different uses.
The simplest way is to use cat. cat is short for "concatenate", and it dumps the contents of files to the screen (actually to the standard output, but that's in another chapter). If you pass it two or more files, it dumps them to the screen in order as if they were one big file - i.e., it concatenates them. However, if you pass it only one file, with the syntax cat myfile, it simply dumps that file to the screen. Try typing cat /etc/profile, to see the contents of that file.
The problem with cat is that it's just an uncontrolled dump, which is bad if the file is longer than one screen. You can't see the beginning of the file. The solution is the more command, which displays a file one page at a time. less does the same thing, only it has more features ("less is more"). These are invoked in the same way as cat: the command name followed by the filename. You may have to type q to exit from less, but more will exit on its own when you reach the end of the file.
These utilities are limited to viewing text files; for viewing the raw form of other kinds of files you might have to use a specialized utility such as od (octal dump). For viewing images, word processor documents, and that kind of thing, you'll need to use an appropriate application. There are also many more specialized ways to look at text files: for example, you might look at only the end of the file, or at lines containing a certain word. These more specialized tools will be covered in a later chapter. FIXME: add cross reference
On GNU and Unix systems, any file beginning with a period (aka a dot) is normally not visible. You can see them by using the -a option to ls.
cd to your home directory.
List all files in the directory, even the dotfiles.
You should see a number of files, all beginning with a ., that you don't normally see when you type ls. You'll also see simply . and .., representing this directory and its parent. If you type ls -A with capital A you won't see these two.
The reason for dotfiles is that many files have nothing to do with your day to day work - rather, they're used for configuring your applications and storing machine-generated data. Thus, they're hidden out of the way so they don't clutter up the directory.
Dotfiles are somewhat analagous to control panels on a Macintosh, or the AUTOEXEC.BAT file under DOS. You can ignore them for now - later in the manual we'll explain how to use some of these files to customize your personal Debian settings.
Many dotfiles have a system-wide analogue in the /etc directory. For instance, you may have a .bash_profile in your directory. This corresponds to /etc/profile. Changes to /etc/profile affect everyone, changes to .bash_profile affect only you.
There are two different facilities for finding files: find and locate. find searches the actual files in their present state. locate searches an index generated by the system every morning at 6:42 a.m. (this is a cron job, explained elsewhere in this manual). locate won't find any files which were created after the index was generated. However, since locate searches an index, it's much faster - like using the index of a book rather than looking through the whole thing.
To compare the two ways of finding files, pretend you can't remember where the X configuration file XF86Config resides.
This should be pretty fast. You'll get a list of filenames which contain XF86Config, something like this:
/etc/X11/XF86Config
/usr/X11R6/lib/X11/XF86Config
/usr/X11R6/lib/X11/XF86Config.eg
/usr/X11R6/man/man5/XF86Config.5x.gz
You will hear a lot of disk activity, and this will take a lot longer. If hearing your disk grind for a long time pains you, you may not want to actually type this command. Results will look something like this:
/etc/X11/XF86Config
/usr/X11R6/lib/X11/XF86Config
find: /var/spool/cron/atjobs: Permission denied
find: /var/spool/cron/atspool: Permission denied
find: /var/lib/xdm/authdir: Permission denied
Notice that find only found files which were named exactly XF86Config, rather than any files containing that string of letters. Also, find actually tried to look in every directory on the system - including some where you didn't have read permissions. Thus the "Permission denied" messages.
The syntax is different as well. You had to specify what directory to search in - / - while locate automatically chose the root directory. And you had to specify a search by name, using the -name option. You could also have searched for files using many other criteria, such as modification date or owner.
In general find is a more powerful utility, and locate is faster for everyday quick searches. The full range of possible searches would take a long time to explain; for more details type info find, which will bring up the very thorough info pages on find and locate.
Often it would be nice to make a file smaller: say to download it faster, or so it takes up less space on your disk. The program to do this is called gzip (GNU Zip).
Switch to your home directory, then copy an arbitrarily chosen file (/etc/profile) to your current directory in the process renaming it mysamplefile. This gives us a file to play with using gzip.
List the contents of the current directory. Note the size of mysamplefile.
Compress mysamplefile.
Observe the results: mysamplefile is now called mysamplefile.gz. It's also a good bit smaller.
Uncompress. Observe that mysamplefile has returned to its original state. Notice that to uncompress one uses gunzip, not gzip.
Remove the file, since it was just to practice with.
Sometimes a file is too big to fit on a disk, or you don't want to send a huge file over the net in a single chunk. You can split the file using the split utility, and reassemble it using the cat (concatenate) utility.
Copy the bash executable to a file in your home directory called myfile. Observe that myfile occupies a little over 300,000 bytes, or around 300 kilobytes.
Splits the file into sections of 100 kilobytes, naming the sections myprefixaa, myprefixab, etc. Type ls -l so see the results.
You can specify any number after the -b: choose one that makes sense. If you leave off the k, it will be understood as bytes instead of kilobytes. If you use m instead of k, it will be understood as megabytes.
Concatenate all the files and write them to mynewfile. the * and > are tricks you'll learn in a later chapter.
Remove everything.
Probably you don't have all the disk space you might want, and your disks will eventually fill up. This section will describe how to find out how much space there is, and gives some tips on how to open up more space. e.g. finding and sorting files by size, df, du, strategic gzip, removing unecessary packages.
How to use tar to copy lots of files, or back up your files. Tarballs. I'm thinking this should be a brief section aimed at single-user systems, with a more thorough sysadmin discussion in a different manual.
Backup commands (contributed by Oliver Elphick, section to be cleaned up and elaborated):
dump - dumps one filesystem at a time; its command options assume that you are using half-inch tape (maximum 45Mb per reel) so it's a bit annoying when using DAT (2Gb or more). Probably the best for regular backups. Can't be used for NFS-mounted filesystems.
cpio - `find [directories] -print | cpio -ovH newc -B >/dev/st0'
tar - `tar cvf /dev/st0 [directories]'
afio - like cpio; supports pre-compression of files before archiving.
tob - front-end for afio
Debian comes with a utility which can guess at the contents of a file for you. It is not always correct. However, it is reasonably accurate, and you can use it to explore your system.
You should see something like this:
/bin/cp: ELF 32-bit LSB executable, Intel 386, version 1, stripped
Skipping the technical parts, this is an executable file for Intel machines.
Gives this response:
/etc/init.d/boot: Bourne shell script text
Meaning that this is a text file, containing a Bourne shell script (see the Shells chapter).
Each file on your system is represented by an inode (eye-node): an inode contains all the information about the file. However, the inode is not directly visible. Instead, each inode is linked into the filesystem by one or more hard links. Hard links contain the name of the file, and the inode number. The inode contains the file itself, i.e., the location of the information being stored on disk, its access permissions, the type of the file, and so on. The system can find any inode once it has the inode number.
A single file can have more than one hard link. What this means is that multiple filenames refer to the same file (that is, they are associated with the same inode number). However, you can't make hard links across filesystems: all hard references to a particular file (inode) must be on the same filesystem. (I'm guessing this is because each filesystem has its own set of inodes, and there will be duplicate inode numbers between filesystems. FIXME: find out why for real)
Since all hard links to a given inode are referring to the same file, you can make changes to the file, referring to it by one name, and then see those changes referring to it by a different name. Try this:
cd to your home directory and create a file called firstlink containing the word "hello". What you've actually done is redirect the output of echo (echo just echoes back what you give to it), placing the output in firstlink. See the chapter on shells for a full explanation.
Confirm the contents of firstlink.
Create a hard link: secondlink now points to the same inode as firstlink.
Confirm that secondlink is the same as firstlink
Notice that the number of hard links listed for firstlink and secondlink is 2.
This is another shell redirection trick - don't worry about the details. We've appended the word "change" to secondlink. Confirm this with cat secondlink.
firstlink also has the word "change" appended! It's because firstlink and secondlink refer to the same file. It doesn't matter what you call it when you change it.
Change permissions on firstlink. Do ls -l to confirm that permissions on secondlink were also changed. This means that permissions information is stored in the inode, not in links.
Delete this link. This is a subtlety of rm - it really removes links, not files. Now type ls -l and notice that secondlink is still there. Also notice that the number of hard links for secondlink has been reduced to one.
Delete the other link. When there are no more links to a file, Linux deletes the file itself, that is, its inode.
All files work like this - even special types of files such as devices (e.g. /dev/hda).
A directory is simply a list of filenames and inode numbers, that is, a list of hard links. When you create a hard link, you're just adding a name-number pair to a directory. When you delete a file, you're just removing a hard link from a directory.
One detail we've been concealing up to now is that Unix considers nearly everything to be a file. That includes directories and devices: they're just special kinds of files.
As you may remember, the first letter of an ls -l display represents the type of the file. For an ordinary file, this will be simply -. Other possibilities are:
Symbolic links (also called symlinks or soft links) are the other kind of link besides hard links. A symlink is a file (with its own inode and hard link!) that "points to" a hard link on any mounted filesystem. When you try to read the contents of a symlink, it gives the contents of the file it's pointing to rather than the contents of the symlink itself. Since directories, devices, and other symlinks are types of files, you can point a symlink at any of those things.
So a hard link is a filename and an inode number. A file is really an inode: a location on disk, file type, permissions mode, etc. A symlink is an inode that contains the name of a hard link.
All hard links to the same file have equal status. That is, one is as good as the other; if you perform any operation on one it's just the same as performing that operation on any of the others. This is because the hard links all refer to the same inode. Operations on symlinks, on the other hand, sometimes affect the symlink's own inode (the one containing the name of a hard link) and sometimes affect the hard link being pointed to.
There are a number of important differences between symlinks and hard links:
Try this:
cd to your home directory. ln with the -s option makes a symbolic link; in this case, one called MyTmp which points to the filename /tmp/me.
Output should look like this:
lrwxrwxrwx 1 havoc havoc 7 Dec 6 12:50 MyTmp -> /tmp/me
The date and user/group names will be different for you, of course. Notice that the file type is l, indicating that this is a symbolic link. Also notice the permissions - symbolic links always have these permissions. If you attempt to chmod a symlink, you'll actually change the permissions on the file being pointed to.
You should get a "No such file or directory" error, because the file /tmp/me doesn't exist. Notice that you could create a symlink to it anyway.
Create the directory /tmp/me.
Should work now.
Create a file in MyTmp.
The file was actually created in /tmp/me.
Remove the symbolic link. Notice that this removes the link, not what it points to. Thus you use rm not rmdir.
Clean up after ourselves.
Device files refer to physical or virtual devices on your system, such as your hard disk, video card, screen, or keyboard. An example of a virtual device is the console, represented by /dev/console.
There are two kinds of devices: character devices can be accessed one character at a time, that is, the smallest unit of data which can be written to or read from the device is a character (byte).
Block devices must be accessed in larger units called blocks, which contain a number of characters. Your hard disk is a block device.
You can read and write device files just as you can from other kinds of files, though the file may well contain some strange incomprehensible-to-humans gibberish. Writing random data to these files is probably a Bad Idea. Sometimes it's useful, though: for example, you can dump a postscript file into the printer device /dev/lp0, or send modem commands to the device file for the appropriate serial port.
MAKEDEV
/dev/null is a special device file that discards anything you write to it. If you don't want something, throw it in /dev/null. It's essentially a bottomless pit. If you read /dev/null, you'll get an end-of-file (EOF) character immediately. /dev/zero is similar, only if you read from it you get the \0 character (not the same as the number zero).
A named pipe is a file that acts like a pipe. You put something into the file, and it comes out the other end. Thus it's called a FIFO, or First-In-First-Out: the first thing you put in the pipe is the first thing to come out the other end.
NOTE: The following explanation probably won't make much sense until you've read about processes and using the shell.
If you write to a named pipe, the process which is writing to the pipe doesn't terminate until the information being written is read from the pipe. If you read from a named pipe, the reading process waits until there's something to read before terminating. The size of the pipe is always zero - it doesn't store data, it just links two processes like the shell |. However, since this pipe has a name, the two processes don't have to be on the same command line or even be run by the same user.
You can try it by doing the following:
Makes the pipe.
Puts a process in the background which tries to write "hello" to the pipe. Notice that the process doesn't return from the background. Try simply echo "hello" without the redirection to see the difference.
At this point the echo process should return, and the cat process will print hello.
You can delete pipes just like any other file.
Sockets are similar to pipes, only they work over the network. This is how your computer does networking, and forms the basis for the internet: you may have heard of "WinSock", which is sockets for Windows.
We won't go into these further, because you probably won't have occasion to use them unless you're programming. However, if you see a file marked with type s on your computer, you know what it is.
The Linux kernel makes a special filesystem available, which is mounted under /proc on Debian systems. This is a "pseudo-filesystem" - it doesn't really exist on any of your devices.
The proc filesystem contains information about the system and running processes. Some of the "files" in /proc are reasonably understandable to humans (try typing cat /proc/meminfo) and others are arcane collections of numbers. Often, system utilities use these to gather information and present it to you in a more understandable way.
People frequently panic when they notice one file in particular - /proc/kcore - which is generally huge. This is (more or less) a copy of the contents of your computer's memory. It's used to debug the kernel. It doesn't actually exist anywhere, so don't worry about its size.
If you want to know about all the things in /proc, type man 5 proc.
Earlier in this chapter, we briefly mentioned that you can set file permissions using numbers. The numeric notation is called an absolute mode, as opposed to the symbolic notation (e.g. u+rx) which is often called a relative mode. This is because the number specifies an exact mode to set, and the symbol just specifies a change to make (e.g. "add user read and execute permissions").
The numeric mode is a series of four octal digits or twelve binary digits. Each octal (base eight) digit represents three binary digits: one octal digit and three binary digits are two ways to represent the decimal digits 0 through 7.
Deriving a particular mode is pretty straightforward. You simply add up the modes you want to combine, or subtract modes you don't want. For example, user permissions, with only read permission turned on, would be 100 in binary. User permissions with write only would be 010 binary. User permissions with read and write both turned on would be 100 + 010 = 110. Alternatively, you could put it in octal: 4 + 2 = 6.
For the full mode, simply add up digits from this table:
0001 others, execute
0002 others, write
0004 others, read
0010 group, execute
0020 group, write
0040 group, read
0100 user, execute
0200 user, write
0400 user, read
1000 sticky bit
2000 set group id
4000 set user id
To use the table, first decide what permissions you want to set. Then add up the numbers for those permissions. The total is your mode. For example, to get mode 0755:
0001 o=x
0004 o=r
0010 g=x
0040 g=r
0100 u=x
0200 u=w
+ 0400 u=r
-------
0755 u=rwx go=rw
You'd actually call this mode simply 755, without the leading 0, because chmod automatically adds zeroes at the beginning of the mode - so simply 7 becomes mode 0007.
To set a file to 755, you'd type chmod 755 myfile.
755 is a very common mode for directories, as it allows anyone to use the directory but only the owner to create and delete files in the directory. 644 is the analogous mode for files, and it is also very common. It allows anyone to use the file but only the owner can change it. For executable files, 755 is a common mode; this is just 644 plus execute permissions (644 + 111 = 755).
fsck, mke2fs, dd, fdisk, etc.
what package is a file in?
MSDOS vs. Mac vs. Unix text files
sync
chattr
Debian User Reference Manual
[email protected][email protected][email protected][email protected][email protected][email protected][email protected][email protected]