FORTRAN in linuxread file problems

[jelanier]

I wrote a simple FORTRAN program to show my read problem. This works fine in windows. On the Linux machine I always get this eof error when I open a file and read. This means that every program I have written doesn't work :) The error is line 12 EOF. What is the problem? (I am using GFORTRAN in linux)

program read_write

implicit none
!reads data from a file called input.dat
integer :: i
real a(10) !single dimension array
real b(10)
open(10,file='input.dat')


do i = 1,10
read(10,*) a(i) !this is line 12
b(i) = a(i)**1.3
end do

close(10)

open(12,file='output.dat')
do i = 1,10
write (12,*) a(i),b(i)
end do

close(12)


end program read_write


oh, the input file is simply:

1
2
3
4
5
6
7
8
9
10


Thanks,

Jim

 

[jtbell]

The program may be looking for input.dat in a different directory (folder) from where it actually is. Try specifying the complete path to the file.

 

[jelanier]

The program may be looking for input.dat in a different directory (folder) from where it actually is. Try specifying the complete path to the file.

Nice try, but did not fix it. Same error. BTW I have everything in the same directory.

Jim

 

[SteamKing]

Is output.dat a new file or one which already exists?

If it is new, I would add STATUS = 'NEW' to the open command.

 

[jelanier]

Is output.dat a new file or one which already exists?

If it is new, I would add STATUS = 'NEW' to the open command.

The output file is fine. If I internally specify the input data it will always create a new output file.

IOW..I can always write files, I just can't read files.

 

[AlephZero]

When you do

open(10,file='input.dat')

if the file input.dat doesn't exist in the directory where Fortran expected to find it, it will create a new empty file. Reading from that will (obviosuly) give you an EOF error.

Do a search of your file system for "input.dat" files and delete any empty (zero length) ones that should't be there.

Then change the statement to

open(10,file='input.dat',status='old')

That will fail if Fortran it can't find the "real" input.dat file.

Usually you don't need the "status" option for an output file, because you want to overwrite an existing file if it already exists, or create a new one if it doesn't exist, and that's what happens by default.

 

[jelanier]

I found a solution. This Linux GFORTRAN compiler handles files differently than the g77 or g95 for windows.
I added a $D,$A (CR,LF) at the end of the file. It works now.

FWIW..I am using a Raspberry Pi with Debian.

Thanks everyone.

Jim

 

[gsal]

I seem to recall a problem like this. I don't remember if dos2unix/unix2dos kind of thing had something to do with it...but it certainly had something to do with the end-of-file character being right after the last entry...so, if you went to the very end and press <enter> and re-saved the file, the problem goes away.

For example, if the original file looked like this:
12.3EOL
23.4EOL
34.5EOF
If wouldn't work, but if it looked like this:
12.3EOL
23.4EOL
34.5EOL
EOF
Then, if would work.

I noticed that such condition could happen depending depending on the editor that you are using to enter the data; for example, if I use Nedit and type the data in and leave the EOF right after the last entry, Nedit automatically increases the number of line in the file and moves the EOF by itself to the next line; but, if I use something like Notepad++, it leaves the data the way I typed it.

my 2 cents.

 

[AlephZero]

It's so long since I've seen a text editor that let you create a file with an "unterminated" last line, I forgot about that problem!

But hey, one of the design goals of Unix was NOT to protect people from their own stupidity - not "what you see is what you get" but "what you got was all you deserved"

 

[jelanier]

Thanks for the reply. I have seen this before with different compilers. They all seem to handle CR LF differently. A few test programs were run and the solution was found.

Thanks again,

Jim

I seem to recall a problem like this. I don't remember if dos2unix/unix2dos kind of thing had something to do with it...but it certainly had something to do with the end-of-file character being right after the last entry...so, if you went to the very end and press <enter> and re-saved the file, the problem goes away.

For example, if the original file looked like this:
12.3EOL
23.4EOL
34.5EOF
If wouldn't work, but if it looked like this:
12.3EOL
23.4EOL
34.5EOL
EOF
Then, if would work.

I noticed that such condition could happen depending depending on the editor that you are using to enter the data; for example, if I use Nedit and type the data in and leave the EOF right after the last entry, Nedit automatically increases the number of line in the file and moves the EOF by itself to the next line; but, if I use something like Notepad++, it leaves the data the way I typed it.

my 2 cents.

 

[jelanier]

It's so long since I've seen a text editor that let you create a file with an "unterminated" last line, I forgot about that problem!

But hey, one of the design goals of Unix was NOT to protect people from their own stupidity - not "what you see is what you get" but "what you got was all you deserved"

No problem! I am writing a compiler that compiles "what you meant to do" hehe

Thanks,

Jim

 

[Mark44]

Thanks for the reply. I have seen this before with different compilers. They all seem to handle CR LF differently. A few test programs were run and the solution was found.

Operating systems handle ends of lines differently. IIRC, Windows adds a <CR> <LF> pair at the end of a line, while Unix and Linux add only a <CR> character.

 

[jelanier]

Operating systems handle ends of lines differently. IIRC, Windows adds a <CR> <LF> pair at the end of a line, while Unix and Linux add only a <CR> character.

That has not been my experience. The linux text editor I use only places a LF ($0A).

I saved the file with no "enter" at the end of the last line, and again with enter at the end.

The one with no enter, has nothing after the last character. The one with "enter" has only a LF ($0A) after the last character.

see attachment. (I used Leafpad in Debian Linux for this test)

Thanks,

Jim

 

[gsal]

As people develop their own editors, they can do whatever they want regardless of operating system and/or cater to both; in particular, if they are developing a multi-platform text editor...all you have to do is go to the settings and pick how you want your lines terminated: Windows or Unix style.