Update/issues regarding MDC project has to be posted on this thread only on daily basis.

Update the status/issues of Assignment 01 through this post only.

Update the status/issues pertaining  to MDC project on daily basis through this post only.

Update the status of Assignment 1 of Data structures with C on this post only.

Update the status of Shell Script assignment as well as any kind of issues has to be updated on this post only.

Update the status of shell script assignment and any issues regarding shell script has to be posted on this thread.

Update the status of Multiple Data Compression project and any kind of issues has to be posted through this thread only.

SIGWAITING        32                    Ignore        Cocurrancy signal used by threads library

SIGLWP             33                     Ignore        Inter LWP signal used by thread library

Where LWP: light weight process

For further information you can access man pages by giving the command

man 7 signal

Normally you should use the exit status to report very broad information about success or failure. You can’t provide a lot of detail about the reasons for the failure, and most parent processes would not want much detail anyway.

There are conventions for what sorts of status values certain programs should return. The most common convention is simply 0 for success and 1 for failure. Programs that perform comparison use a different convention: they use status 1 to indicate a mismatch, and status 2 to indicate an inability to compare. Your program should follow an existing convention if an existing convention makes sense for it.

A general convention reserves status values 128 and up for special purposes. In particular, the value 128 is used to indicate failure to execute another program in a subprocess. This convention is not universally obeyed, but it is a good idea to follow it in your programs.

Warning: Don’t try to use the number of errors as the exit status. This is actually not very useful; a parent process would generally not care how many errors occurred. Worse than that, it does not work, because the status value is truncated to eight bits. Thus, if the program tried to report 256 errors, the parent would receive a report of 0 errors—that is, success.

• fork() is used to create the image of a process using the one of an existing one, and
• exec is used to execute a program by overwriting that image with the program’s one.

This separation allows to perform some interesting housekeeping actions in between, as we’ll see in the following lectures.

A call to fork() of the form:

#include <unistd.h> 
      pid_t fork(void);

Return Value:

On success, the PID of the child process is returned in the parent, and 0 is returned in the child. On failure, -1 is returned in the parent, no child process is created, and errno is set appropriately.

Errors:

• EAGAIN fork() cannot allocate sufficient memory to copy the parent’s page tables and allocate a task structure for the child.
• EAGAIN It was not possible to create a new process because the caller’s RLIMIT_NPROC resource limit was encountered. To exceed this limit, the process must have either the CAP_SYS_ADMIN or the CAP_SYS_RESOURCE capability.
• ENOMEM fork() failed to allocate the necessary kernel structures because memory is tight.

It will creates (if it succeeds) a new process, which a child of the caller’s, and is an exact copy of the (parent) caller itself. By exact copy we mean that it’s image is a physical bitwise copy of the parent’s (in principle, they do not share the image in memory: though there can be exceptions to this rule, we can always thing of the two images as being stored in two separate and protected address spaces in memory, hence a manipulation of the parent’s variables won’t affect the child’s copies, and vice versa). The only visible differences are in the PCB, and the most relevant (for now) of them are the following:

The two processes obviously have two different process id.s. (pid). In a C program process id.s are conveniently represented by variables of pid_t type, the type being defined in the sys/types.h header.

• In LINUX the PCB of a process contains the id of the process’s parent, hence the child’s PCB will contain as parent id (ppid) the pid of the process that called fork(), while the caller will have as ppid the pid of the process that spawned it.
• The child process has its own copy of the parent’s file descriptors. These descriptors reference the same under-lying objects, so that files are shared between the child and the parent. This makes sense, since other processes might access those files as well, and having them already open in the child is a time-saver.

The fork() call returns in both the parent and the child, and both resume their execution from the statement immediately following the call. One usually wants that parent and child behave differently, and the way to distinguish between them in the program’s source code is to test the value returned by fork(). This value is 0 in the child, and the child’s pid in the parent. Since fork() returns -1 in case the child spawning fails, a catch-all C code fragment to separate behaviours may look like the following:

#include <sys/types.h>
#include <stdlib.h>
#include <errno.h>
#include <stdio.h>

