TXT file not read properly by Fortran I/O. Why?

TXT file not read properly by Fortran I/O. Why?

* Why can't I attach the test file? *****

BTW "select media" hangs it up, and the whole thing is lost.


This file looks fine when I read it in with NOTEPAD or some other editor, but when

the Fortran I/O library reads it in, it truncates lines at the first blank.

I am trying to figure out what the editor does to it that changes its properties.

The README.TXT files generated by VS can be read OK by the fortran library,

but this one has some subtle difference that screws up the FORTRAN I/O.

How may I get a HEX dump of the file?


This file looks fine when I read it in with NOTEPAD or some other editor, but when


16 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Now I CAN upload it, but could not before.

Anyway, if I say:



100 format(A)

It doesn't read the whole line in, if any blanks occur before the end.

So sometimes during the process of editing it,

it altered the properties of the file, but it is still

editable from NOTEPAD or some other editor.

Maybe a HEX DUMP would isolate the problem.

Bill, I don't see the upload. I suggest a ZIP of your source and the file. I also didn't see any reaction to the note that your character variable was only 10 characters long. When you upload, be sure to click "Start Upload" after selecting the file.

Retired 12/31/2016

OK, here goes again.


Downloadtext/plain text1.txt378 bytes

See what you get when you write a 3 line fortran program. Does it trucnate any lines on your end?

That first line has embedded blanks in it, it does truncate it on my end.

That 10 character thing was an oversight, yet some of the lines were more than 10 characters long, and it was returning line

lengths shorter then 10 characters in some cases.

CHARACTER(80) :: line
  PRINT *, LEN_TRIM(line)

I don't see the behaviour you describe...

>ifort /check:all /warn:all /standard-semantics readline2.f90
Intel(R) Visual Fortran Compiler XE for applications running on IA-32, Version Build 20131008
Copyright (C) 1985-2013 Intel Corporation.  All rights reserved.
Microsoft (R) Incremental Linker Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.
[U:projectsFortranMisc2013-10-30 read-a-line]
forrtl: severe (24): end-of-file during read, unit 7, file U:projectsFortranMisc2013-10-30 read-a-linetext1.txt

Hang on - a line can be more than ten characters and you will get a response less than 10, LEN_TRIM tells you the significant length of what's been read, not what was the original line.  If you have a line with

123456789 ABCDEF

and you read it into a CHARACTER(10) variable, the variable will contain '123456789 ', where the last character is a blank.

LEN_TRIM of that is then 9.  Trailing blanks are not counted.  That's independent of where they originally come from.

Is that what you are referring to?  If so, and you want to count trailing blanks that were originally in the line, then you need to do things a little differently.

I guess that was the problem. So do you think I should just write a routine that will

scan the line backwards and look for the first non-blank character?

That's sure easy enough to do......

with the text files I am working with, I don't care about trailing blanks anyway.

program Console1
   implicit none
   integer :: il, ierr
   character(256) :: gchar 
   do while (ierr.eq.0) 
       read(15,'(A)',iostat=ierr) gchar 
       print *, il
       print *, gchar(1:il)
end program Console1

I did something similar, the output is in the screen capture attached. It seem to work just fine. you need to post the source you actually used in full and then the cause of the error can be seen.


Downloadimage/gif capture.gif24.73 KB

OK, I will try yours too -

Thanks for the input ! ! !

If you care about characters past the first 10, then the variable you read the line into has to be long enough for the longest possible line. In typical applications I write for handling text files, I use 256 or 512 as the length.

If you do that, then LEN_TRIM will do what you want.

Retired 12/31/2016

You do not need to scan backwards len_trim does what you want. If you want to scan backwards you would need to declare the character to be longer than the longest line in the file and then fill it fully with blanks before the read each time otherwise there will be junk in the character string after the last character read potentially.

No, you don't have to fill it with blanks. The variable will be padded with blanks automatically if a shorter line is read.

Retired 12/31/2016

@steve Yes I stand corrected. Formated internal read/write can leave junk issues though hence I have a habit of nulling character buffers, and ocasionally I must do this uncessarily out of habit/percieved safety.. 


Is this the text file that produced the problems ?

Attached is my trace of the file, which shows nothing unusual.



Downloadapplication/octet-stream test1.log4.19 KB

Leave a Comment

Please sign in to add a comment. Not a member? Join today