C语言编写构建Linux Tail程序的实现

Revision Status
FIT2100 Assignment #1 Building a tail utility with C Programming
Semester 2 2019
Mr Daniel Kos
Lecturer, Faculty of IT. Email: Daniel.Kos@monash.edu © 2019, Monash University
August 8, 2019
version 1: August 2019 by Daniel Kos
© 2019, Faculty of IT, Monash University1 Introduction 3
1 Introduction
In this assignment, you will build a simpli􏰀ed version of the Linux tail utility, which is used for viewing the last portion of a long text 􏰀le. tail is generally useful for viewing the last few lines in long log 􏰀les that the operating system produces (for example the /var/log/kern.log 􏰀le in your virtual machine environment). Linux server administrators use the tail utility for checking recent activity in network logs.
This document constitutes the requirement speci􏰀cation for this assignment. You will be assessed on your ability to both comprehend and comply with the requirements as speci􏰀ed herein.
Due: 30th August 2019 (Friday) 5pm.
Late submissions: A late submission penalty of 5% of assignment total per day will apply. This assignment is worth 15% of the total marks for this unit.
2 Caveats
To complete these tasks, you are allowed to use any of the standard C libraries found on your virtual machine environment1, except one:
You are NOT allowed to use any functions available in <stdio.h>. This means you cannot use printf() to produce output. (For example: to print output in the terminal, you will need to write to standard output directly, using appropriate 􏰀le system calls.) This makes the assignment more challenging, but also means you are interacting with services of the operating system directly.
Your main C source 􏰀le should be named with your student ID as: ctail-123456789.c, where 123456789 is your student ID.2
1For example, you may use getopt according to your preference, but use of any particular library is neither expected nor required, except as required to make system calls.
2
If your completed program contains multiple source 􏰀les, you may name other source and header 􏰀les as you wish.
© 2019, Faculty of IT, Monash University

