Project 1: Warm-up ProjectImportant DatesQuestions about the project? Send them to Due: Monday, 02/01, by 9pm. Clarifications01/23: See Assumptions and Errors below for a clarification on what to do when the input files are the same. NotesBefore beginning: Read Lab 0: Tutorial. It has some useful tips for programming in the C environment. This project must be done alone. You can talk to your colleagues about it, but every line of code must be written and understood by you. Of course, you can always ask the TAs and professors for help too. OverviewThe first project is simply a warm-up to get you used to how this whole project thing will go. It also serves to get you into the mindset of a C programmer, something you will become quite familiar with over the next few months. Good luck! You will write a simple program called shell% ./reverse shell% ./reverse input.txt shell% ./reverse input.txt output.txt The above line means the users typed in the name of the reversing program
An input file might look like this: hello this is a file The goal of the reversing program is to read in the data from the specified input file and reverse it; thus, the lines should be printed out in the reverse order of the input stream. Thus, for the aforementioned example, the output should be: a file is this hello The different ways to invoke the file (as above) all correspond to slightly different ways of using this simple new Unix utility. For example, when invoked with two command-line arguments, the program should read from the input file the user supplies and write the reversed version of said file to the output file the user supplies. When invoked with just one command-line argument, the user supplies the
input file, but the file should be printed to the screen. In Unix, printing to
the screen is the same as writing to a special file known as “standard
output”, or Finally, when invoked without any arguments, your reversing program should
read from “standard input” ( Sounds easy, right? It should. But there are a few details... DetailsAssumptions and Errors
Input is the same as output: If the input file and output file are the same file, you should print out an error message “Input and output file must differ” and exit with return code 1. String length: You may not assume anything about how long a line should be. Thus, you may have to read in a very long input line... File length: You may not assume anything about the length of the file, i.e., it may be VERY long. Invalid files: If the user specifies an input file or output file, and for some reason, when you try to open said file (e.g., Malloc fails: If you call Too many arguments passed to program: If the user runs How to print error messages: On any error, you should print the error to the screen using Useful RoutinesTo exit, call For reading in the input file, the following routines will make your life
easy: Note that fgets() can already read from standard input; all you have to do
is pass The routine If you don't know how to use these functions, use the man pages. For
example, typing Other TipsStart small, and get things working incrementally. For example, first get a program that simply reads in the input file, one line at a time, and prints out what it reads in. Then, slowly add features and test them as you go. For example, the way I wrote this code was first to write some code that
used Testing is critical. A great programmer I once knew said you have to write 5-10 lines of test code for every line of code you produce; testing your code to make sure it works is crucial. Write tests to see if your code handles all the cases you think it should. Be as comprehensive as you can be. Of course, when grading your projects, we will be. Thus, it is better if you find your bugs first, before we do. Keep old versions around. Keep copies of older versions of your program
around, as you may introduce bugs and not be able to easily undo them. A
simple way to do this is to keep copies around, by explicitly making copies of
the file at various points during development. For example, let's say you get
a simple version of Keep your source code in a private directory. An easy way to do this is
to log into your account and first change directories into Handing It InYou should turn in FOUR files. The first, containing your code, should be
called
so make sure it compiles in such a manner.
You should also include a file called Third, you should include a fact page about yourself, called Finally, you should include said picture of yourself. Thus, if someone
points a browser to the file You should copy these files into your handin directory. These will be
located in or more succinctly:shell% cp reverse.c ~cs537-1/handin/remzi/p1/ shell% cp README ~cs537-1/handin/remzi/p1/ shell% cp about.html ~cs537-1/handin/remzi/p1/ shell% cp pic.jpg ~cs537-1/handin/remzi/p1/
(the copy utility knows that if the last thing specified is a directory, it
should just copy the files into that directory and give them the same
names. Read the man page for cp for more details.)
|