COMP 2103 Programming 3 Part 1 Jim Diamond CAR 409 Jodrey School - - PowerPoint PPT Presentation

COMP 2103 — Programming 3 Part 1

Jim Diamond CAR 409 Jodrey School of Computer Science Acadia University

1

Course Objectives

We shall cover

• the C programming language, emphasizing

– procedural programming techniques – correctness – robustness – portability

• the GNU/Linux operating system, emphasizing

– tools and utilities for efficient and effective programming – the C programming interface with the Linux operating system

• the use of the shell as

– a command interpreter – a scripting language

• debugging
• an introduction to modifying other people’s “mystery code”

(if time permits)

Jim Diamond, Jodrey School of Computer Science, Acadia University

2

General Information

• Read course outline at

http://cs.acadiau.ca/~jdiamond/comp2103/comp2103.pdf

– this document refers to other documents you must read

• Getting help

– ask questions in class! – my office hours (CAR 409): MWF 8:30–9:30, other times TBA and/or by appointment – if you need to see me at other times, e-mail or phone me and we can set up a meeting time – TA contact hours, if desired by the class, shall be announced RSN – the lab supervisor (Kelvin in CAR 208) is also be available for help To pretend to know when you do not know is a disease. To know that you do not know is the best. — Lao Tzu

Jim Diamond, Jodrey School of Computer Science, Acadia University

3

Reference Materials

• C for Java programmers by Dr. Tomasz M¨

uldner (2000) – designed for people who already know Java – includes “programming idioms” and related topics

• Programming in C by Stephen G. Kochan (4th edition, 2014)

– this has more detailed explanations of C constructs

• Computer Science: A Structured Programming Approach Using C by

Behrouz A. Forouzan and Richard F. Gilberg (3rd edition, 2005/06)

• Shell programming references

– Unix Shells by Example by Ellie Quigley (4th edition, 2004) –

Bash-Prog-Intro-HOWTO (free download)

–

Advanced Bash-Scripting Guide (free download)

– although some “internet shell experts” pooh-pooh this document

Jim Diamond, Jodrey School of Computer Science, Acadia University

4

Next Things To Do

• For next class, read

http://staff.washington.edu/jon/pubs/safety-critical.html

– think about it, don’t just skim it – be prepared to discuss this and/or answer questions on a quiz

• Self-evaluation quiz: go to Acorn, COMP 2103

– you have six minutes for the 11 short questions

Jim Diamond, Jodrey School of Computer Science, Acadia University

5

Course Environment

• All course work shall be done using Linux

– have Linux on your laptop by Wednesday!

• The course outline points to some tutorials to get you started

– start reading them today! (This means you!)

• Put “learn about regular expressions” on your to-do list

– we shall briefly cover these later in the course, but an in-depth knowledge will serve you well for as long as you do computing

• I will not use Acorn for assignments

– read your Acadia e-mail – and look in

http://cs.acadiau.ca/~jdiamond/comp2103/assignments/

Jim Diamond, Jodrey School of Computer Science, Acadia University

6

Assignment Submission: 1

• Assignments are submitted via

https://cs.acadiau.ca/~jdiamond/course2016/student

– read the docs (at my web site) which explains how to submit a problem solution using Course2016 – before the deadline, you can re-submit problem solutions as many times as you like: submit early, submit often – and then check your submission! – after the deadline, you may only submit a solution to a given problem if you have not already submitted – so after the deadline make sure you do it correctly on the first try!

Jim Diamond, Jodrey School of Computer Science, Acadia University

7

Assignment Submission: 2

• Course2016 automatically applies an adjustment factor for assignments

submitted early or late; the current scheme is

Hours Early

≥ 72 ≥ 48 ≥ 24 ≥ 0 ≥ −24 < −24

Adjustment Factor

1.20 1.10 1.05 1.00 0.67 0.00

The final grade for a particular solution is calculated by multiplying the marker’s grade by the above adjustment factor

• The Course2016 system should be set up and ready to go later today

– just in case you have problems figuring out how to submit your assignment, do not wait until the last minute – that is, try logging in later today and looking at the system

Jim Diamond, Jodrey School of Computer Science, Acadia University

8

Useful Tools To Know (Right Away)

• We shall use the bash shell (command interpreter) to enter commands

