KEMBAR78
Linux - Iv Unit | PDF | Integrated Development Environment | Software
0% found this document useful (0 votes)
28 views34 pages

Linux - Iv Unit

Uploaded by

luvyharish
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
28 views34 pages

Linux - Iv Unit

Uploaded by

luvyharish
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 34

SHELL PROGRAMMING (DN)

CLASS : II B.Sc IT SUBJECT CODE:


17UIT3A5

IV UNIT
DEVELOPMENT TOOLS
TOPIC 1: MAKE COMMAND AND MAKE FILES
What is a Make command?
-- Make is used to build executable programs and libraries from source
code.

What is a Make file?

-- A make file is a special file, containing shell commands.

-- A make file works well in one shell may not execute in another shell.
The make file contains a list of rules that tells us what command the user
need to execute.

Syntax of Make file with options:

$make

list of commands or files or directories


-- The above file should be named as makefile.

Eg.

some_file :-

echo “This line will print first”

echo “This is the end”

other_file :-

echo “This is another file”

echo “welcome”

$make some_file

output:

This line will print first

This is the end

Options:

-k – does not hang and tells the errors.

-n – does tell the result without dong it.

-f – tells which file to be makefile


Rules:

-- All rules must be on lines that starts with a tab.

Comments:

-- # this character is used as a comment line in makefile.

Macros:

-- Macros are a small piece of code that saves commands.

Syntax:

MACRONAME = value

Eg.

MYCMD =

echo “Now you can understand”

echo “OK”

FOO =

ls sample.txt

cat sample.txt prg1.txt

BOY = gcc

$BOY
Multiple targets:

Alternative command:

some_file : ; touch some_file

output:

This line will print first

This is the end

Eg.

some_file : ; touch other_file

output:

echo “This is another file”

echo “welcome”

Built-in rules:

eg. foo.c program

# include<stdio.h>

#include<conio.h>

int main()
{

printf(“Hello World \n ” );

$make foo

cc foo.c -o foo

-- $foo This command itself executes the above series of commands


one by one. No need to compile or run.

Managing Libraries:

-- Libraries are files with extension .a.

-- To store our user files into library, the syntax is :

lib(file.a)

Eg.

lib(foo.o)

-- Advanced make commands are GNU make and gcc.

TOPIC 2: SOURCE CODE CONTROL

-- In small projects, if more than one person is working in a project, it is


important to manage changes, so that to avoid conflicting changes.
-- There are several systems for managing source files. They are:

i) SCCS (Source Code Control System)

ii) RCS (Revision Control System)

iii) CVS (Concurrent Version System)

iv) Subversion.

i) SCCS:

-- SCCS was the original source code control system introduced by


AT&T in the System V versions of Unix.

ii) RCS:

-- It comprises a number of commands for managing source files.

-- It works by tracking a source file with a list of changes.

-- It also allows to store comments.

-- As a project progress, the user can log each change, bug fix and store
comments against each change.

The rcs command:

-- Eg. imp.c C file


/* This is an important file

It implements the canonical hello world program. */

-- The first step to initiate in RCS system is to use rcs command on a


file.

$ rcs –i imp.c

output:

RCS file : imp.c

enter description: terminated by .

The ci command:

-- This command is to check the current version of the file.

$ ci imp.c

output:

initial version : 1.1

The co command:

-- This check out co command is used to check a file and change its
permissions. -1 option is used to lock the file.
$ co -1 imp.c

output:

RCS file: imp.c

version: 1.1 (Locked)

The rlog command:

-- This command is used to list the summary of changes on a file.

$ rlog imp.c

output:

RCS file: imp.c

Working file : imp.c

head : 1.2

branch:

locks: true

access list : -------

The rcsdiff command:

-- This command is used to see the differences of changes before and


after.

$ rcsdiff imp.c
output:

RCS file: imp.c

version : 1.1

revision : 1.2

access 1: --

access 2: --

unlocked

locked

iii) CVS System:

-- The CVS system is similar to RCS except that it can used on the
internet.

-- CVS allows for parallel development, that is many programmers can


work on the same file at once.

-- RCS allows only one programmer to use at a time.

-- The same commands of RCS can work in CVS.

The CVS front ends:

-- Many graphical front ends are available for accessing CVS.


-- Best collection for multiple operating system is available at
www.incvs.org.

iv) Subversion:

-- It is intended to be a version control system.

The patch program:

-- It is used to identify the bugs in a software distribution.

TOPIC 3: RPM PACKAGES

-- The RPM Package Manager, or RPM is a the packaging format for


