Each student will write a Bash script which provides information to the user comparing the statuses of processes and or threads. Also to be included is a detailed report using the attached format
The specific information to be provided to the user will be determined by the student, but must include at least three different values.
The script will use the information from the /proc directory to provide the output.
The script will support multiple uses, which will include a help option which will display basic usage information.
Some examples of comparisons the script may perform:
- Display the two processes most nearly identical in terms of run-time, memory size, etc.
- Display the processes which closely match specific input parameters for process attributes.
- Display processes which were launched from a particular directory or directory tree, or which were launched from similar locations.
- Display processes in adjacent or nearly adjacent memory locations.
- Display processes where Usernames have matching characteristics.
- Create an on-going list of all process names which have been used on the system.
The script must allow for and use at least 2 command line arguments (in addition to help).
- The command line arguments may either be used as a part of the determination (e.g. user or dates)
- Or, to change the behavior of the script (e.g. count remote vrs. local access).
The script must include at least one function.
The script will follow the “Scripting Best Practices” as provided.
Scripting Best Practices
When run with inappropriate arguments, scripts should print a usage message and exit. The same message could be printed with a–helpargument.
Validate inputs and sanity check derived values.
Return an appropriate exit code: zero for success and nonzero for failure.
Use appropriate naming conventions for variables, scripts, and routines.
User variable names that reflect the values they store.
Start every script with a comment block that tells what the script does and what parameters it takes. Include your name and the date. If the script requires non-standard tools, libraries, or modules to be installed, list those as well.
Comment at a useful level. More complexity requires more comments.
Error messages should:
- Go to STDERR, not STDOUT.
- Include the name of the program that’s issuing the error.
- State the function of operation that failed.
- If a system call fails, include the perror string.
- Exit with a code other than 0.