S E C T I O N O V E R V I E W

INPUT, OUTPUT REDIRECTION, PIPING AND PROCESS CONTROL S E C T I O N O V E R V I E W In this section, we will learn about: input redirection; output redirection; piping; process control; 5.1 INPUT AND OUTPUT REDIRECTION The shell can be considered as a medium that interfaces end-users and the UNIX operating system kernel. Typically, when someone enters a string in a terminal window, the sequence of characters enters is buffered. This means that characters entered are not sent straight away into the shell. Instead, they are stored somewhere temporarily, typically in a place called buffer. Any data held there are usually transmitted when user presses the <Return> key. This is obvious as we have used several UNIX commands so far. For instance, by typing ls the shell does not react. It simply buffers the characters entered in a sequential order. Then by pressing the <Return> key, this sequence is transmitted into the shell for further processing. The sequence of characters entered for transmission is called input. The processing of input by the shell usually results in the production of data that are displayed on our terminal. This is known as output. Considering again the ls command, the corresponding output should be a list of all files that reside in our current directory. At this point, readers should be able to realise that each UNIX command is associated with two streams, namely the input and the output stream. However, there is also a third one known as error output. Moreover, as PAGE 1

these are the standards ones, their names are known as standard input, standard output and standard error. They are abbreviated as stdin, stdout and stderr with corresponding identifiers 0, 1, 2 respectively. FIGURE 5.1: STDIN, STDOUT AND STDERR As elaborated previously, the role of standard input and standard output is clear. The role of stderr is twofold. The standard output stream allows us to have error messages if something goes wrong with the execution of a command. Whilst it also gives us some indications regarding the type of error. For example, if we attempt to execute the command ls with argument a file name of a file that is does not exist; we will end up with an error message indicating the file is not existent. So far we have seen several means that allows us to display the output of a file on the terminal window. These include the more command or applications such as vi and emacs. At this stage, we will start working with another one known as cat which stands for concatenate. SYNTAX cat cat <filename> <filename> NOTE: IF NO ARGUMENT IS ENTERED IT TAKES ITS INPUT FROM THE STANDARD INPUT STREAM. [CTRL-D TO EXIT IS REQUIRED] SYNTAX 5.1: cat SYNTAX As, its name reflects, the cat command concatenates all files entered as arguments and outputs them on the terminal window using the standard output. PAGE 2

EXAMPLE cat 4 tiger% cat file1 file2 This is my first file. This is my second file. 5 tiger% SAMPLE OUTPUT 5.1: CAT EXAMPLE Sometimes, we may need to use commands with some predefined input stored in a file. Some other times, it is essential to store data outputted by a command into a file. This can be achieved with the input (<) and output (>) redirection characters. For instance, we may need to redirect input from a file into a UNIX command and to redirect its output into a file. Some other times, we may need to store the output of a command i.e. who to a file in order to store this data for our archive. These needs generate four possible options. However, there are more as, for example, we may need to redirect output to another device such as a printer. The following subsections describe standard input and output redirection that reflect input from files and keyboards and output into files and the terminal display. 5.1.1 KEYBOARD INPUT AND FILE OUTPUT REDIRECTION Figure 5.2 illustrates the concept of output redirection into a file called myfile. By executing the command cat > myfile, we are able to enter data using the keyboard input. FIGURE 5.2: FILE OUTPUT REDIRECTION As shown, cat command can also be used without arguments. This means that everything that is entered after its execution is displayed on the terminal display. However, as we instructed the shell to substitute the terminal display with a file through output redirection, everything that is entered is redirected and stored into this file. PAGE 3

5.1.2 FILE INPUT REDIRECTION In a similar fashion like file output redirection, the following figure (5.3) illustrates the concept of input redirection. More precisely, users can instruct the shell that input should be taken from a file. FIGURE 5.3: FILE INPUT AND FILE OUTPUT REDIRECTION By entering the command cat < myfile, we instructed the shell to get the contents of the file called myfile and use them as input for the command cat. The execution of this command should display the contents of myfile the terminal display. Note that as cat accepts arguments such as files the input redirection can be omitted. 5.1.3 FILE INPUT AND FILE OUTPUT REDIRECTION We may also wish to process some data already stored into a file and the output obtained by executing a UNIX command should be stored in a file, as well. Therefore you can use the standard input and output redirection characters associated with the corresponding files. FIGURE 5.4: FILE INPUT REDIRECTION The command cat < myfile > mynewfile indicates the shell to accept as input the contents of the file myfile and based on the input given to the PAGE 4

