Introduction (This intro is repeated in the scripts section. It was written by Ed and is presented here with a bit of editing.)
UNIX is text. Most configuration is done by editing plain text files. No one is perfect. And sometimes your changes can make things worse. The best way to save yourself from cursing yourself and saying, "Gee. I REALLY shouldn't have done that" is to take every step to make it possible to roll your changes back. There are many ways to ensure the roll back, but I'd like to concentrate on two of them I use. . One is making searchable comments, and another is creating an .orig file. For one-time changes (eg subtle tuning of a Makefile) I prefer searchable comments: (This one was a bit over my head. I'm not quite sure what the difference between Ed's two files are, but the method of using comments [a # before a line comments it out, similar to the "rem" in DOS, making it so that the line is not used--it is simply there for you to read and use its information] is fairly straightforward.
original file:
CFLAGS = -g -O2
changed file (I don't want debugging and would like to speed things up abit):
# KN
CFLAGS = -O2 -fomit-frame-pointer -pipe
#CFLAGS = -g -O2
Now I make it and if it works OK, I usually delete the source and leave the original tarball, ie my changes were true one-time, I don't want them anymore. If something goes wrong, I open the Makefile with vim, type /KN to search for my label, then do :d2 to delete two lines- my label and my line, then press Del to remove comment sign in front of original line, 7 keystrokes. Repeat as necessary.
The above is Ed's explanation. Again, using myself as the guinea pig to test whether or not this is understandable, I feel that a little clarification is in order. (I had to read it twice to figure it out, so I figure it needs more explanation.)
So, he has changed the file. The original one is
CFLAGS= -g -02 (Nope, I dunno what this does.) He changes it to read
CFLAGS= -02 -fomit-frame-pointer -pipe
He hopes that this will work, then he'll be able to get rid of the old file, but hasn't tested it yet. So, he's put in the KN as a comment--note the # before it. This will enable him to find the file easily using vim, a text editor using /KN. The slash serves as a find function in vim. If you're using a different text editor, the chances are it has its own "find" function and just use that to find the KN. I don't use vim so I'm not quite sure about the :d2 thing--I assume it's vim's way to delete selected lines, but at any rate, just delete the new file and the KN with the text editor. Then, remove the # sign from the line with the original file, and you're back in business.

Now Ed writes:
Tuning configuration files is another story. Sometimes I try pretty wild settings, so having an unmodified config is a must. Usually I just copy it: # cd /etc # cp modules.conf modules.conf.orig
(My comments)
This is mentioned in the scripts article. Simply copy the file with a different name. Now, you have the original, which you can modify at will, and the backup which is renamed filename.orig. Now, back to Ed. Now I can reap modules.conf freely as I have a guaranteed safe backup. If you are changing your configuration often, you can create two scripts, mkorig and rstorig, to create and restore original configuration: #!/bin/bash
# # mkorig -- create a backup file
[note the # mark here--Ed is commenting his script--when scripts get a little more complex, you can never have too many comments to remind you of what you were doing]
ORIG=orig echo "Copying $1 to $1.$ORIG...." cp $1 $1.$ORIG echo "Done." # End of mkorig You should be able to see the idea. If the $1 and such are confusing, then see the scripts section
(If you are new to scripting, it might take a few readings to figure out what is going on--but it is understandable.) I'd suggest the following rule of thumb: if your goal can be reached with a single command that requires no argument transformation, make it an alias (eg ll=ls -AFl --color), if you need to manipulate your parameters or to call different commands depending upon the result of previous operation, make a script. This rule is not perfect, but hope it helps. However, you can always make an alias mo=mkorig :)
And now, back to Scott.
Aliases have a superficial similarity to scripts in that they are another way to type one thing and have another occur. They are, however, far less flexible, and perhaps an easier way to screw up your system if you make a mistake. Your distribution may already have aliases built in. For example, on my McMillan 6.5. if I type rm I get a question something like, remove this file, yes or no? (rm is remove). The reason for this is that they have preconfigured an alias for rm to equal rm -i. I think the i stands for interrogate, but at any rate, what it does, if you are going to remove or copy over something, it asks for confirmation.

For example, say you often work in DOS and keep confusing the DOS md with the Linux mkdir. md is easier to type. So, using your text editor, you open up your .bash_rc file. Quite possibly, depending upon your distribution, you will see some aliases already in there. McMillan's distro uses single quotes, though I have usually seen double quotes, in for example "Unix, the Visual Quickstart Guide." At any rate, if there are no aliases already in there, try double quotes, if it doesn't work, use single ones.
The only caveat here is that you can't mix them.I did mix them once accidentally, and just got bash errors on startup--use either single or double ones.
Anyway,as my distro uses the single quotes, I would simply type in:
alias md= 'mkdir'
Save it, exit and you're done. You might have to restart X to get it to work, but I haven't had to on mine. Yo will, however, have to exit whatever terminal emulator you're using and open a new one for it to begin taking effect.

This is of course assuming that you're using the bash shell. I am assuming that if you're reading this you're relatively new to Linux and probably are using bash as it is the default shell selected during installation.

Keep in mind that this will work every time. Therefore, be careful of what you do. For example, say you decide to always confirm before removing files, which can often be a good idea. Therefore, you add:
alias rm= 'rm -i'
Now, anytime you type rm to remove a file it will ask for confirmation. However, if you have a bunch of files to remove, and typing y after each one is a nuisance, you're stuck. (Actually, one could simply type rm -rf for recursive and force, which will eliminate the 'are you sure' after each file name, but the above example is for illustration). Or for example, say that you always use chmod with the u+x on your script files so you add an alias like:
alias chmod= 'chmod u+x /usr/bin/scripts
Now,comes a time when you want to chmod on a different file. You'll get something like file not found in /usr/bin/scripts. You'll have to either go into .bash_rc and delete that alias or figure out another workaround. Therefore, be careful in how you use aliases.

Despite these minor drawbacks, I'm sure the reader can see how useful aliases can be for various cumbersome commands.