Red Hat Linux.

-- RPM has also been adopted as the official package file format by the
Linux Standards Base, or LSB, at www.linuxbase.org.

The main advantages of RPM include:

❑ It is widely used.

❑ It allows to install packages with a single command.

❑ A single file is to deal with. An RPM package is stored in a single


file, making it much easier to transport a package from one system to
another.

❑ RPM automatically handles dependency checks.


❑ RPM packages are designed to be built from pristine sources, allow
to reproduce a build.

Working with RPM Package Files

-- Each RPM package is stored in a file with an rpm extension. Package


files usually follow a naming convention with the following structure:

name-version-release.architecture.rpm

-- With this structure, the name holds a generic name for the package,
such as mysql for the MySQL database, or make for the make build tool.

-- The version holds the version number of the software, such as version
5.0.41 of MySQL.

-- The release holds a number that specifies which release of the RPM
of that version of the software is contained in the file.

-- The architecture holds a specifier for the program architecture, such


as i386 for an Intel-based system. For example. an executable created
for a SPARC processor will likely not run on an Intel processor.

Installing RPM Packages

To install an RPM package, run the rpm command. The format is


simple:

rpm -Uhv name-version-release.architecture.rpm


For example,

$ rpm -Uhv MySQL-server-5.0.41-0.glibc23.i386.rpm

-- This command installs (or upgrades if needed) the MySQL database


server package, for an Intel x86 architecture system.

Building RPM Packages

To build an RPM package, run the rpmbuild command. The process is


relatively straightforward. The steps are:

❑ Gather the software want to package.

❑ Create the spec file that describes how to build the package.

❑ Build the package with the rpmbuild command.

-- The easiest way to gather this software together is to bundle these


files into a tarball. Name the tarball with the application name and
version number, such as myapp-1.0.tar.gz.

-- You can modify your earlier makefile, Makefile6, to add a new target
to bundle the files into a tarball. The final version of the makefile,
simply called Makefile, follows:

-- Start the spec file with a set of definitions of the name, version
number, and other information about your package. For example,
Vendor: Wrox Press Distribution: Any Name: myapp
Version: 1.0 Release: 1 Packager: neil@provider.com
License: Copyright 2007 Wiley Publishing, Inc. Group:
Applications/Media

TOPIC 4: OTHER PACKAGE FORMATS

-- Although RPM is a popular way of distributing applications in a way


that allows users to control installing and uninstalling packages, there
are competing packages out there.

-- Some software is still distributed as gzipped tar files (tgz). Typically


the installation steps consist of unpacking the archive into a temporary
directory and running a script to perform the actual installation.

-- The Debian and Debian-based Linux distributions (and some others)


support another package format, similar in functionality to RPM, called
dpkg.

-- The dpkg utility on Debian unpacks and installs package files that
usually have a .deb extension.

-- If you need to distribute an application using .deb file pack- ages, it is


possible to convert an RPM package to dpkg format using a utility called
Alien. -- More details on Alien at http://kitenet.net/programs/alien/.
Development Environments

-- In the following sections, we explore one such IDE, KDevelop, and


mention a few of the other IDEs available for Linux today.

-- These environments are under active development, with the most


advanced of them beginning to rival the quality of commercial offerings.

KDevelop

-- KDevelop is an IDE for C and C++ programs. It includes particular


support for the creation of applications to run under the K Desktop
Environment (KDE), one of the two main graphical user interfaces on
Linux today. It can also be used for other project types, including simple
C programs.

-- KDevelop is free software released under the terms of the GNU


General Public License (GPL) and is avail- able with many Linux
distributions.

-- Download the latest version from http://www.kdevelop .org. Projects


created with KDevelop by default follow the standard for GNU projects.

-- KDevelop projects also contain templates for documentation, the


GPL license text, and generic installation instructions.
-- There is support with KDevelop for CVS and Subversion source code
control, and applications can be both edited and debugged without
leaving the environment.

Other Environments

-- Many other editors and IDEs, both free and commercial, are available
for Linux or under development. A few of the most interesting are listed
in the following table.

Environment Type Product URL

Eclipse Java-based tool platform and IDE http://www.eclipse.org

Anjuta An IDE for GNOME http://anjuta.sourceforge.net/

QtEZ An IDE for KDE http://projects.uid0.sk/qtez/

SlickEdit A commercial multi-language code editor

http://www.slickedit.com/

TOPIC 5: GENERAL DEBUGGING TECHNIQUES

-- The five stages of debugging are :

i) testing – find out what bugs are