and to write programs – we shall see how a command-line interface can be a very powerful tool compared to a GUI – there are other shells available; I prefer zsh for interactive usage,

• ther people like ksh, tcsh, or others yet

– more on this topic in a couple of slides . . .

• Web browsers:

–

firefox is (probably) already installed on your system

–

• thers (opera, chromium/chrome, epiphany, . . . ) are available for

download; go wild

• Any of the commands “acroread file.pdf”, “xpdf file.pdf”,

“okular file.pdf” and “evince file.pdf” will display a PDF file on your screen, if you have those programs installed –

• r double-click in your file browser and see what happens

Jim Diamond, Jodrey School of Computer Science, Acadia University

9

A Few Useful Commands

• man <something> — read the manual page for <something>

– e.g.,

man man

gives you the “man” page for the man program

• apropos — discover “man” pages dealing with a word of interest

– e.g.,

apropos file

shows you a one-line summary of many man pages, each of which deal with files

• ls — list files

– there are many, many options; read

man ls

• grep — look for a string (or a regular expression!) in one or more files

–

• r in the output of another program!
• cp, mv and rm — copy, move (rename) and remove (delete) files
• mkdir — make a new directory
• exit — terminate the shell program
• more, less and most — programs for browsing text files or textual
• utput of other programs

Jim Diamond, Jodrey School of Computer Science, Acadia University

10

RTFM: Read The (*cough*) Fine Manual

Jim Diamond, Jodrey School of Computer Science, Acadia University

11

Real (Non-toy) Editors

• Most (80%? 90%? 95%?) of your (programming) time spent at your

computer will be entering and editing program or data files

• A poor editor will slow you down immensely, compared to a powerful

editor – learning a powerful editor will pay for itself many times over

• Two good choices:

–

vim (“vi improved”): vi is the standard Unix text editor, available

• n most (all?) Unix systems

– clones (like vim) available for most OS’s (not just Unixes) – two modes: input and command –

emacs: the all-singing, all-dancing editor

– it can do effectively anything (including emulating vi) – extensively customizable – you can extend the editor (i.e., add functions and capabilities you want) by writing “emacs lisp” functions – there are various tutorials for both editors: learn (at least) one!!

Jim Diamond, Jodrey School of Computer Science, Acadia University

12

GUIs vs. Command-Line

Master Foo Discourses on the Graphical User Interface One evening, Master Foo and Nubi attended a gathering of programmers who had met to learn from each other. One of the programmers asked Nubi to what school he and his master belonged. Upon being told they were followers of the Great Way of Unix, the programmer grew scornful. “The command-line tools of Unix are crude and backward”, he scoffed. “Modern, properly designed operating systems do everything through a graphical user interface.” Master Foo said nothing, but pointed at the moon. A nearby dog began to bark at the master’s hand. “I don’t understand you!” said the programmer. Master Foo remained silent, and pointed at an image of the Buddha. Then he pointed at a window. “What are you trying to tell me?” asked the programmer.

Jim Diamond, Jodrey School of Computer Science, Acadia University

13

GUIs vs. Command-Line (continued)

Master Foo pointed at the programmer’s head. Then he pointed at a rock. “Why can’t you make yourself clear?” demanded the programmer. Master Foo frowned thoughtfully, tapped the programmer twice on the nose, and dropped him in a nearby trashcan. As the programmer was attempting to extricate himself from the garbage, the dog wandered over and piddled on him. At that moment, the programmer achieved enlightenment. (http://catb.org/esr/writings/taoup/html/gui-programmer.html)

Jim Diamond, Jodrey School of Computer Science, Acadia University

14

Unix/Linux Command Interpreters (Shells)

• There are many different shells you can use in Unix or Linux

–

sh, csh, ksh, tcsh, bash, ash, zsh, fish, dash, . . .

– the “original” Unix shell was known as sh – it was very minimal and relatively feature-less – later someone added many features (this was a Good Thing), changed some things and tried to make the shell more “C-like”. . . he called this new shell csh

• Other people got into the “make my own shell” game

–

tcsh is an extension of csh

–

bash and ksh are (major) extensions of sh

–

zsh is an extension of everything

– (most?) modern versions of sh are no longer “feature-less”

• There are many similarities between shells, but many differences as well

– annoyingly, there are subtle incompatibilities between (the common features of) sh, bash, ksh and zsh

• We will look at bash (the shell you use by default in most Linux

distributions) in this course

(power users: try zsh)

Jim Diamond, Jodrey School of Computer Science, Acadia University

15

Ways to Use the Shell

• Shells gives you two usage possibilities:

– you can use them interactively – you can also write programs (known as “shell scripts”) – the shell is said to interpret the script

• It is widely held that (modern versions of) sh are the best shells for

writing shell scripts (i.e., don’t use csh or tcsh for shell scripts) – while many of the extensions of bash are to promote effective interactive use, some extensions are useful in programming – since every Unix system has sh, but not necessarily bash, using

bash-only features can make your script non-portable

• There does not seem to be any such consensus on which shell is best

for interactive use – but this is a good topic if you want to start an argument!

Jim Diamond, Jodrey School of Computer Science, Acadia University

16

Interactive Shell Usage

• You can execute multiple commands on one physical line by separating

the commands with ‘;’s:

gcc a_program.c -o myprog ; myprog arg1 arg2

• In a situation like this you might not want to run myprog if the compile

did not work; instead do

gcc a_program.c -o myprog && myprog arg1 arg2

– the “&&” tells the shell to run the second command (myprog) if and

• nly if the first command (gcc) returned an exit status (q.v.) of 0

(i.e., the “success” exit status) – we’ll see how to return success or failure in C (soon)

• Alternatively, you might want to run a second command if and only if

the first one returns a non-zero (failure) status:

gcc a_program.c -o myprog || echo Oh no... \ The compile failed!

– note: the “\” at the end of the line means that the current line is continued on the next line

Jim Diamond, Jodrey School of Computer Science, Acadia University

17

Interactive Shells vs. Non-interactive Shells

• and. . . Login Shells vs. Non-login Shells
• Most shells (bash, sh, csh, tcsh, zsh, . . . ) behave differently if they are

“interactive” than if they are “non-interactive” – interactive: a shell to which you are typing commands – non-interactive: one that is executing a script

• A similar comment for “login” shells vs. “non-login” shells applies
• Look at output of “ps fax” command:

– a “login” shell has a “-” preceding the program name (e.g., -tcsh,

• bin/bash, . . . )

– a non-login shell has no “-”

• Interactive shells (in general) read different initialization files on start-up

than non-interactive shells (similar for “login” vs. “non-login”)

• Why? You might want to do certain things when starting a new

command shell (check e-mail, print out your calendar, . . . ) that you don’t want done whenever a shell script is run

Jim Diamond, Jodrey School of Computer Science, Acadia University

18

Shell Init Files

• Shell init files are very shell specific!

– e.g., the original sh shell always read $HOME/.profile – (note that by default, the ls command does NOT list files whose names start with “.”; try “ls -a” or “ls -A”)

• Example: tcsh

– first it reads /etc/csh.cshrc (if it exists) – then iff it is a “login” shell, it reads /etc/csh.login (if it exists) – then it reads ~/.tcshrc (if it exists) – if ~/.tcshrc does not exist, it tries ~/.cshrc – then iff it is a “login” shell, it reads ~/.login (if it exists)

• Things that every shell wants (e.g., the definition of PATH (q.v.)) go in

~/.(t)cshrc

• In ~/.login put things like

– terminal initialization, checking for e-mail – setting variables (q.v.) and aliases (q.v.) which are of interest only to login shells

Jim Diamond, Jodrey School of Computer Science, Acadia University

19

Word of the Day

Here is one definition of “Byzantine” A term describing any system that has so many labyrinthine internal interconnections that it would be impossible to simplify by separation into loosely coupled or linked components. The city of Byzantium, later renamed Constantinople and then Istanbul, and the Byzantine Empire were vitiated by a bureaucratic

• verelaboration bordering on lunacy: quadruple banked agencies,

dozens or even scores of superfluous levels and officials with high flown titles unrelated to their actual function, if any. Access to the Emperor and his council was controlled by powerful and inscrutable eunuchs and by rival sports factions. — Edward Gibbon, The History of the Decline and Fall of the Roman Empire

Jim Diamond, Jodrey School of Computer Science, Acadia University

20

❇❛s❤ Init Files

• See the bash man page, or, alternatively, the definition of “Byzantine”
• The init file procedure is somewhat complex, to provide some

compatibility with sh

• Also bash (seems to) differentiate both between

– interactive and non-interactive shells, and – login and non-login shells

• Depending on these things, bash will read some subset of

–

/etc/bash.bashrc

–

/etc/profile

–

~/.bash_profile

–

~/.bash_login

–

~/.profile

–

~/.bashrc

• Read the output of man bash for the details

Jim Diamond, Jodrey School of Computer Science, Acadia University

21

③s❤ Init Files

• The set of init files which zsh reads when starting can be described by

the following sequence – note that, by default, $ZDOTDIR is your home directory – if any of the following files don’t exist, zsh happily carries on anyway† (1) read /etc/zshenv (2) read $ZDOTDIR/.zshenv (3) if login shell, (i) read /etc/zprofile (ii) read $ZDOTDIR/.zprofile (4) if interactive, (i) read /etc/zshrc (ii)

$ZDOTDIR/.zshrc

(5) if login shell, (i) read /etc/zlogin (ii) read $ZDOTDIR/.zlogin

† Except for the case where it starts up, sees no zsh init files at all in your

home directory, and optionally guides you through a configuration process.

Jim Diamond, Jodrey School of Computer Science, Acadia University

22

What the Shell Does When You Give it a Command

• When you type a command to the shell, either

– it uses “built-in” functionality – e.g., set a variable, use echo, . . . , or – it attempts to locate and execute a corresponding program

• To execute another program, it

– either tries the specific file if you gave an absolute pathname (i.e., a pathname starting with a “/”) –

• r looks through all the directories in your PATH (q.v.) until it finds

a file by that name†

• If it finds a file matching what you typed and the file is executable by

you, it tries to execute it, otherwise it complains

• If you have to type “./a2p1” that is because “.” is not in your PATH

– putting “.” anywhere in your PATH is a potential security issue – having it at the end of your PATH is reasonably safe, especially on your own computer

† (Not the whole truth, but for now this will have to do)

Jim Diamond, Jodrey School of Computer Science, Acadia University

23

Some Very Useful Shell Features

• I/O redirection:

– many programs are designed to read from “standard input” (“stdin”) and write to “standard output” (“stdout”) –

• BUT. . . “diagnostic” or “error” output should (must) be send

to “standard error” (“stderr”) – can redirect program output (stdout) to a file:

date > the-time

– can obtain program input (stdin) from a file:

myprog < infile

– can redirect stderr too:

progname 2> whinage

– append, rather than create/overwrite, as follows:

date >> times

• Pipelines:

– can feed one program’s output into another program – i.e., one program’s stdout becomes another program’s stdin – e.g.,

date | sed "s/ .*//"

– in this case, the standard output of date is fed into sed

• Programs do not know that their input or output has been redirected or

piped

(Not the whole truth, but for now this will do.)

Jim Diamond, Jodrey School of Computer Science, Acadia University

24

Shell Variables

• Like other programming languages, bash allows you to set variables

– (so does csh/tcsh, but the syntax is a bit different)

• To set the variable “my_var”, you enter (e.g.,)

my_var=12

– no spaces are allowed around the ‘=’!

• To obtain the value, precede the name of the variable with $:

echo the value of my_var is $my_var

– accessing shell variables is actually more sophisticated (see the docs), so to guarantee (*cough*) you get exactly what you want, enclose the variable name in braces:

echo the value of my_var is ${my_var}

– (EXERCISE: try “echo $my_var99” and “echo ${my_var}99”)

• Shell variables are strings (even if all the chars are digits)
• Some string functions are trivial; e.g., concatenation:

longVar=${my_var}${othervar}

– prefix, suffix, and other string functions are available

Jim Diamond, Jodrey School of Computer Science, Acadia University

25

Shell Variables: 2

• There are some shell variables that should always be available to you

when using bash; for example:

HOME

your home directory

PATH

a colon-separated list of directories that the shell searches when trying to find a command

PWD

your Present (current) Working Directory – i.e., the place you cd’ed to

not the whole truth

PS1

the prompt string printed by the shell when it wants you to type a new command

LOGNAME

the userid you are logged in as

$?

the exit/return code from the last command – each program running on Unix (or Linux) returns a so-called “exit code” when it finishes – 0 means “success”, any non-zero value means “failure” – this turns out to be very valuable when writing shell scripts, as we shall see later

Jim Diamond, Jodrey School of Computer Science, Acadia University