int main()
{
 pid_t childpid;
 childpid=fork();
 switch(childpid)
 {
    case -1:
       fprintf(stderr,"ERROR: %s\n", sys_errlist[errno]);
       exit(1);
       break;
    case 0:
       /* Child's code goes here */
 printf(“ Child: My id is: %d and my parents id is: %d\n”,getpid(),getppid());
       break;
    default:
       printf(“ Parent: My id is: %d and my child id is: %d\n”,getpid(),childpid);
       break;
}

Note that a child (i.e. a process whatsoever, since they are all children of some other process, with the exception of processes 0, swapper and 1, init) cannot use the value returned by fork() to know its pid, since this is always 0 in the child. A system call named getpid() is provided for this purpose, and another one, named getppid() is used to ask the system about the parent’s id. Both functions take no arguments and return the requested value in pid_t type, or -1 in case of failure.

In the above program , a system call to exit() is made in case of failure, which causes the program to abort . We’ll see later that the exit() call returns the lower 8 bits of its argument (1, in the above example) to a waiting parent process, which can use them to determine the child’s exit status and behave accordingly. The usual convention is to exit with 0 on correct termination, and with a meaningful (for the parent) error code on abort.

It is often the case that a parent process must coordinate its actions with those of its children, maybe exchanging with them various kind of messages. UNIX defines several sophisticated inter-process communication (IPC) mechanisms, the simplest of which is a parent’s ability to test the termination status of its children. A synchronization mechanism is provided via the wait() system call, that allows a parent to sleep until one of its children exits, and then get its exit status. This call actually comes in three flavors,

• one simply called wait() and common to all version of UNIX (that i know of),
• one called waitpid(), which is a POSIX extension, and
• one called wait3(), and it’s a BSD extension.

General Syntax of wait() system call is:

#include<sys/types.h>
#include <sys/wait.h>

pid_t wait(int *status);

DESCRIPTION

The wait function suspends execution of the current process until a child has exited, or until a signal is delivered whose action is to terminate the current process or to call a signal handling function. If a child has already exited by the time of the call (a so-called “zombie” process), the function returns immediately. Any system resources used by the child are freed.

Return Value:

The process ID of the child which exited, or zero if WNOHANG was used and no child was available, or -1 on error (in which case errno is set to an appropriate value).

Errors:

• ECHILD : if the process specified in pid does not exist or is not a child of the calling process. (This can happen for one’s own child if the action for SIGCHLD is set to SIG_IGN. See also the LINUX NOTES section about threads.)
• EINVAL : if the options argument was invalid.
• EINTR : if WNOHANG was not set and an unblocked signal or a SIGCHLD was caught.

Here’s an example call to wait(): a program spawns two children, then waits for their completion and behaves differently according to which one is finished. Try to compile and execute it (no need to type: you can cut and paste from your web browser…).

#include <sys/types.h>
#include <sys/wait.h>
#include <stdio.h>

int main(int argc, char *argv[])
{
    pid_t whichone, first, second;
    int howmany;
    int status;

    if ((first=fork())==0) /* Parent spawns 1st child */
    {
        printf("Hi, I am the first child, and my id is %d\n",getpid());
        sleep(10); /* Sleep 10 sec, then exit */
        exit(0); 
    }
    else if (first == -1)
    {
        perror("1st fork: something went bananas\n");
        exit(1);
    }
    else if ((second=fork())==0) /* Parent spawns 2nd child */
    {
        printf("Hiya, I am the second child, and my id is %d\n",getpid());
        sleep(15); /* Sleep 15 sec, then exit */
        exit(0); 
    }
    else if (second == -1)
    {
        perror("2nd fork: something went bananas\n");
        exit(1);
    }

    printf("This is the parent\n");

    howmany=0; 
    while (howmany < 2) /* Wait twice */
    {
        whichone=wait(&status);
        howmany++;

        if (whichone==first)
           printf("First child exited ");
        else
           printf("Second child exited ");

        if ((status & 0xffff)==0)
           printf("correctly\n");
        else
           printf("uncorrectly\n");
    }
    return 0;
}

The parent enters into the loop; waiting for the children’s completion. The wait() system call blocks the caller process until one of its immediate children (not children’s children, or other siblings) terminates, and then returns the pid of the terminated process. The argument to wait() is the address on an integer variable or the NULL pointer. If it’s not NULL, the system writes 16 bits of status information about the terminated child in the low-order 16 bits of that variable. Among these 16 bits, the higher 8 bits contain the lower 8 bits of the argument the child passed to exit() while the lower 8 bits are all zero if the process exited correctly, and contain error information if not (see the wait(2) man page for details). Hence, if a child exits with 0 all those 16 bits are zero. To reveal if this is actually the case we test the bitwise AND expression (status & 0xffff), which evaluates as an integer whose lower 16 bits are those of status, and the others are zero. If it evaluates to zero, everything went fine, otherwise some trouble occurred. Try changing the argument passed to exit() in one of the children.

The Posix and BSD extensions to wait() are useful when a parent must not block waiting for children, but still wants to know about the children’s termination status values via the wait mechanism. We’ll treat only the Posix waitpid() call, and you are referred to the man page for the BSD call.

The waitpid() call is declared as follows in the sys/wait.h header:

pid_t waitpid(pid_t pid, int *statptr, int options);

Here the meaning of the the return value and of the pointer to the status statptr is exactly the same in wait(). However this call allows to specify which children should be waited for and how. Specifically, the first argument pid specifies the process(es) that must be waited for. The relevant (for now) cases are:

• pid == -1: all children are waited for;
• pid > 0: it specifies the pid of a single child that should be waited for (an error occurs if that process does not exist or is not one of the caller’s children);

The relevant (for now) value for the third argument is a constant called WNOHANG, that causes the function not to suspend the caller’s execution if status is not immediately available for one of the child processes. This allows to implement a loop in which the parent can do something useful and periodically poll the children’s status as well.

Sources

• http://www.cim.mcgill.ca/~franco/OpSys-304-427/lecture-notes/node16.html
• http://linux.about.com/od/commands/l/blcmdl2_wait.htm
• info pages of linux operating system

To create a new process, which initially is a near duplicate of its parent process . Often, the new process immediately executes a new program. The act of creating a new process is called forking, and this functionality is provided by the fork( ) system call. Two acts—first a fork, to create a new process, and then an exec, to load a new image into that process are thus required to execute a new program image in a new process.

The exec family of functions shall replace the current process image with a new process image. The new image shall be constructed from a regular, executable file called the new process image file. There shall be no return from a successful exec, because the calling process image is overlaid by the new process image.

 There is no single exec function; instead, there is a family of exec functions built on a single system call. List of exec() family system calls are:

• int execl(const char *path, const char *arg, …);
• int execlp(const char *file, const char *arg, …);
• int execle(const char *path, const char *arg,…, char * const envp[]);
• int execv(const char *path, char *const argv[]);
• int execvp(const char *file, char *const argv[]);
• int execvpe(const char *file, char *const argv[],char *const envp[]);

 When a C-language program is executed as a result of this call, it shall be entered as a C-language function call as follows:

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

where argc is the argument count and argv is an array of character pointers to the arguments themselves.

The argv array are each terminated by a null pointer. The null pointer terminating the argv array is not counted in argc. The arguments specified by a program with one of the exec functions shall be passed on to the new process image in the corresponding main() arguments. The argument path points to a pathname that identifies the new process image file.

The argument file is used to construct a pathname that identifies the new process image file. If the file argument contains a slash character, the file argument shall be used as the pathname for this file. Otherwise, the path prefix for this file is obtained by a search of the directories passed as the environment variable PATH

Signals set to the default action (SIG_DFL) in the calling process image shall be set to the default action in the new process image. Except for SIGCHLD, signals set to be ignored (SIG_IGN) by the calling process image shall be set to be ignored by the new process image. Signals set to be caught by the calling process image shall be set to the default action in the new process image

• After a successful call to any of the exec functions, any functions previously registered by atexit() are no longer registered.
• Any shared memory segments attached to the calling process image shall not be attached to the new process image
• Any named semaphores open in the calling process shall be closed as if by appropriate calls to sem_close().
• Any blocks of typed memory that were mapped in the calling process are unmapped,
• Memory locks established by the calling process via calls to mlockall() or mlock() shall be removed
• All open message queue descriptors in the calling process shall be closed, as described in mq_close().
• The new process image shall inherit the CPU-time clock of the calling process image.

The new process shall inherit at least the following attributes from the calling process image:

• Read and write descriptor created via pipes.
• Nice value
• Process ID
• Parent process ID
• Process group ID
• Session membership
• Real user ID
• Real group ID
• Supplementary group IDs
• Time left until an alarm clock signal (see alarm())
• Current working directory
• Root directory
• File mode creation mask
• File size limit
• Process signal mask
• Pending signal
• Resource limits
• Controlling terminal
• Interval timers

Upon successful completion, the exec functions shall mark for update the st_atime field of the file. If an exec function failed but was able to locate the process image file, whether the st_atime field is marked for update is unspecified.

Lets see a the some examples of  exec() family calls.

 Using execl()

The following example executes the ls command, specifying the pathname of the executable ( /bin/ls) and using arguments supplied directly to the command to produce single-column output.

#include <unistd.h>
int ret;
ret = execl ("/bin/ls", "ls", "-1", (char *)0);

Using execle()

The following example is similar to Using execl(). In addition, it specifies the environment for the new process image using the env argument.

#include <unistd.h>

int ret;
char *env[] = { "HOME=/usr/home", "LOGNAME=home", (char *)0 };
ret = execle ("/bin/ls", "ls", "-l", (char *)0, env);

Using execlp()

The following example searches for the location of the ls command among the directories specified by the PATH environment variable.

#include <unistd.h>
int ret;
ret = execlp ("ls", "ls", "-l", (char *)0);

Using execv()

The following example passes arguments to the ls command in the cmd array.

#include <unistd.h>

int ret;
char *cmd[] = { "ls", "-l", (char *)0 };
ret = execv ("/bin/ls", cmd);

Using execve()

The following example passes arguments to the ls command in the cmd array, and specifies the environment for the new process image using the env argument.

#include <unistd.h>

int ret;
char *cmd[] = { "ls", "-l", (char *)0 };
char *env[] = { "HOME=/usr/home", "LOGNAME=home", (char *)0 };
ret = execve ("/bin/ls", cmd, env);

Using execvp()

The following example searches for the location of the ls command among the directories specified by the PATH environment variable, and passes arguments to the ls command in the cmd array.

#include <unistd.h>
int ret;
char *cmd[] = { "ls", "-l", (char *)0 };
ret = execvp ("ls", cmd);

 Return Value:

If one of the exec functions returns to the calling process image, an error has occurred; the return value shall be -1, and errno shall be set to indicate the error.(Refer man pages)

In our next article we will cover some more system calls like exit(),kill() and using fork and exec() family functions.

Pipes and FIFOs are “Inter-process Communication Mechanisms” while semaphores, message queues and shared memory segments are “Inter-process Communication Resources”.

The best way to remember the difference between the two is: Inter-process Communication Mechanisms emphasize “how and why” data communication occurs between two User Mode processes, while on the other hand, Inter-process Communication Resources define the same objective, but in a more polished manner, by implementing the functionality through programming interfaces (and most of the times, using rather complex ones!).

To understand the concept of PIPES and FIFOS we have to look how a process is created in linux opearing system.

Linux is a very dynamic system with constantly changing computing needs. The representation of the computational needs of Linux centers around the common abstraction of the process. Processes can be short-lived (a command executed from the command line) or long-lived (a network service). For this reason, the general management of processes and their scheduling is very important.

From user-space, processes are represented by process identifiers (PIDs). From the user’s perspective, a PID is a numeric value that uniquely identifies the process. A PID doesn’t change during the life of a process, but PIDs can be reused after a process dies, so it’s not always ideal to cache them.

In user-space, you can create processes in any of several ways. You can execute a program (which results in the creation of a new process) or, within a program, you can invoke a fork or exec system call.

Process representation

Within the Linux kernel, a process is represented by a rather large structure called task_struct. This structure contains all of the necessary data to represent the process, along with a plethora of other data for accounting and to maintain relationships with other processes (parents and children).

A full description of the task_struct is beyond the scope of this article, but a portion of task_struct is shown here. This code contains the specific elements this article explores. Note that task_struct resides in ./linux/include/linux/sched.h.

A small portion of task_struct is re

struct task_struct {
volatile long state;
void *stack;
unsigned int flags;
int prio, static_prio;
struct list_head tasks;
struct mm_struct *mm, *active_mm;
pid_t pid;
pid_t tgid;
struct task_struct *real_parent;
char comm[TASK_COMM_LEN];
struct thread_struct thread;
struct files_struct *files;
…
};

Process Management

Now, let’s explore how you manage processes within Linux. In most cases, processes are dynamically created and represented by a dynamically allocated task_struct. One exception is the init process itself, which always exists and is represented by a statically allocated task_struct. You can see an example of this in ./linux/arch/i386/kernel/init_task.c.

Lets take an example of process, If you have two terminal windows showing on your screen, then you are probably running the same terminal program twice—you have two terminal processes. Each terminal window is probably running a shell; each running shell is another process. When you invoke a command from a shell, the corresponding program is executed in a new process; the shell process resumes when that process completes.

All processes in Linux are collected in two different ways. The first is a hash table, which is hashed by the PID value; the second is a circular doubly linked list. The circular list is ideal for iterating through the task list.

Process IDs are 16-bit numbers that are assigned sequentially by Linux as new processes are created.
Every process also has a parent process (except the special init process).Thus, you can think of the processes on a Linux system as arranged in a tree, with the init process at its root. The parent process ID, or ppid, is simply the process ID of the process’s parent.

When referring to process IDs in a C program, always use the pid_t typedef, which is defined in <sys/types.h>. A program can obtain the process ID of the process it’s running in with the getpid() system call, and it can obtain the process ID of its parent process with the getppid() system call.
Lets see an example of getpid() and getppid()

#include <stdio.h>
#include <unistd.h>
int main ()
{
printf (“The process ID is %d\n”, (int) getpid ());
printf (“The parent process ID is %d\n”, (int) getppid ());
return 0;
}

If you invoke this program several times, a different process ID is reported because each invocation is in a new process. However, if you invoke it every time from the same shell, the parent process ID (that is, the process ID of the shell process) is the same.

Viewing Active Processes

The ps command displays the processes that are running on your system. The GNU/Linux version of ps has lots of options because it tries to be compatible with  versions of ps on several other UNIX variants. These options control which processes are listed and what information about each is shown.

root@localhost~]#% ps
PID        TTY     TIME         CMD
21693   pts/8   00:00:00   bash
21694   pts/8   00:00:00    ps

