Key Terms and Concepts
and other relevant and fascinating technical discussions and diversions
with regard to some aspects of either Unix or computer science in general
Compiler: Computers only execute "executable" programs, which are huge sets of binary bit patterns (stored, of course, in a file) in a dialect virtually incomprehensible to normal humans. (By the time you get a bachelors degree in EE, CE, or SE, you'll understand machine language just fine; that tells you something, doesn't it?) The compiler-as-translator analogy to translating among human languages is a pretty good one. I speak English, but not French, for example. To talk to a Frenchman who spoke no English, I would need a translator. No computer "speaks" C or any other language you've ever heard of; like most Americans, it speaks only one language its own binary machine language. (Each major family of computer chips has its own language the machine language for Motorola chips is not the same as that for Intel, for example.) The language C and other high level languages are designed, among other things, to be more easily comprehensible by programmers than are machine languages (that's why they're called "high level"). To get a machine to execute a program whose logic is written in C, the C program must be translated into that particular machine's language. A compiler is a translation program that takes input from a source file containing source code and translates it into a target language, typically (not always) some machine language. After translation, the compiler places the resulting executable code in some output file.
A compiler, of course, is just a program too and so ultimately it itself is just a bunch of machine language instructions for some machine. When the compiled output from a compiler is a program in some other machine's language (different from the the machine language of the compiler itself), the compiler is said to be a "cross-compiler". Kinky, no? (And you thought there was nothing sexy in computer science.)
On most modern keyboards, the lower leftmost key on the keyboard is labeled "Ctrl". It's like the "Shift" key that makes capital letters upper case you have to hold it down while you type another character to get it to mean or do anything; it doesn't mean anything by itself. When you hold down "Shift" and type a letter, you know what you expect to see; but when you hold down "Ctrl" and press another key, you may or may not see anything and what happens will probably vary depending on what program you're currently talking to.
Control characters are often used in Unix systems as a very concise way to tell either the shell or some of the Unix utility programs to do something. But the shell's response to a control key need have no resemblance to an editor's response to that same control key. (Microsoft Windows has a similar concept and calls such keystrokes "keyboard shortcuts"; they too vary from program to program.) You have to learn the conventions for each program you use. Pico and some other programs make that easy, by the way, since they display an on-screen legend or menu of available control characters for you; the shell, unfortunately, does not. Various display/documentation conventions exist for telling you to enter a control character. ^c, C-c, control-c, ctrl-c and <ctrl-c> have all been used in documentation I've seen, for example. They all mean the same thing: hold down the control key and then press the c key.
^c is an almost universal Unix command to cancel whatever program is currently running useful, for example, if a program of yours has gone into an infinite loop. But note that I said "almost " there; not all programs will abort in response to a ^c; pico won't for example. But unless and until you get very advanced and are able to override some built in Unix defaults, all of your programs will indeed abort if you hit ^c
Shell that component of an operating system (OS) that, among other things, handles the command line interface. (A window manager and some other stuff is needed for a pretty, windows-based GUI). Unix/Linux includes a very sophisticated shell several, in fact. When you get more experienced you can select exactly which shell you want to use and join the eternal, impassioned, and totally pointless religious debates about which shell is "better". The basics are all the same, however.
The shell parses (processes) the command line you enter. It works from left to right. Everything up to the first blank (for a Unix shell) is interpreted as the name of a command (program) you want the OS to execute for you. Everything else on the line is some sort of data or "argument" for that command, often including the name of a file that the command is to do something to or with. In Unix terminology, "commands" and "programs" are essentially interchangeable, and, like everything else, they're both stored in files. Any executable file can be used as a command. All the shell really does (usually) when you type the name of a command in response to a shell prompt is to go looking for an executable file by that name. If it can't find a file by that name, it gives you an error message. If it finds the file but the file is not executable (like, your weekly shopping list), it gives you a different error message.
On the web, there are many good tutorials on the basic commands common to all major Unix shells. Unix shells are extremely complex, powerful and interesting tools in their own right; but you don't need very much in the way of shell savvy for an introductory programming course. If you're interested in learning more, however, or are finding this set of notes totally incomprehensible, try some other online sources of Unix information.
Source code: Code (instructions) written in a high level language like C, Ada, Fortran, Cobol, or Basic, for example. It is called source code because it is the source of the logic in the ultimately executable computer program; but source code itself cannot usually be executed as a program by a computer. It must first be compiled (translated) into some machine's machine language which is all that that particular machine can ever really execute. (There are usually other translation steps besides compilation, such as linking and loading, for example; but they can often be hidden from even the programmer by sophisticated compilers and operating systems.) Source code is what a programmer types into a source file using an editor. You'll usually name the source file with an appropriate extension (like .c for a C program), but to Unix, it's still just a text file. The .c just tells you and the compiler that you intend the text in the file to obey the rules for C source code, and if it doesn't, the compiler will certainly let you know. But to the rest of Unix, it's still a text file and so the various useful Unix text manipulation commands are available to you (like cat or more, for example, and there are lots of others).
Unix/Linux Unix is an operating system (OS) that was originally designed by Ken Thompson, Denis Ritchie, and others at Bell labs back in the 60's. (For the purpose of undergraduate programming, you can consider Linux as just a modern flavor of Unix.) Thompson and Ritchie designed Unix more or less for their own personal use, never dreaming that anybody else would have to learn their idiosyncratic (and occasionally downright idiotic) command names and conventions. You know the rest: other folks picked it up, lots of stuff was written in and for it, and by the time people realized it was going to become one of the world's standards, it was far to late to even consider going back and cleaning up some of it odder features. So if you occasionally find it frustrating don't worry; it's not you: Unix is occasionally frustrating and it certainly wasn't designed to be user-friendly or easy to learn. But the basics are simple enough and you don't need very much at all to start productive programming. Besides being idiosyncratic, Unix is also far and away the professional's choice. It is immensely powerful, universally available, better documented and easier to understand than Microsoft Windows by a jillion orders of magnitude, and, once you get used to it, quite logical. (You know you're deeply into this business when it starts to seem logical to you but it will, and you'll forever hate having to deal with anything else.)
In CS420, we study operating systems in some detail. For now, all that you need to know is that an OS like Unix is the most basic set of programs that run on a computer. A modern computer is pretty complicated; it has a lot of parts that interact in strange and wonderful ways. The purpose of an OS is to shield users, programmers, and even other programs from that complexity and allow them to focus on doing what they want rather than all the details necessary to coordinate all the components of a modern computer.
Programs themselves ask for services from an OS via system service calls (a special type of procedure or function call); human users get OS services via one of two methods: a GUI or a command line interface to a shell:
Although ultimately, a CLI is more powerful than a GUI, a GUI is a lot more convenient for many things such as web surfing or reading hypertext documentation like these notes. But as a programming environment, a GUI is more complicated and hence usually much less standardized than a shell and it also takes more bandwidth over a communications line as well. So for one of these reasons or another, beginning programmers, users working over a slow network, and many/most heavy-duty code slingers usually use a CLI.
RTFM Read the Freakin' Manual, an acronym all computer professionals should know ;-)