scp/ssh commands for getting/sending homework files?
submit: copy (a) file(s) over from your CWD to the submission folder specified by <asno>. Note that multiple files can be copied at once.
/c/cs223/bin/submit <asno> <file>*
check: see all files submitted for a particular <asno>. This script basically just runs ls -la on the SUBMIT directory where your code is sent for grading.
/c/cs223/bin/check <asno>
retrieve: copy (a) file(s) from the submission directory specified by <asno> to your CWD. Note that a file with the same name as file cannot exist in your CWD. Once again, multiple files can be copied at once. This command has special flags that are enabled in this class. See the section below on RCS for more information.
/c/cs223/bin/check <asno> <file>*
unsubmit: delete (a) file(s) located in the submission directory specified by <asno>. Note that if the error "<file> is protected" is thrown, you simply need to unprotect that file. See below for more on protecting.
/c/cs223/bin/unsubmit <asno> <file>*
protect: prevent (a) file(s) located in the submission directory specified by <asno> from being discreetly overwritten. Undone by unprotect.
/c/cs223/bin/protect <asno> <file>*
unprotect: allow (a) file(s) located in the submission directory specified by <asno> to be overwritten.
/c/cs223/bin/unprotect <asno> <file>*
revert: return a file submitted to directory <asno> to the version specified by the -r flag. Enabled in CS223, but not necessarily other classes.
/c/cs223/bin/revert <asno> -r<version_no> <file>
results: view your scores for a particular <asno>. Enabled in CS223, but not necessarily other classes.
/c/cs223/bin/results <asno>
This guide is based on the most frequent problems that students encountered last semester while attempting to submit their work. To get your local machine ready for the semester, please see this guide. Note that if you want to use some kind of remote IDE solution, you won't have to worry about constantly scp-ing your homework files to/from the Zoo and your local machine.
If you're following the steps given below and it’s not working or you don’t understand it, please email a member of the instructional team or come to help hours as soon as possible! The skills that make you fast and efficient on your own computer do not necessarily translate into the command-line world of UNIX. So don’t worry if you find yourself frustrated in the early going – it doesn’t reflect on your ability to learn computer science!
To set them apart typographically, and to allow code-snippet formatting in Markdown, I will “quote” the following items inside back-ticks.
Enter, j, ~, and Ctrl/c/cs223/bin/testitcd, ls, and grepgrep -i peanut_butter jelly.cTo follow along with a command, type it into your terminal exactly (making sure your file paths are correct with respect to your CWD, or “current working directory”) and without any leading whitespace. To run the command, press Enter.
The angle brackets < and > are used as placeholders for an example <file_name> or for unique identifiers. Your <NetID> is necessarily different from mine, but the paths to our respective user-spaces on the Zoo have the same structure: /home/accts/<NetID>.
scp/ssh commands for getting/sending homework files?The scp syntax is:
scp <file_you_want_to_send_or_receive> <destination>
Zoo –> Me. One-liner for getting some file from your home folder on the Zoo onto your own computer. This also assumes you are currently in the local directory to which you want to transfer the file (i.e. you’re fine with the Zoo file ending up in your CWD, denoted by ./).
scp <NetID>@node.zoo.cs.yale.edu:~/<filename> ./
Note that the homeworks will always be available via a browser at:
https://zoo.cs.yale.edu/classes/cs223/f2021/Assignments/index.html
Me –> Zoo. Send a file that exists in your CWD from your computer to your userspace on the Zoo. Make sure the target directory ends in a forward slash (/) so that bash interprets cs223 as a directory and not a file. Otherwise, you’ll end up sending your file but it will now be named cs223, which is confusing! If the ~/cs223 directory doesn’t exist, you will see an error message that /cs223/ is not a directory. Use mkdir to create the cs223 subfolder or just transfer the file to ~/.
scp <file_name> <NetID>@node.zoo.cs.yale.edu:~/cs223/
Remotely log in to the Zoo cluster with:
ssh <NetID>@node.zoo.cs.yale.edu
Bash hides your typing of passwords for security reasons. You can still type as normal and use Backspace if you suspect you’ve made a typo.
When you scp or ssh into the Zoo, if it’s your first time doing so from a particular computer, you will see the message:
The authenticity of host 'node.zoo.cs.yale.edu (128.36.232.19)' can't be
established.
ED25519 key fingerprint is 0f:28:c3:7d:10:de:2f:fa:3b:ec:93:7b:09:b5:04:d7.
Are you sure you want to continue connecting (yes/no)?Short answer: type “yes” or “y” and press Enter. This is just a boilerplate warning you don’t need to worry about.
Long answer: bash will “remember” the Zoo cluster by adding its hostname and IP address to the file ~/.ssh/known_hosts. The fingerprint has to do with the cryptographic protocol that makes “secure shell” communication possible. See:
To get a sense for the purpose behind the hostname “node.zoo.cs.yale.edu,” run:
whois 128.36.232.19
Yale recently enabled two-factor authentication for Zoo access. The idea is to increase security by verifying your identity over another channel because a password alone is not very secure (especially for ssh access).
After entering your password, you will be prompted with three authentication options. Select one by typing in its corresponding number and hitting enter. Then, you'll need to complete the verification request using information forwarded to your mobile device. Once finished, you should be on the Zoo!
If you use the Yale VPN, you won't have to use 2FA each time you login. Download links and instructions for installation can be found here.
Either you have Windows 10, or you have Windows <10.
You can activate and download the Linux Subsystem for Windows. This will give you a full-on Unix shell, equivalent to the terminal on the Zoo machines or a Mac. Good directions from Microsoft are here:
https://msdn.microsoft.com/en-us/commandline/wsl/install_guide
Once you have the “Bash on Ubuntu on Windows” shell running (and saved to your Taskbar!), you will be in your Linux-area home directory, also abbreviated ~. cd over to where your stuff is actually located with:
cd /mnt/c/<Username>/Documents
Replace c with d or whatever the name of your primary drive is. The Linux subsystem creates a full Linux file tree (with a root and /usr/bin just like on the Zoo). But unfortunately, this “Linux area” is not accessible via the Windows file explorer. So you’ll want to keep your files where you normally store them in My Documents, for instance. Then when you launch the Ubuntu shell (NOT PowerShell or cmd.exe!), move to that location by cd-ing to the “mounted” or mnt directory which is the way that the Linux area makes sense of and can access the Windows drives.
You can now follow along with any of the scp or ssh commands no problem!
Update to Windows 10 now! These earlier versions aren't supported anymore and will just cause trouble for you.
The machines are located on the 3rd floor of Arthur K Watson Hall (AKW) and in HLH 17 Room 111. Keep in mind that you can always walk up to them and log in using your NetID and password!
The Zoo is a cluster of computers running the Linux operating system and sharing a common filesystem. Your userspace exists at /home/accts/<NetID>. This directory (in my case /home/accts/swk2) is called the home directory and it has a shortcut or alias which is the tilde character, ~. This is where you will find the cs223 directory that was created when you registered. Putting these two facts together, we can see that ~/cs223 is a logical place to keep your homework files.
An important basic command is: pwd (short for “print working directory”). Enter this command on the terminal and press Enter. You should see the absolute path of your current location in the filesystem. “Absolute” means that the path starts at the root (represented by /) and shows all the parent folders of your current folder. A “relative” path is defined by reference to the current working directory.
If you are using the terminal and get lost, just use pwd to find your place.
If your terminal is cluttered with a bunch of unneeded text, type clear to refresh it. Practice by invoking pwd multiple times and then clear-ing the display. This is a typical workflow: accumulate the output from several commands and then refresh the screen.
Now try cd. If you enter cd without any arguments, you will be returned to your home folder. This is a useful default, but the true power of the command line interface (CLI) is the ability to specify arguments and options (“flags”) for commands. The typical syntax for a command is: <program> <flags> <argument>. You type these elements, each separated by a single whitespace, and then press Enter.
The cd command takes an argument that is the path to a directory. Thus you already know where the command cd ~ will bring you. Hint: it’s the same place as cd invoked with no arguments (but why?). Now try this:
cd /c/cs223/bin
To check that you’re in the right place, use pwd. See what we did? We gave an absolute path to cd as an argument and then we moved to that path within the file system.
But moving around is useless without the ability to see the stuff located in our CWD. Use the ls command to “list” the contents of the current working directory. If you’ve been following along and have moved to /c/cs223/bin, you should see a bunch of scripts related to submitting and checking your homework files. ls and cd are to the CLI what the trackpad and cursor are to your laptop. Practice using them!
ls brings up two new ideas. First, it is often convenient to invoke ls with some additional features, or “flags”. Try running ls -al. This should display for you the contents of the current directory, but listed in one column with extra details. Note that ls can take an argument (the path to some other directory), but usually you will want to call it without an argument so that it defaults to show the contents of the current directory. The -al part of ls -al is not an argument, but rather two flags or options, each denoted by a lowercase letter (a for “show all” and l for “long format”). By convention, a hyphen precedes the flags, which are not ordered. That is to say, -al is the same as -la.
Suppose you are working in ~/cs223 but want to remember the commands available in the ZSS. Putting what we know together, we could type
ls -la /c/cs223/bin
and get a quick printout of the various submit scripts without having to leave our working directory in user-space.
The second idea flows out of what you see in the top three lines when you invoke ls -al. Here’s an example:
total 32
drwxrwxr-x 6 swk2 swk2 4096 Jan 17 10:50 .
drwx------ 55 swk2 swk2 4096 Jan 10 16:43 ..You can ignore the first line, which has to do with the memory blocks used by the current directory. The file named . is a directory, as can be seen from the initial d in drwxrwxr-x. Don’t worry about this too much. In Linux everything is a file, so directories are just a special case of files. More importantly, the . is a special shortcut just like the tilde ~ is. The . is a symbolic link to the CWD. From this, we can reason that cd . will “move” the shell into the current directory, or, right back where we started. This doesn’t seem helpful at all! But we will see an application later on.
The two periods .. are a shortcut to the parent directory, or the folder “one level up” from where we currently are located. If you keep invoking cd .., you will eventually end up where? At the root of course! If cd .. gives you a way to move upward, the typical way of moving “downward” is to ls the contents of the CWD. Are there any subfolders? If so, then you can move “down” into them by running cd <name_of_folder>.
Now is a decent time to discuss two vital features of your bash shell. Using the terminal without them is like trying to speak a language without the verb “to be.”
Hit the up-arrow key to access prior commands, which will be displayed next to the prompt, ready for you to run them. This is handy for recalling long commands that would be a pain to re-type! The commands are stored in “stack” order such that the immediately previous command is the first accessed via up-arrow. To see how many of your commands bash will remember, run
echo $HISTSIZE
Bash will autocomplete resource names once it has enough characters to disambiguate them. Huh? Let’s say we’re in ~. We want to cd into the cs223 folder. Type cd cs2 and then hit TAB. What happens? Play around and you should be able to figure it out. You can also use tab completion to check for the existence of files or folders. Type /c/cs223/bin/un and then press TAB twice in a row. Bash will list all the files in /c/cs223/bin that begin with the substring “un”. We can use this fact to check that the file we want to run as a program or specify as an argument actually exists in the location we expect it. If tab completion doesn’t find anything, we may be looking in the wrong place.
At least 50% of the errors that students run into with the ZSS arise from trying to run executables such as /c/cs223/bin/check using the wrong path. Do NOT rely on cut-and-paste! Instead, always be mindful of your current location within the filesystem and use tab completion and ls -la to ensure that the folder or file you want to work with actually exists at the location you are saying it does.
The ONLY way to submit is using a Zoo terminal. In all likelihood, your error is that you are referring to a file that does not exist in the location you have specified.
Using relative or absolute filepaths, it’s possible to submit your homework from a location other than the directory in which those files reside. But it is not a good idea for beginners. So step one is to cd over to the location of your homework file.
Once you’re in the right location, you need to understand the difference between system-wide programs and user programs. /c/cs223/bin/submit is a user program. It is a piece of code written by a professor and then compiled into a binary that can then do stuff on your files and the Zoo filesystem. You might ask why we can’t just type submit, much in the way we type man to invoke the manual program. man and ls and cat and ssh are all programs that ship with Linux or can be downloaded as system packages. They live in /usr/bin and are in some senses privileged. When you run a command, the terminal automatically looks first in /usr/bin to see if there’s a match for the name of program you are trying to invoke. System-wide programs like these can conflict with user programs by having the same name.
Suppose you write a script and call it man. Bash will run the system-wide version every time, unless you run the script not with man but with the path to where your “user” version exists. This is where the . shortcut becomes handy. Say my version of man is located in ~/cs223 and that’s in fact my CWD. I can run (assuming my man is executable) the following:
./man
and the shell will know that it’s my version and not the one in /usr/bin because I have specified that the program I want is located in the current working directory (a.k.a. .).
You MUST give the absolute (or correct relative) filepath to /c/cs223/bin/submit (or /c/cs223/bin/protect, etc.) WHENEVER you invoke it. Use ls or tab completion to make sure you have specified the path correctly. The intuition is that Yale’s Zoo Submit System is specific to the Zoo cluster and is thus a resource only available to you and the rest of the CS department and not the general Linux community. So we need to tell the shell exactly where this program exists. Furthermore, we can’t misspell anything or forget whitespace between arguments since the CLI is unforgiving in a way that a Google search, say, is not.
You must use this level of care and precision when referring to all files. So please go slowly. GO SLOWLY. Don’t copy-and-paste.
Rant over! Here’s how we would submit a file (hello.c) and a log for grading if our CWD is the folder in which the file exists. (Note that submit can be invoked to copy multiple files over to your submission directory at once)
/c/cs223/bin/submit <asno> ./hello.c ./log
From above, we note that the program takes at least two arguments (the order of arguments DOES matter, unlike with flags). The first is the assignment number, and all subsequent are accurate paths to whichever files you'd like to submit. In this case, the homework file and our log exist in the CWD so we could also simply specify
/c/cs223/bin/submit <asno> hello.c log
You should see a message saying that your submissions were “copied” if you have done everything right and “not copied” if something went wrong. If you do not see any output, assume that the command failed. The syntax is exactly the same for the other submit scripts, which you can use to unsubmit your work or protect it or verify that you have indeed submitted file(s).
This guide is NOT the manual for the ZSS; rather, it attempts to demystify why the submit programs need to be invoked in the way they do. Again, you will learn so much more (and be able to check your work) if you commit to not copying-and-pasting the commands from the existing guide.
You need to learn how to send files to the Zoo from a remote machine (e.g. your laptop) over the internet. Remember that your code must first make it to your Zoo account before submission! /c/cs223/bin/submit only exists on the Zoo cluster, and to refer to it on your own computer makes no sense.
Good ways of transferring files to the Zoo
ssh/scp (the best and easiest way, reinforces CLI skills)ssh/git (only if you know/like Git and are familiar with ssh keys)You may have tried to use some of the shell commands like ls and cd on your own computer. If you have a Mac, the program Terminal.app is accessible via “Utilities” within “Applications.” Once again, I recommend pinning the terminal to the dock for easy access. The Mac terminal works great because the Mac OS, like Linux, is based on the Unix operating system. So it follows all the same conventions and will have many of the same system-wide programs.
If you are running Linux you probably don’t need to be reading this quick-start guide (!) and you will of course have a Unix-style terminal built in.
If you are running Windows, then the situation is somewhat murkier. The Windows equivalent to terminal is called PowerShell. Microsoft has promised to support ssh in future builds, but right now, the only workaround is to use the Linux Subsystem for Windows. Since this is rather complicated, please write to the TF regarding your Windows setup or come to help hours. The many slight and annoying differences between Windows and *nix OS’s are not worth delving into here.
OK, so from here on I am assuming that you are using a *nix-based CLI. Now we can discuss what ssh or “secure shell” does. Pause for a moment and type man ssh in your terminal. It’s a bit intimidating, but it’s good practice. To scroll down in a man page, use the j key and to scroll up use k. To exit, hit q for “quit.”
If man ssh or which ssh doesn’t display anything, then you don’t have the ssh utility on your machine and you should also email me or come to help hours.
ssh is the protocol for logging into the Zoo cluster remotely. You must be connected to the internet to do this. You should memorize the following “magic incantation”:
ssh <NetID>@node.zoo.cs.yale.edu
The ssh program takes an argument that is string consisting of a username “at” a particular host. For you, the username will always be your NetID and the host is ALWAYS node.zoo.cs.yale.edu. You can remember this because each entity is a superset of the previous one. The space of all educational institutions contains Yale, which in turn contains Yale’s CS department, which contains the Zoo, which is ultimately composed of different nodes/workstations named after animals.
Easy, right? After running this command, you’ll be asked to enter your NetID password. You may be asked to type “yes” or “no” to trust/add the Zoo’s ssh key to your list of known hosts. Go ahead and type “yes” or “Y” and then hit Enter. If everything works, your shell will now turn into your shell on the Zoo. From here you will be able to use the submit scripts and the Zoo’s version of gcc/make/valgrind/gdb. You can drop back into your computer’s shell by typing exit.
We now have a way of getting you into the Zoo, but we still need to get your files onto the Zoo.
You could in theory ssh into the Zoo from your computer each time you wanted to work on your code. This would mean using a text editor like Emacs or Vim and doing everything from the command line since it’s not possible to use DrRacket (or any other graphical program) when ssh-ed in to the Zoo. A better workflow is to install the latest version of DrRacket on your computer and work locally (saving and backing up locally as you go). Then, when you have finished or reached a milestone in the assignment, you can transfer the file to the Zoo and then ssh into the Zoo and submit that file.
The way to send a file from one host to another host securely is with scp or “secure copy”. scp is rather brittle when it comes to tab-completed file paths, so I recommend always following these steps. I will be using the file rm_rf_slash.c as the example filename.
cd into the directory where rm_rf_slash.c residesscp rm_rf_slash.c and NOT ./rm_rf_slash.c or /abs/path/to/rm_rf_slash.c (scp may incorrectly try to force the name of the file to be ./rm_rf_slash.c in the target folder since Linux is very permissive re: what filenames are allowed)<NetID>@node.zoo.cs.yale.edu:~/cs223Enter; if all goes well, you’ll be prompted for a password and see this:swk2@node.zoo.cs.yale.edu's password:
rm_rf_slash.c 100% 20KB 19.5KB/s 00:00N.B. that Linux will hide your typing when you enter a password. If you’ve made a typo, you can still use Backspace. If you don’t see the statistics about the transfer size and rate, the transfer has not succeeded and you will need to try again. The full command is:
scp rm_rf_slash.c swk2@node.zoo.cs.yale.edu:~/cs223/
note the subtle differences between this and ssh. With scp you ALSO need to specify the target directory on the host. This is the part after the colon in user@host:target (no spaces). So in my example, the target is ~/cs223/, which is the cs223 folder in my home directory. Only send files to your user-space on the Zoo! That is, your home folder ~ and its sub-folders.
As soon as you transfer files, you should ssh into the Zoo and check that they have arrived as intended.
Research the commands touch, mkdir, rm, and mv. These are essential. Often you will want to move a file from one directory to another without leaving the CLI. mv can do this as well as rename a file or folder.
mv <file> /path/to/new/folder mv <old_file_name> <new_file_name>
Be careful with rm, particularly when called with the flags for “recursive” and/or “force” (-rf). In what situations are these flags necessary? In what situations might they be very dangerous? Don’t use them without finding out!
To practice with mv and rm, you can create an empty file with the touch command. To see how touch should be invoked, use man! You can easily delete the file with rm. Here are the terminal commands you should now review:
pwd
ls
cd
man
mv
mkdir
cp
rm
ssh
scp
touch
and for good measure, two new ones:
less cat
It's never a bad time to learn a CLI editor. I recommend Vim. But this is a matter of eternal debate :) The important thing is to test a few out. Vim should come preinstalled in the /usr/bin of your Mac and can thus be called with vim from the terminal. The Zoo machines will of course have many editors available (vim, emacs, nano, etc.). A quick note on Vim: the first time you open a file with this editor you will realize you have no idea how to close the program and freak out. Just remember that ESCAPE:q is your friend.
RCS, or Revision Control System, is a protocol that allows multiple users to develop and maintain code simultaneously. Conveniently, it enables users to restore files to their prior states, the main motivation for its use in this class.
Each submission directory contains an RCS subdirectory in which several files reside. These files track changes made to files stored directly inside the submission directory.
For example, let's say we want to include hello_world.c as part of our hw94 submission. Right now, the relevant submission directory (/c/cs223/SUBMIT/brunstad.rob.crb84) contains only the RCS subdirectory:
[crb84@turtle cs223]$ /c/cs223/bin/check 94 total 4 drwxrws--- 2 crb84 cs223ta 4096 Dec 14 18:53 RCSNow, let's run
/c/cs223/bin/submit 94 hello_world.c and check to ensure that the submission went through successfully.
[crb84@turtle cs223]$ /c/cs223/bin/submit 94 hello_world.c Copying hello_world.c [crb84@turtle cs223]$ /c/cs223/bin/check 94 total 8 -rw-r----- 1 crb84 cs223ta 112 Dec 14 18:54 hello_world.c drwxrws--- 2 crb84 cs223ta 4096 Dec 14 18:54 RCSSure enough, we can see that
hello_world.c has been copied successfully. If we look closely, we can see that something else has happened, too, as evidenced by a change in the timestamp associated with the RCS directory. Although you don't have the ability to do so, I've navigated to my RCS subdirectory. We can see that a new file hello_world.c,v has been created:
[crb84@turtle RCS]$ ls hello_world.c,vNow, let's change
hello_world.c a bit and submit again:
[crb84@turtle cs223]$ /c/cs223/bin/submit 94 hello_world.c Copying hello_world.c [crb84@turtle cs223]$ /c/cs223/bin/check 94 total 8 -rw-r----- 1 crb84 cs223ta 112 Dec 14 19:25 hello_world.c drwxrws--- 2 crb84 cs223ta 4096 Dec 14 19:25 RCSWe've overwritten the version of
hello_world.c that was sitting there before, and RCS/hello_word.c,v has been updated, too, with all the information necessary for us to retrieve its prior state. Let's assume our recent changes were misguided, and we'd like to retrieve the older version of the file. We can see that the timestamp associated with our most recent submission is Dec 14 19:25, so let's use the retrieve command in concert with the -d flag specifying a minute before Dec 14 19:25 to get the penultimate version. First, however, because the retrieve command requires that there exists no file with the same name as that being retrieved, let's change the name of our older submission:
mv hello_world.c hello_world_19:25.cNow, we're ready to run the
retrieve command.
[crb84@turtle cs223]$ /c/cs223/bin/retrieve 94 -d"2020/12/14 19:24" hello_world.c Copying hello_world.c /home/classes/cs223/SUBMIT/94/brunstad.rob.crb84/RCS/hello_world.c,v --> hello_world.c revision 1.1 doneWe can see that version 1.1 was copied over to our CWD. With the
diff command, we can confirm that we have, in fact, retrieved the older version of our hello_world.c:
[crb84@turtle cs223]$ diff hello_world.c hello_world_19\:25.c 2c2 < // New version! --- > // Old versionIf we wish to
revert our submitted hello_world.c file, we can do so with the revert command, specifying the version to which we'd like to return.
[crb84@turtle cs223]$ /c/cs223/bin/revert 94 -r1.1 hello_world.c /home/classes/cs223/SUBMIT/94/brunstad.rob.crb84/RCS/hello_world.c,v --> /home/classes/cs223/SUBMIT/94/brunstad.rob.crb84/hello_world.c revision 1.1 writable /home/classes/cs223/SUBMIT/94/brunstad.rob.crb84/hello_world.c exists; remove it? [ny](n): y doneNote that we had to type
y followed by Enter to perform the reversion. Finally, we should check that everything went according to plan.
[crb84@turtle cs223]$ /c/cs223/bin/check 94 total 8 -r--r----- 1 crb84 cs223ta 112 Dec 14 18:54 hello_world.c drwxrws--- 2 crb84 cs223ta 4096 Dec 14 19:25 RCSHere, we see that the old timestamp has been restored.
testit program?Once the public tests are made available for an assignment, you can test your code against them in two different contexts. If you've already submitted your homework, you can test the exact files that you submitted (which reside in your submission directory) with the following:
/c/cs223/bin/testit <asno> <executable_name>
Note that the name of each assignment's executable will be given in the spec. For instance, for the zeroth assignment you can run the following:
/c/cs223/bin/testit 0 Hello
Additionally, you can test the files that reside in your CWD by running the following:
/c/cs223/hw<asno>/Tests/<executable_name>
Please keep in mind that if you invoke the above command you're testing the version of your homework that's present in your CWD. If you make a change to those files after submitting and then run the above positive results, the submitted versions of your homework files are outdated and you will need to submit your homework again.
You can also run individual tests on the files residing in your CWD with the following command:
/c/cs223/hw<asno>/Tests/t<test_number>
To get a complete list of all the <test_number>s available to you, run ls -al /c/cs223/hw<asno>/Tests/. Note that if a given test is NOT an executable (that is, it does not have a permissions signature ending in x––more info here), you must use the following syntax to throw it against your code:
./<executable_name> < /c/cs223/hw<asno>/Tests/t<test_number>
In this case, you might want to generate <executable_name> by invoking the third command given in this section.
This class's submit system has RCS (revision control system) enabled, so feel free to submit your work often as you go! For example, if you'd like to get back the version of the file rm_rf_slash.c you submitted sometime just before September 5th, 2020 at 4 pm, you could invoke the retrieve command as follows:
/c/cs223/bin/retrieve <asno> -d"2020/09/05 16:00" rm_rf_slash.c
Note that, in order for this command to be executed correctly, you need to make sure that there does not exist some file named rm_rf_slash.c in your CWD.
Your resubmissions are automatically tagged with a version number, starting from 1.1 and growing in increments of 0.1. You can also retrieve a particular version of your code using the system-assigned tags:
/c/cs223/bin/retrieve <asno> -n1.2 rm_rf_slash.c
It’s always a good idea to test your code with different inputs (and types of inputs) before submitting. Although the bulk of your grade will depend on whether your program produces the correct results when the input meets the specification, your program will be tested on inputs that do not follow the specification. For example, if the input is supposed to contain only integers, it will also be tested on inputs containing floats and strings. Unless otherwise specified, the only requirement in such cases is that your program does not crash or hang and whatever output your program produces will be ignored.
Before anything else, check that you have submitted a file and that it is the correct file. Use /c/cs223/bin/check for the existence of a submission.
Suppose you submitted rm_rf_slash.c at some point but would like to ensure that it's the most up-to-date version of the file. Instead of deleting and resubmitting, you can invoke the retrieve command:
/c/cs201/bin/retrieve <asno> rm_rf_slash.c
In order for this command to be executed correctly, you need to make sure that there does not exist some file named rm_rf_slash.c in your CWD. Let's assume there is, in fact, another version of that file, so let's rename it:
mv rm_rf_slash.c rm_rf_slash_old.c
And then, after running the retrieve command, test to see if there are any differences between the two files:
diff rm_rf_slash.c rm_rf_slash_old.c
If the diff command does not produce any output, you can be sure that the two files are identical. If there are differences, they should appear on your terminal window with line numbers and other helpful details.
General best practices:
<assignment_3_makefile>, for instance, with /c/cs223/bin/submit 2 <assignment_3_makefile> and Homework 2 has not been graded yet, <assignment_3_makefile> will overwrite <assignment_2_makefile> if said file is present. This is a very serious issue, as it's almost certain that your submission for the second assignment will fail under make. In this case, please see the section below./c/cs223/bin/unsubmit/c/cs223/check to make sure that your submitted work folder is now emptyUse the protect command. Just do it. It'll save you a lot of headache in the event that you accidentally submit code to the wrong submission directory. If, for example, you submit your makefile for Exercise 4 to the submission directory for Exercise 3, your prior makefile will be overwritten without any fanfare (as RCS is enabled). Then, when we grade Exercise 4, you will likely fail all tests. Additionally, if we have not yet graded Exercise 3, you will likely fail all of those tests, as well.
Using protect prevents the overwrite and alerts you to the fact that you previously protected the file that you're attempting to overwrite:
[crb84@macaw cs223]$ /c/cs223/bin/submit 4 codes.code
Copying codes.code
[crb84@macaw cs223]$ /c/cs223/bin/protect 4 codes.code
Protecting codes.code
[crb84@macaw cs223]$ /c/cs223/bin/submit 4 codes.code
submit.pl: Homework #4: codes.code is protected
You can always unprotect your submissions using the exact same syntax (but with /c/cs223/bin/unprotect as the executable).
If you have indeed accidentally overwritten some file from a previous homework that has yet to be graded, do not panic, but also do not do nothing. It is your responsibility to ensure that the contents of your submission folders accurately represent what you wish to be graded.
Let's assume we overwrote file.c in /c/cs223/SUBMIT/4. First, we must determine which version of file.c existed in /c/cs223/SUBMIT/4 when it was in its most appropriate state for that assignment. In most cases, we can assume it was the version we were hoping to submit at the time of its due date, so let's start there. Let's also assume that this assignment was due on October 2, 10:00 pm EST. We can use the retrieve command to get information about the file's version history:
[crb84@macaw cs223]$ /c/cs223/bin/retrieve 4 -d"2020/10/02 22:00" file.c
Copying file.c
/home/classes/cs223/SUBMIT/4/brunstad.rob.crb84/RCS/file.c,v --> file.c
revision 1.1
done
From what's printed to stdout we can deduce that version 1.1 existed in the submit directory at the time the assignment was due. (Note, however, that this command will fail if you have another copy/version of file.c in your CWD. If this is the case, rename the file.c in your CWD or simply move to another location in the system file tree.)
Now, we can revert file.c to the state in which we'd like it to be graded with the following command:
/c/cs223/bin/revert 4 -r1.1 file.c
If you have submitted files to a particular submission directory that do not belong in that submission directory––without performing an overwrite, please note that their timestamps will likely count against you, possibly triggering a lateness penalty.
Please remove these files with the unsubmit command:
/c/cs223/bin/unsubmit <asno> <filename>
Once we've cleaned up the submission directory for a particular assignment, we should see only the files we want to be graded after invoking the check command (/c/cs223/bin/check <asno>). Note that the timestamp associated with the RCS directory will not induce a lateness penalty.