C代写/C++代写/linux shell代写: C & linux shell assignment

C代写/C++代写/linux shell代写: 这是一个C语言代写和C++代写结合的作业,通过二者结合进一步考察linux shell的编写
If you’ve done the above correctly, you should now find the following files in the directory:

Makefile a set of dependencies used to control compilation
IntList.h interface definition for the IntList ADT
IntList.c implementation for the IntList ADT
useIntList.c main program for testing the IntList ADT
randList.c main program for generating random sequences of numbers
timing.txt template for your results file; you need to add more rows
Before you start using these programs, it’s worth looking at the code. Are there any constructs that you don’t understand? Try to work them out with your lab partner, or ask your tutor.

Once you’ve understood the programs, the next thing to do is to run the command:

$ make
It’s worth taking a look at the Makefile to see if you can work out what it’s doing. Don’t worry if you don’t understand it all; we’ll be taking a longer look at make in later labs. Note: you will need to run make to recompile the system each time you make changes to the source code file and are ready to test the program again.

The make command will produce messages about compiling with gcc and will eventually leave two executable files in your directory (along with some .o files).

usel
This is the executable for the useIntList.c program. It reads a list of integers from standard input, then attempts to make a sorted (ascending order) copy of the list, and then prints both the original and the sorted lists. It doesn’t work at the moment because the function to produce the sorted list is incomplete.
randl
This is the executable for the randList.c program. It writes, on its standard output, a list of random numbers in the range 1..999999. It takes one command-line argument to indicate how many numbers it should write, and another optional argument to give a seed for the random number generator. Note that it does not attempt to eliminate any duplicate values produced; if you generate a large enough number of values, duplicates are inevitable.
You can run the usel command by typing the command name, followed by return. It will then patiently wait for you to type some numbers, and will store them in a list, display the list, then call the function that is supposed to sort the list, and then display the “sorted” list. Of course, this doesn’t currently work, because the list sorting function is incomplete. You can, however, fake it by typing the numbers in in order, e.g.

$ ./usel -v
1 2 3 4
Here you type control-D to finish your input
Original:
1
2
3
4
Sorted:
1
2
3
4
When usel eventually works properly, this is the kind of output you’ll expect to see … except that you won’t be giving it sorted lists as input. To see the existing behaviour on an unsorted list, type a few numbers not sorted in ascending order, e.g.

$ ./usel -v
1 3 2
Once again, you type control-D to finish your input
Original:
1
3
2
Sorted
1
3
2
usel: useIntList.c:20: main: Assertion `IntListIsSorted(myOtherList)’ failed.
Aborted
If you omit the -v command-line parameter, the the usel program only displays the final sorted list (which is not yet sorted, of course).

$ ./usel
1 3 2
Once again, you type control-D to finish your input
1
3
2
usel: useIntList.c:20: main: Assertion `IntListIsSorted(myOtherList)’ failed.
Aborted
Now it’s time to play with the list generator. If you execute the command:

$ /.randl 10
it should display a list of 10 random numbers. If you run it again, you’ll get a different list of random numbers. Enjoy generating small lists of random numbers until you are bored.

If you then execute the command:

$ ./randl 10 | ./usel
the randl command will generate 10 random numbers and give them to the usel command which will print the list of numbers twice (separated by the word Sorted) and then fail the assertion as above.

If you’re not familiar with Unix/Linux conventions, the | is a “pipe” that connects two commands, e.g. C1|C2. The standard output (stdout) of the command C1 will be directly connected to the standard input (stdin) of the command C2, so that whatever C1 writes, C2 reads.
You can adjust the number of numbers that randl generates via the command-line argument, e.g.

$ ./randl 100 | less
will produce 100 random numbers. If you want to change the range of numbers produced (e.g. to only make numbers in the range 1..10) edit the randList.c code and add extra command-line arguments to set the range.

