I think a common problem among a lot of university students is knowing enough UNIX to shoot yourself in the foot without knowing enough UNIX to get work done effectively. Here are some tips and tricks I wish I'd known as a sophomore in college.Dwindlehop wrote:The following text is taken directly from the Internet Archive's February 2003 archive of Mohtalim, which can be accessed from the URL below.
http://web.archive.org/web/200212132040 ... topic?t=18
Give everything a meaningful name. Every directory, every temporary file, every little kludge variable. Don't use a number, don't use foo. I once made the mistake of making a 238 bit wire because it saved on typing 238 different variable names. We probably spent a solid week figuring out which gates needed bit 178 instead of bit 78. Two hours after making changes to bit 203, we'd forget what bit 203 meant and have to relearn its meaning by tracing the logic. Name everything as if you'll have to read your code again at the end of the semester.
If you need to find a specific file, use
Code:
locate
If you need to find a specific file in your path, use
Code:
which
If you need to find every file of a specific name in your path, use
Code:
where
If you need to find a bunch of files, use
Code:
find -name "*.files"
If you need to run a command on a bunch of files, you can do either
Code:
find -name "file*pattern.txt" -exec gzip {} \;
Code:
ls file*pattern.v? | xargs chmod u+rw
The first recursively enters subdirectories, the second does not.
Do use search and replace in your editor. Better yet, learn regular expressions and use regex search and replace. If you have to type something more than five times, use some sort of search and replace plus pasting. If you have to type something more than twenty times, write a script.
To redirect standard error and standard out to a file, use
Code:
cmd >& stderr_and_stdout
Set ls to use colors by putting
Code:
alias ls 'ls --color=auto'
in your .cshrc (or .bashrc or .kshrc) file.
Use egrep, not grep. egrep supports real regular expressions and is faster than grep (or fgrep!). As a trivial example, type
Code:
egrep 'modify|wide|term' ~/.login
grep 'modify|wide|term' ~/.login
and compare the output.
Make lots and lots of little files. Short one, two, or twenty line files take up about a kilobyte of your quota, but can help immeasurably when debugging stuff you did last night or last week. If you type a command line that has more than three arguments, stick the command line in a file and make the file executable
Code:
chmod 700 my_cmd
If your program generates more than a screenful of output or takes more than sixty seconds to run, redirect its output to a file every time you run it.
If you're working on a project for more than two weeks, with other people, or with more than two milestones, think about using CVS. You can create your own cvs repository
Code:
cvs -d ~/CVSROOT init
Then you can import whatever code you've got written.
Code:
cd ~/work/proj/hw11; cvs -d ~/CVSROOT import hw11 initial_version alpha_code
Your friends can check out copies, providing you've given them the permissions on your files.
Code:
cd ~me/groupwork/cs211/; cvs -d ~jdpearce/CVSROOT checkout hw11 -d homework11
CVS will keep track of changes for you, merge changes between two files that were edited simultaneously, and allow you to roll back changes that cause problems.
If you know emacs, use vi by entering 'i' to start inserting text and then hitting ESC to leave INSERT mode. Save the file by typing ':wq' or don't save by typing ':q!'. If you know vi, use emacs by opening files with 'C-x C-f' and then just type. When you're done, save the file by typing 'C-x C-s' and exit the program by typing 'C-x C-c'. If you don't know either one, stop using pico and learn a real editor.
If you have a runaway process and it isn't responding to ^C, hit ^Z to suspend it and then type 'jobs'. Find its job id (usually a one digit number) and use the kill command like so
Code:
kill %1
to kill the suspended job. If that doesn't work, use
Code:
kill -9 %1
This is much easier than trying to use top or ps to find the process id. If your computer is locked up, try ssh'ing in from a nearby machine and killing the offending process before you attempt to reboot. Always try to rescue a stalled machine before rebooting, and never ever reboot the machine by unplugging it. If your admins wanted to let you reboot the machine easily, they would provide a big fat button.
On the command line, the character sequence !$ is an abbreviation for the last argument on the previous command line. This is unbelievably useful. Get used to typing
Code:
mv littlefile monstrous/path/of/doom/@nD/eVil/hate_very_much/
cd !$
Sometimes, the convenience of working from your room outweighs the efficiency of working in the cluster. Install a free UNIX clone, XFree86, and ssh so you can have X Forwarding on your home computer. You can also do this over Windows using XWin32 and ssh.
Ask upperclassmen, even ones not in your class, for help. They can't do your homework for you, but they can tell you the magic sequence of commands to make Matlab print.
Core dumps can be handy! If your program segfaults and dumps core, try
Code:
gdb ~/work/myprog core
When gdb starts, type 'bt' to see the list of functions on the stack. You can pop up to a particular function with 'up 2' and then 'list' the code that caused the offense. If this doesn't work, add a -g to your compiler.
Monitor your quota. If you have to run jobs that will produce more than a couple megabytes of output, redirect their outputs to /tmp. When you're done, remember to rm -rf /tmp so others can use it. Always delete core after you finish using it.
Break work up into multiple files. This helps you think about your project because the complexity is organized. This also helps you split work up and find functions more easily.
Use TAB autocomplete when changing directories or opening files. If TAB autocomplete doesn't work in your shell, try ^D. Sometimes, TAB is the autocomplete character and ^D is the 'prompt for matching files' character.
If you TAs out there have suggestions, additions, or complaints, email me at jonathan@pearce.name and let me know.