Killing a Process

You can kill a running process with the kill command. Simply specify on the command line the process ID of the process to be killed.
Creating Processes
Two common techniques are used for creating a new process.

• The first is relatively simple but should be used sparingly because it is inefficient and has considerably security risks using system().
• The second technique is more complex but provides greater flexibility, speed, and security using fork() and exec().

Using system() call

The system function in the standard C library provides an easy way to execute a command from within a program, much as if the command had been typed into a shell.
In fact, system creates a subprocess running the standard Bourne shell (/bin/sh) and hands the command to that shell for execution.

For example, in our program we invoke the ls command to display the contents of the root directory, as if you typed ls -l / into a shell.

#include <stdlib.h>
int main ()
{
int return_value;
return_value = system (“ls -l /”);
return return_value;
}

As the system function uses a shell to invoke your command, it’s subject to the features,  imitations, and security flaws of the system’s shell. You can’t rely on the availability of any particular version of the Bourne shell.

Using fork and exec

Linux provides one function, fork, that makes a child process that is an exact copy of its arent process. Linux provides another set of functions, the exec family, that causes a particular process to cease being an instance of one program and to instead become an instance of another program.

To spawn a new process, you first use fork to make a copy of the current process.Then you use exec to transform one of these processes into an instance of the program you want to spawn.

