Task 1: filegrep (20pt.)

In this task, you will implement a simplified version of the grep program in C, called filegrep. The usage syntax of filegrep will be as follows:

filegrep PATTERN FILE 

Both command-line arguments are necessary. PATTERN is a string of characters. FILE is a name of a file in which search is performed. Note that, unlike grep, filegrep searches for the pattern literally as it is. In other words, you do not need to consider meta characters and regular expressions. Our test cases will only include patterns that contain alphanumeric characters.

The output of running the program using the above arguments must be exactly the same as running grep -n PATTERN FILE. Note that the output should include line numbers.

If less/more than two arguments are provided you must print the following message to stderr:

Usage: filegrep PATTERN FILE 

Moreover, if FILE is invalid, your program should print the same error that grep would print to stderr.

Task 2: lsal (40pt.)

One of the most basic and useful packages shipped with all GNU/Linux operating systems is coreutils. It provides you system utilities such as ls and rm. At this point of the semester, you know enough to be able to implement similar functionality by using system calls in C. That is exactly how coreutils is implemented too!

In this task, you will implement a special version of the ls program, called lsal. In particular, you need to write a C program that accepts a command-line argument and behaves almost like ls -al, printing details of all files. The followings will explain the expected behavior:

If an argument is provided, it can be either a file name or a directory name. If the argument is a directory name, you will list all files/directories inside it. Otherwise, you only list the corresponding file.

Note that "." or ".." are directories as well and therefore your program should work for them too.

If an argument is not provided your program will list the working directory (same as ".").

In order to retrieve and inspect the file information, you need to carefully study the inode's manual.

Only list the regular files and directories. Skip other types such as links, etc. See inode for how to test the file type.

Your output must be exactly the same as in ls. Therefore, you can use diff as you have seen in previous test scripts to fully test your program before submission. This is of course true for directories that contain regular files and directories only. For example, your output would not list a symlink while ls does.

Make sure that you also replicate the behavior of ls if file/directory cannot be found by printing the same error message to stderr.

Hint: Some of the system calls that may be useful for this Task include opendir, readdir, lstat, getpwuid, and getgrgid.

Hint: Make sure you pass the full pathname (absolute/relative) as argument to functions such as lstat.

Task 3: Improved lsal (10pt.)

As you know, ls can accept multiple arguments. Improve your code from Task 2 to provide the same flexibility in a new program called lsal2. Note that when multiple arguments are passed to ls, for directories it also prints the name of the directory before listing the files inside it.

Hint: Write your code as modular as possible to avoid duplicating code that might be reused. That way you avoid debugging same errors again and again. For example, you should put any shared functionality between lsal.c and lsal2.c (i.e., most of what Task 2 asks you to do) in a separate source file which will be linked to your lsal.o and lsal2.o code to make the executable files.

Task 4: makefile (10pt.)

Create a makefile that has at least the following four targets:

all (default target): build all three programs

filegrep: create executable filegrep of Task 1

lsal: create executable lsal of Task 2

lsal2: create executable lsal2 of Task 3

Note that the above are the required targets. You will probably need to create other targets (used by above as prerequisites), especially if your code is modular as suggested above.

Note: makefile is a critical part of your submission as we use it to compile and grade your programs. Make sure to include it.