command cat to redirect the command s output into a new file called newfile. Filenames that are given for input and output redirection should be distinct. Alternatively, you cannot redirect input to a command from a file and redirect output of this command to the same file. If you will attempt to do this, you will eventually destroy the source file as the system will attempt to create a new destination file by deleting the source one. 5.1.4 FILE OUTPUT REDIRECTION The last case corresponds to the file output redirection. Consider, for example, that we need to know who is currently logged in the same UNIX machine. Although we can do this using the who UNIX command, we also need to store this information and process it later. In this case, we can instruct the shell to redirect the contents obtained from the who command into a file given as an argument. FIGURE 5.5: FILE INPUT REDIRECTION The who > myfile redirected standard output into a file called myfile. Users can use the cat or more command to see the contents of this file. Moreover, they can use editors to open myfile file. In fact, the contents of this file are exactly the same as those would be displayed on the terminal window. 5.1.5 ISOLATING STANDART OUTPUT AND ERROR OUTPUT As elaborated previously, we can also redirect standard output and standard error. Moreover, we can also separate them. This is useful, in case we need to obtain standard output and standard error. Consider for example, we need to find a file in a UNIX directory. Moreover, as we are not aware about the location of this file we wish to start searching from the root directory. The problem in this case is that we can search only directories, we have access rights. If the find command will attempt to access restricted areas, this would result in the generation of error messages indicating that. Therefore, it is PAGE 5

reasonable to redirect standard error to a file of even to a device in order to avoid redundant output. This is carried out by typing find / -name myfile print 2> /dev/null. Observe the string 2> that should be entered without spaces. The number 2 corresponds to the standard error while the symbol (>) refers to the output redirection character. Moreover, the string /de/null represents the device null located into the /dev/ directory. This device will simply discard any error messages forwarded to it. In order to simplify that, we can consider some parts of this command as crudely defined if then statements. In short, the 2> means that if there is a standard error message, recalling from back 2 represents stderr, then redirect the standard error into the /dev/null device. Here is an example output that illustrates this concept (5.2). NOTE THAT THIS IS A SPECIFIC SHELL SYNTAX USED BY BOURNE SHELL FAMILY. THEREFORE YOU NEED TO SWITCH TO BOURNE SHELL BY TYPING SH. OBSERVE THAT THE PROMPT HAS BEEN CHANGED TO $. EXAMPLE sh, find 8 tiger% sh $ find / -name mynotes -print find: cannot read dir /lost+found: Permission denied find: cannot read dir /usr/lost+found: Permission denied find: cannot read dir /usr/local/lost+found: Permission denied./one/mynotes./mynotes $ find / -name mynotes -print 2> /dev/null./one/mynotes./mynotes SAMPLE OUTPUT 5.2: ERROR REDIRECTION IN BOURNE SHELL Initially, we attempted to fine mynotes file starting form the root directory. However, the UNIX system started searching; we received numerous errors as permission to certain directories was denied. Therefore, we followed a more efficient approach by redirecting standard error to the /dev/null device. In this way, we just filtered standard error based on its file descriptor and redirected it to the /dev/null device. In a similar fashion, we can redirect standard error and standard output to a file for further processing. However, we have a slightly different syntax PAGE 6

for carrying out that. The following is an example base on the C Shell. Note that in order to switch back to the C Shell, we usually use type csh. EXAMPLE csh, find $ csh 1 tiger% find / -name mynotes -print >& myfile 2 tiger% SAMPLE OUTPUT 5.3: STANDARD OUTPUT AND ERROR REDIRECTION The execution of find / -name mynotes print >& myfile redirected standard error and standard output into file myfile. This means that any errors and any results were placed in myfile. We can conclude that these redirections in C Shell are not so flexible like in the Bourne Shell family. For instance, using the C Shell, we may need to obtain only the standard output without the standard error. However, we cannot separate them. A possible solution is that we may to redirect standard output to a file while standard error is redirected to the window terminal. This is shown in sample code 5.4. EXAMPLE find, cat 15 tiger% find / -name mynotes -print > output find: cannot read dir /lost+found: Permission denied find: cannot read dir /usr/lost+found: Permission denied 16 tiger% cat output./one/mynotes./mynotes 17 tiger% SAMPLE OUTPUT 5.4: STANDARD OUTPUT AND ERROR REDIRECTION The find / -name mynotes -print > output filtered standard error by displaying it on the terminal window while standard output was being redirected to the file output. The command cat output displayed the standard output obtained. As there are differences regarding the syntax of the redirection characters among shells; we provide a table with some form of these redirections between the C Shell and Bourne Shell family. C SHELL BOURNE SHELL DESCRIPTION > > Redirect standard output >& Redirect standard output and standard error < < Redirect standard input >! Redirect standard output by overriding existed file >&! Redirect standard output and error by overriding existed file PAGE 7

