Help with while loops, EOF. (Have read FAQ)

[Ocifer]

Hi there. I've been programming in C for a few months, and I've hit a snag with EOF and fgetc. I read Hammer's FAQ article about why it's bad to use feof() in a while loop. I tried it, and like he said the last line of output was repeated. Now that I've adjusted my while loop to use a value determined by fgetc, I'm still having the same problem.

My program is meant to print off the first word of each line of a given .txt document. I program in Ubuntu, and I'm using a the redirection operator "<" to redirect my text file into the stdin stream of my program.

My code is short:

int main (int argc, char * argv[] ){

  char temp[20];
  char holder, holder2;

  fscanf(stdin, "%s", temp);
  printf("%s\n", temp);
  holder = fgetc(stdin);

  while(holder != EOF){
    if(holder == '\n') {
      fscanf(stdin, "%s", temp);
      printf("%s\n", temp);
    }
    holder = fgetc(stdin);  
  }

  return 1;
}

My text file is simply:


Here is some text
arranged in a strange way
on
each line
END.


The output I receive is:

Here
arranged
on
each
END.
END.

I understand this may be trivial to many of you. I'm not so much looking for code, but more so a clarification of how the EOF is handled; I'd like to figure out which subtlety has been driving me bonkers for the last two hours.

[tabstop]

Presumably you have \n after "END." in your file, so that after that word is scanned and printed, your fgetc gets that \n, the loop continues, and the fscanf fails since that \n was the last bit in the file.

[Ocifer]

I have tried making sure that there is no extra '\n' after the "END." to no avail.

Is it possible that a newline is inserted at the end of every file in linux? If so, what can I do to ignore the final \n?

[MK27]

Is it possible that a newline is inserted at the end of every file in linux?

No. Try inserting this to see what that character is:

  while(holder != EOF){
    if(holder == '\n') {
      fscanf(stdin, "%s", temp);
      printf("%s\n", temp);
    }
    holder = fgetc(stdin);  
    printf("->%d"<-",holder);
  }

This will give you the ascii value of the holder, I'm guessing it will be 0.

Qv. the ascii table if you are unaware of it.
ASCII Table / Extended ASCII Codes

[Ocifer]

I'm sorry but the code you provided did not compile, I received a number of error messages. What do the -><- do?

[tabstop]

He's got an extra quote mark in there, which you should remove.

(What it will do is give you output like so:

$ ./ociter < txtfile
Here
->105<-->115<-->32<-->115<-->111<-->109<-->101<-->32<-->116<-->101<-->120<-->116<-->10<-arranged
->32<-->105<-->110<-->32<-->97<-->32<-->115<-->116<-->114<-->97<-->110<-->103<-->101<-->32<-->119<-->97<-->121<-->10<-on
->10<-each
->32<-->108<-->105<-->110<-->101<-->10<-END.
->10<-END.
->-1<-

So that 10 (==\n) is still there, somehow.)

EDIT: The workaround is obviously to check the return value of fscanf.

[Ocifer]

Upon removing the extra quotation mark:

The last two printed values for the variable "holder" were ->10<- , corresponding to line feed.

[MK27]

I'm sorry but the code you provided did not compile, I received a number of error messages. What do the -><- do?

Sorry, whoops, there was an extra " in there (too much glue sniffing again today ):

printf("->%d"<-",holder);

You may want to combine this with tabstop's point:

  int r;
  while(holder != EOF){
    if(holder == '\n') {
      r = fscanf(stdin, "%s", temp);
      printf("%s\n", temp);
    }
    holder = fgetc(stdin);  
    printf("->r: %d h: %d<-", r, holder);
  }

[MK27]

Upon removing the extra quotation mark:
The last two printed values for the variable "holder" were ->10<- , corresponding to line feed.

Hmmm. Could be the shell does this with redirection but I doubt it, will check...

[Ocifer]

Okay, I've managed to write a workaround, using a "check" integer variable for fscanf. I've noticed that the last time fscanf tries to scan information from the text file, the value of the check digit is -1. I'm assuming this denotes an error, or EOF or something similar.

My revised code looks like this and it works as desired:

int main (int argc, char * argv[] ){

  int check;
  char temp[20];
  char holder;

  fscanf(stdin, "%s", temp);
  printf("%s\n", temp);
  holder = fgetc(stdin);

  while(holder != EOF){
    if(holder == '\n') {
      check = fscanf(stdin, "%s", temp);
      if(check <= 0)
        break;
      printf("%s\n", temp);
    }
    holder = fgetc(stdin);  
  }

  return 1;
}

Now that my program works, I'm happy. However, I'd still like to figure out exactly what goes on with the end of a file. I can imagine that as I come to write longer programs, which may be using much longer files, that workarounds like this can become trickier.

If anyone can explain why LF character appears at the end? I have not transferred the file between operating systems like Windows and Linux. The .txt file was created and used solely in Ubuntu.

[MK27]

However, I'd still like to figure out exactly what goes on with the end of a file.

No, the problem is you did not get rid of the final newline. How do you know it isn't there? Create a one character text file in the editor you are using, with no line return, and check the file size. Betya it's 2, not 1.

The easiest way to demonstrate is to create a 1 byte test file:

#include <stdio.h>
#include <fcntl.h>

int main(void) {
	int fd = open("test.file",O_CREAT|O_WRONLY);
	char b[] = "A";
	write(fd,b,1);
	close(fd);

	return 0;
}

Check the file size. It should be 1. Now compile this:

#include <stdio.h>

int main(void) {
	char byte;
	while (read(0,&byte,1)) printf("%d ",byte);

	return 0;
}

and try:
./a.out < test.file

I get "65" and that's it. No newline.

[tabstop]

Try the following code:

#include <stdio.h>

int main(void) {
    char string[] = "Here is some text\narranged in a strange way\non\neach line\nEND.";
    FILE *out;
    out = fopen("txtfile", "w");
    fprintf(out, "%s", string);
    fclose(out);
    return 0;
}

This will definitely write out a file with no \n at the end. Try that with your original program and good things might happen. (gedit is apparently known to add \n at the end of every file; it appears that we can add vim to that list, at least with default settings, since that's what I was using.) (Apparently if I had typed :help eol in vim I would have seen that.)

[MK27]

it appears that we can add vim to that list, at least with default settings, since that's what I was using.)

Yeah! I was certain that was not the case but just noticed the same thing, vim adds a \n.

[Ocifer]

I was using gedit, so that makes sense.

[hk_mp5kpdw]

fgetc returns an int, not a char.