Software Development and Systems
Dr. Don Goelman
Table of Contents
Operating system structures; system calls; system libraries; interprocess
communication; user-interface programming environments; software utilities;
To establish an understanding of software design and development through
the use of software tools and program interoperability.
To explore various system-oriented software tools, including command
interpreters, system libraries, pattern matchers and filters.
As the title indicates, this course is intended to teach you some important concepts and
approaches to software development. This includes many different kinds of tools, filters, libraries, and system calls. Although the environment which we use in class will be a UNIX one,
and the system programming will therefore, of course, primarily be in
C, you shouldn't think of this course as bound to that system
or that language. Rather, we will be concentrating on ideas of software
development. Indeed, you will notice that one of
the excellent references below, Kernighan and Plauger's
book, presents its
programs in Pascal (its original version used a language called Ratfor).
is therefore that it's not the language that is critical, but the concepts.
Like so many aspects of this course, the longevity of C is pretty amazing.
There are typically several constituencies in our class: computer scientists,
astronomers, computer engineers and others. For this reason I'm leaving some
of the later plans somewhat flexible. The ratio between heavy-duty C
programming and Perl programming will be determined based on your
interests and my own perception of which way we should go.
The absolutely best things you could be doing for this class are experimenting,
exploring, and testing the examples discussed in class and in our primary
text. The first reason is that you will learn more by doing them and
playing with them than by
listening to me explain commands. The second is that it should actually
be fun. You don't need to have a hacker personality to do well, but it
doesn't hurt. The single biggest factor in a student's course grade is
probably the number of hours per week s/he spends on the course, outside
You might be interested in acquiring one or more of the references mentioned
below, especially if it would be useful for your
but I suggest
you look them over first (I have personal copies of
most of them; you're welcome to look them over).
If you're interested in software tools, you'll probably find the
new book by Kernighan and Pike, plus the ones by
Plauger, Leininger, and Peek, O'Reilly, Loukidis et al interesting.
Speaking of the
it will emphasize
working in groups to apply or investigate some tools and their
applications beyond what
we discuss in class. I'll be giving you the specifications around the time
of our midterm break. Even though this will be done in teams of two and
three, the scope is not on a scale of what CSC and CPE majors experience
in their project courses, or even in database CSC 4480.
You might be wondering about the age of our primary text, and rightly so.
In this age of Web programming and the ubiquitousness of GUI's,
what are we doing
discussing text-based tools? In fact,
as the more recent (copyright 2006) Das book points out,
you will be astonished at the timeless nature and power of those tools.
(The Das book was a close second choice to K&P as a text for this course,
by the way.) Besides the references listed below, your Web search will turn
up other even more recent ones (but none, you'll discover, as good as K&P),
as well as many free downloads on the topics we hit.
Of course the downsides of using an old book, even a terrific one like K&P,
are (a) some of the material is obsolete, and (b) the publisher never got
around to furnishing PowerPoint slides for it. We'll surmount those obstacles.
Further, our author Brian Kernighan, among the original developers of
the UNIX operating system, the C programming language, and the awk
language/filter (he's the 'k' in 'awk'), is alive and well and teaching
at Princeton, (see his
- CSC 1600
(Operating Systems), or
- CSC 2405 (Computer Systems II), or
- permission of the instructor
4/21) This is about the first line in your Perl scripts. The slides show two
#! /opt/local/bin/perl -w
#! /usr/bin/perl -w
That's because the "perl" command is found in a couple of directories. The
problem is that not each directory is accessible on each system in our Unix
cluster. /opt/local/bin is mounted on monet and tanner and others, but not
csdb. /usr/local/bin is mounted on csdb and tanner and others, but not monet.
4/30 (Tuesday)) Labs 4 are due.
5/1) Exam 4
5/9 (Thursday)) Project presentations 8:30 AM. Copy of slides due then,
as well as the paper.
You can see your "primary" perl by using the which perl command.
Regardless of where you are and what your opening line is, you can run your
script by saying perl myscript.
If your opening line's directory is mounted on the system where you are, you
can just say myscript (or ./myscript, if you need to mention
your current directory explicitly).
If it's not, and you say myscript, you'll get a strange error message,
something like myscript: file not found. This doesn't mean the shell
can't find myscript (assuming the current directory is in your search
path); it means that first line's perl directory can't be found.
Hope that's clear. Let me know if you have questions. And if you don't want
to have to worry, just run your script by saying perl myscript.
Dr. Don Goelman
162A Mendel Science Center
FAX: (610) 519-7889
Office hours: MTWTh 10:00-11:00 in general. If you plan to come by, it's
safest to warn me in advance. You can also just drop in at any time at all:
if I'm available,
I'm yours. And I'll be glad to set up an appointment at a time that's
convenient for you.
- S. Das, Your UNIX - The Ultimate Guide, McGraw-Hill, 2006
- B. Kernighan & R. Pike, The Practice of Programming,
- B. Kernighan & P.J. Plauger, Software Tools in Pascal,
- B. Kernighan & D. Ritchie, The C Programming Language, 2d
Edition, Prentice-Hall, 1988
- K. Leininger, UNIX Developer's Tool Kit, McGraw-Hill, 1994
- T. Muldner, C for Java Programmers, Addison Wesley, 2000
- J. Peek, T. O'Reillly, M. Loukidis et al, UNIX Power Tools,
O'Reilly & Associates, 1993
- P.J. Plauger, The Standard C Library, Prentice-Hall, 1992
- R. Schwartz, T. Phoenix & b foy,
Perl, 5th Ed., O'Reilly, 2008
- W.R. Stevens, Advanced Programming in the UNIX Environment,
- L. Wall, T. Christiansen & J Orwant,
Programming Perl, 3d Ed., O'Reilly,
- UNIX Reference Manuals on the Web
Free Online Perl Tutorial (and there are others)
- GRADE COMPONENTS
|4 Tests x 100
|4 Labs x 50
|Other (participation, homework, etc.)
- TESTS & LABS
February 5 (Test #1 on February 6)
||March 12 (Test #2 on March 13)
April 9 (Test #3 on April 10)
April 30 (Test #4 on May 1)
- FINAL GRADE
Required at examinations and on Thursday, May 9, 8:00-10:00 AM (the time
of our final examination; but we'll be using it for
Notice the dates of the labs, which are a mix of questions to investigate
and programs (of various sizes) to write, and tests.
The idea is that the best way to
prepare for the test is to do the lab, so you should pretty much have
completed the lab by Monday of the week when it's due. At the Monday class
we should have time for some last-minute questions. You will then submit the lab
on Tuesday and thus be in pretty good shape for Wednesday's exam (but don't
stop your preparations for it). Hopefully the schedule won't get messed up
by snow days and the like.
I'll be giving you instructions on how the files in each lab should be
submitted. Remember that all shell scripts (unless there are explicit
alternate instructions) must run under the Bourne shell, and,
if there are any C programs, then they
must compile and run correctly under gcc on the Suns. And the labs
are to be done individually: don't discuss them with your classmates. If you
have questions, ask me or the TA.
It's easy to get substantial partial credit even on
those questions you're not sure about: (1) Submit the files at the
due date. Unfortunately I won't be able to grade late assignments. 2) Spell the file names correctly.
(3) Eliminate any compilation errors; (4) Make
sure no program crashes.
mentioned earlier, the degree that C will be covered will be determined
in a few weeks. Most likely, it will be less explicitly "taught" than
"brushed up on."
Given the fact that we have various majors in this course,
there's a variety of levels of expertise in the C language here.
If yours is among the highest, you'll find some lectures paced a little
slow for you. If you have had no or little experience, you'll have the
opposite impression. Don't worry: as upperclass majors in computer
science or related fields, you are expert in some other language, probably
Java, and should be able to pick up C with few problems. As with the
UNIX side of the course, the best way to help yourself is to try a huge
number of examples. While the Muldner book (C for Java Programmers)
might appear most suitable as an aid, remember that the numbering of
topics in the C outline refers to the Kernighan
and Ritchie reference. You can easily map it to the Muldner
(or any other standard text) book, though.
Discussion among students should never include pending assignments.
This means the assigned labs.
Questions relating to them should be addressed only to the professor or
the graduate assistant. Violations of this policy are breaches of the
code of ethics of the ACM and of
University's academic integrity policy (you need to scroll down the page
to find the part about academic integrity),
with which you should acquaint yourself. In previous courses you may have
been encouraged to work in groups on your programming assignments, and
there are certainly pedagogical reasons for that. However, all labs here
are to be individual products (and there are pedagogical reasons for
Tadakamalla (click to send him email) will be the TA for our course.
His regular hours will be Monday afternoons
from 4:30 to 5:30 in MSC 158 (the Department's Software
Engineering Lab). He'll also be available for
appointments at other times,
if you email him a request for one.
He'll help catch you up if you miss any lectures, and he'll be able to field
your questions on pending labs and exams.
1 in K&P
2 in K&P
3 in K&P
4 in K&P, through sed
4 in K&P: awk
5 in K&P
Sample Program and Some i/o
C4: Storage Classes
Review of Pointers
Review of <string.h>
Review of Structs
Arrays of Strings
It is the policy of Villanova to make reasonable academic accommodations
for qualified individuals with disabilities. If you are a person with a
disability, please check out the Office
of Disability Services' Web site.
Everyone in this class will have a UNIX account on our departmental
Accessing it is described on the department
For new accounts,
your initial login (that's UNIX for "username") and password will be
described in class. Try it soon (that will be your first homework
assignment), and let me know if there
are any problems.
In general I will be sending announcements to your official
(@villanova.edu) Villanova email
address (not your UNIX email, which we'll discuss in class).
Make sure you check it several times a week.
Your labs will be done on those departmental systems (even if you
also have UNIX accounts elsewhere). The process for submitting them is
described in this video.
Last updated April 29, 2013