If you supply only one command-line argument, randl will generate a completely random (well, pseudo-random) sequence each time you run it. If you want to generate a large sequence of pseudo-random numbers, and be able to generate the same sequence consistently, you can use the second command-line argument to specify a seed for the random number generator. If you give the same seed each time you run randl, you’ll get the same sequence each time. To see the difference between using and not using the second command-line argument, try the following commands:

$ ./randl 10
$ ./randl 10
$ ./randl 10
$ ./randl 10 13
$ ./randl 10 13
$ ./randl 10 13
The first three commands will generate different sequences. The second three commands all generate the same sequence.

While ./randl is useful for producing large amounts of data, you don’t need to use ./randl to produce input to ./usel. An alternative is to use the echo command and enter the numbers yourself, e.g.

$ echo 5 4 3 2 1 | ./usel
Another alternative, which will be more useful for testing, is to use the seq command, in combination with the sort command, e.g.

$ seq 10
# gives 1 2 3 4 5 6 7 8 9 10
$ seq 10 | sort -n
# gives 1 2 3 4 5 6 7 8 9 10
$ seq 10 | sort -nr
# gives 10 9 8 7 6 5 4 3 2 1
$ seq 10 | sort -R
# gives 1..10 in a random order
The -nr argument to the sort command tells it to treat the input as numbers and sort them in reverse order. The -R argument to the sort command tells it to put the input in random order. You can find more details about sort via the command man sort.

One thing to remember is that sort orders items lexically, not numerically, by default. The following pipeline may not produce what you expect. Try it.

$ seq 10 | sort
Task 1
The IntListInsertInorder() function is incomplete. In fact, it’s just a stub function that invokes the IntListInsert() function, which inserts the number, but not in order. You should re-write the IntListInsertInorder() function so that it takes an IntList and an integer and inserts the value into the appropriate place in the list, so that the list always remains sorted (in ascending order). The function should fail if the original list (before insertion) is not sorted. Don’t forget to handle the cases of (a) empty list, (b) smallest value, (c) largest value, (d) second-smallest value, (e) second-largest value, (f) value somewhere in the middle. Why were these kinds of values chosen? Discuss with your partner and propose test cases that test these and any other cases that you can think of.

Make a directory called tests, and place files containing your test cases in that directory with one test case in each file. A useful name strategy is to call the test files 01, 02, etc. You could create test files in various ways, e.g.

$ mkdir tests
$ seq 10 | sort -R > tests/01
$ seq 10 | sort -nr > tests/02
$ randl 10 11 > tests/03
etc. etc. etc.
In order to check that your program is producing the correct results, you could compare it to the output of a known correct sorting program. The diff command can help here (see man diff for details). For example, you could put each test case in a file, then run both your usel program and the built-in sort command, save the results of each output in a file, and then compare the files using diff. If your program is correct, there should be no difference. The following shows an example of how to do this:

$ sort -n < tests/01 > tests/01.expected # generate correct result
$ ./usel < tests/01 > tests/01.observed # generate *your* result
$ diff tests/01.expected tests/01.observed # if correct, no output
If you produce a decent number of tests (10-20), as you should, then testing them one by one using the above is a bit tedious. You could simplify carrying out the testing by writing a small shell script like:

#!/bin/sh

for t in 01 02 03 04 05 … and the rest of your test files
do
echo === Test $t ===
sort -n < tests/$t > tests/$t.expected
./usel < tests/$t > tests/$t.observed
diff tests/$t.expected tests/$t.observed
done
rm tests/*.expected tests/*.observed
If you put the above in a file called e.g. run_tests, and then run the command:

$ sh run_tests
the script will run all your test cases and any that fail will either produce an assertion message or show you the difference between your output and the expected output.

You will have some confidence that your IntListInsertInorder() function is working properly when, for all test cases, the assertions in useIntList.c no longer fail.

发表评论

电子邮件地址不会被公开。 必填项已用*标注