• No results found

CL-I LAB MANUAL 2010-11

N/A
N/A
Protected

Academic year: 2021

Share "CL-I LAB MANUAL 2010-11"

Copied!
100
0
0

Loading.... (view fulltext now)

Full text

(1)

PUNE INSTITUTE OF COMPUTER TECHNOLOGY DHANKAWADI, PUNE – 43.

LAB MANUAL

ACADEMIC YEAR: 2010-2011 DEPARTMENT: COMPUTER ENGINEERING

CLASS: B.E SEMESTER: I SUBJECT: COMPUTER LABORATORY-I

INDEX OF LAB EXPERIMENTS EXPT.

NO

PROBLEM STATEMENT Revised on

PART I: Principles of Compiler Design

1 Write a LEX program to count number of characters, words and lines as remove the C and C++ comments from a given input text file. Create an output text file that consists of the contents of the input file with line no. and display total no. of character word and lines.

02/07/2010

2 Implement a lexical analyser for a subset of C using LEX. Implementation should support error handling.

22/06/2009 3 Implement a natural language parser using LEX & YACC. 22/06/2009 4 Write an ambiguous CFG to recognise an infix expression and

implement a parser that recognises the infix expression using YACC. Provide the details of all conflicting entries in the parser table generated by LEX and YACC and how they have been resolved. (can take calculator as an application)

22/06/2009

5 Write an attributed translation grammar to recognise declarations of simple variables, “for”, assignment, if, if-else statements as per syntax of C or Pascal and generate equivalent three address code for the given input made up of constructs mentioned above using LEX and YACC. Write a code to store the identifiers from the input in a symbol table and also to record other relevant information about the identifiers. Display all records stored in the symbol table.

22/06/2009

6 Laboratory Project

For a small subset of C with essential programming constructs, write a compiler using LEX and YACC(To be carried out in a group of 4 to 6 students).

(2)

PART II : Operating System 22/06/2009 7 Study of Various Commands in Unix/ Linux

This assignment includes:

General commands like grep,locate,chmod,chown,ls,cp etc. It also includes the various system calls like:

File System Calls: read(),write(),open() etc. Process System Calls: fork(),execv(),execl() etc.

Inter-process System Calls :pipe(), popen(), fifo(),signal() etc. Each command should be written as per the format specified

22/06/2009

COMMAND NAME command name

FORMAT command [option(s)] argument(s)

DESCRIPTION A brief description of what the command does.

OPTIONS A list of the most useful options and a brief description of each.

ARGUMENTS Mandatory or optional arguments.

EXAMPLE A simple example of how to use the command.

8 Using fork system call create a child process, suspend it using wait system call and transfer it into the Zombie state.

22/06/2009 9 Write a program for Client-Server communication using following

inter- process communication mechanism. 1. Unnamed pipe

2. Named pipe

3.Semaphore (General)

22/06/2009

10 File management using low level file access system calls such as write, read, open lseek, fstat

22/06/2009

11 Implement an Alarm clock application using signals 22/06/2009

12 Create a program which has three threads

1. Display Seconds 2. Display Minutes 3:Display Hours.

22/06/2009

13 Write and insert module in Linux Kernel. 22/06/2009

PART III: Design and Analysis of Algorithm Note: Compute the time and space complexity for following

assignments.

22/06/2009

14 Implement using divide and Conquer strategy(any one)

• Merge Sort and Randomized Quick sort (recursive and non recursive) and Compare recursive and non recursive versions • Multiplication of 2 ‘n’ bit numbers where ‘n’ is a power of 2 .

(3)

15 Implement using Greedy Method

Minimal spanning tree/Job scheduling 22/06/2009

16 Find shortest path for multistage graph problem (single source shortest path and all pair shortest path)

22/06/2009 17 Implement 0/1 Knapsack's problem using Dynamic programming,

Backtracking and Branch & Bound strategies. Analyse the problem with all three methods

22/06/2009

18 Implement with Backtracking(any one)

1. Implement ‘n’ queens problem with backtracking. Calculate the no. of solutions and no. of nodes generated in the state space tree

2. For the assignment problem of ‘n’ people to ‘n’ jobs with cost of assigning as C( i, j), find the optimal assignment of every job to a person with minimum cost.

22/06/2009

19 Implement following using branch and Bound

Traveling salesperson problem 22/06/2009

Head of Department Subject Coordinator

(4)

STUDENT ACTIVITY FLOW-CHART END START If Completed Consult Lab Teacher & If accepted YES

Demonstrate to lab teacher for different i/p Write the program and execute and test for different inputs

Design the applications

Get imparted knowledge from Lab Teacher

Make suggested modification NO Make suggested modification YES YES NO

(5)

Revised on: 02/07/2010 TITLE Using LEX PROBLEM STATEMENT /DEFINITION

Write a LEX program to count number of characters, words and lines in a given input text file. Create an output text file that consists of the contents of the input file as well as line numbers

OBJECTIVE • Understand the importance and usage of LEX automated tool S/W PACKAGES

AND

HARDWARE APPARATUS USED

Windows 2000, PC with the configuration as

Pentium IV 1.7 GHz. 128M.B RAM, 40 G.B HDD, 15’’Color Monitor, Keyboard, Mouse

Linux with a support of LEX utility

REFERENCES

1. A V Aho, R. Sethi, .J D Ullman, "Compilers: Principles, Techniques, and Tools", Pearson Education, ISBN 81 - 7758 - 590 2. J. R. Levine, T. Mason, D. Brown, "Lex & Yacc", O'Reilly, 2000,

ISBN 81-7366 -061-X.– 8

3. K. Louden, "Compiler Construction: Principles and Practice", Thomson Brookes/Cole (ISE), 2003, ISBN 981 - 243 - 694-4:

STEPS Refer to student activity flow chart, theory, algorithm, test input, test output INSTRUCTIONS FOR WRITING JOURNAL • Title • Problem Definition • Theory • Source Code • Output • Conclusion

(6)

Theory:

Lex is a tool for generating programs that perform pattern-matching on text. It is a tool for generating scanners i.e. Programs which recognize lexical patterns in text. The description of the scanner is in the form of pairs of regular expressions and C code calls rules. Lex generates as output a C source file called lex.yy.c

Format of the input file :

The general format of lex source shall be: Definitions

%% Rules %%

UserSubroutines

The definition section is the place to define macros and to import header files written in C. It is also possible to write any C code here, which will be copied verbatim into the generated source file.

The rules section is the most important section; it associates patterns with C

statements. Patterns are simply regular expressions. When the lexer sees some text in the input matching a given pattern, it executes the associated C code. This is the basis of how lex operates.

The C code section contains C statements and functions that are copied verbatim to the generated source file. These statements presumably contain code called by the rules in the rules section. In large programs it is more convenient to place this code in a separate file and link it in at compile time.

How the input is matched :

