added job control section
authorEdgar Bering <ebering@csclub.uwaterloo.ca>
Mon, 4 Aug 2008 16:45:33 +0000 (12:45 -0400)
committerEdgar Bering <ebering@csclub.uwaterloo.ca>
Mon, 4 Aug 2008 16:45:33 +0000 (12:45 -0400)
holy-fuck-a-shell.pod

index 7af4ba3..8fd8aa2 100644 (file)
@@ -346,12 +346,85 @@ shell that separate it from the gui, the programmable loops, variables that
 affect program execution, and io redirection. This section describes the
 machinary the shell provides to put words together to form ideas.
 
+=head3 Every command you run is a process: how to run more than one.
+
+Every command you start from the shell (well there are a few exceptions we'll
+go in to in a bit) runs as a I<process>. In Unix processes represent separate
+discrete running programs, for example you can have several processes which 
+are all cp with different arguments (or the same arguments, but that is likely
+to break and not advised). In playing around with what you've learned in the
+last chapter you may have been frustrated by only being able to do one thing
+at a time. The shell does not limit you to running one thing at a time, and
+on the contrary gives you powerful tools for managing processes, both those 
+started by you and those already running on the system.
+
+For the purposes of I<job control>, processes can be viewed in two groups:
+those under the control of your shell (your I<jobs>), and those not. We'll
+first discuss the ways of starting your own jobs and interacting with them.
+
+=head4 Your jobs and what to do about them
+
+The first thing you're probably wondering is how to start more than one job.
+To do this you first need to know the difference between a I<foreground>
+process and a I<background> process. A foreground process is running attached
+to your terminal, your command prompt goes away and is replaced by its output 
+and any input goes to the program. With a program running in the background 
+it doesn't recieve input (unless you have an io redirect, more on that later)
+and output goes to your terminal, but you can still enter other commands.
+
+Before we can get to fancier features you probably want to know how to stop
+something in the foreground. To I<interrupt> or B<c>ancell the job in the
+foreground press C<CTRL+C> (hereafter C<control> will be abreviated with C<^>
+followed by a character. So C<CTRL+C> is C<^C> and so on and so forth). If you
+want to pause the job instead of terminating it press C<^Z>. This stores the
+process in a stopped state and gives you your command prompt back. You'll also
+see a message that looks like
+
+ [1]+   Stopped         some command with args
+
+The number in square brackets is the job number, C<+> means the state has
+changed. This is followed by the new state and what job is being run. If you
+want to bring your job back to the foreground type C<fg %1> and your job will
+come back just as you left it. Not very interesting, but the next part is. If
+you want to let your job finish running in the I<background> while you do
+something else type C<bg %1> and your job will resume running, but you still
+have a prompt to use. If you know you want a command to run in the background
+and don't want to futz with C<^Z>ing it and then typing bg you can just put an
+C<&> at the end of your command like so:
+
+ $cp ~/giant_file.tar.gz /mnt/usbdrive &
+
+Note that the number 1 in C<%1> isn't special, its just the usual job number of
+your first job. It will be different if you have more jobs running. To get a
+list of your jobs type C<jobs>. This will have job numbers, states and what
+command is running.
+
+To terminate a job early or put one of your background in a "Stopped" state
+(and often to communicate with it in other ways) unix provides I<signals>. A
+signal is a numbered code sent to a process with a meaning defined by the
+system. Commonly used signals are terminate, C<TERM>; kill, C<KILL>; and stop, 
+C<STOP>. C<TERM> instructs a process to stop what its doing and quit, C<KILL>
+ends it, and C<STOP> is equivalent to C<^Z>. Yes, C<^C> has a corresponding
+signal: interrupt, C<INT>. To send signals to jobs use the C<kill> command.
+By defaul C<kill> sends the C<TERM> signal, to specify other ones use C<-s>
+followed by the signal name. You also need to tell C<kill> which job to send
+the signal to.
+
+=head4 Other processes
+
+You may be wondering about the mention of processes not started by your shell.
+These all have associated numbers, called a I<process id>. Your jobs also have
+pids, and kill will take a pid instead of a job id. To see a listing of current
+processes use the command C<ps>. This will give all sorts of information:
+the pid, who started it, the attached terminal, whats running, the ram usage.
+C<ps> gets more useful when you're using more than one terminal or performing
+system administration.
+
 =for commentary
 
 Now I have to write this fucking section. Subsections:
-Jobs and controlling them
-Variables, Environment Variables
 IO Redirection and the Pipe
+Variables, Environment Variables
 Loops and conditionals
 Scripts and arguments for them