Cant read TXT files?

[WSinc]

Apparently with I use LEN_TRIM to get the length of an input line,

it stops when I come to a blank character.

I thought LEN_TRIM was supposed to give me the length of the whole line.

Is there some other way to get that?

For example:

100  format(A)

open(5,file="text1.txt")

character*80 line

integer ll

read ( *,100)line

ll=len_trim(line)

if text1.txt has AA BBB CCCC DDDDD in it, I get  ll=2.

[WSinc]

I can't edit this post. Why?

[WSinc]

Here is another more elaborate example.

README.txt was generated by the VS when I first opened the project.

[WSinc]

Here is another more elaborate example.

README.txt was generated by the VS when I first opened the project.

[IanH]

5 is a bit of an unfortunate choice of unit number.  For ifort and many other compilers it corresponds to the logical unit used for standard output (the same as used by a print statement or write (*,...)).

(Though it is unfortunate that ifort continues to use those numbers for that role with /standard-semantics.)

If I modify your program to write its own little test file, I don't see the behaviour you describe.

[fortran]    program test19
    implicit none
    character*10 line
    integer ll
    open(10,file="2013-10-30 readline.txt", status='replace', action='write')
    write(10,"(A)") 'AA BBB CCCC DDDDD'
    close(10)
    
    open(10,file="2013-10-30 readline.txt")
    do
      read(10,100,end=90)line
100 format(A)
    ll=len_trim(line)
    print *,"ll=",ll
    enddo
90  print *,"EOF encountered"
    read "()"
    end program test19
[/fortran]

I get ll=10, which is the length of the character variable.

[WSinc]

Well of course the FORTARAN library is compatible

with files that IT HAS WRITTEN, but I was trying to point out the problem with files

of type TXT. So is there some other way to read those?

That other more elaborate example gives wrong values for the line lengths.

[mecej4]

If you want to read an entire record (i.e, line) into a character type variable, and the line is likely to contain blanks, do not use list-directed input. The Fortran Ref. Man. says under the rules for list-directed input:  "A nondelimited character string is terminated by the first blank, comma, slash, or end-of-record encountered".

Secondly, declare the character variable to be of sufficient size to hold the largest input line in the data file being read.

[IanH]

I initially made the same mistake - seeing the * in the read and immediately thinking this was simply due to list directed format.  But the formats in the code examples are explicit "(A)".

Bill - could you attach the problematic text file?

[WSinc]

The text file is the one that Visual studio generates in the README.TXT

when you open a new project. But if you want me to upload it, I will.

I am not on the same computer right now.

[IanH]

I just used the README.txt from creating an ifort console project in visual studio and I see:

[plain] ll= 10
 ll= 10
 ll= 10
 ll= 0
 ll= 9
 ll= 10
 ll= 0
 ll= 9
 ll= 9
 ll= 0
 ll= 10
 ll= 10
 ll= 10
 ll= 9
 ll= 10
 ll= 10
 ll= 0
 ll= 10
 ll= 10
 ll= 10
 ll= 0
 ll= 10
 ll= 10
 ll= 0
 ll= 10
 EOF encountered[/plain]

which is what I'd expect. 

All but the same program as what you attached, (same as what I attached above, but with the file writing bit chopped out) but with the unit number changed to 10.  Compiled with /warn:all /check:all /standard-semantics.

Check that what you are running is what you think it is, that what is actually the input file is what you think it is, and make sure your program doesn't use READ (*,*) list directed formatting, as mecej4 (why the "4"?) suggests.

[John_Campbell]

A likely reason for the read problem is the file is not a DOS format file. This is about the only source of a read error you can get with an A format.
In a DOS file, each line is terminated with <CR><LF>.
I think for a unix file, each line is terminated with a <LF> only and I have recently scanned a file that uses <CR> only.
Opening the file as unformatted, fixed length records with length of 1 byte should allow you to read each byte and determine the contents.

Wordpad is fairly robust for looking at small "text" files.

John

[Les_Neilson]

Bill,
If you change the print statement to also include printing the variable "line" (without the trim), then you would see exactly what had been read in. You could also try to look at the readme file in an editor which is able to display the contents in hexadecimal to see what comes after the first two characters, something is causing the read to stop after them. The test19 code as written should work but ...

Les

[WSinc]

What it seems to be returning is the number of characters until the first blank is encountered. Now if the file is WRITTEN with a Fortran Write statement, then blanks don't trigger that, as we might expect. So the problem isn't reading the file in, as it is using the LEN_TRIM statement to get the

length actually read in.

I will experiment with this some more. Maybe there is a special way to open the file, as has been suggested.

Or perhaps the Fortran libray was not suited to read in files of this type? 

[andrew_4619]

In your example test19.f90 you have 

character*10 line

so you will never get a length LL greater than 10.  The example Ian posted seems to give correct answers. You need to declare the buffer larger than the max line length.

[WSinc]

OK, I will try different TXT files. I was hoping I could get this to work with ANY one that meets their criterion.

As soon as I get back to the other computer, I will send some examples.

[John_Campbell]

Bill,

You should attach the file so we can look at the contents.

Could len_trim be responding to a null character value that is being read in?

John

ps: I tried the attached example, to include null, CR or LF characters in the string, but always returned the active string length, ignoring trailing blanks. Even extending the active string with a null worked. Attach the file so we can see the problem.
Should you check your disk for errors !!

pps: A have attached a program that reads any file, opening as binary, which looks for control characters. It should read any file up to the "end_of_file" and can report any control characters and also the end of line control format. Give it a go and report what it finds. If the problem is the file content then this should identify it.  Failing that as the source of the problem, you must have a coding problem that you have not identified.
For reading text files, "format (A)" is usually very robust !!