When the generated scanner is run, it analyzes its input looking for strings which match any of its patterns. If it finds more than one match, it takes the one matching the most text (for trailing context rules, this includes the length of the trailing part, even though it will then be returned to the input). If it finds two or more matches of the same length, the rule listed first in the flex input file is chosen.

Once the match is determined, the text corresponding to the match (called the token) is made available in the global character pointer yytext, and its length in the global integer yyleng. The action corresponding to the matched pattern is then executed (a more detailed description of actions follows), and then the remaining input is scanned for another match.

If no match is found, then the default rule is executed: the next character in the input is considered matched and copied to the standard output. Thus, the simplest legal flex  input is:

(7)

output.

Actions in lex :

The action to be taken when an ERE is matched can be a C program fragment or the special actions described below; the program fragment can contain one or more C statements, and can also include special actions.

Four special actions shall be available:

| The action ’|’ means that the action for the next rule is the action for this rule.

ECHO: Write the contents of the string yytext on the output.

REJECT:Usually only a single expression is matched by a given string in the input. REJECT means "continue to the next expression that matches the current input", and shall cause whatever rule was the second choice after the current rule to be executed for the same input. Thus, multiple rules can be matched and executed for one input string or overlapping input strings.

BEGIN The action: BEGIN newstate;

(8)

Algorithm

1. Write a lex input file and save it as <filename.l>

2. Generate a C file using the command 'lex <filename.l>'. This creates a .c file named lex.yy.c

3. Compile the .c file using the command 'gcc lex.yy.c -lfl'. This compiles the c file using the lfl library

4. Execute the file using the command './a.out <arguments to be passed> '

Test Input:

[root@localhost Lex&Yacc]# lex first.l [root@localhost Lex&Yacc]# cc lex.yy.c -ll [root@localhost Lex&Yacc]# ./a.out myinput.c

//myinput.c---/* hello world!!!! this is a program to test my first lex assignment */

#include<stdio.h> #include<conio.h> main()

{

// this is a single line comment int num,i;

printf("\nEnter the number: "); scanf("%d",&num);

if(num<10)

printf("\nNumber Less than 10!!!"); else

printf("\nNumber Greater than 10!!!"); return(0);

}

Test Output:

/* HELLO WORLD!!!! THIS IS A PROGRAM TO TEST MY FIRST LEX ASSIGNMENT

PICT */

(9)

#include<stdio.h> #include<conio.h> main()

{

// THIS IS A SINGLE LINE COMMENT int num,i;

printf("\nEnter the number: "); scanf("%d",&num);

if(num<10)

printf("\nNumber Less than 10!!!"); else

printf("\nNumber Greater than 10!!!"); return(0);

} */

(10)

Revised on:22/06/2009 TITLE

Lexical analyzer using LEX

PROBLEM STATEMENT /DEFINITION

Implement a lexical analyser for a subset of C using LEX Implementation should support error handling.

OBJECTIVE Appreciate the role of lexical analysis in compilationUnderstand the theory behind design of lexical analyzers and lexical analyzer generator

• Be able to use LEX to generate lexical analyzers S/W PACKAGES

AND

HARDWARE APPARATUS USED

Windows 2000, PC with the configuration as

Pentium IV 1.7 GHz. 128M.B RAM, 40 G.B HDD, 15’’Color Monitor, Keyboard, Mouse

Linux with LEX utility

REFERENCES 1. A V Aho, R. Sethi, .J D Ullman, "Compilers: Principles, Techniques, and Tools", Pearson Education, ISBN 81 - 7758 - 590

2. J. R. Levine, T. Mason, D. Brown, "Lex & Yacc", O'Reilly, 2000, ISBN 81-7366 -061-X.– 8

3. K. Louden, "Compiler Construction: Principles and Practice", Thomson Brookes/Cole (ISE), 2003, ISBN 981 - 243 - 694-4:

STEPS Refer to student activity flow chart, theory, algorithm, test input, test output INSTRUCTIONS FOR WRITING JOURNAL • Title • Problem Definition • Theory • Source Code • Output • Conclusion

(11)

Theory:

Regular Expressions in lex

"..." - Any string enclosed in double-quotes shall represent the characters within the double-quotes as themselves, except that backslash escapes.

<state>r, <state1,state2,...>r - The regular expression r shall be matched only when the program is in one of the start conditions indicated by state, state1, and so on.

r/x - The regular expression r shall be matched only if it is followed by an occurrence of regular

expression x

* - matches zero or more occurrences of the preceding expressions

[] - a character class which matches any character within the brackets. If the first character is a

circumflex '^' it changes the meaning to match any character except the ones within brackets.

^ - matches the beginning of a line as the first characters of a regular expression. Also used for negation

within square brackets.

{} - Indicates how many times the previous pattern is allowed to match, when containing one or two

numbers.

$ - matches the end of a line as the last character of a regular expressions

\ - used to escape metacharacters and a part of usual c escape sequences e.g '\n' is a newline character

while '\*' is a literal asterisk.

+ - matches one more occurrences of the preceding regular expression.

| - matches either the prceding regular expression or the following regular expression. () - groups a series of regular expressions together, into a new regular expression. Examples :

DIGIT [0-9]+

IDENTIFIER [a-zA-Z][a-zA-Z0-9]*

The functions or macros that are accessible to user code : int yylex(void)

Performs lexical analysis on the input; this is the primary function generated by the lex utility. The function shall return zero when the end of input is reached; otherwise, it shall

(12)

int yymore(void)

When called, indicates that when the next input string is recognized, it is to be appended to the current value of yytext rather than replacing it; the value in yyleng shall be adjusted accordingly.

int yyless(int n)

Retains n initial characters in yytext, NUL-terminated, and treats the remaining characters as if they had not been read;the value in yyleng shall be adjusted accordingly.

int yywrap(void)

Called by yylex() at end-of-file; the default yywrap() shall always return 1. If the application requires yylex() to continue processing with another source of input, then the application

can include a function yywrap(), which associates another file with the external variable FILE * yyin and shall return a value of zero.

int main(int argc, char *argv[])

Calls yylex() to perform lexical analysis, then exits. The user code can contain main() to perform application-specific operations, calling yylex() as applicable.

(13)

Algorithm :

1. Accept a C input filename as a command line argument.

2. Separate the tokens as identifiers, constants, keywords etc. and fill the generic symbol table.

3. Check for syntax errors of expressions and give error messages if needed. Test Input: #include<stdio.h> void main() { int a,b; char b; a=3;b=5;c=d; c=a+d; } Test Output: #include<stdio.h> void main() { int a,b,c;

char b; Error : Redefinition of symbol b; a=3;b=5;c=d;

c=a+d; Error : Undefined symbol d; }

(14)

Revised on: 22/06/2009

TITLE Natural language Parser

PROBLEM STATEMENT /DEFINITION

Implement a natural language parser using LEX & YACC

OBJECTIVE Be proficient on writing grammars to specify syntaxUnderstand the theories behind different parsing strategies-their strengths and limitations

• Understand how the generation of parser can be automated • Be able to use YACC to generate parsers

S/W PACKAGES AND

