Home > Archive > Fortran > February 2007 > reading lines with trailing white spaces
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
reading lines with trailing white spaces
|
|
| Kamaraju S Kusumanchi 2007-02-22, 4:16 am |
| I am having very basic problem with reading lines in a file with trailing
white spaces. Consider
program copy_a_file
! Fortran 90 program to copy a file
implicit none
integer :: ios
integer, parameter :: file_len=20, line_len=200
character(len=file_len) :: filename1, filename2
character(len=line_len) :: line
write(filename1, '(A)') 'copy_a_file.f90'
write(filename2, '(A)') 'temp.txt'
write(*,*) '******************************'
write(*,*) 'cp ', filename1, ' ', filename2
write(*,*) '******************************'
open(unit=101, file=filename1, action='read')
open(unit=102, file=filename2, action='write')
do
! read a line from file
read(101,'(A)', IOSTAT=ios) line
! negative IOSTAT indicates that an "end of file" or "end of record"
! condition occurred
if (ios < 0) then
exit
else
write(102,'(A)') trim(line)
end if
end do
close(unit=101)
close(unit=102)
end program copy_a_file
The strategy I am adopting is to read a line into chracter array of size 200
and then trim it and write it into a new file. Because of the trim function
I will loose all the trailing spaces in the original file. If I dont use
the trim function, I will end up with lines of length 200 (filled with
spaces at the end) even if the lines in the original file are shorter than
200 characters width. I want to have an exact copy of the original file and
I want to do this in Fortran (since the actual problem is somewhat
different)...
My questions are
1) Is there a clever way of copying a file into another file even if has
some trailing white space characters?
2) Is there a clever way of reading lines with trailing white spaces and
preserving them?
thanks
raju
--
Kamaraju S Kusumanchi
http://www.people.cornell.edu/pages/kk288/
http://malayamaarutham.blogspot.com/
| |
| Arjen Markus 2007-02-22, 4:16 am |
| > My questions are
> 1) Is there a clever way of copying a file into another file even if has
> some trailing white space characters?
> 2) Is there a clever way of reading lines with trailing white spaces and
> preserving them?
>
Yes, there is: non-advancing I/O. That will allow you to read
up to the end of the line and get the length of the line back.
I use that in a module to handle strings of arbitrary length
(for storage and simple manipulations, not as a general-purpose
facility). See: http://flibs.sf.net
Regards,
Arjen
| |
| Terence 2007-02-22, 4:16 am |
| This is a common problen in parsing text in natural-language compilers
or in langauage translations. I suggest you read a file as unformatted
binary in suitable blocks, taking the error exit to an EOF-marking
statement before the normal exit from the read (and stoppig on end-
block or #1a).
Process the data by calling a subroutine which gets text strings from
the current block, and advancing an index pointer, up to a blank or
punctuation, and which returns the length of the word and a code for
the delimiter. Note that "any language" means character codes #20
through #FF are often valid, and you may have to locate and process
tabs and other characters in the #01 to #1F range other than then
expected #0A, #0D and a final #1A.
| |
| Richard Maine 2007-02-22, 4:16 am |
| Terence <tbwright@cantv.net> wrote:
> I suggest you read a file as unformatted
> binary in suitable blocks,...
I suggest instead that the OP follow Arjen's advice, which is
standard-conforming, portable, and simple. Why we needed to follow it
with a suggestion that has none of those properties puzzles me. I won't
bother to detail all the issues that come up with Terence's approach.
There are times when one has to resort to such things, but this isn't
one of those times.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Kamaraju S Kusumanchi 2007-02-22, 4:16 am |
| Terence wrote:
> This is a common problen in parsing text in natural-language compilers
> or in langauage translations. I suggest you read a file as unformatted
> binary in suitable blocks, taking the error exit to an EOF-marking
> statement before the normal exit from the read (and stoppig on end-
> block or #1a).
> Process the data by calling a subroutine which gets text strings from
> the current block, and advancing an index pointer, up to a blank or
> punctuation, and which returns the length of the word and a code for
> the delimiter. Note that "any language" means character codes #20
> through #FF are often valid, and you may have to locate and process
> tabs and other characters in the #01 to #1F range other than then
> expected #0A, #0D and a final #1A.
Oh boy! I dont have time to do all this complicated stuff. I will just use
C++ or C which handles this kind of jobs easily!
--
Kamaraju S Kusumanchi
http://www.people.cornell.edu/pages/kk288/
http://malayamaarutham.blogspot.com/
| |
| Kamaraju S Kusumanchi 2007-02-22, 4:16 am |
| Arjen Markus wrote:
>
> Yes, there is: non-advancing I/O. That will allow you to read
> up to the end of the line and get the length of the line back.
>
> I use that in a module to handle strings of arbitrary length
> (for storage and simple manipulations, not as a general-purpose
> facility). See: http://flibs.sf.net
Could you narrow it down a bit as to which subroutines I have to look etc.,?
When I glanced over textstream_readbuffer subroutine, the code happily uses
goto statements. Is this a nice of doing it?
raju
--
Kamaraju S Kusumanchi
http://www.people.cornell.edu/pages/kk288/
http://malayamaarutham.blogspot.com/
| |
| Richard Maine 2007-02-22, 4:16 am |
| Kamaraju S Kusumanchi <kamaraju@bluebottle.com> wrote:
> Oh boy! I dont have time to do all this complicated stuff. I will just use
> C++ or C which handles this kind of jobs easily!
So does Fortran, if you follow Arjen's advice. The complications of
Terence's suggestion are not inherent in the language - just in his way
of using it.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Terence 2007-02-22, 4:16 am |
| I understand what the OP was doing, but it's all part of a general
problem with reading text, including one of just multiple spaces in
text lines.
We use a tool we wrote to compare text files (obviously mainly Fortran
source code for different versions and uses) to find important
differences in the code (which are not spaces of course), so the files
have to be massaged in the input process, so that stopping is only on
real differences.
And we write commercial natural-language compilers which need the same
text massaging.
So we just use the one general parser tool to solve similar problems
evry time they arise.
Once written, the investment is made.
| |
| Arjen Markus 2007-02-22, 4:16 am |
| On 22 feb, 10:12, Kamaraju S Kusumanchi <kamar...@bluebottle.com>
wrote:
> Arjen Markus wrote:
>
>
>
> Could you narrow it down a bit as to which subroutines I have to look etc.,?
>
> When I glanced over textstream_readbuffer subroutine, the code happily uses
> goto statements. Is this a nice of doing it?
>
> raju
>
> --
> Kamaraju S Kusumanchihttp://www.people.cornell.edu/pages/kk288/http://malayamaarutham.blogspot.com/
Oh, I rather meant this routine: http://flibs.sourceforge.net/textstr.html#12
And, although gotos have a bad reputations, sometimes it is a very
natural
construct to use.
Regards,
Arjen
| |
| meek@skyway.usask.ca 2007-02-22, 8:08 am |
| In a previous article, Kamaraju S Kusumanchi <kamaraju@bluebottle.com> wrote:
>I am having very basic problem with reading lines in a file with trailing
>white spaces. Consider
>
>program copy_a_file
> ! Fortran 90 program to copy a file
> implicit none
If all you want to do is copy a file, a system call the easiest
way.
Chris
<snip rest>
| |
| David Frank 2007-02-22, 8:08 am |
|
"Kamaraju S Kusumanchi" <kamaraju@bluebottle.com> wrote in message
news:erjm97$k4a$1@ruby.cit.cornell.edu...
> Terence wrote:
>
>
> Oh boy! I dont have time to do all this complicated stuff. I will just use
> C++ or C which handles this kind of jobs easily!
>
> --
> Kamaraju S Kusumanchi
> http://www.people.cornell.edu/pages/kk288/
> http://malayamaarutham.blogspot.com/
If you just want a simple way to copy a file you dont have to look for
out-of-language help, just use a modified version of below which works NO
MATTER WHAT the file contains..
program copy_a_file
character :: byte
open (1,file='old.dat',form='binary')
open (2,file='new.dat',form='binary')
do
read (1,end=101) byte
write (2) byte
end do
101 stop
end program
| |
| Paul van Delst 2007-02-22, 7:08 pm |
| Kamaraju S Kusumanchi wrote:
> The strategy I am adopting is to read a line into chracter array of size 200
> and then trim it and write it into a new file. Because of the trim function
> I will loose all the trailing spaces in the original file. If I dont use
> the trim function, I will end up with lines of length 200 (filled with
> spaces at the end) even if the lines in the original file are shorter than
> 200 characters width. I want to have an exact copy of the original file and
> I want to do this in Fortran (since the actual problem is somewhat
> different)...
>
> My questions are
> 1) Is there a clever way of copying a file into another file even if has
> some trailing white space characters?
In Fortran? Yes:
call system('cp file1 file2')
(or whatever your flavour of compiler+OS requires)
Not portable without due considerations but your history of posts to clf indicate you know
what you're doing so I doubt the non-portable-ness is that big of a hurdle. It's easily
isolated.
I would challenge the need to replicate such a basic functionality in Fortran. I'm not
saying you can never have good reasons to want/need to do it, just that I would want a
full explanation as to why. Your other posts suggest that doing it in C/C++ is also an
option which probably introduces other issues so the "portable Fortran"-only solution
doesn't seem so compelling.
cheers,
paulv
--
Paul van Delst Ride lots.
CIMSS @ NOAA/NCEP/EMC Eddy Merckx
| |
| Kamaraju S Kusumanchi 2007-02-22, 7:08 pm |
| m @skyway.usask.ca wrote:
> In a previous article, Kamaraju S Kusumanchi <kamaraju@bluebottle.com>
> wrote:
>
> If all you want to do is copy a file, a system call the easiest
> way.
> Chris
> <snip rest>
The actual problem is quite different and I was unable to achieve it with a
system command.
I have say 4 files each 100 lines. I want to copy first 10 lines of file1,
10 lines of file2 ... 10 lines of file4 and put them in a big_file. Next I
wanted to copy lines 11-20 from file1, lines 11-20 from file2 ... lines
11-20 from file4 and append them to the big_file. Repeat the process till
the end. I dont think there is any system command which can do copy of data
interspersed across different files.
raju
--
Kamaraju S Kusumanchi
http://www.people.cornell.edu/pages/kk288/
http://malayamaarutham.blogspot.com/
| |
| Kamaraju S Kusumanchi 2007-02-22, 7:08 pm |
| Kamaraju S Kusumanchi wrote:
> m@skyway.usask.ca wrote:
>
>
> The actual problem is quite different and I was unable to achieve it with
> a system command.
>
> I have say 4 files each 100 lines. I want to copy first 10 lines of file1,
> 10 lines of file2 ... 10 lines of file4 and put them in a big_file. Next I
> wanted to copy lines 11-20 from file1, lines 11-20 from file2 ... lines
> 11-20 from file4 and append them to the big_file. Repeat the process till
> the end. I dont think there is any system command which can do copy of
> data interspersed across different files.
>
> raju
>
Sorry, I should have explained why I have 4 files to begin with. I have a
parallel program running with MPI with 4 processes. The number 4 is
arbitrary and can go up as 4, 8, 16, .... Let's denote it by NP. In this
MPI program, I have let's say xvel(0:512,0:512,0:512/NP) which is computed
at different timesteps. But each process has access to 1/NP th of xvel.
process 0 will have xvel(0:512,0:512,0:127),
process 1 will have xvel(0:512,0:512,128:255),
....
process 3 will have xvel(0:512,0:512,384:511)
The output from the program is (NP=4) written i into NP files as follows
output_p0.txt
timestep=0
xvel(0:512,0:512,0:127)
yvel(0:512,0:512,0:127)
timestep=1
xvel(0:512,0:512,0:127)
yvel(0:512,0:512,0:127)
....
timestep=100
xvel(0:512,0:512,0:127)
yvel(0:512,0:512,0:127)
output_p1.txt
timestep=0
xvel(0:512,0:512,128:255)
yvel(0:512,0:512,128:255)
timestep=1
xvel(0:512,0:512,128:255)
yvel(0:512,0:512,128:255)
....
timestep=100
xvel(0:512,0:512,384:511)
yvel(0:512,0:512,128:255)
and so on upto output_p3.txt
however when debugging the program it is useful to have as follows
timstep_0.txt
timestep=0
xvel(0:512,0:512,0:127)
xvel(0:512,0:512,128:255)
....
xvel(0:512,0:512,384:511)
yvel(0:512,0:512,0:127)
yvel(0:512,0:512,128:255)
....
yvel(0:512,0:512,384:511)
timestep_1.txt
timestep=1
xvel(0:512,0:512,0:127)
xvel(0:512,0:512,128:255)
....
xvel(0:512,0:512,384:511)
yvel(0:512,0:512,0:127)
yvel(0:512,0:512,128:255)
....
yvel(0:512,0:512,384:511)
....
upto timestep=100
etc., Due to amount of memory involved in these calculations, I cannot do
MPI_Gather . I am using MPI standard 1.1, Fortran 90/95, Using Debian
GNU/Linux.
I have chosen the size as 512, timesteps=100, 2 velocity arrays arbitrarily
but in actual problem they could be different...
raju
--
Kamaraju S Kusumanchi
http://www.people.cornell.edu/pages/kk288/
http://malayamaarutham.blogspot.com/
| |
| Gordon Sande 2007-02-22, 7:08 pm |
| On 2007-02-22 12:16:23 -0400, Kamaraju S Kusumanchi
<kamaraju@bluebottle.com> said:
> m@skyway.usask.ca wrote:
>
>
> The actual problem is quite different and I was unable to achieve it with a
> system command.
>
> I have say 4 files each 100 lines. I want to copy first 10 lines of file1,
> 10 lines of file2 ... 10 lines of file4 and put them in a big_file. Next I
> wanted to copy lines 11-20 from file1, lines 11-20 from file2 ... lines
> 11-20 from file4 and append them to the big_file. Repeat the process till
> the end. I dont think there is any system command which can do copy of data
> interspersed across different files.
>
> raju
Sounds like a second lecture in AWK type of problem.
The small scripting languages can be very useful for this type of problem.
On occassion mixed language or some other language can be worth the bother
of learning the other language.
| |
| Kamaraju S Kusumanchi 2007-02-22, 7:08 pm |
| >
> Oh, I rather meant this routine:
> http://flibs.sourceforge.net/textstr.html#12
>
Cool! Thanks. I was reading "Fortran 95 Handbook" by Adams, Brainerd,
Martin, Smith, Wagener. Before posting here, I read the non-advancing I/O
from that book but did not understand how it could be useful in my case.
Your example helped a lot.
I have modified my original code with the advance='no' as follows. It is
working. It is not as advanced as yours but thought it could help someone
else in the future looking for it in the archives.
program copy_a_file2
! Fortran 90 program to copy a file
implicit none
integer :: reclen ! length of the record
integer, parameter :: file_len=20, line_len=200
character(len=file_len) :: filename1, filename2
character(len=line_len) :: line
write(filename1, '(A)') 'copy_a_file2.f90'
write(filename2, '(A)') 'temp.txt'
write(*,*) '******************************'
write(*,*) 'cp ', filename1, ' ', filename2
write(*,*) '******************************'
open(unit=101, file=filename1, action='read')
open(unit=102, file=filename2, action='write')
do
! read a line from file
read(101,'(A)', advance='no', end=180, eor=170, size=reclen) line
170 write(102, '(A)') line(1:reclen)
cycle
180 exit
end do
close(unit=101)
close(unit=102)
end program copy_a_file2
> And, although gotos have a bad reputations, sometimes it is a very
> natural
> construct to use.
>
Coming from a C,C++ background I have been told to avoid GOTO like hell.
But, I guess, it is more of a choice/style ...
raju
--
Kamaraju S Kusumanchi
http://www.people.cornell.edu/pages/kk288/
http://malayamaarutham.blogspot.com/
| |
| David Jones 2007-02-22, 7:08 pm |
| Kamaraju S Kusumanchi wrote:
>
> Sorry, I should have explained why I have 4 files to begin with. I
> have a parallel program running with MPI with 4 processes. The
number
> 4 is arbitrary and can go up as 4, 8, 16,
Have you thought of using a single file opened for "direct access"
rather than sequential access and write to the same file from all
processes ... you would just need to work out which record number to
write to with what information. I don't know if there are difficulties
in simultaneous access of the same file by different processes ...
this may vary a lot between implementations.
David Jones
| |
| Paul van Delst 2007-02-22, 7:08 pm |
| David Jones wrote:
> Kamaraju S Kusumanchi wrote:
> number
>
>
> Have you thought of using a single file opened for "direct access"
> rather than sequential access and write to the same file from all
> processes ... you would just need to work out which record number to
> write to with what information. I don't know if there are difficulties
> in simultaneous access of the same file by different processes ...
> this may vary a lot between implementations.
That path is fraught with issues - each MPI process would have to keep track of the record
numbers written by each other process. Doable, I guess, but what a pita. I believe there
is an MPI read/write functionality, but I've never used it.
The OPs original solution is a common/simple method of combining o/p from different
processes. (Although I still don't understand why losing blank space to EOL is an issue,
but I also don't know anything about his post-processing).
cheers,
paulv
--
Paul van Delst Ride lots.
CIMSS @ NOAA/NCEP/EMC Eddy Merckx
| |
| Terence 2007-02-22, 7:08 pm |
| After the OP's clarification of his problem, I see he could just write
a tiny Fortran program to open his 2^^N files (up to a practical limit
of say 64) in sequential mode, then read from each in sequence, the L
lines he needs from each file, writing them to one single new file.
Eventually, if he needs more than 64 input files, he merges his output
files the same way, but counting a different number of lines (N*L) on
this pass.
If he needs to, he can now strip off any trailings blanks in the last
output file, althought I don't see the point any more.
| |
| Kamaraju S Kusumanchi 2007-02-22, 7:08 pm |
| Paul van Delst wrote:
> The OPs original solution is a common/simple method of combining o/p from
> different processes. (Although I still don't understand why losing blank
> space to EOL is an issue, but I also don't know anything about his
> post-processing).
You are right that losing trailing blank characters is not an issue in this
case. I just wanted to preserve the white spaces, I guess. I just took the
problem up to try and learn something new!
raju
--
Kamaraju S Kusumanchi
http://www.people.cornell.edu/pages/kk288/
http://malayamaarutham.blogspot.com/
| |
| andy2O 2007-02-22, 7:08 pm |
| On 22 Feb, 16:55, Kamaraju S Kusumanchi <kamar...@bluebottle.com>
wrote:
>
> Cool! Thanks. I was reading "Fortran 95 Handbook" by Adams, Brainerd,
> Martin, Smith, Wagener. Before posting here, I read the non-advancing I/O
> from that book but did not understand how it could be useful in my case.
> Your example helped a lot.
>
> I have modified my original code with the advance='no' as follows. It is
> working. It is not as advanced as yours but thought it could help someone
> else in the future looking for it in the archives.
>
> program copy_a_file2
> ! Fortran 90 program to copy a file
> implicit none
>
> integer :: reclen ! length of the record
> integer, parameter :: file_len=20, line_len=200
> character(len=file_len) :: filename1, filename2
> character(len=line_len) :: line
>
> write(filename1, '(A)') 'copy_a_file2.f90'
> write(filename2, '(A)') 'temp.txt'
> write(*,*) '******************************'
> write(*,*) 'cp ', filename1, ' ', filename2
> write(*,*) '******************************'
>
> open(unit=101, file=filename1, action='read')
> open(unit=102, file=filename2, action='write')
> do
> ! read a line from file
> read(101,'(A)', advance='no', end=180, eor=170, size=reclen) line
>
> 170 write(102, '(A)') line(1:reclen)
> cycle
> 180 exit
> end do
> close(unit=101)
> close(unit=102)
> end program copy_a_file2
>
>
> Coming from a C,C++ background I have been told to avoid GOTO like hell.
> But, I guess, it is more of a choice/style ...
>
> raju
>
> --
> Kamaraju S Kusumanchihttp://www.people.cornell.edu/pages/kk288/http://malayamaarutham.blogspot.com/
<pedant>
one *minor* point: shouldn't your unit numbers really lie between 1
and 99 to be standard conforming? i have memories of getting errors
(or warnings at least) for using numbers outside this range not that
long ago (i'm not sure which compiler - i've used a lot recently). i'm
sure it's a common extension though to allow higher values though...
see e.g: http://www.qmw.ac.uk/~cgaa260/BUILD...IO/UNITNUMB.HTM
</pedant>
:-)
andy
| |
| Paul van Delst 2007-02-22, 7:08 pm |
| Kamaraju S Kusumanchi wrote:
> Paul van Delst wrote:
>
>
> You are right that losing trailing blank characters is not an issue in this
> case. I just wanted to preserve the white spaces, I guess. I just took the
> problem up to try and learn something new!
A noble and worthy goal. Please let the group know that in the future. :o)
Maybe it's just me, or maybe it applies to the wider clf audience, but when someone posts
a problem they're having with doing something, my initial reaction is usually to ask why
they want to do that (in the hope that the *true* problem will be exposed after some
digging). Unlike your case, it's a fairly common occurrance that either a) people don't
know what their actual problem is, or b) they're masking the actual problem by simplifying
the question.
Anyway.. enough of my ramblings... :o)
cheers,
paulv
--
Paul van Delst Ride lots.
CIMSS @ NOAA/NCEP/EMC Eddy Merckx
| |
| Richard Maine 2007-02-22, 7:08 pm |
| andy2O <andy2O@hotmail.com> wrote:
> shouldn't your unit numbers really lie between 1
> and 99 to be standard conforming?
No. The standard says nothing even vaguely related to that. The standard
just says that they have to be positive. Any particular limits beyond
that are compiler dependent.
I would say that staying between 1 and 99 is a good guideline (well,
better between 10 and 99, as compilers often reserve various of the
single-digit ones for special purposes). There have been compilers with
those as limits. However, that is just a portability guideline - not
anything even hinted at by the standard.
Newer compilers tend to be more permissive in this area. I think that
most/many new compilers probably allow any positive integer. But I still
use 99 as my personal portability guideline.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| glen herrmannsfeldt 2007-02-23, 4:15 am |
| Gordon Sande wrote:
(snip)
It can be done with combinations of head, tail, and a loop
in the appropriate shell, but it is a lot of work, and slow.
[color=darkred]
> Sounds like a second lecture in AWK type of problem.
If the number of input files is somewhat less than the maximum
that can be opened, it is easy to do in awk.
This program reads a list of file names from a file specified
on the awk command line, or stdin if none specified. The first
is the name of the output file, the rest are input files.
Then it reads the input files 10 lines at a time, writing to stdout.
It keeps going until no input remains in any file.
# read a list of files
{ files[n++]=$0}
END {
while(!done) {
done=1
# loop over files
for(i=1;i<n;i++) {
# read 10 lines and write 10 lines
for(j=0;j<10;j++) {
k=getline < files[i]
if(k>0) print > files[0]
}
# if the last getline read something, we aren't done yet
if(k>0) done=0
}
}
}
That should work with awk on any unix system. gawk (gnu awk)
is also available for windows systems.
I once had to do something similar, though it was one input
file and many (thousands) of output files. Instead of being
10 lines to each, there was a list indicating which line
went to each file. I indicated a similar method recently
for a different problem, but it went something like...
Read the list of which lines (actually groups of lines for
my problem) and which file they go to, then start reading the
input file. Take the number of the desired output file,
divide by 100 (integer division) and write to the appropriate
intermediate file. One file will have lines destined for files
0 to 99, the next for files 100 to 199, etc.
Then a second step reads each of those files and sends the output
to the appropriate file. The above process was repeated for each
set of 10000 files generated. If the number was many tens of thousands
it should be done in three steps, but we never got that far.
The opposite method should work for the OP's problem if it needs
to be done for thousands of files or more.
-- glen
| |
| Arjen Markus 2007-02-23, 4:15 am |
| > Coming from a C,C++ background I have been told to avoid GOTO like hell.
> But, I guess, it is more of a choice/style ...
>
No offense taken :) I checked my code (the textstream one), it
contains
a single goto in a routine of approximately 20 lines. I guess I could
have
used the value of an IOSTAT= variable (-2 indicates end-of-line) but I
was
probably too lazy to do it :).
Anyway:
Even in C gotos can be very useful, just as in Fortran: to avoid
cluttering
the source code that deals with the ordinary case with error handling
code
directly after the detection of the error. I have seen source code
that
aggressively tries to avoid that - as it was reading a file, after
every
read statement, several tens of them, you would see a check on
possible
I/O errors and if there was an error, the file would be closed and the
routine would return ... I leave the conclusion to you :)
Regards,
Arjen
|
|
|
|
|