CS 2211 Advanced Programming
Submission of Recitations, Spring 2005

Paperless Course: I am using a system of electronic submission of recitations, to make do with less paper in this course. All work for recitations will be submitted electronically, graded, and returned by email. You must have an account on the CS network.

Rules:
  1. Each recitation must be submitted using a program of mine on the CS Sun network. Specifically, log into one of the Sun machines,using your own account. Create your recitation materials as a text file, named say rec1.text, although you can choose any file name in any directory that you wish. Open a terminal window, and execute the following from the directory containing this file:

    where % is the Unix prompt. The above is for Recitation 1, and similarly, use cs2213r2 for Recitation 2, etc.

    Below is an interactive session illustrating the correct submission of Recitation 0:

  2. If you are running on one of the Linux Lab machines, you must open a terminal window: pop up the left-hand menu to "System Tools" and follow over to "Terminal". This will start up a terminal window. Then you must connect to the regular Sun network using the Secure Shell (ssh) with one of the two following commands:

    where % is the Unix prompt, username is your account name, and ten63 can to be replaced by one of the other Sun client machines, such as ten57, etc. At this point you can submit as in item 1 above.

  3. Each submission must be a single text file (.txt or .text).   Absolutely no WORD, HTML, PostScript, or PDF files (no .doc or .html or .ps or .pdf files), or any other formatted or binary file. (It is just too confusing to try to cope with all the different forms that documents can take.)

  4. If you would normally want to submit several files, just concatenate them into one file. On Unix systems, you can use something like:

    Normally, however, you would want to do the concatenation inside an editor, identifying each separate file and providing some kind of line of characters separating different parts.

  5. Each recitation has a full credit due date and time (usually Tuesday at midnight during the week after the recitation). After that there is a 75% credit due date and time (usually Sunday at midnight during the week after the recitation). After that the recitation is not good for any credit.

    I intend to be strict about these deadlines. If some special problem comes up, that is what the 75% fallback credit is for, and if a special problem keeps you from meeting the second deadline, you just shouldn't have cut it that close, and it is only one out of 14 recitations. In the end, you should send something to meet the deadlines even if it is not complete.

  6. Unless explicitly stated otherwise, programs must always be followed by the results of a run.

  7. Grading comments will be inserted using ALL CAPS, so you should not use these in your submission.

  8. Submissions for a recitation should not contain extraneous or excessive material, but should be limited to the recitation requirements.

  9. It is permissible to submit the recitation in time for the first deadline, and then to submit a better version in time for the second deadline. Your grade in this case will be the better of the two grades for the two submissions. In case of multiple submissions for the same deadline, only the latest will be graded, although all will be archived.

  10. Each recitation must be your own individual work. It is permissible to talk over recitations, to get help from the instructor or the teaching assistant, but you must not supply code or answers to other students. It is completely unacceptable to exchange machine-readable portions of recitations. Anyone providing such material is just as much at fault as a person using it. There will be significant penalties for submitting work that has been copied from someone else, and the same penalties for allowing someone else to copy your work. You should realize that the recitation files will remain indefinitely and can be examined at any future time, even after the semester is over. (See Plagiarism by Student Programmers for a discussion of copying by students.)

  11. In an emergency, for example if you can connect to the Internet but cannot manage to do an ssh to one of the UTSA machines, you may email your recitation directly to me at:

    Please try to do this as seldom as possible. The same deadlines will apply, based on the timestamp on the email. You should be aware that there can be almost an arbitrarily long delay between sending an email and its receipt. Please do not send any attachments at all, particularly not WORD attachments. (Just paste your email in along with your message.)

Security of the submission process: I wanted a system for submitting and retaining recitations that would be simple, secure, under my own complete control, and not requiring root access on any machine. The method I ended up with relies for its security on the secrecy of the file names. These files reside in directories that cannot be directly read, but the file can be read if one knows its name. Thus security depends on the secrecy of (long) filenames. Dr. Maynard said that this method stinks, because information like the names of files often leaks out from an OS. He's probably right.

Even though this system is not unbreakable, you will still be in big trouble if you crack it and use the cracking to cheat. However, if you want to study the security of the system, I'll even supply you with the C source code for the system.

Revision date: 2005-01-05. (Please use ISO 8601, the International Standard.)
Copyright © 2011, Neal R. Wagner. Permission is granted to access, download, share, and distribute, as long as this notice remains.