ctime.c: In function 'main':
ctime.c:16: parse error before '='

The first entry on the first line, before the colon, is the name of the file being compiled (ctime.c, in this example). The rest of that first line tells you which function in that file the error messages pertain to. ("Functions" are the building blocks of programs written in the C programming language. Initially, all your programs will consist of only one function and its name will be main; later, you'll be writing more complicated programs composed of several functions.) Subsequent lines in the error message give you the line numbers containing the errors (line #16,in this example), plus as much information as the compiler can manage about each error itself. Note:

• The line numbers are from the beginning of the source file, not from the beginning of the function.
• Always start correcting your errors starting from the very first one the compiler reports, as it's the only one you can be sure is correct, meaning that there really is an error where the compiler says it is. The compiler usually attempts to continue on (after reporting an error) looking for other problems; but often your first error throws things off so much that its subsequent error messages may be pointless. The result is that fixing the first actual error may in fact make a lot of later, apparently unrelated, error messages disappear. Later, when you're more experienced, you can sometimes ignore this rule a bit and try to fix several problems at a time or fix them "out of order"; but for now, do it as I've recommended here: Fix the first problem first and then recompile and move on to the next "real" error.

You'd think there would be a lot of really good web pages out there describing how to interpret gcc error messages, but there aren't. Here are the best I've found so far (as of late Nov 2003):

• http://web.ics.purdue.edu/~cs240/misc/errors.html
• http://cs-www.bu.edu/help/unix/the_four_most_common_gcc_error_messages.html

If you're working outside of the scheduled lab time for this course (meaning that I won't be within 50' or so) and can't figure out what some error message means, post your code and the message on the class discussion board on Blackboard and I'll answer it within a few hours. If you find some better web pages on this subject than those two I noted above, be so kind as to let me know please; I and your classmates will be grateful.

5. Where do my comments go? Comments are part of your source code and go in your source file, not your script file that you turn in to me. They show up in the script file, of course, because the entire source file shows up there, along with other information, including instructions to the email system, but comments are part of your C code. They are part of your programming style and are designed to make it easier for people (including you yourself) to read your source code and figure out what it does and how it does it. External documentation (documentation that is not in comments in source files but in separate documents like User Manuals, for example) can and does get lost. But source code usually doesn't. (If it does, you can forget about ever making any further changes to the program, right? If you had a compiled version of the program, you could continue to use it, but without source code, it could never be changed unless you wanted to go back to the good old days when programmers programmed directly in machine code. I've done that; you wouldn't want to; trust me on this.) I recommend that you try early in your career as a programmer (like now!) to get in the habit of routinely commenting your source code as you write it rather than regarding it a separate step to be undertaken only after the program is working correctly. Many is the time I've done a bunch of code at 3 in the morning with no comments and tried to go back and fix it after getting some sleep only to discover that I couldn't understand my own code from the night before. In the beginning of the CS125 semester, the comments may be trivial enough that you can't see how this would be possible (not remember how my "Hello world!" program works?) but by the end of the semester you will be writing much more sophisticated code and you might easily forget what you meant if it were not properly commented. Start developing good programming habits early.

6. Why is the first week of this course so confusing? We are dealing with several different programs designed and built by totally different people for totally different reasons and there is no consistency among them. The lab machines' operating system is Microsoft Windows but first we have to (sort of) login via a Novell server and then use a commercial SSH product on Windows to connect to a Unix server where we will run an editor from the University of Washington to produce source code for a compiler provided by the Free Software Foundation. This is nuts, you say; haven't you people (the faculty idiots in charge of this course) ever heard of an Integrated Development Environment (IDE)? Well, sure we have. We even have one already installed on all the lab machines. So it's an integrated development environment for a Windows based system. But the aerospace industry generally does not use Windows for software development. Any effort we (ERAU) asked you to expend to learn a Windows IDE (Visual Studio, in specific) would be essentially worthless as far as the aerospace industry is concerned. Wouldn't learning one IDE make it easier to learn other ones, the ones used in industry, later? Well, not really. If you don't know it already, let me be the first to tell you: Microsoft very rarely invents anything; they borrow the basic ideas of their products from other sources and then have to change them a lot to avoid copyright infringement, patent issues, etc. So Microsoft's IDE doesn't look anything like the Unix-based stuff the aerospace industry uses. Well, you say, how about skipping Microsoft completely and just putting the Unix environment (or Linux, a very close cousin) and a "real" industrial IDE on our lab machines? Which lab machines, just the ones in the King building? So if the King building were closed you couldn't use the machines in building 58 the way you can now? And the (hypothetical) Unix machines in King wouldn't be able to run Microsoft Word and PowerPoint and Excel so you wouldn't be able to use the King labs for term papers and other minor stuff like that. And of course you couldn't work from off campus or the dorms since the "real" Unix IDEs are expensive and you probably wouldn't want to have to buy your own copy for your personal computer(s). Serious programmers in the aerospace industry are expected to know how to work in a Unix environment like the one we have here. Maybe, even probably, a big firm will have a Unix-based IDE for its staff, but they usually don't expect you to know it (the IDE they use) at the start and you can always get started with the sort of basic Unix environment we have here — that's almost always available almost anywhere you go in aerospace, and academia too, for that matter, for those of you who will eventually think about graduate school..

OK, you say, but how about this script file business? Isn't that unnecessarily complicated? After all, what does it have to do with writing and compiling C programs? Well, either you're going to email me your programming assignments or you're going to print them out and hand them in hardcopy . Everybody got a printer at home? No? Everybody want to stand in line for the one printer in the King building (and it's usually out of paper anyway)? No? I thought not. And you're going to staple those pages together for me so I don't lose any of them and flunk you and ruin your college career and your life? Staplers always in the lab? Never run out of staples? As I see it, mailing your script file from the Unix command line is our only reasonable choice. (It's got to be the same for everyone or I'd go nuts trying to keep track of everyone's work properly.) Fine, you say, but how come I make you edit your script file before sending it? Well, CS125 is often a big class and there are going to be lots of programs. I need a way to automate the filing of the programs I get in the email and the campus email server allows filing rules to be based on the subject of the email. So your email from Unix has to have a subject line and you have to put it there without the benefit of neat little GUI-widgets. (Yahoo, Hotmail, Internet Explorer, Eudora, etc; they're all GUI based) and that means you have to edit the output file from your Unix script session before you email it to me.

Unix is a set of Lego-like building blocks. In the Unix world, which came from (and still is) the world of research labs and universities (at least the engineering colleges), the burden of stringing together a bunch of (essentially) simple freeware tools needed to perform a complex task is up to the user. In the Microsoft world, vendors try to bundle a set of tools together, slap a couple of buttons on the front along with their logo and charge you money for the proprietary result. The more they can put together in one product, the more they can charge you. The "glue" that holds the Unix building blocks together is the file system. Every Unix tool takes input from files and makes output to files and the format of the files is described in the Unix manual so if you want to write a new tool, or better yet, combine a set of tools to do something new, it's easy to figure out how. In the Microsoft world, the vendors don't want you making changes to things; they want to make all changes and charge you for them. If you wanted to write a program that automatically added information to a Microsoft Word document, where would you find a description of the internal layout of a Word document? Right — you can't. So if there's a Microsoft world integrated toolset that does exactly what you want, it's likely to appear to be easier to use than an equivalent set of Unix tools. But (1) you have to pay for it, (2) if it doesn't do exactly what you want, you're out of luck, you can't change it, and (3) if you go somewhere else they'll have a completely different tool that is incompatible with the one you're used to.

Consider Blackboard. It's got communication tools like an emailer and a bulletin board. It's got course management software for making up tests and grading them. It's got its own web page composition tools to help faculty make up Blackboard web pages, and it's got its own internal filing system so faculty can organize the course materials. All integrated via a common proprietary GUI . Now suppose I go to a different university that uses WebCT (a competing product) instead of Blackboard. Everything would look different; I'd have to start learning a whole big new system all from scratch. In the Unix world, everything would be almost exactly the same at the two universities. The cost is that when we are just getting started in Unix, we have to learn how to use a bunch of small tools and figure out how to glue them together ourselves. But that skill is not rendered useless if we go to another university or go to a different job.

I've oversimplified this story, of course, but not by much, really. Learning to take the very first interesting steps with separate Unix tools is probably harder than learning to do something cool with more integrated Windows ones; but the Unix skill set will be useful forever and allows you more power and flexibility and even ease of use once you are used to it. Windows stuff is designed to make it look easy from the start (so as to not scare off the naive potential customers) at the cost of downstream power, flexibility, and time. You're in the learning curve phase of Unix now, and it is more confusing; but it will pay off in the end. Trust me.

7. What is syntax? Syntax refers to the structural rules of a language describing what symbols may be used and how they may and may not be combined. ¿Spanish uses some different symbols than English, does it not? And in German, many sentences with a verb must end. Which is not true in English.

This page last changed 10 Jan 2004 by Dr. M.S. Jaffe