ii) stabilization – making the bugs reproduceable

iii) localization – identifying the lines of bug codes

iv) correction – fixing the code

v) verification – making sure the fix works

a) A program with bugs:

#include<stdio.h>

void main()
{
int x = 10;
int y = 15;
printf("%d", (x, y))
}

Error: Missing semicolon error by mistake.

#include<stdio.h>
int main(void)
{
while(.)
{
printf("hello");
}
return 0; }

Error: A dot cannot be a value for a while loop.

for(i = 0; i < 3; i++);

Error: A loop cannot be terminated by a semicolon.

void Main()
{
int a = 10;
printf("%d", a);
}

Error: Typing mistake. M cannot be allowed in capital letters.

void main()

{
int a;
int b;
int c;
a + b = c;
}

Error: Semantic error. a+b cannot be assigned a value.


b) Code Inspection:
-- Code Inspection is a process of tracing out a few hundred lines of
code by a group of developers in a software development process.
c) Instrumentation:
-- Instrumentation is the adding of code to a program for the purpose of
collecting more information about the behavior of a program as it runs.
d) Controlled Execution:
Debugger: A computer program that assists in detection and correction
of errors in a program.
-- A number of debuggers are available for UNIX systems such as adb,
sdb, idebug, dbx.
-- The more sophisticated debuggers allows the programmers to know
about the state of the program in some detail at source code level.
TOPIC 6: DEBUGGING WITH GDB

-- The debugger gdb is used to find out the errors in a C program.

-- Eg.

$ cc sample sample.c

$ gdb sample
GNU gdb 6.6

Copyright GDB is a free software …….

List of commands in gdb:

breakpoints – making program to stop at some breakpoints

data – examining the data

files – examining the files

stack – examining the stack

userdefined – examining the user defined commands

help – for additional help online

Listing the program:

-- The gdb will list out all the errors of a program line by line.

Setting breakpoints:

-- To find out the exact place of the error in a program, it is necessary to


set some breakpoints in a program so that the debugger will trace each
blocks individually.

-- The GNU gdb is a powerful tool that can provide a lot of information
about the internal state of a program while executing.
-- Hardware breakpoints are also there to test the code . It is done by
the CPU. These processors are able to stop automatically if certain
conditions arise.

-- gdb can stop a program based on some conditions.

-- gdb is able to recover a crash program.

Other debugging tools:

Lint: It is one of the debugger that is used in a program to remove fluffs


in a program.

Function call tools:

There are 3 tools, ctags, cxref and cflow.

ctags: It creates an index of a function.

cxref: It analyzes the source code and produces cross references.

cflow: It associates all function related arguments.

The prog/gprof: It is a program that monitors a program and produces a


report.
TOPIC 7 : DEBUGGING TOOLS

-- Apart from gdb, Linux provides several tools to aid debugging


process.

-- Debugging tools are generally classified into two types:

a) static analysis

b) dynamic analysis

a) Static analysis:

-- Static analysis provides information from the source program source


code only.

-- Programs such as ctags, cxref, cflow works on source codings and


provides useful information.

b) Dynamic analysis:

-- Dynamic analysis provides information about how a program behaves


during execution or run time.

-- Programs such as prof, gprof are some examples.

-- Some of them are:

i) Lint

ii) Function call tools


iii) prof / gprof

i) Lint:

-- It removes the fluff from your programs.

-- It would detect cases where variables were used before being set and
where function arguments were not used.

-- In Linux, we call it as Splint and available in www.splint.org.

Eg. sample.c program

typedef struct

char *data;

int key;

} item;

item X[] = {

{“bill”, 3},

{“john”, 4},

{“lilly”, 5},

{“rosy”, 2}

};
void sort(a,n)

item *a

for (i=6; i≤10; i++)

printf(“%i”, a[i]);

To use Splint debugger:

$> splint sample.c

output:

sample.c : Line 18: unqualified variable dimension.

sample.c : Line 12: variable a used before declaration

ii) Funtion call tools:

-- Three programs ctags, cxref and cflow.

a) ctags: It creates an index for functions.


b) cxref: It produces the cross reference for source code.

c) cflow: It creates a tree that describes the flow of a program.

iii) prof / gprof:

-- The prof equivalent to gprof which produces a report from the


execution that is after run. It catches all runtime errors.

TOPIC 8 : PROCESS AND SIGNALS:

PROCESS STRUCTURE

-- If two users neil and rick access two processes trek.txt and
nextgen.doc at the same time.

neil trek.txt

PID = 101

Code

Data s=kirk

Library

