Computer Science 271
Software I: Unix

Dr. Stephen Bloch
office 113A Alumnæ Hall
phone 877-4483
Web page
Class Web page
office hours MTTh 1:00-2:15, W 10:00-12:00
class meetings TTh 3:05-4:20


This course assumes you have taken and passed CSC 171 ("Introduction to Computer Programming") and either CSC 172 ("Introduction to Algorithms and Data Structures") or CSC 173, This course will demand a lot of time programming, testing, and debugging in C, particularly in the latter half of the semester, so we'll also cover the basics of C programming, on the assumption that you already know some Java.

Subject Matter

This course will explain the basic concepts common to many computer operating systems and introduce you to a great number of tools and features provided by operating systems, especially Unix, which is currently the most popular at academic and research institutions and coming into widespread use elsewhere.

The Unix operating system has more personality than most, not because of how it works but because the people who built (and continue to build) it left such a distinctive mark on it with their senses of beauty, humor, and responsible behaviour. These have led to a system which, once you've grasped its fundamental philosophy, allows you both to make efficient use of your time and to have fun at it.

The creators of Unix used computers all day, every day, and wanted to use them as efficiently as possible. These people loved elegance and simplicity, and hated re-inventing the wheel, so they built a number of simple tools that could be combined as needed in billions of ways. They also loved whimsy, so you will find a lot of puns and jokes built into the system. On the other hand, they believed strongly in personal responsibility, so destructive pranks, invasions of privacy, and insults are strongly discouraged -- usually not by rules, but by peer pressure. Unix has evolved from a computer system to a philosophy and finally to a community. I hope, among other things, to make you productive and civilized members of that community.

A disadvantage of building the whole system out of simple tools is that you need to learn a lot of simple tools before you can do anything. So in the first half of the semester you'll read a lot of documentation and try your skill on small examples. In the second half of the semester the emphasis will shift from reading about Unix tools to actually using them.

Many of the people in this class are taking CSC 270 concurrently. The two courses have different emphases: 270 is primarily about programming languages, with occasional mentions of operating-system issues, while 271 is primarily about the Unix operating system and secondarily about the C programming language.

How to Learn Unix

This is not a theoretical course; it is a very practical, hands-on course. To learn the stuff I expect you to learn, you must spend a lot of time on the computer trying things. Every time you read about a new command, or hear me describe one in lecture, try it. Invent new ways to use it, beyond what I or the textbook have described. Play with it. The best way to learn Unix is to use it until you don't even have to think about the most common commands--your fingers know them by heart.


The main text for this course is Unix Power Tools, by Powers, Peek, O'Reilly, and Loukides. This isn't really a textbook, and it isn't really written for beginners to Unix, but it contains a lot of valuable information about Unix. Don't try to read it sequentially, from beginning to end; it's made up a hundreds of one-page "articles", many of which refer to one another, so you can jump around as your interest leads you. In most "chapters", the more basic information is near the beginning and the more obscure stuff near the end of the chapter, so if I assign (say) chapters 10, 12, and 14 for a particular day, you really only need to read probably the first half of each chapter.

Likewise, when we switch to C in a Nutshell, by Prinz and Crawford, there will be sections -- typically at the end of a chapter -- covering relatively obscure topics that we don't really need. Much of the C material should be review for you, since we'll have already discussed C++ in the Survey of Programming Languages course.

This will still add up to a lot of reading: make time in your schedule for about 20 pages per class meeting, or 40 pages per week. I recommend keeping the books for reference after the semester is over.

I'll also give some reading assignments in class handouts, on the World Wide Web, by email, in magazines, etc.

Some of you might also be interested in The Art of Unix Programming, by Eric Raymond. I will not require specific readings from this book, but it contains a lot of good "philosophical" discussion by the Big Names of Unix history.

You are responsible for everything in the reading assignments, whether or not I discuss it in a lecture.


There will be several homework assignments.

Each homework assignment will be worth 10-15% of the semester grade. There may be a midterm exam, also worth 10-15% of the semester grade; there will definitely be a comprehensive final exam, worth 20-30% of the semester grade. "Brownie points" will be another 10-15% of the semester grade; you earn brownie points by asking and answering good questions in class, by seeking my help when needed, etc. You lose brownie points by cheating, by being lost and not seeking help, and by generally making a pain of yourself.

Exams must be taken at the scheduled time, unless arranged in advance or prevented by a documented medical or family emergency. If you have three or more exams scheduled on the same date, or a religious holiday that conflicts with an exam or assignment due date, please notify me in writing within the first month of the semester in order to receive due consideration. Exams not taken without one of the above excuses will get a grade of 0.

Homework and programming assignments will be accepted late, with a penalty of 1/3 per 24 hours or portion thereof after they're due. An hour late is 33% off, 25 hours late is 67% off, and after 48 hours don't bother turning it in. It's still a good idea to do as much of it as you can, however, because I'll assume on the exams that you've done the homework.

Programs are not abstract works of art, they are supposed to run and solve real problems. So if I get a program that doesn't compile or run, or a program that has little or nothing to do with the problem I assigned, I will give it a zero, no matter how much time you put into it. Don't bother turning in a program you haven't tested yourself.


The Adelphi University Code of Ethics applies to this course; look it up on the Web at .

Most homework assignments in this course involve writing, testing, and debugging a program by yourself. You are welcome to seek help on mechanical and syntactic matters ("how do I save this file?", "what does this compiler error message mean?") from me, from other students in the class, and from tutors in the Learning Center, and you are welcome to discuss general approaches to a problem with classmates; but you may not copy large pieces of programs or homework solutions. If you do, all the students involved will be penalized.

All work on an exam must be entirely the work of the one person whose name is at the top of the page. If I have evidence that one student copied from another on an exam, both students will be penalized; see above.

Last modified: