Trouble Working Through Kernighan's C

[agxphoto]

I'm reading a copy of Kernighan's "The C Programming Language." Oft cited, this book seems to be the touchstone for learning C programming. I've got the Second Edition, 46th printing, 2010.

I cannot get some of the examples to compile in Chapter 1. This would be not just once or twice, but example after example. The first four work alright. Thereafter, I have trouble.

When some of the examples do compile, and I run them in a terminal window, they'll often exit without usable output. I have taken to seeding the examples with "printf" segments to check to see how far into the program the computer will progress.

Are there any points, in principle, that I need to keep in mind for adapting Kernighan's examples for use on a contemporary computer?

I feel that I should be able to type the examples into a text editor, compile it with "gcc" open it, and watch it do its stuff.

Limited success so far. Any tips?

When I got to Chapter 1's example 1.7 I started getting compiler errors about using an older method for making a declaration. So, I suspect that maybe there have been changes in principle which I don't understand.

Thanks.

[oracleguy]

If you run the program and the window for it only briefly appears, it is because it is running and then the program is completely so the window ends. You can either add a scanf statement near the end of your program to keep the window open or run your program from an already open command prompt.

Secondly, when asking for help with programming problems please include the specific errors you are getting and the code if appropriate. We can't help you compile the examples if we don't know what is wrong.

[agxphoto]

Okay, I'll pick the last one. Example 1.9, from Chapter 1, the section of Character Arrays (p. 29), which is the following code:


#include <stdio.h>
#define MAXLINE 1000 /* maximum input line size */

int getline(char line[], int maxline);
void copy(char to[], char from[]);

/* print longest input line */
main()
{
int len; /* current line length */
int max; /* maximum line length seen so far */
char line[MAXLINE]; /* current input line */
char longest[MAXLINE]; /* longest line saved here */

max = 0;
while ((len = getline(line, MAXLINE)) > 0)
if (len > max) {
max = len;
copy(longest, line);
}
if (max > 0) /* there was a line */
printf("%s", longest);
return 0;
}

/* getline: read a line into s, return length */
int getline(char s[], int lim)
{
int c, i;

for (i=0; i<lim-1 && (c=getchar())!=EOF && c!='\n'; ++i)
s[i] = c;
if (c == '\n') {
s[i] = c;
++i;
}
s[i] = '\0';
return i;
}

/* copy: copy from into to ; assume to is big enough */
void copy(char to[], char from[])
{
int i;

i = 0;
while ((to[i] = from[i]) != '\0')
++i;
}



I had opened up a copy of Text Edit, typed the code in as plain text, and saved it to a known location on the computer. Same as always.

I then opened up Terminal, GCC to compile, using the commands: "GCC FILENAME.C -o FILEOUTNAME"

The code compiled in this instance.

In Terminal, I went back in, "OPEN FILENAME". Terminal then opens a Terminal window, shows the filename's path followed by "; exit" and then gives me a cursor, without further response.

So, in a program where I was expecting to see some opportunity for interaction and some response, I received only a clean and quick exit.

My guess is that I am making some kind of obvious operator error. Gut feeling.

Any advice?

* * * * *
For example, after I compile the code above, and then try to run it inside GDB, all I get is a message that the program is starting, followed by: Reading symbols for shared libraries . done

And then, that's it.

Is that it?

I was expecting these opening examples to do more, to show more. Instead, it's a quick and clean "done."

[agxphoto]

I went back and began working some problems in Cshell, which pointed the way towards some answers. I suppose before I didn't really understand the importance of the relationship between the shell and the program, working together, in order to avoid some of the memory management limitations and other ideas. I was running into some of those before.

Consider the question answered. Thanks.

[agxphoto]

I used this procedure to get the example above to work. Earlier, I had failed to realize the importance of the Cshell to Cprogramming. My fault. Here's how I got out of it.

I typed that code in, as above. Compiled it. AOK. Stored it in a folder.

Added a "target" text file of information for that program to read. This fulfills the "input" role that particular program needs.

Wrote a shell script to link the program to an input file. This got things rolling. It was, in fact, covered, in Kernighan's book. There was a brief mention of the importance of using the other parts of the computer system. He wasn't kidding. All of the directions, like these, for getting the program to ride in a shell and work were omitted.

The system I ran this on was Mac OSX Tiger; typed with Terminal and Text Edit; compiled with GCC.

Well, a copy of the example Cshell script follows:
#!/bin/csh
#
clear
echo
echo
echo "Example 1.9 page 29"
./19p29 < testtarget.txt
echo "got this far."

Where "./19p29" was the name of the compiled program written with the code posted above (from section 1.9, page 29); and, where "testtarget.txt" was just a text file used to give the program something to count. In this case, it was filled with some HTML source code that I had leftover from another project.

"CHMOD" to change permissions to make those files usable.
Triggered the program in Cshell with ./FILENAMEOFTHESCRIPT.

The program worked just fine. It returned the longest lines of text from the "testtarget.txt" file. This was the main idea of the example program. AOK.

I was able to use a similar procedure to get some of the others working. I imagine that this is what's needed for all but the simplest programs. I suspect that the few that did work without the shell kickoff were the simplest ones.

Sometimes the toughest problems are the ones with the simple but powerful answers. Thanks.

[BobbyD]

Man I remember that book from way back...

It's kinda nice to see people still learning to code the old fashioned way, one concept at a time... I thought all the kids these days only care about rapid development, drag and draw a window, declare events ... or better yet, make it work within a website, design the interface first... all java and .net and ror...

Stick with it buddy!

[agxphoto]

I have been able to make it about halfway through the book. Once I learned how to use that BASH and CSH to route information into the programs, things were a lot easier.

It really helped to realize that the language came about during a time of keypunch machines. I picked up a book on programming at my local library; it was actually written for use with keypunch cards.

Well, so I did, after Chapter 4, jump ahead to Chapter 7, to get some information on Input and Output; that, and realizing the importance of checking the libraries on hand: I think that the examples in the book are based on library names I may not have here. Also got to reading those libraries to get a little understanding of what is in there. I found them sith a simple search for their names.

Thanks for the encouragement.

I think I'm going to end up favoring C for the programs, maybe a little python to put a GUI on it (instead of trying to program with that GUI), and stick with HTML 4 and CSS (including some HTML2 with CSS and some pre-formatted plain texts) for information presentation.

I really like working with this C.