Redirect standard output to another command (pipe) >> >> Append to standard output >>& Append standard output and standard error 2> Redirect standard error 2>&1 Redirect standard error to standard output 2>&1 Pipe standard output and standard error to another command TABLE 5.1: C AND BOURNE SHELL FAMILIES: INPUT/OUTPUT REDIRECTIONS The last redirection output redirection character, we should consider is (>>). Recalling back, the (>) character will redirect standard output to a file with a given filename. However, if the file exists, the shell will override it in order to place any new information. This (>>) character or the sequence of these two characters will instruct the shell to append an already existed file. Therefore, any information obtained by the execution of a command will be inserted at the end of any contents held in the existed destination (file). Note that, if the file does not exist the shell will create a new one. This is illustrated in sample output 5.4. EXAMPLE csh, find 21 tiger% date > events 22 tiger% cat events Sun May 15 19:45:07 BST 2005 23 tiger% who >> events 24 tiger% cat events Sun May 15 19:45:07 BST 2005 beusdul pts/20 May 15 08:21 (host-84-9-15-179.bulldogdsl.com) svigkoi pts/3 May 15 18:52 (dsl-80-42-146-58.access.as9105.com) w0207706 pts/4 May 15 19:00 (81-86-183-207.dsl.pipex.com) 25 tiger% SAMPLE OUTPUT 5.5: APPENDING FILES THROUGH OUTPUT REDIRECTION Assuming that we want to maintain a file called events that logs the date and time of the system and any users that are logged in the tiger UNIX server. First, we executed the command date > events by redirecting its output to the file events. This resulted in the generation of the file with contents as printed out by the more events command. As, we want to have a list of users logged in, we executed the command who >> events. The output of this command was redirected from the standard output and placed in the file events. The file events was not actually deleted but it was appended with additional data. The cat events execution printed out the contents of the appended file. PAGE 8

5.1.4 MULTIPLE COMMAND EXECUTION AND REDIRECTION We can also execute several commands at once and redirect their standard output to a given file. This can be carried out by the use of the semicolon (;) and brackets symbols ( ( ), ( ) ). Assuming that we need to generate a file that contains information about time and users logged in a UNIX server. A possible solution elaborated previously is to execute first the command date > logfile where date is a UNIX command and logfile corresponds to a give file name. The execution of this command will generate the file and it will store in it information about current date and time. Then is is obvious, we need to execute who >> logfile. This will append the file logfile with information outputted by the who command. However, the approach illustrated in sample output 5.6 refers to a different way. EXAMPLE (date;who) > events 2 tiger% (date;who) > events 3 tiger% more events Wednesday May 18 21:15:00 BST 2005 beusdul pts/7 May 18 09:24 (host-84-9-15-179.bulldogdsl.com) svigkoi pts/20 May 18 20:36 (dsl-80-42-146-58.access.as9105.com) w0304983 pts/35 May 18 21:14 (tiger) w0305792 pts/33 May 18 20:46 (snake.gotadsl.co.uk) svigkoi pts/34 May 18 20:48 (dsl-80-42-146-58.access.as9105.com) w0314661 dtremote May 18 08:23 (ncs-202-pc17.oac.wmin.ac.uk:0) w0314661 pts/3 May 18 08:23 (ncs-202-pc17.oac.wmin.ac.uk:0.0) w0314661 pts/4 May 18 08:23 (ncs-202-pc17.oac.wmin.ac.uk:0.0) w0314661 pts/18 May 18 08:23 (ncs-202-pc17.oac.wmin.ac.uk:0.0) w0314661 pts/5 May 18 08:23 (ncs-202-pc17.oac.wmin.ac.uk:0.0) w0211447 dtremote May 18 16:40 (ws-hd-pc04.irs.wmin.ac.uk:0) w0211447 pts/40 May 18 16:41 (ws-hd-pc04.irs.wmin.ac.uk:0.0) 4 tiger% ^C SAMPLE OUTPUT 5.6: APPENDING FILES THROUGH OUTPUT REDIRECTION By executing command (date;who) > events, the shell executed the command date first and buffered its output. Then, in a similar way executed the second command who and added into the buffer its output. As, we indicated that output should be redirected into file events; the shell wrote the contents of the buffer into the corresponding file. The brackets indicated the precedence of the execution. Alternatively, they dictated the execution of both commands whose output, then, was redirected. Note that in sample output 5.6, we described the execution of two UNIX commands. However, we indice PAGE 9

