Fortran FORTRAN in linuxread file problems

  • Thread starter Thread starter jelanier
  • Start date Start date
  • Tags Tags
    File Fortran
AI Thread Summary
The discussion centers around a FORTRAN program that encounters an EOF error when attempting to read from a file on a Linux system, despite functioning correctly on Windows. The user, Jim, shares a simple program that reads data from "input.dat" and processes it. The EOF error occurs at line 12 during the read operation. Suggestions from other users include checking the file's existence and specifying the complete path to "input.dat." It is noted that if the file does not exist, FORTRAN may create an empty file, leading to the EOF error. A recommended solution involves using the "status='old'" option in the open statement to ensure the file must exist. Ultimately, Jim discovers that the issue is related to the end-of-file character in the input file. By adding a newline character at the end of the file, the program successfully reads the data. The discussion also touches on how different text editors handle line endings and EOF characters, highlighting the differences between Windows and Unix/Linux systems.
jelanier
Messages
67
Reaction score
1
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
 
Technology news on Phys.org
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.
 
jtbell said:
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
 
Is output.dat a new file or one which already exists?

If it is new, I would add STATUS = 'NEW' to the open command.
 
SteamKing said:
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.
 
When you do
Code:
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
Code:
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.
 
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
 
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.
 
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" :devil:
 
  • #10
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


gsal said:
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.
 
  • #11
AlephZero said:
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" :devil:

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

Thanks,

Jim
 
  • #12
jelanier said:
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.
 
  • #13
Mark44 said:
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
 

Attachments

  • files.jpg
    files.jpg
    103.7 KB · Views: 528
  • #14
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.
 

Similar threads

Replies
8
Views
1K
Replies
25
Views
3K
Replies
5
Views
5K
Replies
12
Views
3K
Replies
4
Views
2K
Replies
17
Views
6K
Replies
5
Views
2K
Replies
2
Views
870
Back
Top