HARDWARE APPARATUS USED

Windows 2000, PC with the configuration as

Pentium IV 1.7 GHz. 128M.B RAM, 40 G.B HDD, 15’’Color Monitor, Keyboard, Mouse

Linux with LEX utility

REFERENCES 1. A V Aho, R. Sethi, .J D Ullman, "Compilers: Principles, Techniques, and Tools", Pearson Education, ISBN 81 - 7758 - 590 2. J. R. Levine, T. Mason, D. Brown, "Lex & Yacc", O'Reilly, 2000,

ISBN 81-7366 -061-X.– 8

3. K. Louden, "Compiler Construction: Principles and Practice", Thomson Brookes/Cole (ISE), 2003, ISBN 981 - 243 - 694-4:

STEPS Refer to student activity flow chart, theory, algorithm, test input, test output INSTRUCTIONS FOR WRITING JOURNAL • Title • Problem Definition • Theory • Source Code • Output • Conclusion

(15)

Theory:

Lex recognises regular expressions, whereas YACC recognises entire grammar. Lex divides the input stream into tokens, while YACC uses these tokens and groups them together logically.

The syntax of a YACC file : %{

declaration section %}

rules section %%

user defined functions

Declaration section :

Here, the definition section is same as that of lex, where we can define all tokens and include header files. The declarations section is used to define the symbols used to define the target language and their relationship with each other. In particular, much of the additional information required to resolve ambiguities in the context-free grammar for the target language is provided here.

Grammar Rules in yacc

The rules section defines the context-free grammar to be accepted by the function yacc generates, and associates with those rules C-language actions and additional precedence information. The grammar is described below, and a formal definition follows.

The rules section is comprised of one or more grammar rules. A grammar rule has the form:

A : BODY ;

The symbol A represents a non-terminal name, and BODY represents a sequence of zero or more names, literals, and semantic actions that can then be followed by optional precedence rules. Only the names and literals participate in the formation of the grammar; the semantic actions and precedence rules are used in other ways. The colon and the semicolon are yacc punctuation. If there are several successive grammar rules with the same left-hand side, the vertical bar ’|’ can be used to avoid rewriting the left-hand side; in this case the semicolon appears only after the last rule. The BODY part can be empty.

Programs Section

(16)

and any other functions; for example, those used in the actions specified in the grammar rules. It is unspecified whether the programs section precedes or follows the semantic actions in the output file; therefore, if the application contains any macro definitions and declarations intended to apply to the code in the semantic actions, it shall place them within "%{ ... %}" in the declarations section.

Interface to the Lexical Analyzer

The yylex() function is an integer-valued function that returns a token number representing the kind of token read. If there is a value associated with the token returned by yylex() (see the discussion of tag above), it shall be assigned to the external variable yylval.

Running lex and yacc :

• Generate y.tab.c and y.tab.h files using 'yacc -d <filename.y> • Generate a .c file using 'lex <filename.l>

(17)

Algorithm :

1. Accept a sentence from the user

2. Write lex code to separate out the tokens.

3. Write YACC code to check the validity of the sentence. 4. If valid print 'accepted' else 'rejected'

Test Input:

I am a boy.

Test Output:

Statement is correct

Test Input:

I boy am.

Test Output:

Statement is wrong

(18)

Revised on: 22/06/2009

TITLE Calculator program handling ambiguous grammar using LEX & YACC

PROBLEM STATEMENT /DEFINITION

Write an ambiguous CFG to recognise an infix expression and implement a parser that recognises the infix expression using YACC. Provide the details of all conflicting entries in the parser table

generated by LEX and YACC and how they have been resolved. (can take calculator as an application)

OBJECTIVE Be proficient on writing grammars to specify syntaxUnderstand the theories behind different parsing strategies-their strengths and limitations

• Understand how the generation of parser can be automated • Be able to use YACC to generate parsers

• Understanding conflicting entries in the parser table . • Resolution of conflicts by Parser.

S/W PACKAGES AND HARDWARE APPARATUS USED

Windows 2000, PC with the configuration as

Pentium IV 1.7 GHz. 128M.B RAM, 40 G.B HDD, 15’’Color Monitor, Keyboard, Mouse

Linux with LEX utility REFERENCES

1. A V Aho, R. Sethi, .J D Ullman, "Compilers: Principles, Techniques, and Tools", Pearson Education, ISBN 81 - 7758 - 590

2. J. R. Levine, T. Mason, D. Brown, "Lex & Yacc", O'Reilly, 2000, ISBN 81-7366 -061-X.– 8

3. K. Louden, "Compiler Construction: Principles and Practice", Thomson Brookes/Cole (ISE), 2003, ISBN 981 - 243 - 694-4:

STEPS Refer to student activity flow chart, theory, algorithm, test input, test output INSTRUCTIONS FOR WRITING JOURNAL • Title • Problem Definition • Theory • Source Code • Output • Conclusion

(19)

Theory:

Ambiguity :

A grammar is said to be an ambiguous grammar if there is some string that it can

generate in more than one way (i.e., the string has more than one parse tree or more than one leftmost derivation).

The context free grammar

A → A + A | A − A | a

is ambiguous since there are two leftmost derivations for the string a + a + a: A → A + A A → A + A

→ a + A → A + A + A

→ a + A + A → a + A + A → a + a + A → a + a + A → a + a + a → a + a + a

Conflicts may arise because of mistakes in input or logic, or because the grammar rules. This will result in a shift/reduce conflict. When there are shift/reduce or reduce/reduce conflicts, Yacc still produces a parser. It does this by selecting one of the valid steps wherever it has a choice. A rule describing which choice to make in a given situation is called a disambiguating rule.

Yacc invokes two disambiguating rules by default:

• In a shift/reduce conflict, the default is to do the shift.

• In a reduce/reduce conflict, the default is to reduce by the earlier grammar rule (in the input sequence).

There is one common situation where the rules given above for resolving conflicts are not sufficient; this is in the parsing of arithmetic expressions. Most of the commonly used constructions for arithmetic expressions can be naturally described by the notion of precedence levels for operators, together with information about left or right associativity.

The precedences and associativities are attached to tokens in the declarations section. This is done by a series of lines beginning with a Yacc keyword: %left, %right, or %nonassoc, followed by a list of tokens. All of the tokens on the same line are assumed to have the same precedence level and associativity; the lines are listed in order of increasing precedence or binding strength.

Thus,

%left '+' '-' %left '*' '/'

(20)

minus are left associative, and have lower precedence than star and slash, which are also left associative. The keyword %right is used to describe right associative operators, and the keyword %nonassoc is used to describe operators that may not associate with themselves.

Passing Values between Actions

To get values generated by other actions, an action can use the yacc parameter keywords that begin with a dollar sign ($1, $2, ... ). These keywords refer to the values returned by the components of the right side of a rule, reading from left to right. For example, if the rule is:

A : B C D ;

