As we mentioned before, it is easy enough to make a mess of the system. We can't put enough stress on the importance of keeping the place tidy. When you learn this from the start, it will become a good habit that will save you time when programming on a Linux or UNIX system or when confronted with system management tasks. Here are some ways of making life easier on yourself:
Make a bin directory for your program files and scripts.
Organize non-executable files in appropriate directories, and make as many directories as you like. Examples include separate directories for images, documents, projects, downloaded files, spreadsheets, personal files, and so on.
Make directories private with the chmod 700 dirname command.
Give your files sensible names, such as Complaint to the prime minister 050302 rather than letter1.
On some systems, the quota system may force you to clean up from time to time, or the physical limits of your hard disk may force you to make more space without running any monitoring programs. This section discusses a number of ways, besides using the rm command, to reclaim disk space.
Run the quota -v command to see how much space is left.
Sometimes the content of a file doesn't interest you, but you need the file name as a marker (for instance, you just need the timestamp of a file, a reminder that the file was there or should be there some time in the future). Redirecting the output of a null command is how this is done in the Bourne and Bash shells:
andy:~> cat wishlist > placeholder andy:~> ls -la placeholder -rw-rw-r-- 1 andy andy 200 Jun 12 13:34 placeholder andy:~> > placeholder andy:~> ls -la placeholder -rw-rw-r-- 1 andy andy 0 Jun 12 13:35 placeholder
The process of reducing an existing file to a file with the same name that is 0 bytes large is called truncating.
For creating a new empty file, the same effect is obtained with the touch command. On an existing file, touch will only update the timestamp. See the Info pages on touch for more details.
To "almost" empty a file, use the tail command. Suppose user andy's wishlist becomes rather long because he always adds stuff at the end but never deletes the things he actually gets. Now he only wants to keep the last five items:
andy:~> tail -5 wishlist > newlist andy:~> cat newlist > wishlist andy:~> rm newlist
Some Linux programs insist on writing all sorts of output in a log file. Usually there are options to only log errors, or to log a minimal amount of information, for example setting the debugging level of the program. But even then, you might not care about the log file. Here are some ways to get rid of them or at least set some limits to their size:
Try removing the log file when the program is not running, if you are sure that you won't need it again. Some programs may even see, when restarted, that there is no log file and will therefore not log.
If you remove the log file and the program recreates it, read the documentation for this particular program in search for command options that avoid making log files.
Try making smaller log files by logging only the information that is relevant to you, or by logging only significant information.
Try replacing the log file with a symbolic link to /dev/null; if you're lucky the program won't complain. Don't do this with the log files of programs that run at system boot or programs that run from cron (see Chapter 4). These programs might replace the symbolic link with a small file that starts growing again.
Regularly clean out your mailbox, make sub-folders and automatic redirects using procmail (see the Info pages) or the filters of your favorite mail reading application. If you have a trash folder, clean it out on a regular basis.
To redirect mail, use the .forward file in your home directory. The Linux mail service looks for this file whenever it has to deliver local mail. The content of the file defines what the mail system should do with your mail. It can contain a single line holding a fully qualified E-mail address. In that case the system will send all your mail to this address. For instance, when renting space for a website, you might want to forward the mail destined for the webmaster to your own account in order not to waste disk space. The webmaster's .forward may look like this:
webmaster@www ~/> cat .forward email@example.com
Using mail forwarding is also useful to prevent yourself from having to check several different mailboxes. You can make every address point to a central and easily accessible account.
You can ask your system administrator to define a forward for you in the local mail aliases file, like when an account is being closed but E-mail remains active for a while.
When several users need access to the same file or program, when the original file name is too long or too difficult to remember, use a symbolic link instead of a separate copy for each user or purpose.
Multiple symbolic links may have different names, e.g. a link may be called monfichier in one user's directory, and mylink in another's. Multiple links (different names) to the same file may also occur in the same directory. This is often done in the /lib directory: when issuing the command
ls -l /lib
you will see that this directory is plenty of links pointing to the same files. These are created so that programs searching for one name would not get stuck, so they are pointed to the correct/current name of the libraries they need.
The shell contains a built-in command to limit file sizes, ulimit, which can also be used to display limitations on system resources:
cindy:~> ulimit -a core file size (blocks) 0 data seg size (kbytes) unlimited file size (blocks) unlimited max locked memory (kbytes) unlimited max memory size (kbytes) unlimited open files 1024 pipe size (512 bytes) 8 stack size (kbytes) 8192 cpu time (seconds) unlimited max user processes 512 virtual memory (kbytes) unlimited
Cindy is not a developer and doesn't care about core dumps, which contain debugging information on a program. If you do want core dumps, you can set their size using the ulimit command. Read the Info pages on bash for a detailed explanation.
A core file or core dump is sometimes generated when things go wrong with a program during its execution. The core file contains a copy of the system's memory, as it was at the time that the error occured.
Compressed files are useful because they take less space on your hard disk. Another advantage is that it takes less bandwidth to send a compressed file over your network. A lot of files, such as the man pages, are stored in a compressed format on your system. Yet unpacking these to get a little bit of information and then having to compress them again is rather time-consuming. You don't want to unpack a man page, for instance, read about an option to a command and then compress the man page again. Most people will probably forget to clean up after they found the information they needed.
So we have tools that work on compressed files, by uncompressing them only in memory. The actual compressed file stays on your disk as it is. Most systems support zgrep, zcat, bzless and other members of the z-family to prevent unnecessary decompressing/compressing actions. See your system's binary directory and the Info pages.
See Chapter 9 for more on the actual compressing of files and examples on making archives.