Calling fork()
General Syntax for fork() call is:

#include <unistd.h>

pid_t fork(void);

fork() creates a new process by duplicating the calling process. The new process, referred to as the child, is an exact duplicate of the calling process, referred to as the parent, except for the following points:

• The child has its own unique process ID, and this PID does not match the ID of any existing process group.
• The child’s parent process ID is the same as the parent’s process ID.
• The child does not inherit its parent’s memory locks.
• Process resource utilizations and CPU time counters are reset to zero in
  the child.
• The child’s set of pending signals is initially empty.
• The child does not inherit semaphore adjustments from its parent.
• The child does not inherit timers from its parent

The child process is created with a single thread — the one that called fork(). The entire virtual address space of the parent is replicated in the child, including the states of mutexes, condition variables, and other pthreads objects.

The child inherits copies of the parent’s set of open file descriptors. Each file descriptor in
the child refers to the same open file description (see open(2)) as the corresponding file
descriptor in the parent. This means that the two descriptors share open file status flags, current file offset, and signal-driven I/O attributes (see the description of F_SETOWN and F_SETSIG in fcntl(2)).

The child inherits copies of the parent’s set of open message queue descriptors (see
mq_overview(7)). Each descriptor in the child refers to the same open message queue description as the corresponding descriptor in the parent. This means that the two descriptors share the same flags (mq_flags).