brackets we can enter as many commands as we wish to execute separated by the semicolon symbol. 5.2 COMMAND PIPING So far, we had the opportunity to work with input and output redirection. For example, we considered a process output redirection to a file and its input redirection from a file or the keyboard and so on. At this stage, we may have an obvious question which is Can we redirect a command s output to another one?. The answer is simply Yes, we can do that with two ways; an indirect and a direct one. Let us consider the first approach which we are familiar with. For example, let us assume that we wish to count the number of users who are currently logged in. Therefore, we need to use the who and wc -l commands. However, as we are not familiar with the notion of process piping, we initially execute the first command and redirect its output to a file called mylog. EXAMPLE who, wc l 14 tiger% who > mylog 15 tiger% wc -l < mylog 9 16 tiger% SAMPLE OUTPUT 5.7: APPENDING FILES THROUGH OUTPUT REDIRECTION Next, we redirected into standard input the contents of the file mylog into wc -l. This resulted in having as output number 9 which refers to the number of users currently logged in tiger UNIX machine. The second way is to use the piping technique. This means that in a similar fashion with the input/output redirection, we redirect standard output of a process as standard input into another one. In order to indicate the shell out intentions we use the symbol ( ). The syntax of piping technique is described as follows (Syntax 5.2). SYNTAX piping % command A command B [NOTE THAT THE SYMBOL % REFERS TO THE COMMAND PROMPT.] SYNTAX 5.2: SYNTAX: PIPING TECHNIQUE PAGE 10

