Accessing the UNIX system

Terminal emulators
On most UNIX servers:
The cost of running a GUI is prohibitive.
Imagine keeping track of a graphical environment,
mouse movements, multiple windows for each
user.
The overhead is enormous.

We shall therefore only be using terminal

sessions for this course.
 Terminal Emulators
There are open source packages available that can
satisfy the requirements for this course.

The suggested applications are:

putty Terminal Emulator
TeraTerm a BETTER emulator !
pscp or WinSCP Secure copy/file-transfer
These are stand-alone executables which do not
require installation.
Available from:
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
https://osdn.net/projects/ttssh2/downloads/67769/teraterm-4.95.exe
 Terminal Emulators
The up-side:
Terminal emulators are light weight and
uncomplicated.

The down side:

They do not provide a graphical editing
environment for your code.
 Putty
A pretty simple interface:
 Putty
Login:
 Terminal Session
So, what can you do once you are logged in?
Everything is done at the command line!
 Terminal Session
Listing all of your files: ls, ls lt...

Editing your code:

nano
vi
 nano shortcut keys
Key stroke (CTRL == ^) Function
^g Help
^o Write the edit buffer to disk
^x Exit nano back to the shell
^k Delete the line the cursor is on. It also
places the line in the paste buffer.
Multiple deletes get added to the paste
buffer.
^u Place the content of the paste buffer at
the current cursor position
^_ Will prompt you for a line number. Nano
will then advance to that line
^\ Search and replace
^c Display current line and column position
of the cursor
 Other useful Tools
Maybe nano and vi arent productive enough...
you can always use notepad or an IDE and then
transfer your files to the UNIX server.

Secure transfer tools:

pscp from the makers of putty (command line)
WinSCP Windows GUI drag-and-drop transfers
 pscp
Pretty simple command line:

C:> pscp filename_to_transfer username@server_name:path

e.g.

D:\COIS_3380> COIS_3380>pscp my_code.sh jacques@192.168.137.134:

jacques@192.168.137.134's password:
my_code.sh | 0 kB | 0.0 kB/s | ETA: 00:00:00 | 100%
 WinSCP
Available from:
http://winscp.net/eng/index.php
WinSCP
Submitting Assignments !!!
 Creating assignment content
For each and everyone of your assignments, you will be
required to submit:
Well documented code (example on blackboard)
Sample runs to show the proper functioning of your code. You
can use your terminal emulator to log the session. Multiple
permutations and combinations of sample data may be required
(including incorrect input).

As per the Syllabus, all submissions to Blackboard MUST be:

in the format of a ZIP file. Not a 7z, ARC or any other
archive format.
The name of the ZIP file MUST be:
LastName_FistName_Assignment_x.zip.
 ZIP
ZIP is a utility which creates a compressed
archive of a set of files.

It is STRONGLY suggested that you use a

command very similar to this to create your
assignment submissions:
zip a $HOME/beland_jacques_lab1.zip /home/jacques/lab1/*
zip filename files to be archived

Forcing the /home/username in front of the lab# directory

allows for the files from multiple students to be
extracted WITHOUT overwriting someone elses work!

Jacques Beland is my name. Please do NOT submit your

assignment using my name
Verifying that two files are identical
md5sum:
a tool which calculates a cryptographic HASH of the
contents of a file.
There are documented cases where MD5 collisions
can occur. These are not important enough to be of
concern for the purposes of this course.
e.g.:
$ md5sum unpack_logs.sh
2c3d0f071c2f3938ae0d85606aedc0e0 *unpack_logs.sh
 Logging your work
History:
The history command recalls all of the previous
commands you issued in the last interactive
sessions.
Say you are working on getting the proper syntax to
a set of commands. You can use the history
command to capture ALL of your previous
commands into a file that you could then edit
into a functional script

e.g. jacques@UBU64vm:~$ history > my_prev_commands.txt

 Logging your work
Putty:
The putty terminal application can capture the
interactive content of your session two ways:
1) Copy-Paste

(how large is the scroll back buffer?)

 Logging your work
Putty:
Session logging:
1) Turn on logging for
printable output
2) Overwrite or append?
 Logging your work
On the *NIX system, you can also use the
script command to capture your session
output.
NOTE: It creates a child process that you must
exit to close the log file properly

NOTE: Places your output in the directory you

need to ZIP up for your assignment
submission. No file transfers are required.
 Logging your work
script:

jacques@UBU64vm:~$ script lab1.log

...(do stuff all I/O logged to lab1.log)
...
jacques@UBU64vm:~$ exit
Script done, file is lab1.log
jacques@UBU64vm:~$
 Documentation
Grading of assignments will take into account how well
you document your work.

In code documentation
Proper header blocks for main()
Proper headers for each function you write
Descriptive variable names. If you pick GOOD variable
names, a knowledgeable code reviewer can read the code
fairly well and therefore requires fewer comments.
Sufficient in-code documentation to allow a casual reader
to understand whats going on for each chunk of code.
They need not understand the programming language, just
the intent of the code.
Do NOT over document your code.
 Documentation
Documenting your sample runs:
You will be asked to run your program for
some test cases.
It is expected that you include additional test
cases to show the robustness of your code.
Examples should include your testing of
invalid input. Your code should respond in an
appropriate manner.
 Whats in a documentation header?
/*======================================================================
| Monte Carlo evaluation of Pi
|
| Name: monte_Carlo_Pi_erand48.c
|
| Written by: Jacques Beland - November 2015
|
| Purpose: Calculate a value for Pi using a Monte Carlo approach.
|
| usage: ./monte_Carlo_Pi_erand48.o #random_points_to_use
| e.g. ./monte_Carlo_Pi_erand48.o 1000000
|
|
| Description of parameters:
| argv[1] - number if random number pairs to generate
|
|
| Subroutines/libraries required:
| See include statements.
| this routine uses the erand48 random number generator from the
| math library. Include the -lm option at compile time
| (gcc -o monte_Carlo_Pi_erand48.o monte_Carlo_Pi_erand48.c -lm)
|
|------------------------------------------------------------------
*/
 Documentation