So how do the two processes differ? First, the child process is a new process and therefore has a new process ID, distinct from its parent’s process ID. One way for a program to distinguish whether it’s in the parent process or the child process is to call getpid. However, the fork function provides different return values to the parent and child processes—one process “goes in” to the fork call, and two processes “come out,” with different return values.The return value in the parent process is the process ID of the child.The return value in the child process is zero. Because no process ever has a process ID of zero, this makes it easy for the program whether it is now running as the parent or the child process.
#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
int main ()
{
pid_t child_pid;
printf (“the main program process ID is %d\n”, (int) getpid ());
child_pid = fork ();
if (child_pid != 0)
{
printf (“this is the parent process, with id %d\n”, (int) getpid ());
printf (“the child’s process ID is %d\n”, (int) child_pid);
}
else
printf (“this is the child process, with id %d\n”, (int) getpid ());
return 0;
}

In our next article we will cover exec families and also combining both exec and fork.

Sources:

• linux man pages
• Advance Linux Programming by Mark Mitchell, Jeffrey Oldham,
  and Alex Samuel

Let’s understand the actual meaning of: IPC. IPC is an abbreviation that stands for “Inter-process Communication”. It denotes a set of system calls that allows a User Mode process to:

• Synchronize itself with other processes by means of ‘Semaphores’.
• Send messages to other processes or receive messages from them.
• Share a memory area with other processes.

