Where cpsXX is replaced with the class identifier, e.g., cps100, cps104, etc. The executables are accessible from /usr/local/bin/submit_cpsXX on CS machines and /afs/acpub/project/cps/bin/submit_cps108 on the acpub system.
The first argument assignment is required. Think of it as the name of an assignment, but it corresponds to a directory in which all student submissions will be stored. You might name assignments semantically, i.e., mutexdemo or chronologically, i.e., assign1. As the professor or TA in charge of a course you must create the directory for each assignment --- this is how you control the assignment names. Per class directories for storing assignments are found in /usr/project/courses/cpsXXX/submit. All submissions are logged in /usr/project/courses/cpsXXX/submit.log which helps identify submissions.
Under the new archive system you will need to create a link in the /usr/project/courses directory that points to the correct semester, e.g. /usr/project/courses/cps100 -> /usr/project/courses/fall00/cps100. If you do not do this, the listener daemon will not start since it can not write a log file.
After the assignment name, arguments are filenames that will be submitted. All files must reside in the directory from which the submit command is run and all must be less than 10 MB in size. In introductory classes student often submit everything, i.e.,
submit_cps006 firstprog *.cc README
Students can also be asked to create tar files for submitting hierarchical file and directory structures.
If no filenames are provided as arguments, the submit program will provide the student running submit with the names and sizes of the files last submitted. For example:
prompt> submit_cps108 demo
assignment 'demo' submitted 4 times
size name
---- ----
(1) 3057 foo.cc
(2) 4024 bar.cc
(3) 766 README
Each time a student submits files a new subdirectory for the files is created in the assignment directory. The submitter's user-id is used as the basename of the subdirectory with _1, _2, etc appended for each submission so that user ola might create ola_1 and ola_2 with two submissions.
All listener programs should be run from the machine submit login to submit, the actual machine changes). Once logged in you should run the listen program for your class which is called listen_cpsXXX and is accessible in /usr/local/bin.
Run the program in background so that it continues to run after you log out from the submit machine. It's probably a good idea to set up a cron job that monitors the listen program to ensure it starts up again if it goes down for some reason. To run a cron job, log in to the machine submit and type crontab -e. Then enter the line below in the editor, and save the buffer.
0,15,30,45 * * * * /usr/local/bin/listen_cpsXXX
This will ensure that the status of the listen program is checked every 15 minutes.