topic Hang on - a line can be more in Intel® Fortran Compiler

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

WSinc — Fri, 01 Nov 2013 19:45:07 GMT

* 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

Now I CAN upload it, but

WSinc — Fri, 01 Nov 2013 19:50:50 GMT

Now I CAN upload it, but could not before.

Anyway, if I say:

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

read(7,100)line

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.

Steven_L_Intel1 — Fri, 01 Nov 2013 19:58:45 GMT

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.

OK, here goes again.

WSinc — Fri, 01 Nov 2013 20:07:12 GMT

OK, here goes again.

See what you get when you

WSinc — Fri, 01 Nov 2013 20:10:10 GMT

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

WSinc — Fri, 01 Nov 2013 20:11:00 GMT

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

IanH — Fri, 01 Nov 2013 20:38:10 GMT

[fortran]CHARACTER(80) :: line
OPEN(7,file='text1.txt')
DO
READ(7,100)line
PRINT *, LEN_TRIM(line)
END DO
100 FORMAT(A)
END
[/fortran]

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

[plain]>ifort /check:all /warn:all /standard-semantics readline2.f90
Intel(R) Visual Fortran Compiler XE for applications running on IA-32, Version 14.0.1.139 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.

-out:readline2.exe
-subsystem:console
readline2.obj

>readline2.exe
15
1
2
3
4
5
4
3
2
1
65
33
5
4
5
12
50
50
12
11
1
10
30
forrtl: severe (24): end-of-file during read, unit 7, file U:\projects\FortranMisc\2013-10-30 read-a-line\text1.txt[/plain]

Hang on - a line can be more

IanH — Fri, 01 Nov 2013 20:43:05 GMT

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

[plain]123456789 ABCDEF[/plain]

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.

WSinc — Fri, 01 Nov 2013 20:56:00 GMT

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

andrew_4619 — Fri, 01 Nov 2013 20:59:17 GMT

[fortran]program Console1

implicit none
integer :: il, ierr
character(256) :: gchar
open(15,file='text1.txt',status='old',iostat=ierr)
do while (ierr.eq.0)
read(15,'(A)',iostat=ierr) gchar
il=len_trim(gchar)
print *, il
print *, gchar(1:il)
enddo
pause
end program Console1[/fortran]

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.

OK, I will try yours too -

WSinc — Fri, 01 Nov 2013 21:01:36 GMT

OK, I will try yours too -

Thanks for the input ! ! !

If you care about characters

Steven_L_Intel1 — Fri, 01 Nov 2013 21:03:44 GMT

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.

You do not need to scan

andrew_4619 — Fri, 01 Nov 2013 21:05:19 GMT

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

Steven_L_Intel1 — Fri, 01 Nov 2013 21:18:04 GMT

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

@steve Yes I stand corrected.

andrew_4619 — Fri, 01 Nov 2013 22:52:04 GMT

@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..

Bill,

John_Campbell — Sat, 02 Nov 2013 00:21:00 GMT

Bill,

Is this the text file that produced the problems ?

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

John