IPC was introduced in a development UNIX variant called “Columbus Unix” and IPC was introduced in a development UNIX variant called “Columbus Unix” and later adopted by AT&T’s System III. It is now commonly found in most UNIX systems, including GNU/Linux.

Need of Inter process communication:

There are several reasons for providing an environment that allows process cooperation:

• Information sharing
• Speedup
• Modularity
• Convenience

System V IPC is more heavyweight than BSD mmap, and provides three methods of communication:

• message queues,
• semaphores, and
• shared segments.

Like BSD mmap, System V IPC uses files to identify shared segments. Unlike BSD, System V uses these files only for naming. Their contents have nothing to do with the initialization of the shared segment. IPC data structures are created dynamically when a process requests an IPC Resource, i.e. a semaphore, a message queue, or a shared memory segment.

What is Inter Process Communication means?

The mechanism in which User Mode processes synchronize themselves and exchange data is referred to as “Inter-process Communication (IPC)” in UNIX Systems (that includes Linux too).

But in what way exactly do terms like: Semaphores, Shared Memory and Message Queues relate to IPC?
Semaphores, Shared Memory and Message Queues do relate to IPC in a very special way, since Semaphores, Shared Memory and Message Queues are “Inter-process Communication Resources” or “Inter-process Communication Facilities”, and different in the way they represent IPC from “Inter-process Communication Mechanisms” like Pipes and FIFOs. Semaphores, Shared Memory and Message Queues are System V (AT&T System V.2 release of UNIX) IPC facilities, and they represent wrapper functions that have been developed and inserted in suitable libraries to harness the energy and beauty of IPC mechanisms.