Although syntax 5.2 described the piping technique for two commands, namely command A and command B, we can pipe more than two processes. In order to understand the piping technique in a more clear way, we provide an illustration (figure 5.6) FIGURE 5.6: PROCESS PIPING In figure 5.6, we can see that standard input (stdin[0] A ) is redirected into process A. The execution of this process results in the generation of some output ((stdout[1] A ) which is redirected into process B as standard input (stdin[0] B ). Then the execution of command B generates is redirected to standard output (stdout[1] B ). Note that, the execution of pipelined commands may result to the generation of errors. These are handled by the standard error (stderr[2]). 5 tiger% who wc -l 11 6 tiger% who wc -l > nusers 7 tiger% more nusers 11 8 tiger% SAMPLE OUTPUT 5.8: USING PIPED PROCESSES As illustrated in sample output 5.8, the standard output of who command was redirected as standard input in the wc l command. This means that who gave us a list of all users then the wc l count all lines in the given list and showed result on our terminal window. Moreover, as also shown, we can use piped processes with redirection. For example, we executed again the piped command who wc l but we redirected its output into a file called nusers. PAGE 11

5.3 PROCESSES AND PROCESS CONTROL From knowledge and experience gathered so far, we are able to understand that commands allow us to interact with the UNIX operating system. This kind of interaction ranges from entering commands for getting information about the state of the system to executing commands that change the state of the file system i.e. deleting or creating files and directories. Whatever, we do we need to remember that when we execute commands, we give certain instructions to the system which, then, takes some action. TERM process Typically, the commands we have considered so far reflect to sequences of bytes, at a very low level, that can be understood by UNIX machines. However, there is also a second kind of commands that are executed in a different way. These are first interpreted by specific programs, known as interpreters, and executed then by the interpreters themselves. Both of these types of commands are known as processes. At any time, each process that is under execution should be moved out or fetched along with any necessary data, from the machine s memory and sent to the CPU for processing. After this step, any output given based on a set of these instructions will be stored back into the machine s memory. At, this point, the obvious question is that Yes, but what happens if a process requires lots of processing resources or its execution takes long time; moreover what happens to other processes waiting for execution? You said UNIX is a multi-tasking operating system but here we can see a kind of sequential processing! The point here is that processes have different requirements and their execution time differs. However, in order to maintain the notion of multitasking, processes are given a certain amount of time to complete their execution while they are being processed. If their execution cannot be completed at the given time slot, the operating system s kernel, just suspends their execution and starts executing another command. Then, based upon some kernel s criteria, a suspended process is fetched again from memory, for further processing. When, a process finishes execution is removed from machine s processor(s) and killed. The managing of processes is carried out by the kernel while this task is transparent from end users. PAGE 12

TERM system process Now, it is clear that, processes can be in one of several states. For example, they can be in execution state or they can be suspended. At any time or when their execution is finished, they are just killed and removed from a machine. This typically happens to all processes which are initialised by endusers. Whilst, some process known as system-processes run at all times in order to make a machine operable. For instance, some of these include the kernel itself and the shell. Although the control of these processes is transparent from end-users and managed with an autonomous way, users can also manage some of these processes. In general, processes initialised in a shell have two types. They may be part of the shell itself or they can be not. In the former case, processes will be interpreted and executed by the shell and after execution the command prompt will return back to end-users. In the latter, a new process will be created by invoking code stored in the machine while the shell which is a process itself will be suspended. Its execution will be resumed after the execution of the new process. For example, by invoking one of the UNIX editors i.e. emacs, a new process starts execution known as emacs. This makes the command prompt stop operating and it will be returned back to us after emacs process finishes execution or killed. Typically, users can control the execution of processes initialised in a shell. They can obtain information about processes that are running; they can suspend some of them or even kill them. In order to get information about all processes initialised, a user needs to execute the ps command where ps stands for process. Its syntax is described as follows: ps [options] SYNTAX 5.3: SYNTAX OF ps COMMAND There are several options that can be used with ps command. Some of these options are summarized in table 5.2. However, by typing ps only, we can obtain information about each process that corresponds to its unique process identifier (PID), displayed in the first column; the name of the terminal from which a process is running and can be controlled (TTY); the third column displays the amount of processing time, a process has consumed while the last column refers to the name of each process. The following sample output shows processes running in a shell. PAGE 13

10 tiger% ps PID TTY TIME CMD 15497 pts/5 0:00 ps 14954 pts/5 0:00 csh 11 tiger% ps -lf F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD 8 O w0304983 15498 14954 0 50 20? 144 11:27:18 pts/5 0:00 ps -lf 8 S w0304983 14954 14952 0 40 20? 203? 11:03:12 pts/5 0:00 -csh 12 tiger% ps -al F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD 8 O 23719 15499 14954 0 50 20? 144 pts/5 0:00 ps 8 S 127 14707 14646 0 40 20? 1268? pts/17 0:01 pine 8 S 127 14646 14640 0 40 20? 326? pts/17 0:00 bash 8 S 48330 14951 14854 0 40 20? 289? pts/18 0:00 telnet 8 S 679 14135 14126 0 40 20? 1339? pts/23 0:01 pine 8 S 653 12789 12776 0 40 20? 1745? pts/20 0:10 pine 13 tiger% SAMPLE OUTPUT 5.9: USING PIPED PROCESSES As shown, ps displayed some information about processes running in a shell. Moreover, we also used several options to obtain more information. For example, -lf instructed the shell to display a long listing of processes and their current priorities. However, at this stage we are only interested to know some of this information. For example, we may consider the PPID (Parent process ID) which initialised a process. Moreover, we may also consider the STIME (start time) of a process, its current priority (PRI) and the UI (user ID) of the user who initialised a process. OPTIONS DESCRIPTION -a Lists information about all processes most frequently requested -e Lists information about every process now running. -f It generates a full listing -l It generates a long listing -P Prints the number of the processor to which the process is bound, under column header, PSR. TABLE 5.2: SOME PS OPTIONS We can also get information about all processes that are currently running. These include system processes and processes generated by anyone who uses a UNIX machine. In a similar way, we can obtain information regarding PIDs, users who initialised each process (USER), processes priorities (PRI), memory each process consumes (SIZE) also expressed in percentage rate (%MEM), processor power (%CPU). Moreover, we also get PAGE 14

information about each process name (COMMAND) and its processing time (TIME). load averages: 0.04, 0.04, 0.04 12:12:52 72 processes: 70 sleeping, 1 stopped, 1 on cpu CPU states: % idle, % user, % kernel, % iowait, % swap Memory: 2048M real, 1403M free, 151M swap in use, 4458M swap free PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND 16160 root 1 59 0 3168K 2784K sleep 0:01 1.05% in.ftpd 16191 svigkoi 1 0 0 2664K 1264K cpu/1 0:00 0.44% top 15973 root 1 59 0 3504K 2880K sleep 0:00 0.07% sshd 16061 w0310195 1 59 0 8960K 6720K sleep 0:01 0.06% emacs 16121 root 1 59 0 3656K 3272K sleep 0:00 0.03% in.ftpd 234 root 20 59 0 3752K 3232K sleep 0:34 0.02% nscd 16190 svigkoi 1 59 0 1000K 792K sleep 0:00 0.02% tee 15976 svigkoi 1 59 0 1584K 1384K sleep 0:00 0.01% csh 15527 root 1 59 0 3616K 2920K sleep 0:02 0.01% sshd 16157 root 1 59 0 3160K 2776K sleep 0:00 0.00% in.ftpd 198 root 3 59 0 4704K 2912K sleep 12:24 0.00% automountd 3085 nobody 1 59 0 11M 10M sleep 1:45 0.00% xfs 302 root 1 59 0 6232K 3792K sleep 1:28 0.00% cfenvd 174 root 1 59 0 2520K 1880K sleep 0:45 0.00% inetd 20702 w0310199 5 59 0 111M 74M sleep 0:40 0.00% soffice.bin SAMPLE OUTPUT 5.10: USING top COMMAND For example, we can see from sample output 5.10 that there are 70 processes which are running with 70 of them sleeping, one which is stopped and one which is being processed by the central processing unit of the corresponding machine (tiger). The second line refers to various statistics of tiger machine expressed as percentages. Then, the top command displayed a list of processes. For example, let us consider the first described process. It has process ID 16160 and it was initialised by user root who is the administrator of this machine. Its priority is 59, its size is 3168Kbytes and it is currently sleeping. Moreover, considering its name, ftpd, it is clear that it refers to the ftp server process which actually allows us to connect to this machine through FTP and transfer files. 5.3.1 WORKING WITH PROCESSES: BACKGROUND AND FOREGROUND So far, we use the command prompt to execute various UNIX commands. Some of them after finishing execution return the command prompt to us indicating that the system is ready to accept another command. However, using some other commands or applications, we have to exit in order to get back the command prompt. For instance, this happens when we PAGE 15

use emacs editor. In this case, it is said that a command runs in the foreground. As this is not very efficient, we may instruct the shell to execute a command in the background. In fact, this will allow us to use our command prompt for executing other processes, as well. In order to instruct the shell for sending a command to the background we use the ampersand symbol (&) places at the end of a command. 24 tiger% ls & [1] 16859 25 tiger% StarOffice52 ffjuser30 mydir one1.2 Final Trash file myn2 public_html Folder after mail. [1] Done ls 25 tiger% SAMPLE OUTPUT 5.11: SENDING COMMANDS IN THE BACKGROUND The execution of ls command was sent in the background. This is shown because after sending this command for execution, we were informed about its job number ([1]) and its process identifier (PID) which is16859. Then, the command prompt was given back to us. As, ls finished executing, we received a notice informing us about this event. The most important point here is that when we send processes in the background we get our shell prompt back, almost immediately. Note that usually ls displays the content of a directory and automatically exits. Although the provided example is not very indicative, it shows the concept described previously. 5.3.2 CONTROLLING PROCESSES The sleep command can suspend execution of the shell for a given time. For example, we can type sleep 20 in order to suspend execution of the shell for 20 seconds. 29 tiger% date;sleep 20;date Thu May 19 12:58:20 BST 2005 Thu May 19 12:58:40 BST 2005 30 tiger% PAGE 16

SAMPLE OUTPUT 5.12: SUSPENDING EXECUTION It is probably understood that sleep is not very useful. However, it is a precise example that demonstrates how we can interact with and control processes in the UNIX operating system. 5.3.3 KILLING PROCESSES TERM signal Each UNIX process can communicate with another one through the exchange of simple messages. These messages, known as signals, are expressed as single bytes and can instruct processes to perform various operations. Typically, with this approach the kernel has the ability to manipulate processes existed in a machine. For example, the kernel can suspend the execution of a process or it can kill it, if this is necessary. Moreover, it can also schedule processes by indicating their execution order, when they should be executed and their priority. Users can also send messages to processes that have been initialised by them, as well. At this stage, we are interested only about killing processes that have been sent in the background. Consider for example that command sleep 5000 has been sent for background execution. Although, we can use ps to check out that this process is running, we may also wish to stop its execution. Therefore, we need to send a message to sleep command that instructs it to exit. This can be carried out by the signal SIGKILL that when received, it will cause sleep to be destroyed almost immediately. The command responsible for sending these kinds of messages is the kill UNIX command. kill <PID> SYNTAX 5.4: SYNTAX OF kill COMMAND As shown, in order to kill a process we use the kill command while we enter as an argument the process identifier of the process we wish to terminate. In order to find out the process identifier of the corresponding process, we may use the ps command first. Here is a sample output (5.13). 30 tiger% sleep 5000& [1] 17790 31 tiger% ps PID TTY TIME CMD PAGE 17

17791 pts/5 0:00 ps 17790 pts/5 0:00 sleep 14954 pts/5 0:00 csh 32 tiger% kill 17790 33 tiger% [1] Terminated sleep 5000 33 tiger% SAMPLE OUTPUT 5.13: KILLING PROCESSES First, we sent to in the background the command sleep 5000&. Then, we entered ps, in order to find out its process identifier and then we instructed the shell to terminate this process. When, the termination completed, the shell informed us by displaying an event notification. There are several motivational aspects regarding the termination of a process. For example, we may have sent a process for background execution by mistake or a process started running for a long time and it consumes lots of computational power. At last but not least, we may terminate a process if it is not responding anymore (crashed). 5.4 PRACTICE 1. Crate a file called dayandtime and then insert information about today s date and time; use an appropriate command to display the contents of this file in your terminal window; create a hard link of this file called hdayandtime; make sure the new file has been created; display the contents of your hard linked file; delete the source; append your hard-linked file with information about day and time; display the contents of your hard-linked file; create a soft link of your hdayandtime file with name sdayandtime; make sure your new file has been created; PAGE 18

display its contents in the terminal window; append your soft linked file with information about date and time; display the contents of your soft linked file in the terminal window; delete your soft link file; delete your hdayandtime file. [NOTE: MAKE SURE THAT YOU WILL NOT USE ANY EDITORS. INSTEAD, USE THE APPROPRIATE REDIRECTION CHARACTER(S) FOUND IN.1.] 2. Create a log file, called userslog that contains information about users who are currently logged in tiger.westminster.ac.uk machine. Your file should contain the following: Date and time; All users logged in; [HINT: USE THE > REDIRECTION CHARACTER] 3. Repeat exercise one (1), at this time your file with the same filename (do not append it) should include: An integer number that reflects the number of users who are currently logged in tiger.westminster.ac.uk. 4. Delete file userslog using the appropriate UNIX command. Then create a file called userslog again and: enter the date and time; all users logged in tiger.westminster.ac.uk; display the file contents in your terminal window; log in jaguar.westminster.ac.uk; append your file userslog with day and time as obtained from jaguar.westminster.ac.uk machine; the additional information should include all users logged in jaguar.westminster.ac.uk. display the contents of your appended file in your terminal window; delete your file. PAGE 19

5. Execute the appropriate command that displays information about processes which run under your current shell. Forward, the commands output: to the terminal window; execute it again and redirect it to a file called myprocesses; diplay the file contents on the terminal window; initialise a sleep command with duration 10000 seconds and send it in the background; call the appropriate command to get a long listing of processes which are currently running. The output of this command should be displayed in your terminal window; call the appropriate command again but redirect its output into the file myprocesses; redirect the contents of myprocesses into the file bmyprocesses. Do not use the copy command. display the contents of bmyprocesses in the terminal window; terminate the sleep command initialised previously. Get a long listing of processes which are currently running. Dipplay them in your terminal window. Make sure the sleep command is terminated. delete all files created. 6. Using the file bankacc created by you in the last section (section 4, exercise 5), redirect its output into a file called dates. Your dates file should include only the transaction dates made on the shared bank account. 7. In a similar fashion to exercise 6, cretate a file with all account holders who made transactions. Your file should be called tnames. 8. Use the find command to look for a file in your current directory and all subdirectories i.e. search for mynotes file. Create a directory called noaccess and change its access rights so no one can access it. Then, use the find command to search again for mynotes file. Diplay any outout on the terminal window. Then: PAGE 20

Redirect find s output in a file called search. Could you forward standard error or standard error and standard output into this file? Use C shell and Bourne shell. PAGE 21