then $1 has the value returned by the rule that recognized B, $2 has the value returned by the rule that recognized C, and $3 the value returned by the rule that recognized D. To return a value, the action sets the pseudo-variable $$ to some value. For example, the following action returns a value of 1:

(21)

Algorithm :

1. Accept expression from user.

2. Write a yacc file to evaluate the expression. 3. Print the result.

Test Input:

none

Test Output:

>A=2 >B=3 >C=A+B >C =5

(22)

Revised on: 22/06/2009 TITLE Three address code generation using LEX & YACC

PROBLEM STATEMENT /DEFINITION

Write an attributed translation grammar to recognise declarations of simple variables, “for”, assignment, if, if-else statements as per syntax of C or Pascal and generate equivalent three address code for the given input made up of constructs mentioned above using LEX and YACC. Write a code to store the identifiers from the input in a symbol table and also to record other relevant information about the identifiers. Display all records stored in the symbol table.

OBJECTIVE Understand the intermediate code generation phaseUnderstand the need for various static semantic analyses such as declaration processing, type checking

• Be able to perform such analysis on a syntax directed fashion through the use of attributed definitions

S/W PACKAGES AND

HARDWARE APPARATUS USED

Windows 2000, PC with the configuration as

Pentium IV 1.7 GHz. 128M.B RAM, 40 G.B HDD, 15’’Color Monitor, Keyboard, Mouse

Linux with LEX utility Linux with YACC utility GCC

REFERENCES

1. A V Aho, R. Sethi, .J D Ullman, "Compilers: Principles, Techniques, and Tools", Pearson Education, ISBN 81 - 7758 - 590

2. J. R. Levine, T. Mason, D. Brown, "Lex & Yacc", O'Reilly, 2000, ISBN 81-7366 -061-X.– 8

3. K. Louden, "Compiler Construction: Principles and Practice", Thomson Brookes/Cole (ISE), 2003, ISBN 981 - 243 - 694-4 STEPS Refer to student activity flow chart, theory, algorithm, test input, test

output INSTRUCTIONS FOR WRITING JOURNAL • Title • Problem Definition • Theory • Source Code • Output • Conclusion

(23)

Theory:

Basically there are three types of 3 address codes: 1. Quadruplets

2. Triplets

3. Indirected Triplets

There are following types of 3 address statements

-Assignment statements of the form x:=y op z where op is binary arithmetic or logical operation.

Assignment instruction of the form x:=op y where op is a unary operation like unary minus

logical negation, shift operators & conversion operation.

Copy statements of the form x:=y where value of y is assigned to x.

the unconditional jump goto L. The 3 address statement with label L is the next statement to be executed.

Conditional jumps such as if x rel op y goto L. This instruction applies a relational operator as <=,>= etc to x & y. If condition is false next statements are executed. Program x and call is for procedure calls and return y where y represents a return value that is optional. Teir typical use is as the sequence of 3 address statements

param xn

param xn+1

generated as part of call to procedure.

Address and pointer assignment of the form x:=&y, x=*y, *x=y.

Quadruple--A quadruple is a record structure with 4 fields which we will call as op,arg1,arg2 and result

Op field contains an integral code & operator

The 3 address statements x:=y op z is represented by placing y in arg1 and z in arg2 and x in result.

Statements with unary operators like x:=-y or x:=y do not use arg2. The quadruplet for the arrangement

(24)

Op Arg1 Arg2 Result Unary minus C  t1 * B T1 T2 Unary minus C T3 * B T3 T4 + T2 T4 T5 := T5 A

(25)

Algorithm:

1. Write a lex file to detect various tokens like if, for, brackets, identifiers etc. 2. Write the yacc file for checking syntatically correct sattements.

3. Generate lex.yy.c & y.tab.c files and link them. 4. Print 3 address code & symbols in the symbol table. 5. Stop.

Test Input:

int main(int a,char b) { int a=6,b=3,c,d,e; c=5; if (a<c) { a=b+c*d-e; }

while (a<b && c!=3) {

b=c+3; }

}

Test Output:

Program Syntactically Correct Quadruples Produced :

Address Operator Operand1 Operand2 Result 0 = a 6 1 = b 3 2 = 5 c 3 < a c t0 4 IF t0 1 (6) 5 (n0) 6 * c d t1 7 + b t1 t 2 8 - t2 e t3 9 = t3 a 10 (n0) 11 < a b t4 12 != c 3 t5 13 && t4 t5 t6 14 WHILE t6 1 (16) 15 (n1)

(26)

16 + c 3 t7 17 = t7 b 18

(prev)

(27)

Revised on: 22/06/2009 TITLE COMMANDS IN UNIX/LINUX OPERATING SYSTEMS PROBLEM DEFINITION Study of Commands in UNIX/LINUX Operating Systems OBJECTIVE

Customizing the operating systems environment • To get familiar with operating environment

REFERENCES INTERACTIVE UNIX Operating System Primer – Version 3.0.

• man commands

• Online LINUX Documentation Project

STEPS Refer to theory

INSTRUCTIONS FOR WRITING JOURNAL Title • Problem Definition • Theory • Algorithm • Source code • compilation steps • Output • Conclusion

(28)

Theory: NAME

grep, egrep, fgrep, rgrep - print lines matching a pattern

SYNOPSIS

grep [options] PATTERN [FILE...]

grep [options] [-e PATTERN | -f FILE] [FILE...]

DESCRIPTION

grep searches the named input FILEs (or standard input if no files are named, or the file name - is given) for lines containing a match to thegiven PATTERN. By default,grep prints the matching lines.

In addition, three variant programs egrep, fgrep and rgrep are available. egrep is the same as grep -E. fgrep is the same as grep -F.rgrep is the same as grep -r.

OPTIONS

-A NUM, --after-context=NUM

Print NUM lines of trailing context after matching lines.Places a line containing -- between contiguous groups of matches.

-a, --text

Process a binary file as if it were text; this is equivalent to the --binary-files=text option.

-B NUM, --before-context=NUM

Print NUM lines of leading context before matching lines.Places a line containing -- between contiguous groups of matches.

-b, --byte-offset

Print the byte offset within the input file before each line of output.

EXAMPLE ls –l | grep

(29)

NAME

locate - list files in databases that match a pattern SYNOPSIS

locate [-d path | --database=path] [-e | -E | --[non-]existing] [-i | --ignore-case] [-0 | --null] [-c | --count] [-w | --wholename] |-b | --basename] [-l N | --limit=N] [-S | --statistics] [-r | --regex ] [-P

| -H | --nofollow] [-L | --follow] [--version] [-A | --all] [-p | --print] [--help] pattern...

DESCRIPTION

This manual page documents the GNU version of locate. For each given pattern, locate searches one or more databases of file names and displays the file names that contain the pattern. Patterns can containshell-style metacharacters: `*', `?', and `[]'. The metacharacters do not treat `/'or `.' specially. Therefore, a pattern `foo*bar' can match a file name that contains `foo3/bar', and a pattern `*duck*' can match a file name that contains `lake/.ducky'. Patterns that contain metacharacters should be quoted to protect them from expansion by the shell.

