$ grep ZK105 /net/share/unix1/cosmids?.txt > lines_with_ZK105We can also append (add more lines) to an existing file:
$ grep ZK105 /net/share/unix1/cosmids?.txt > multiple_lines $ grep L2 /net/share/unix1/cosmids?.txt >> multiple_lines
$ grep ZK105 /net/share/unix1/cosmids?.txt > lines_with_ZK105 $ sort -r lines_with_ZK105versus
$ grep ZK105 /net/share/unix1/cosmids?.txt | sort -rWe can also do
$ grep ZK105 /net/share/unix1/cosmids?.txt | sort -r > reverse_sorted_lines_with_ZK105
For many commands
$ grep abc some_fileis equivalent to
$ grep abc < some_fileThis is a convient convention: if a file is specified on the command line, the command takes its input from the file; if not, the command takes its input from standard input.
Sometimes this convention can lead to unexpected behavior. For example, if you type
$ grep abc
grepwill read its standard input from your terminal. That is, each line you type will go to
grep, until you type control-D, which indicates that you are done.
grepis only an example.
catworks the same way, as will many perl programs that you will write.
$ ls non_existent_file* > file_listthe error message
ls: non_existent_file*: No such file or directorystill goes to your screen and not into
file_list. Why? Because
lswrites the error message to standard error, and > grabs only the standard
ls, while leaving standard error alone.
How can you make all of lines that
generates go to the file
That depends on which shell you are running.
To find that out, type
$ echo $SHELLIf you are running csh or tcsh then
$ ls non_existent_file* >& file_listwill do the trick. If you are running sh or bash then
$ ls -l non_existent_file*> file_list 2>&1is the way to go.
Why do we care about standard error? When we run commands in the background we often need to capture their error messages as well as their standard error. In addition, when we start running programs from perl (for example running blast from perl and then taking its output, massaging it, and then feeding it to clustalw) we often want our perl scripts to capture standard error from the programs they are running.
$ blastall -p blastn -i query1 -d nr >& query1_results &Even if we close our terminal and log out,
blastallwill continue to put all its output in
query1_results(as long as we do not reboot the computer).
When we put commands in the background, we have to solve three problems:
xemacsis running in the foreground.) Type Control-Z
Suspended $ bg  xemacs &(
xemacsis running in the background.)
Putting a command in the background after we started it makes sense only if does not produce any output we need to capture.
$ xemacs &  11682 $ gimp &  11683 $ jobs  + Running xemacs  Done gimpUsing this information you can bring jobs back into the foreground:
$ fg %2 gimpbrings
gimpinto the foreground.
jobscommand only shows us jobs that we started directly from a particular shell. Once we exit that shell, we can no longer use their job numbers, nor can we manipulate them with the
fgcommands. Instead, we have to deal with them as processes.
We can see information about (some) of our processes with
$ ps -l F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD 000 S 508 11436 9181 0 70 0 - 542 rt_sig ttyp2 00:00:00 tcsh 000 S 508 11520 11436 0 60 0 - 2386 do_sel ttyp2 00:00:00 xemacs 000 S 508 11620 11436 0 60 0 - 1061 do_sel ttyp2 00:00:00 xterm 000 R 508 11624 11436 0 73 0 - 637 - ttyp2 00:00:00 psThe column PID contains process ids, a.k.a. pids.
You can see more of your processes with
$ ps -lcf -U srozen F S UID PID PPID CLS PRI ADDR SZ WCHAN STIME TTY TIME CMD 000 S srozen 9181 1 - 33 - 3034 do_sel 13:54 ? 00:02:12 xemacs index.html 000 S srozen 9402 9181 - 39 - 542 rt_sig 14:41 ttyp0 00:00:00 -bin/tcsh -i 000 S srozen 9547 1 - 25 - 1530 do_pol 15:09 ? 00:24:19 gtop 000 S srozen 9594 9181 - 39 - 600 pipe_r 15:16 ? 00:00:00 /usr/bin/ispell -a -m -B 000 S srozen 10725 9402 - 39 - 420 wait4 16:33 ttyp0 00:00:00 bash 000 S srozen 10736 10725 - 39 - 418 read_c 16:34 ttyp0 00:00:00 sh 100 S srozen 11360 11357 - 39 - 564 read_c 18:47 pts/5 00:00:00 -tcsh 000 S srozen 11436 9181 - 29 - 543 rt_sig 18:49 ttyp2 00:00:00 -bin/tcsh -i 000 S srozen 11520 11436 - 39 - 2386 do_sel 18:57 ttyp2 00:00:00 xemacs 000 S srozen 11620 11436 - 39 - 1061 do_sel 19:03 ttyp2 00:00:00 xterm 000 S srozen 11622 11620 - 39 - 512 read_c 19:03 pts/7 00:00:00 -csh 000 R srozen 11678 11436 - 23 - 637 - 19:11 ttyp2 00:00:00 ps -lcf -U srozenDrop the
-U srozento see everyone's processes.
show all processes (and other information about the
$ xeyes &  11860 $ kill %1or processes
$ ps -l F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD 000 S 508 11436 9181 0 70 0 - 544 rt_sig ttyp2 00:00:00 tcsh 000 S 508 11861 11436 1 62 0 - 628 do_sel ttyp2 00:00:00 xeyes 000 R 508 11863 11436 0 75 0 - 637 - ttyp2 00:00:00 ps $ kill 11861 $ ps -l F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD 000 S 508 11436 9181 0 70 0 - 545 rt_sig ttyp2 00:00:00 tcsh 000 R 508 11864 11436 0 74 0 - 636 - ttyp2 00:00:00 psSee problem #2 for more on
$ grep abcexample above. Make sure you type in a line containing abc before you end
grep's input with Control-D.
du -s *command. (Look at the
duman page to see what
duagain, and use > to put its output in a file called
du_week0. Don't forget to to do
duagain in a week to see how your disk usage has grown.
lscommand. Redirect the output from the
lscommand to a file,
~/ls_output.(Where is that file located?)
wccommand to count the number of lines in
ls_output. (By now you know how to find out what
ls_outputand use | (a "pipe") to connect the output of
lsto the input of
$ wc > ls_output $ wc > ls_outputand
$ wc >> ls_output $ wc >> ls_output?
$ wc ls_outputand
$ wc < ls_output?
$ ls non_existent_file* > file_listexample above, and then change the command so that the error message goes into
grepwith a pipe in order to show only files that were last modified on
xtermat the command line (in the foreground). Suspend it. Use the
jobscommand to find out what jobs you have. Use
ps -lcf -Uusername to find out what processes you have. Can you find the process that corresponds to the suspended
bgcommand to reactive the suspended
xtermjob in the background. Re-run the
ps -lcfcommands to see what has changed.
killand the pid.
xtermin the background again, and this time kill it using the job number (i.e. using the % sign followed by the job number).
xtermin the background again, and this time run
kill -STOP %job. Is the process still running? If so, get rid of it.
killman page. What is difference between
xtermin the background the easy way, by putting & at the end of the command line. Then start
gtopin the background, and then run
ps -lcf -U...to find the pids of the
gtopprocesses. Can you find those pids in the
ducommand from the first problem in the background, first with redirected output and then without. What happens when output is not redirected?