You will find a document called Documenting
your code on Blackboard.

Use this document to guide your level of

documentation in your code.
 Labs
Labs will be programming assignments
Some will be MUCH longer than others.
The UNIX mantra is write small chunks of code. Write
them well so you only need to write them once.
EVERYTHING is UNIX is processed as a file (stream of
data)
Components of one lab WILL reappear in subsequent
labs (5,6 and 7 in particular). If you write these
components well, you can almost cut-and-paste them
into the other labs.
Code reuse is a GOOD thing (as long as it is good code).
 Grading of labs !!!!
All work for the labs MUST be done on the supplied
server (see following instructions!)

Assignments grading guidelines. Assuming you submit

a program that attempts to solve the given problem:
Following Instructions 10%
Documentation 30%
Does the code perform the assigned task? 50%
Programming Style 10%
 Grading of labs !!!!
Following Instructions: 10%

Did the submission follow the instructions given on the assignment

sheet?
Does the assignment submission work in the way it was described on
the assignment sheet?
Were variable components "variable" and not coded as static values?
was a ZIP file submitted to Blackboard and not a .7z, .ARC, .RAR or
other archive format?
Were the identified sample/test cases actually used?
Were cleaned log files documenting the running of the code
submitted?
Did the ZIP file submission have the proper name?
First_Last_Lab(1-6).zip
Did the ZIP submission contain the proper directory structure?
Were the original copies of the source/binary kept on the server in
the user's directory to facilitate marking/debugging:
/home/username/COIS-3380-A/Lab(1-6)/ ?
Documentation: 30%

Header for main() describing;

author
purpose
how-to-run it
explanation of command line parameters,
system libraries required...
Similar block comments should exist as headers for each function/subroutine.
Commented sections of code: For each major structure of code (IF blocks, while
loops, CASE statements), there should be some comments explaining what the
block of code is for.
The comments need not explain, in most cases, the algorithm behind large
complex mathematical equations in the code. The "purpose" of the program
should identify major algorithms used in the solution the code is trying to
provide. It would be sufficient to comment "Calculating the roots" and not have
pages of comments explaining how to solve for the roots of an equations using
the Runge-Kutta method
Definition of variables: When a variable is defined, there should be a comment
explaining what the variable is to be used for.
Definitions like #DEFINE or any #include (of non system routines) should be well
commented as to their purpose.
Does the program run as required? (50%)

Does the program achieve the goal of the assignment?

Does the program provide good prompts for input and
sufficient messages to be able to interpret the output?
Code robustness: Are error conditions being caught and
appropriate messages passed on to the user running the
code. (e.g. when expecting command line variables and none
are give, is there a HELP option?).
TESTING (25 points): The lab will require you to run your code
against specific targets (text input by the user, data files etc).
The lab submission MUST include, when appropriate,
examples of running the code to cover multiple input
conditions to prove that the code works on different inputs.
For the input given in the assignment, does the program
produce the expected output?
Programming style: (10)
Naming conventions:
The name of the program itself should be representative of its function.
Having a.out as the binary is NOT acceptable.
A more representative name such as FIFO_Server or Process_generations would be better names.
All variables and functions in the code have names that represent their function/purpose.
Naming variables a,b,c when they are used to contain real data, such as a username, a timestamp or a
running sum, is not acceptable.
A possible exception for the rule would be temporary loop variables which are used to walk through
elements of an array. These could be called I, J, K or the like as long as, when they are defined as INTs,
the associated comment defines their function. I would still prefer real names (e.g. row, column) but it
sometimes makes the code too wordy.
Formatting:
The code contains sufficient whitespace to make the code legible.
Block structures are indented properly to make it clear where they start/end.
For large multi-line nested structures which terminate with curly braces, it is preferable if these end-
braces are identified as to which structure they belong to ( e.g } // endcase timeoption or } // end if
sales>$20,000). This is especially true if multiple blocks terminate one after the other in the same few
lines (hence the nested part).
Definitions:
All functions must be pre-declared as prototypes. Their real code should appear after main(). The only
exception to this would be to have people include their own .c or .h files as long as the associated
#include statement is documented properly.
Variable definitions should all appear at the top of every function (including main()). Defining variables
and their types here-and-there in the code is not acceptable.
It is preferable if the definitions are blocked by type wherein all definitions of INT are grouped
together (and if possible in alphabetical order). Same for other types as well.
An example of a well documented program will be provided on Blackboard.