If a pattern is a plain string -- it contains no metacharacters --locate displays all file names in the database that contain that strin anywhere. If a pattern does contain metacharacters, locate only dis-plays file names that match the pattern exactly. As a result, patterns that contain metacharacters should usually begin with a `*', and will most often end with one as well. The exceptions are patterns that are intended to explicitly match the beginning or end of a file name.

The file name databases contain lists of files that were on the system when the databases were last updated. The system administrator can choose the file name of the default database, the frequency with which the databases are updated, and the directories for which they contain entries; see updatedb(1).

If locate's output is going to a terminal, unusual characters in the output are escaped in the same way as for the -print action of the find command. If the output is not going to a terminal, file names are printed exactly as-is.

OPTIONS -A, --all

(30)

matching one or more non-option arguments. -c, --count

Instead of printing the matched filenames, just print the total number of matches we found, unless --print (-p) is also present. -d path, --database=path

Instead of searching the default file name database, search the file name databases in path, which is a colon-separated list of

database file names. You can also use the environment variable LOCATE_PATH to set the list of database files to search. The option overrides the environment variable if both are used. Empty elements in the path are taken to be synonyms for the file name of the default database. A database can be supplied on stdin, using `-' as an element of path. If more than one element of path is `-', later instances are ignored (and a warning sage is printed).

The file name database format changed starting with GNU find and locate version 4.0 to allow machines with different byte ings to share the databases. This version of locate can matically recognize and read databases produced for older sions of GNU locate or Unix versions of locate or find. Support for the old locate database format will be discontinued in a future release.

-e, --existing

Only print out such names that currently exist (instead of such names that existed when the database was created). Note that this may slow down the program a lot, if there are many matches in the database. If you are using this option within a program, please note that it is possible for the file to be deleted after

locate has checked that it exists, but before you use it. -E, --non-existing

Only print out such names that currently do not exist (instead of such names that existed when the database was created). Note that this may slow down the program a lot, if there are many matches in the database.

-L, --follow

If testing for the existence of files (with the -e or -E options), consider broken symbolic links to be non-existing. This is the default.

(31)

-P, -H, --nofollow

If testing for the existence of files (with the -e or -E options), treat broken symbolic links as if they were existing files. The -H form of this option is provided purely for larity with find; the use of -P is recommended over -H. -i, --ignore-case

Ignore case distinctions in both the pattern and the file names. -l N, --limit=N

Limit the number of matches to N. If a limit is set via this option, the number of results printed for the -c option will never be larger than this number.

-m, --mmap

Accepted but does nothing, for compatibility with BSD locate. -0, --null

Use ASCII NUL as a separator, instead of newline. -p, --print

Print search results when they normally would not, because of the presence of --statistics (-S) or --count (-c).

-w, --wholename

Match against the whole name of the file as listed in the database. This is the default.

-b, --basename

