Backspace to read last line?

[pecan204]

Can someone help? I am trying to read to the end of a file then backspace and read the last line. I tried a rewind which I believe sets it to the beginining of the file and it works but a backspace does not. Please see examples below. Does anyone know why a backspace does not work?

Thanks
Ken

This works!

do iread = 1,1000
Read(lin2,*,end=104) file_line
enddo
104 rewind lin2
Read(lin2,*) file_line

This does not work!

do iread = 1,1000
Read(lin2,*,end=104) file_line
enddo
104 backspace lin2
Read(lin2,*) file_line

[Steven_L_Intel1]

Ah, fun with backspace.

When you get to line 104, the file is positioned past the "end of file marker". This is a concept in the Fortran language that is not necessarily embodied as something in the physical file (and in fact is not). The first backspace positions you just before the EOF marker, so the read gets an EOF! You want TWO backspaces, the second will get the last record.

Please note that reading character variables using list-directed input is fraught with peril - you'll get only up to the first delimiter, unless your data is surrounded with quotes.

Steve

[pecan204]

Steve,

I tried two backspaces and that still did not work.
I read the below file with a 9 character string and the rest a floating point array like
104 backspace lin2
backspace lin2
Read(lin2,*) string1, (xread1(i), i=2,nv(1))

My file looks like :
12.xx -173317. 1111. 99 111 .85 218.44 727.7 85. 1114.6 -4.65 1

It appears that in the debugger it says that the character variable string1 is not found.

Do you think it is the string variable messing this up? What else can I do?

Thanks

[TimP]

As Steve implied, you might wish to read each line into a character string, using a plain A format. When you reach the end of file, the contents of the last line would remain in your buffer, so that you would not need to depend on BACKSPACE.

[pecan204]

Tim,

Then how would I get the floating point variables into their memory location?

Also I expect to have very large files and if there was a way to immediately advance to the last record for a read would seem to be the most efficient. Is there another way?

Thanks

[Steven_L_Intel1]

What compiler and version are you using? What error do you get on the READ after the two BACKSPACEs. I tried a sample here with CVF 6.6B and it correctly read the first "token" on the last line.

12.xx should be read ok into a character variable.

Steve

[pecan204]

I have 6.1.0.

[pecan204]

The error is an end of file during read. That occurs after the two backspaces.

It is a CVF compiler if that is the compiler.

[Steven_L_Intel1]

Ah, 6.1. 1999 was a good vintage year... I faintly recall that we fixed a problem in this area a few years ago.

Steve

[kdkeefer]

Dear Steve, et al.,
There is a very real, physical reason for this double EOF, which originated with IBM 9 track tapes (actually probably 7 track ones, but those were before my time). Tapes, like disks, had to be physically moving in order to read or write magnetic flux reversals. A tape drive could only stop at a special end-of-file gap (EOF) when seeking information on "fast-forward". Records on a tape were marked by a special end-of-record (EOR) character. Unlike a disk, a tape had to stop when the data were no longer being continuously supplied at the write speed of the tape. When the last a record of a sequence was written, the drive wrote an end-of-file (EOF)gap, marking it as the end of the file. The computer did not know when or if you were done writing a file, so it always made sure that what you had already written was readable (and the drive would stop at the end of it), akin to closing a file on a disk. Otherwise, the information might just be a fragment. If/when another record was added, the drive physically rewound past the EOF and the R/W head was positioned between the EOR and EOF. This was done so that when tape went forward again to write, there was enough empty tape so the drive got up to speed before data were written, and the EOF was overwritten by the new record. When the file was closed, a second EOF was written. A double EOF indicated the logical end of the tape and anything after it was "lost". Those of us who knew too much could read past an EOF. If we lost count and read past a double EOF, the tape would run off the end and we would sheepishly have to send a message or telephone the operator on duty to rewind our tape for us.
Keith

[TimP]

With the copy of the line of interest in a character string, you would do a formatted internal read on the string,just as you would to read it from a correctly positioned file.

[Steven_L_Intel1]

Keith,

I'm well familiar with magtapes and tapemarks, even having written my own ANSI label processing code a long long time ago. However, there is no double EOF here.

The magtape model is the basis for how Fortran treats a file. The semantics are as if there was some physical end-of-file mark after the last record - this can be actual (tapemark), a convention (CTRL-Z has often been used), or implied by the file system (no more bytes in the file.) In all cases, the Fortran environment is required to behave as if there were a separate endfile marker.

When you "read past" the endfile marker, you get an end-of-file condition and are now positioned "past" the endfile marker. The first BACKSPACE backs up over the marker and positions you just before it. That is why a READ at this point will get EOF. If you want to read the last record, you need two BACKSPACEs, the second repositions before the last record.

See also ENDFILE.

Steve

[kdkeefer]

Steve, et al.,
Steve is, of course, absolutely correct.
I appologize to him and others in the forum if I sounded patronizing and my response was unclear and long-winded.
Keith