3 If you require extra help 4
3 If you require extra help
This assignment is an independent learning and assessment exercise.
You may utilise the student forums to ask questions and obtain clari􏰀cation, however you may not share details or code in your implementation with other students, nor may you show your code to the teaching team prior to submission. This is an assessment task: tutors and lecturers are not permitted to help you debug your assignment code directly (you are expected to debug and test your own code), but can help with more general queries, such as queries related to C programming syntax, concepts and debugging tips.
You may make use of online references with appropriate citation in accordance with academic integrity policies, however your work must be your own.
3.1 References
Thhe following resources are available on the FIT2100 Unit Information page.
􏰄 Curry, David, UNIX Systems Programming for SVR4, Chapter 3: `Low-Level I/O Rou- tines’.
􏰄 Curry, David, Using C on the UNIX System, Chapter 3: `Low-Level I/O’.
􏰄 He, Jialong, LINUX System Call Quick Reference.
4 Task 1: Character-based functionality with hard- coded options
Write a utility called ctail (`character tail’) which does the following:
1. Opens a 􏰀le named log􏰀le.txt in the current working directory.
2. Outputs (to standard output􏰂usually the terminal) only the last 200 characters from that 􏰀le. If the 􏰀le contains fewer than 200 characters, output the entire 􏰀le contents. (Where the program completes normally, no other output should be produced.)
© 2019, Faculty of IT, Monash University

5 Task 2: Support command-line options 5
Your program should always exit `cleanly,’ i.e. close any open 􏰀les (and free any resources you allocate) before termination.
If there is a problem accessing the 􏰀le (e.g. 􏰀le does not exist), your program should display an error message (you should output this to the program’s standard error stream rather than standard output 􏰁 why?) and exit cleanly with a return value of 1. On successful completion, your program should return an error code of 0.
Write up an instruction manual (user documentation) in a plain text 􏰀le, explaining how to compile your program and how to use it.
You may test your program using either your user documentation itself, or by using system log data found in many 􏰀les under the /var/log/ directory.
5 Task 2: Support command-line options
Now extend your program to allow the user to run your program using command-line arguments as follows:
1. Instead of the default 200 characters, allow the user to specify an -n argument at the command line in order to specify a di􏰃erent number of characters. Where the -n option is used, the argument immediately following it is treated as the number of characters to be used. If the next argument after an -n argument is not a non-negative integer, the program arguments are invalid (see below).
2. Allow the user to specify a di􏰃erent 􏰀lename (instead of logfile.txt) by putting the 􏰀lename in a command-line argument.
Example commands:
1
2
3
4
5
6
$ ./ctail /var/log/kern.log
[ output will be last 200 chars from kern . log ]
$ ./ctail readme.txt −n 80
[output will be last 80 chars from readme.txt]
$ ./ctail −n 5
[output will be last 5 chars from logfile.txt]
Both command-line options are optional: if an argument is not provided, your program should use the default settings from task 1.
© 2019, Faculty of IT, Monash University

6 Task 3: Add support for line-based functionality 6
If an argument is invalid (for example: ./ctail -n filename.txt), your program should display an error message and then exit cleanly with an error code of 2.
Do not collect these options from standard input, or prompt the user to enter them. They should be speci􏰀ed as program arguments.
Extend your user documentation to include the added usage functionality.
6 Task 3: Add support for line-based functionality
Add support for one additional (optional) argument:
1. The -L argument, if speci􏰀ed within the program arguments, should switch the program to line-based mode. In this mode, ctail outputs the last 10 lines3 in the 􏰀le by default. If the -n argument is speci􏰀ed, the value given by the user should be used as the number of lines rather than characters. If the 􏰀le is shorter than 10 lines, the entire 􏰀le contents should be output.
Extend your user documentation to include the new functionality.
6.1 Important: commenting is required
Commenting your code is essential as part of the assessment criteria (refer to Section 6.2). All program code should include three types of comments: (a) File header comments at the beginning of your program 􏰀le, which specify your name, your Student ID, the start date and the last modi􏰀ed date of the program, as well as with a high-level description of the program. (b) Function header comments at the beginning of each function should describe the function, arguments and interpretation of return value. (c) In-line comments within the program are also part of the required documentation.
6.2 Marking Criteria
Each task is worth an equal share of the total. The same marking criteria will be applied on all tasks:
3Each line in a text 􏰀le is separated by a newline ’\n’ character.
© 2019, Faculty of IT, Monash University

6.3
Hints and tips 7
􏰄 50% for working functionality according to speci􏰀cation.
􏰄 20% for code architecture (algorithms, use of functions for clarity, appropriate use of
libraries, correct use of pointers, etc. in your implementations of the three tasks.)
􏰄 10% for general coding style (clarity in variable names, function names, blocks of code clearly indented, etc.)
􏰄 20% for documentation (user documentation code is well-commented.)
6.3 Hints and tips
Do…
+ read up on low-level I/O system calls
+ write normal program output to standard output
+ close open 􏰀les before exiting and free any manually-allocated memory
+ check return values and handle error condi- tions
+ access and modify valid memory
+ read up on argc and argv
+ write user documentation in a plain text 􏰀le
+ in user documentation: explain all function- ality to those who might use your program
+ use descriptive, self-explanatory variable names
+ break your program logic into multiple func- tions
+ use consistent code indentation for clarity
+ comment your code with 􏰀le header, function header and inline comments
+ test your program in the speci􏰀ed VM envi- ronment
+ read the assignment speci􏰀cation care- fully and thoroughly
describes functionality for the relevant task,
Don’t… (!)
􏰁 use fancy C <stdio.h> library functions that don’t demonstrate your understanding of mak- ing system calls to the OS directly.
􏰁 write error messages to standard output (use standard error instead)
􏰁 terminate without cleaning up 􏰀rst
􏰁 act in unde􏰀ned ways when a parameter is invalid or a 􏰀le can’t be opened
􏰁 attempt to set values in unde􏰀ned pointers 􏰁 prompt the user to enter options after your program has started
􏰁 submit user documentation in a Word docu- ment or PDF
􏰁 expect your users to understand the C code inside your program (users are not always pro- grammers!)
􏰁 use vague single-character variable names 􏰁 stu􏰃 everything into a single main function
􏰁 use inconsistent indentation or fail to indent nested code blocks
􏰁 write uncommented code or add comments at the last minute
􏰁 forget to run your 􏰀nished program through valgrind to test for memory access bugs
􏰁 treat this table as a substitute for reading the spec carefully.
© 2019, Faculty of IT, Monash University

7 Submission 8
7 Submission
There will be NO hard copy submission required for this assignment. You are required to archive and compress all your deliverables into a single .tar.gz 􏰀le named with your Student ID, for submission. For example, if your Student ID is 12345678, you would submit a zipped 􏰀le named 12345678_A1.tar.gz.
Your submission is via the assignment submission link on the FIT2100 Moodle site by the deadline speci􏰀ed in Section 1, i.e. 30th August 2019 (Friday) by 5:00pm.
Note: You must ensure you complete the entire Moodle submission process (do not sim- ply leave your assignment in draft status) to signify your acceptance of academic integrity requirements.
7.1 Deliverables
Your submission should be archived and compressed into a single .tar.gz 􏰀le containing the following documents:
􏰄 Electronic copies of ALL your 􏰀les (e.g. C source 􏰀le(s)) that are needed to compile and run your program. (Note that your program must run in the Linux Virtual Machine environment which has been provided for this unit. Any implementation that does not run at all in this environment will receive no marks.)
􏰄 A user documentation 􏰀le (not more than 3 pages) in plain .txt format with clear and complete instructions on how to compile and run your program.
Marks will deducted for any of these requirements that are not strictly complied with.
7.2 Academic Integrity: Plagiarism and Collusion
Plagiarism Plagiarism means to take and use another person’s ideas and or manner of express- ing them and to pass them o􏰃 as your own by failing to give appropriate acknowledgement. This includes materials sourced from the Internet, sta􏰃, other students, and from published and unpublished works.
Collusion Collusion means unauthorised collaboration on assessable work (written, oral, or practical) with other people. This occurs when you present group work as your own or as
© 2019, Faculty of IT, Monash University

7.2 Academic Integrity: Plagiarism and Collusion 9
the work of another person. Collusion may be with another Monash student or with people or students external to the University. This applies to work assessed by Monash or another university.
It is your responsibility to make yourself familiar with the University’s policies and procedures in the event of suspected breaches of academic integrity. (Note: Students will be asked to attend an interview should such a situation is detected.)
The University’s policies are available at: http://www.monash.edu/students/academic/ policies/academic-integrity
© 2019, Faculty of IT, Monash University