UNIX C PROGRAMMING
Question 1: Executing Commands in Child Processes
Write a program that takes a list of command line arguments, each of which is the full path of a command (such as /bin/ls, /bin/ps, /bin/date, /bin/who, /bin/uname etc). Assume the number of such commands is N, your program would then create N direct child processes (ie, the parent of these child processes is the same original process), each of which executing one of the N commands. You should make sure that
these N commands are executed concurrently, not sequentially one after the other. The parent process should be waiting for each child process to terminate. When a child process terminates, the parent process should print one line on the standard output stating that the relevant command has completed successfully or not successfully (such as Command /bin/who has completed successfully,
or Command /bin/who has not completed successfully). Once all of its child processes have terminated, the parent process should print All done, bye-
bye! before it itself terminates.
Note: do not use function system in this question.
Question 2: Reporting Information of Files
Write a C program, myls.c, that is similar to the standard Unix utility ls -l (but with much less functionality). Specifically, it takes a list of command line arguments, treating each command line argument as a file name. It then reports the following information for each file:
1. user name of the owner owner (hints: Stevens & Rago, 6.2.);
2. group name of the group owner; (hints: Stevens & Rago, 6.4.);
3. the type of file;
4. full access permissions, reported in the format used by the ls program;
5. the size of the file;
6. i-node number;
7. the device number of the device in which the file is stored, including both major
number and minor number (hints: Stevens & Rago, 4.23.);
8. the number of links;
9. last access time, converted to the format used by the ls program (hint: Stevens &
Rago, 6.10.);
10. last modification time, converted to the format used by the ls program;
11. last time file status changed, converted to the format used by the ls program;
Like ls -l command, if no command line argument is provided, the program simply reports the information about the files in the current directory.
Of course, your program cannot use ls program in any way.
Documentation Requirements
Create a word document name Assignment1.docx. For each question, you must include
a. Self-diagnosis and evaluation: a statement giving following details for each requirement of the question: what have been fully completed and working, and what have been fully completed but not fully working, and what are not been fully completed or not attempted. This statement is essential. You will lose at least 50% of the mark allocated to the question if this statement is missing, misleading, or too vague.
b. Test evidence: depending on the nature of the problem, you may need one or more test cases to demonstrate that your program has met all requirements.
When testing your program, please turn on the gcc warning (gcc -Wall ), and make sure you fixed all warnings before submitting your program.
For each test case, you should 1) explain the purpose of the test, 2) provide the test output including the command line used, and 3) give an explanation on what the test has achieved based on the test results.
It is important that you present a sufficient number of test cases to convince your tutor that your solution works in all situations. Please note that although your tutor may test your program to verify the evidence presented in your documentation, it is not the responsibility of your tutor to test your program for the purpose of finding marks for you. It is up to individual student to mount a convincing case that the submitted solution works as required. You will be awarded marks based on the test evidences you presented. Therefore, if you do not provide test evidence you do not get marks regardless of whether your program works or not. If the test evidence you have provided is not sufficient, your marks will be substantially reduced.
You should format your test output using fonts such as courier so that test output is clearly distinguishable from the rest of the document. You should not modify the test output unless it is too long and repetitive.
In presenting your test cases, do not use the tabular format that you may have been told to use in some other units. Simply present one test case after the other in a linear order.
c. Source code listing: the source code must be properly indented, commented, and formatted.
Reviews
There are no reviews yet.