Files
rick nextgen.doc

PID = 102

Code

Data s=troi

Library

Files

$ > ps

output:

UID PID PPID STIME TTIME CMD

rick 102 96 18:10:00 19:00:00


nextgen.doc

neil 101 93 18:10:00 18:30:00 trek.txt

Process table:

-- It is a data structure describing all of the processes that are currently


loaded with PID and its output status.

Viewing process: using ps command


UID PID PPID STIME TTIME CMD

john 105 22 13:12 14:10 a.txt

mary 109 34 11:12 13:09 b.txt

violet 111 12 23:12 00:34 c.txt

ria 154 79 17:12 18:22 d.txt

System processes: using ps with option

S – sleeping

R – running

T – stop

< - high priority task

N – low priority task

Process scheduling:

-- It can be done either by the user or automatically by the operating


system in Linux.

-- Priorities can be set by using nice or renice command.

Eg.
$ renice sample.c old priority 0 new priority 10

TOPIC 9: STARTING A NEW PROCESS

-- A new process can be started by running it from inside another


program.

Syntax:

#include<stdlib.h>

int system (const char *string)

Eg. sample.c

#include<stdlib.h>

#include<stdio.h>

int main()

printf(“Running the program ps with system \n”);

system(ps ax.txt);

printf(“Done ! “);

exit(0);

}
-- In the above program , the program ps is run by the system coding.
Ask the system to write coding to run the program ps.

-- When the program sample.c is executed, the ps command will also


be executed and results displayed.

$ ./sample.c

output:

Running the program ps with system

ax.txt

UID PID PPID STIME TTIME CMD

john 105 22 13:12 14:10 ax.txt

Done !

Duplicating a process:

-- To use processes to perform more than one function at a time, can be


either a thread.

-- A new process can be created by using fork command.

-- This fork command duplicates the current file , creating a new


process entry in the process table.

Eg.
#include<stdlib>

pid fork(void);

-- This fork creates a new duplicate process for the current process and
returns the pid of the child process.

Waiting for a process:

-- When a parent process needs to wait until the child process runs,
wait () can be used.

Eg.

#include<sys/types.h>

pid wait (int stat *local);

-- This will return the child process id when it gets terminated.

Zombie process:

-- When a parent process terminates or dies, it’s child process still be in


alive. This is also called zombie process.

Input and output redirection:

-- The outputs can be redirected to another file using coding logic.

Threads:
-- A thread is a small independent unit of a program. If a program
contains more than one threads, it is called multithreaded program.

TOPIC 10: SIGNALS

-- A signal is an event generated by the Linux operating system in


response to some condition upon receipt of which a process may in turn
take some action.

-- The ‘raise’ keyword is used to indicated the generation of a signal


and the keyword ‘catch’ to indicate the receipt of a signal.

-- Signals are raised by some error conditions such as memory segment


violations, floating point processor errors or illegal instructions.

-- They are generated by the shell or the terminals to cause interrupt.

-- These interrupts can also be sent from one process to another as a


way of passing information or modifying behavior.

-- Signals can be raise, caught, acted upon or just be ignored.

S. No Signal Name Description


1. SIGABORT Process Abort

2. SIGALRM Alarm Clock

3. SIGHUP Hangup

4. SIGILL Illegal Instruction

5. SIGINT Terminal Interrupt

6. SIGKILL Kill

7. SIGQUIT Terminal Quit

8. SIGTTIN Background process


trying to read

Program: sample.c

#include <signal.h>

#include <stdio.h>

#include <unistd.h>

void ouch(int sig)

printf(“OUCH ! I got a signal %d” , sig);


signal(SIGINT, del);

int main()

signal(SIGINT, ouch);

while(1)

printf(“Hello World \n”);

sleep(1);

OUTPUT:

$ ./ sample.c

Hello world

Hello world

Hello world

Hello world
^c

Ouch ! I got a signal 2

Hello world

Hello world

i) Sending Signals:

-- A process may send a signal to another process including itself by


calling kill.

-- The call will fail if a program does not have permission to send the
signal.

Eg.

#include<signal.h>

#include<sys/types.h>

int kill(pidt pid, int sig);

ii) Signal Sets:

-- The header file signal.h contains a set of signals and functions to


manipulate with signals.

* sigaddset()

* sigemptyset()
* sigfillset()

* sigdelset()

* sigismemberset()

* sigprocmaskset()

Masks:

SIG_BLOCK -- the signals in the set are added to the mask

SIG_UNBLOCK -- the signals in the set are removed from the mask.

You might also like