#Needs some explaining and a sample C coding

4. extend your shell with pipelining. The command $ cmd1 | cmd2 | cmd3 connects the standard output of cmd1 to the standard input of cmd2, and again connects the standard output of cmd2 to the standard input of cmd3 using the pipeline operator '|'.

An example usage is $ sort < file.txt | uniq | wc counts the number of unique lines in file.txt.

Without pipes, you would have to use three commands and two intermediate files to count the unique lines in a file.

You will need to use the pipe() system call.

Your shell should handle an arbitrary number of commands chained together with the pipeline operator.

As seen in the usage example, your shell should handle combinations of redirection and pipelining when they can be combined.

Your shell does not need to handle built-in commands implemented above (i.e., cd, exit, and path) in pipeline.

4 of 7 DEFENSIVE PROGRAMMING With regards to multiple commands on the same line, the following lines are all valid and have reasonable commands specified:

prompt> ls prompt> /bin/ls prompt> ls l prompt> ls l;

cat file1 prompt> ls l | wc;

cat file1 prompt> ls l;

cat file1;

grep Dallas file2 For example, on the last line, the commands ls l, cat file, and grep Dallas file2 should all be running at the same time.

As a result, you may see that their output is intermixed.

You must support pipes (i.e., |) to connect the output of one program to the input of another as in the second-to-last command above.

Check the return values of all functions utilizing system resources.

Do not blindly assume all requests for memory will succeed and that all writes to a file will occur correctly.

Your code should handle errors properly.

Many failed function calls should not be fatal to a program.

Typically, a system call will return -1 in the case of an error (malloc returns NULL on error).

An OS cannot simply fail when it encounters an error.

It must check all parameters before it trusts them.

In general, there should be no circumstances in which your C program will core dump, hang indefinitely, or prematurely terminate.

Therefore, your program must respond to all input in a reasonable manner.

By reasonable, this means that you should print a meaningful and understandable error message and either continue processing or exit, depending upon the situation.

Many questions about functions and system behavior can be found in the manual pages.

You should consider the following situations as errors in each case, your shell should print a message to stderr and exit gracefully:

An incorrect number of command line arguments to your shell program; and

The batch file does not exist or cannot be opened. For the following situation, you should print a message to the user (stderr) and continue processing:

A command does not exist or cannot be executed.

Optionally, to make coding your shell easier, you may print an error message and continue processing in the following situation:

A very long command line (over 512 characters including the ' ').

Your shell should also be able to handle the following scenarios, which are not errors (i.e., your shell should not print an error message):

An empty command line; 5 of 7

Extra white spaces within a command line; and

Batch file ends without exit command or user types Ctrl-D as command in interactive mode.

In no case should any input or any command-line format cause your shell program to crash or exit prematurely.

You should think carefully about how you want to handle oddly formatted command lines (e.g., lines with no commands between a semi-colon). In these cases, you may choose to print a warning message and/or execute some subset of the commands.

However, in all cases, your shell should continue to execute.

prompt> ; cat file1 ; grep Dallas file2 prompt> cat file1 ; ; grep Dallas file2 prompt> cat file1 ; ls l ; prompt> cat file1 ;;;; ls l prompt> ;; ls l prompt> ;