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

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

imagem de billsincl

* 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
Último post
Para obter mais informações sobre otimizações de compiladores, consulte Aviso sobre otimizações.
imagem de billsincl

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.

imagem de Steve Lionel (Intel)

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.

Steve
imagem de billsincl

OK, here goes again.

Anexos: 

AnexoTamanho
Download text1.txt378 bytes
imagem de billsincl

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.

imagem de billsincl

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.

imagem de IanH

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

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 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
[U:projectsFortranMisc2013-10-30 read-a-line]
>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:projectsFortranMisc2013-10-30 read-a-linetext1.txt

imagem de IanH

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.

imagem de billsincl

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.

imagem de app4619

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

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.

Anexos: 

AnexoTamanho
Download capture.gif24.73 KB
imagem de billsincl

OK, I will try yours too -

Thanks for the input ! ! !

imagem de Steve Lionel (Intel)

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.

Steve
imagem de app4619

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.

imagem de Steve Lionel (Intel)

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
imagem de app4619

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

imagem de John Campbell

Bill,

Is this the text file that produced the problems ?

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

John

Anexos: 

AnexoTamanho
Download test1.log4.19 KB

Faça login para deixar um comentário.