Results are considered to match if the pattern specified matches the final component of the name of a file as listed in the database. This final component is usually referred to as the `base name'.

-r, --regex

The pattern specified on the command line is understood to be a regular expression, as opposed to a glob pattern. The Regular expressions work in the same was as in emacs and find, except for the fact that "." will match a newline. Filenames whose full paths match the specified regular expression are printed (or, in the case of the -c option, counted). If you wish to anchor your regular expression at the ends of the full path name, then as is usual with regular expressions, you should use the characters ^ and $ to signify this.

(32)

-s, --stdio

Accepted but does nothing, for compatibility with BSD locate. -S, --statistics

Print various statistics about each locate database and then exit without performing a search, unless non-option arguments are given. For compatibility with BSD, -S is accepted as a onym for --statistics. However, the ouptut of locate -S is ferent for the GNU and BSD implementations of locate. --help Print a summary of the options to locate and exit.

--version

Print the version number of locate and exit

NAME

chmod -- change file modes or Access Control Lists

SYNOPSIS

chmod [-fv] [-R [-H | -L | -P]] mode file ...

chmod [-fv] [-R [-H | -L | -P]] [-a | +a | =a] ACE file ... chmod [-fv] [-R [-H | -L | -P]] [-E] file ...

chmod [-fv] [-R [-H | -L | -P]] [-C] file ...

DESCRIPTION

The chmod utility modifies the file mode bits of the listed files as

specified by the mode operand. It may also be used to modify the Access Control Lists (ACLs) associated with the listed files.

The generic options are as follows:

-H If the -R option is specified, symbolic links on the command line are followed. (Symbolic links encountered in the tree traversal are not followed by default.)

-L If the -R option is specified, all symbolic links are followed. -P If the -R option is specified, no symbolic links are followed. This is the default.

-R Change the modes of the file hierarchies rooted in the files instead of just the files themselves.

(33)

-f Do not display a diagnostic message if chmod could not modify the mode for file.

-v Cause chmod to be verbose, showing filenames as the mode is fied. If the -v flag is specified more than once, the old and

new modes of the file will also be printed, in both octal and symbolic notation.

The -H, -L and -P options are ignored unless the -R option is specified. In addition, these options override each other and the command's actions are determined by the last one specified.

Only the owner of a file or the super-user is permitted to change the mode of a file.

EXAMPLES OF VALID MODES

644 make a file readable by anyone and writable by the owner only.

go-w deny write permission to group and others.

=rw, +X set the read and write permissions to the usual defaults, but retain any execute permissions that are currently set. +X make a directory or file searchable/executable by everyone if it is already searchable/executable by anyone.

755

u=rwx,go=rx

u=rwx,go=u-w make a file readable/executable by everyone and writable by the owner only.

go= clear all mode bits for group and others.

g=u-w set the group bits equal to the user bits, but clear the group write bit.

NAME

(34)

SYNOPSIS

ls [OPTION]... [FILE]... DESCRIPTION

List information about the FILEs (the current directory by default). Sort entries alphabetically if none of -cftuSUX nor --sort.

Mandatory arguments to long options are mandatory for short options too.

-a, --all

do not ignore entries starting with . -A, --almost-all

do not list implied . and .. --author

with -l, print the author of each file -b, --escape

print octal escapes for nongraphic characters --block-size=SIZE

use SIZE-byte blocks -B, --ignore-backups

do not list implied entries ending with ~

-c with -lt: sort by, and show, ctime (time of last modification of

file status information) with -l: show ctime and sort by name otherwise: sort by ctime

-C list entries by columns --color[=WHEN]

control whether color is used to distinguish file types. WHEN may be `never', `always', or `auto'

-d, --directory

list directory entries instead of contents, and do not derefer- ence symbolic links

NAME

(35)

LIBRARY

Standard C Library (libc, -lc)

SYNOPSIS

#include <sys/types.h> #include <sys/uio.h> #include <unistd.h> ssize_t

read(int d, void *buf, size_t nbytes); ssize_t

readv(int d, const struct iovec *iov, int iovcnt); ssize_t

pread(int d, void *buf, size_t nbytes, off_t offset);

DESCRIPTION

Read() attempts to read nbytes of data from the object referenced by the descriptor d into the buffer pointed to by buf. Readv() performs the same action, but scatters the input data into the iovcnt buffers fied by the members of the iov array: iov[0], iov[1], ..., iov[iovcnt-1]. Pread() performs the same function, but reads from the specified position in the file without modifying the file pointer.

For readv(), the iovec structure is defined as: struct iovec {

char *iov_base; /* Base address. */ size_t iov_len; /* Length. */ };

Each iovec entry specifies the base address and length of an area in ory where data should be placed. Readv() will always fill an area pletely before proceeding to the next.

On objects capable of seeking, the read() starts at a position given by the pointer associated with d (see lseek(2)). Upon return from read(),

the pointer is incremented by the number of bytes actually read. Objects that are not capable of seeking always read from the current

(36)

position. The value of the pointer associated with such an object is undefined.

Upon successful completion, read(), readv(), and pread() return the ber of bytes actually read and placed in the buffer. The system tees to read the number of bytes requested if the descriptor references a normal file that has that many bytes left before the end-of-file, but in no other case.

RETURN VALUES

If successful, the number of bytes actually read is returned. Upon reading end-of-file, zero is returned. Otherwise, a -1 is returned and the global variable errno is set to indicate the error.

Name

write - write to a file descriptor Synopsis

#include <unistd.h>

ssize_t write(int fd, const void *buf, size_t count); Description

write() writes up to count bytes to the file referenced by the file descriptor fd from the buffer starting at buf. POSIX requires that a read() which can be proved to occur after a write() has returned returns the new data. Note that not all file systems are POSIX conforming.

Return Value

On success, the number of bytes written are returned (zero indicates nothing was written). On error, -1 is returned, and errno is set appropriately. If count is zero and the file descriptor refers to a regular file, 0 may be returned, or an error could be detected. For a special file, the results are not portable.

Errors EAGAIN

Non-blocking I/O has been selected using O_NONBLOCK and the write would block.

EBADF

fd is not a valid file descriptor or is not open for writing. EFAULT

(37)

buf is outside your accessible address space. EFBIG

An attempt was made to write a file that exceeds the implementation-defined maximum file size or the process' file size limit, or to write at a position past the maximum allowed offset.

EINTR

The call was interrupted by a signal before any data was written. EINVAL

fd is attached to an object which is unsuitable for writing; or the file was opened with the O_DIRECT flag, and either the address specified in buf, the value specified in count, or the current file offset is not suitably aligned.

EIO

A low-level I/O error occurred while modifying the inode. ENOSPC

The device containing the file referred to by fd has no room for the data. EPIPE

fd is connected to a pipe or socket whose reading end is closed. When this happens the writing process will also receive a SIGPIPE signal. (Thus, the write return value is seen only if the program catches, blocks or ignores this signal.) NAME

fork, fork1 - create a new process SYNOPSIS #include <sys/types.h> #include <unistd.h> pid_t fork(void); pid_t fork1(void); DESCRIPTION

The fork() and fork1() functions create a new process. The new process (child process) is an exact copy of the calling process (parent process). The child process inherits the following attributes from the parent process:

o real user ID, real group ID, effective user ID, effective group ID o environment

o open file descriptors

o close-on-exec flags (see exec(2))

o signal handling settings (that is, SIG_DFL, SIG_IGN, SIG_HOLD, function address)

(38)

o set-user-ID mode bit o set-group-ID mode bit o profiling on/off status o nice value (see nice(2))

o scheduler class (see priocntl(2))

o all attached shared memory segments (see shmop(2))

o process group ID -- memory mappings (see mmap(2))

o session ID (see exit(2)) o current working directory o root directory

o file mode creation mask (see umask(2))

SunOS 5.9 Last change: 23 Jul 2001 1 System Calls fork(2)

o resource limits (see getrlimit(2))

o controlling terminal

o saved user ID and group ID o task ID and project ID

o processor bindings (see processor_bind(2))

o processor set bindings (see pset_bind(2))

Scheduling priority and any per-process scheduling parameters that are specific to a given scheduling class may or may not be inherited according to the policy of that particular class (see priocntl(2)). The child process differs from the parent process in the following ways:

o The child process has a unique process ID which does not match any active process group ID.

o The child process has a different parent process ID (that is, the process ID of the parent process).

o The child process has its own copy of the parent's file descriptors and directory streams. Each of the child's file descriptors shares a common file pointer with the corresponding file descriptor of the parent.

o Each shared memory segment remains attached and the value of shm_nattach is incremented by 1.

o All semadj values are cleared (see semop(2)).

o Process locks, text locks, data locks, and other memory locks are not inherited by the child (see plock(3C) and memcntl(2)).

(39)

o The child process's tms structure is cleared:

tms_utime, stime, cutime, and cstime are set to 0 (see times(2)).

o The child processes resource utilizations are set to 0; see getrlimit(2). The

it_value and it_interval values for the ITIMER_REAL timer are reset to 0; see getitimer(2).

o The set of signals pending for the child process is initialized to the empty set. o Timers created by timer_create(3RT) are not inherited by the child process.

NAME

pipe -- create descriptor pair for interprocess communication

SYNOPSIS

#include <unistd.h> int

pipe(int *fildes);

DESCRIPTION

The pipe() function creates a pipe, which is an object allowing tional data flow, and allocates a pair of file descriptors. The first

descriptor connects to the read end of the pipe, and the second connects to the write end, so that data written to fildes[1] appears on (i.e., can be read from) fildes[0]. This allows the output of one program to be sent to another program: the source's standard output is set up to be the write end of the pipe, and the sink's standard input is set up to be the read end of the pipe. The pipe itself persists until all its associated descriptors are closed.

A pipe whose read or write end has been closed is considered widowed. Writing on such a pipe causes the writing process to receive a SIGPIPE signal. Widowing a pipe is the only way to deliver end-of-file to a reader: after the reader consumes any buffered data, reading a widowed pipe returns a zero count.

RETURN VALUES

On successful creation of the pipe, zero is returned. Otherwise, a value of -1 is returned and the variable errno set to indicate the error.

(40)

ERRORS

The pipe() call will fail if:

[EMFILE] Too many descriptors are active. [ENFILE] The system file table is full.

[EFAULT] The fildes buffer is in an invalid area of the process's address space.

(41)

Revised On: 22/06/2009 TITLE Client - Server communication using Inter process Communication:

PROBLEM

STATEMENT /DEFINITION

Write a program for Client-Server communication using following IPC mechanism.

1. Unnamed pipe 2. Named pipe

OBJECTIVE To understand Inter process communication using pipe.

• To implement client server communication using Unnamed pipe,Named pipe . S/W PACKAGES AND HARDWARE APPARATUS USED Linux Fedora 4

PC with the configuration as

Pentium IV 1.7 GHz. 128M.B RAM, 40 G.B HDD, 15’’Color Monitor, Keyboard, Mouse

REFERENCES Advanced Unix Programming By Richard Stevans Vijay Mukhi's -The 'c' odyssey UNIX- Gandhi

STEPS Refer to student activity flow chart, theory, algorithm, test input, test output INSTRUCTIONS FOR WRITING JOURNAL Title • Problem Definition • Theory • Algorithm • Source code • compilation steps • Output • Conclusion

(42)

Theory:

A pipe is a form of redirection that is used in Linux and other Unix-like operating systems to send the output of one program to another program for further processing. Redirection is the transferring of standard output to some other destination, such as another program, a file or a printer, instead of the display monitor (which is its default destination). Standard output, sometimes abbreviated stdout, is the destination of the output from command line (i.e., all-text mode) programs in Unix-like operating systems. Pipes are used to create what can be visualized as a pipeline of commands, which is a temporary direct connection between two or more simple programs. This connection makes possible the performance of some highly specialized task that none of the constituent programs could perform by themselves. A command is merely an instruction provided by a user telling a computer to do something, such as launch a program. The command line programs that do the further processing are referred to as filters.

This direct connection between programs allows them to operate simultaneously and permits data to be transferred between them continuously rather than having to pass it through temporary text files or through the display screen and having to wait for one program to be completed before the next program begins.

History

Pipes rank alongside the hierarchical file system and regular expressions as one of the most powerful yet elegant features of Unix-like operating systems. The hierarchical file system is the organization of directories in a tree-like structure which has a single root directory (i.e., a directory that contains all other directories). Regular expressions are a pattern matching system that uses strings (i.e., sequences of characters) constructed according to pre-defined syntax rules to find desired patterns in text.

Pipes were first suggested by M. Doug McIlroy, when he was a department head in the Computing Science Research Center at Bell Labs, the research arm of AT&T (American Telephone and Telegraph Company), the former U.S. telecommunications monopoly. McIlroy had been working on macros since the latter part of the 1950s, and he was a ceaseless advocate of linking macros together as a more efficient alternative to series of discrete commands. A macro is a series of commands (or keyboard and mouse actions) that is performed automatically when a certain command is entered or key(s) pressed. McIlroy's persistence led Ken Thompson, who developed the original UNIX at Bell Labs in 1969, to rewrite portions of his operating system in 1973 to include pipes. This

implementation of pipes was not only extremely useful in itself, but it also made possible a central part of the Unix philosophy, the most basic concept of which is modularity (i.e.,

(43)

a whole that is created from independent, replaceable parts that work together efficiently).

Examples

A pipe is designated in commands by the vertical bar character, which is located on the same key as the backslash on U.S. keyboards. The general syntax for pipes is:

command_1 | command_2 [| command_3 . . . ]

This chain can continue for any number of commands or programs.

A very simple example of the benefits of piping is provided by the dmesg command, which repeats the startup messages that scroll through the console (i.e., the all-text, full-screen display) while Linux is booting (i.e., starting up). dmesg by itself produces far too many lines of output to fit into a single screen; thus, its output scrolls down the screen at high speed and only the final screenful of messages is easily readable. However, by piping the output of dmesg to the filter less, the startup messages can conveniently be viewed one screenful at a time, i.e.,

dmesg | less

less allows the output of dmesg to be moved forward one screenful at a time by pressing the SPACE bar and back one screenful at a time by pressing the b key. The command can be terminated by pressing the q key. (The more command could have been used here instead of less; however, less is newer than more and has additional functions, including the ability to return to previous pages of the output.)

The same result could be achieved by first redirecting the output of dmesg to a temporary file and then displaying the contents of that file on the monitor. For example, the following set of two commands uses the output redirection operator (designated by a rightward facing angle bracket) to first send the output of dmesg to a text file called tempfile1 (which will be created by the output redirection operator if it does not already exist), and then it uses another output redirection operator to transfer the output of tempfile1 to the display screen:

dmesg > tempfile1 tempfile1 > less

However, redirection to a file as an intermediate step is clearly less efficient, both because two separate commands are required and because the second command must await the completion of the first command before it can begin.

(44)

The use of two pipes to chain three commands together could make the above example even more convenient for some situations. For example, the output of dmesg could first be piped to the sort filter to arrange it into alphabetic order before piping it to less:

dmesg | sort -f | less

The -f option tells sort to disregard case (i.e., whether letters are lower case or upper case) while sorting.

Likewise, the output of the ls command (which is used to list the contents of a directory) is commonly piped to the the less (or more) command to make the output easier to read, i.e.,

ls -al | less or

ls -al | more

ls reports the contents of the current directory (i.e., the directory in which the user is currently working) in the absence of any arguments (i.e., input data in the form of the names of files or directories). The -l option tells ls to provide detailed information about each item, and the -a option tells ls to include all files, including hidden files (i.e., files that are normally not visible to users). Because ls returns its output in alphabetic order by default, it is not necessary to pipe its output to the sort command (unless it is desired to perform a different type of sorting, such as reverse sorting, in which case sort's -r option would be used).

This could just as easily be done for any other directory. For example, the following would list the contents of the /bin directory (which contains user commands) in a convenient paged format:

ls -al /bin | less

The following example employs a pipe to combine the ls and the wc (i.e., word count) commands in order to show how many filesystem objects (i.e., files, directories and links) are in the current directory:

ls | wc -l

ls lists each object, one per line, and this list is then piped to wc, which, when used with its -l option, counts the number of lines and writes the result to standard output (which, as usual, is by default the display screen).

(45)

The output from a pipeline of commands can be just as easily redirected to a file (where it is written to that file) or a printer (where it is printed on paper). In the case of the above example, the output could be redirected to a file named, for instance, count.txt:

ls | wc -l > count.txt

The output redirection operator will create count.txt if it does not exist or overwrite it if it already exists. (The file does not, of course, require the .txt extension, and it could have just as easily been named count, lines or anything else.)

The following is a slightly more complex example of combining a pipe with redirection to a file:

echo -e "orange \npeach \ncherry" | sort > fruit

The echo command tells the computer to send the text that follows it to standard output, and its -e option tells the computer to interpret each \n as the newline symbol (which is used to start a new line in the output). The pipe redirects the output from echo -e to the sort command, which arranges it alphabetically, after which it is redirected by the output redirection operator to the file fruit.

As a final example, and to further illustrate the great power and flexibility that pipes can provide, the following uses three pipes to search the contents of all of the files in current directory and display the total number of lines in them that contain the string Linux but not the string UNIX:

cat * | grep "Linux" | grep -v "UNIX" | wc -l

In the first of the four segments of this pipeline, the cat command, which is used to read and concatenate (i.e., string together) the contents of files, concatenates the contents of all of the files in the current directory. The asterisk is a wildcard that represents all items in a specified directory, and in this case it serves as an argument to cat to represent all objects in the current directory.

The first pipe sends the output of cat to the grep command, which is used to search text. The Linux argument tells grep to return only those lines that contain the string Linux. The second pipe sends these lines to another instance of grep, which, in turn, with its -v option, eliminates those lines that contain the string UNIX. Finally, the third pipe sends this output to wc -l, which counts the number of lines and writes the result to the display screen.

(46)

Algorithm:

1. Unnamed Pipe:

1. Create two pipe ends using pipe () command. 2. Create child process using fork () command.

3. Close read end for client ie.child and write data on the write end.

4. Close write end for server ie.parent and read data from the read end written by the client.

2. Named Pipe:

1. Create two FIFOs using mkfifo() command.

2. Open one for reading (FIFO1) and other for writing (FIFO2). 3. Send data from client.

4. Wait from data from client and print the same. 3. Semaphore:

Server:

1. Semaphore set is obtained with semget () function with some specific Semaphore key and set value to one.

2. While not reset by client continue else read data from the file written by client.

Client:

1. Semaphore set is obtained with semget () function with servers specific Semaphore key and set value to 1.

2. Write data to the file and reset the semaphore value and break. Test Input:

1. Named Pipe Client:

[root@localhost Programs]# gcc –o client namedclient.c [root@localhost Programs]#. /client hellopictsctr

Named Pipe Server:

[root@localhost Programs]# gcc –o server namedserver.c [root@localhost Programs]#. /server

2. Unnamed Pipe:

[root@localhost Programs]# gcc unnamed.c [root@localhost Programs]# ./a.out

3. Semaphore Client:

[root@localhost Programs]# gcc semclient.c [root@localhost Programs]# ./a.out

Semaphore Server

[root@localhost Programs]# gcc semserver.c [root@localhost Programs]# ./a.out

(47)

Test Output:

1. Named Pipe Server:

Half duplex Server: Read from Pipe: hellopictsctr

Half duplex Server: Converting string: HELLOPICTSCTR 2. Unnamed Pipe:

Parent process:

Enter the data to the pipe: hellopictsctr Child process:

Pipe read successfully: hellopictsctr 3. Semaphore Client:

Enter data: hellopictsctr Semaphore Server:

Waiting for clients to update… Updated : hellopisctsctr

(48)

Revised On: 22/06/2009

TITLE System Call PROBLEM

STATEMENT /DEFINITION

Using fork system call creates child process, suspend it using wait system call and transfer it into the Zombie state.

OBJECTIVE To understand concept of Zombie state and learn system calls fork and wait.

• To implement fork system call to create child process and transfer it into Zombie state.

S/W PACKAGES AND HARDWARE APPARATUS USED Linux Fedora 4

PC with the configuration as

Pentium IV 1.7 GHz. 128M.B RAM, 40 G.B HDD, 15’’Color Monitor, Keyboard, Mouse

REFERENCES Advanced Unix Programming By Richard Stevans Vijay Mukhi's -The 'c' odyssey UNIX- Gandhi

STEPS Refer to student activity flow chart, theory, algorithm, test input, test output INSTRUCTIONS FOR WRITING JOURNAL Title • Problem Definition • Theory • Algorithm • Source code • compilation steps • Output • Conclusion

(49)

Theory:

On Unix and Unix-like computer operating systems, a zombie process or defunct process is a process that has completed execution but still has an entry in the process table, this entry being still needed to allow the process that started the zombie process to read its exit status. The term zombie process derives from the common definition of

zombie—an undead person. In the term's colorful metaphor, the child process has died

but has not yet been reaped.

When a process ends, all of the memory and resources associated with it are deallocated so they can be used by other processes. However, the process's entry in the process table remains. The parent can read the child's exit status by executing the wait system call, at which stage the zombie is removed. The wait call may be executed in sequential code, but it is commonly executed in a handler for the SIGCHLD signal, which the parent is sent whenever a child has died.

After the zombie is removed, its process ID and entry in the process table can then be reused. However, if a parent fails to call wait, the zombie will be left in the process table. In some situations this may be desirable, for example if the parent creates another child process it ensures that it will not be allocated the same process ID. As a special case, under Linux, if the parent explicitly ignores the SIGCHLD (sets the handler to

SIG_IGN, rather than simply ignoring the signal by default), all child exit status information will be discarded and no zombie processes will be left.

A zombie process is not the same as an orphan process. An orphan process is a process that is still executing, but whose parent has died. They don't become zombie processes; instead, they are adopted by init (process ID 1), which waits on its children.

Zombies can be identified in the output from the Unix ps command by the presence of a "Z" in the STAT column. Zombies that exist for more than a short period of time typically indicate a bug in the parent program. As with other leaks, the presence of a few zombies isn't worrisome in itself, but may indicate a problem that would grow serious under heavier loads. Since there is no memory allocated to zombie processes except for the process table entry itself, the primary concern with many zombies is not running out of memory, but rather running out of process ID numbers.

To remove zombies from a system, the SIGCHLD signal can be sent to the parent manually, using the kill command. If the parent process still refuses to reap the zombie, the next step would be to remove the parent process. When a process loses its parent, init

becomes its new parent. Init periodically executes the wait system call to reap any zombies with init as parent.

(50)

Algorithm:

1. Include <sys/wait.h>,<sys/types.h> and <unistd.h> along with other header files. 2. Call the fork system call.

3. In the child process print the child process and parent process ID. 4. In the parent process print the parent process ID.

5. Execute the wait () system call in the parent.

6. While executing, programs use the ps command to see the Zombie child.

Test Input: None Test Output:

[root@localhost Programs]# gcc -o zombie zombie.c [root@localhost Programs]# ./zombie

Child process.

PID = 3952 Parent PID = 3951 Parent process.

PID = 3951 //On terminal 2

[root@localhost Programs]# ps -al

F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD 0 S 0 3951 3037 0 82 0 - 396 - pts/0 00:00:00 zombie

1 Z 0 3952 3951 0 82 0 - 0 exit pts/0 00:00:00 zomb <defunct> 4 R 0 3953 3099 0 77 0 - 1069 - pts/1 00:00:00 ps

References

Related documents

chemopreventive activity being shown primarily in in vitro studies with cancer cell lines.. For example, it inhibited the function of phosphorylated AKT, CyclinD1, CDK4,

formal tests can be part of the ongoing assessment process, but other methods of assessment should also be used to keep the class interesting and to provide a more

The importance of the microbiome of mammals was highlighted in the findings of the Human Microbiome Project ( 50 ), specifi- FIG 4 Proportions of various species or genera of

Our proposal, known as OO-H Method, provides a UML extension that, departing from a UML class diagram, defines a new set of views to capture the user interface requirements..

Extract the tooth, clean the socket and make an immediate bone and soft tissue graft with delayed implant placement.. Extract the tooth, clean the socket and make an immediate

Maurer: Should a signal for heterogeneity not be dependent on observed overall effect strength (i.e. a signal is considered present if between stage effect difference is larger

Así, la introducción de un enfoque participativo, horizontal y con perspectiva de género fue fundamental para promover la implicación de las mariscadoras en este proceso

Methods: A working group of multi-site research programmers evaluated the need for tools to support data security and data privacy. The group determined that data privacy support