Data sharing among processes can be obtained by storing data in temporary files protected by locks. But this mechanism is never implemented as it proves costly since it requires accesses to the disk filesystem. For that reason, all UNIX Kernels include a set of system calls that supports process communications without interacting with the filesystem.

Application programmers have a variety of needs that call for different communication mechanisms. Some of the basic mechanisms that UNIX systems, GNU/Linux is particular has to offer are:

• Pipes and FIFOs: Mainly used for implementing producer/consumer interactions among processes. Some processes will fill the pipe with data while others will extract from it.
• Semaphores: Here we refer to (NOT the POSIX Realtime Extension Semaphores applied to Linux Kernel Threads), but System V semaphores which apply to User Mode processes. Used for locking critical sections of code.
• Message Queues: To set up a message queue between processes is a way to exchange short blocks (called messages) between two processes in an asynchronous way.
• Shared Memory: A mechanism (specifically a resource) applied when processes need to share large amounts of data in an efficient way.

In our next article, we will cover understanding of PIPES and FIFOs with example.

Source:

• http://linux.omnipotent.net/article.php
• http://en.wikipedia.org/wiki/Inter-process_communication

Step 2: Type it in exactly the way it’s given, maintaining all the spaces and every word of it.

.TH MYAPP 1

.SH NAME myapp \- A Demonstration application.

.SH SYNOPSIS .B myapp [\-option ...]

.SH DESCRIPTION  \fImyapp\fP is a complete application that  does nothing useful.

It was written for demonstration purposes for http://www.linux.com

.SH OPTIONS It doesn’t have any, but let’s pretend, to make this template complete:

.TP .BI \-option If there was an option, it would not be -option.

.SH RESOURCES myapp uses almost no resources.

.SH DIAGNOSTICS The program should provide an approximate position  where the cat ought to be found. The return value is in terms  of time, distance and direction.

.SH SEE ALSO The only other program we know with this little  functionality is the ubiquitous hello world application.

.SH COPYRIGHT myapp is Copyright (c) 2011-2012 M.Siddarth

This program is free software; you can redistribute it and/or modify  it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License  along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.

.SH BUGS There were a few bugs, but my naughty cat ate all of them.
.SH AUTHORS XXXXX
E-mail : xxxx@xxx.org

Step 3: Okay, after typing in everything, check once more, and then save and exit. Let’s get a custom manual page running first! Now, we have the source to the manual page ready, so we can process it with groff. The groff command commonly produces ASCII (American Standard Code for Information Interchange) text (-Tascii) or PostScript (-Tps) output. The -man option in the command line tells groff that it’s a manual page that we want to create. So, type in at the command prompt (from within the same directory where the myapp.1 file resides): “groff -Tascii -man myapp.1″ and press enter.

Step 4: We need to install it in the proper directory for using from the command line. So, for installing our custom man page, first we need to convert it into a .gz file and then install it in /usr/share/man/man1 directory. But first, don’t forget to create a backup of our text file “myapp.1″. Name the backup “myapp.1.bak”. We need this backup in case we need to create future manual pages, or alter the already created one (when it’s converted into a .gz file and installed into the /usr/share/man/man1 directory. So type in (from within the directory that contains the file myapp.1): “cp myapp.1 myapp.1.bak” and press enter.

Step 5: The backup created, now type in: “gzip myapp.1″ and press enter. This creates a file myapp.1.gz that now needs to be installed into the /usr/share/man/man1 directory for future use.

Step 6: Type in: “cp myapp.1.gz /usr/share/man/man1″ and press enter. This will successfully install the custom manual page and prepare it for further use as when required.

 Step 7: Now for using the manual page, from the command line, just type in: “man myapp” and press enter. The first time someone asks for this manual page, the man command will automatically format and display it.

We started out with a text file called “myapp.1″, processed it using the “groff” utility, then converted the “myapp.1″ into “myapp.1.gz” and finally installed it within /usr/share/man/man1 directory. These are the only steps that one needs to follow for creating his/her own manual pages in Linux. And for future use just use the template file for creating more manual pages.

One question that needs to be asked is: Hey, why did you create that compressed file using “gzip”? What’s the use of this step? 

Who can provide the answer?