Home > Archive > Fortran > November 2004 > Parsing blanks in Fortran 90/95
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 |
Parsing blanks in Fortran 90/95
|
|
| Romain DUJOL 2004-11-21, 3:58 pm |
| Hello,
This must not be a new problem, but here's the issue :
CHARACTER(255) :: fileName
CHARACTER(255) :: currentLine
OPEN(UNIT = 10, FILE = fileName, &
STATUS = 'OLD' , &
ACCESS = 'SEQUENTIAL', &
ACTION = 'READ' )
READ(10, '(A)') currentLine
READ(currentLine, '(''VALUE'',''='',I)') n
In the file 'fileName' I have the line :
VALUE = 4
The program compiles but executes with error on the '='.
I tested without blanks around the '=' and it goes well.
I looked for old posts and found the option BLANK = 'NULL' :
unfortunately, it does not work.
Is it possible to solve the problem in a simple way ?
Thanks in advance.
| |
| Phillip Helbig---remove CLOTHES to reply 2004-11-21, 8:57 pm |
| In article <a0a6d8b9.0411210902.68c25718@posting.google.com>,
romain.dujol@caramail.com (Romain DUJOL) writes:
> OPEN(UNIT = 10, FILE = fileName, &
> READ(10, '(A)') currentLine
> In the file 'fileName' I have the line :
>
> VALUE = 4
>
> The program compiles but executes with error on the '='.
> I tested without blanks around the '=' and it goes well.
Presumably, the problem is that you expect the entire string to be read
in. Of course, with no length on the A specifier, it will just read
until a space comes. (BLANK=NULL means blanks are blanks; BLANK=ZERO
means to interpret them as (numerical) zeros---all irrelevant here.
I'm not sure what you're trying to do with the internal file. Maybe
NAMELIST is for you?
| |
| Michael Metcalf 2004-11-21, 8:57 pm |
|
"Romain DUJOL" <romain.dujol@caramail.com> wrote in message
news:a0a6d8b9.0411210902.68c25718@posting.google.com...
> READ(10, '(A)') currentLine
> READ(currentLine, '(''VALUE'',''='',I)') n
>
> In the file 'fileName' I have the line :
>
> VALUE = 4
>
> The program compiles but executes with error on the '='.
> I tested without blanks around the '=' and it goes well.
> I looked for old posts and found the option BLANK = 'NULL' :
> unfortunately, it does not work.
>
It's not clear to me what you're trying to do, but if you substitute the 2nd
read by
READ(currentLine, '(a5,a3,I4)') dummy1,dummy2,n
print *, dummy1,dummy2,n
where dummy1, 2 are character variables, it prints something sensible. Note
that the first read does read the whole line (record) regardless of the
presence or absence of blanks (that's what an 'a' format is for). See also
Sections 9.6 and 9.13.2 of "Fortran 90/95 Explained".
Hope that helps,
Mike Metcalf
| |
| beliavsky@aol.com 2004-11-21, 8:57 pm |
|
romain.dujol@caramail.com (Romain DUJOL) wrote:
>Hello,
>
>This must not be a new problem, but here's the issue :
>
> CHARACTER(255) :: fileName
> CHARACTER(255) :: currentLine
>
> OPEN(UNIT = 10, FILE = fileName, &
> STATUS = 'OLD' , &
> ACCESS = 'SEQUENTIAL', &
> ACTION = 'READ' )
> READ(10, '(A)') currentLine
> READ(currentLine, '(''VALUE'',''='',I)') n
>
>In the file 'fileName' I have the line :
>
> VALUE = 4
>
>The program compiles but executes with error on the '='.
>I tested without blanks around the '=' and it goes well.
>I looked for old posts and found the option BLANK = 'NULL' :
>unfortunately, it does not work.
>
>Is it possible to solve the problem in a simple way ?
>
>Thanks in advance.
If file 'test_input.txt' contains the line
VALUE = 4
or
VALUE=4
you can read an integer from it as follows:
program xread_input
implicit none
integer, parameter :: in_unit=20
character (len=255) :: text
integer :: n
integer :: ipos
open (unit=in_unit,file="test_input.txt",action="read")
read (in_unit,"(a)") text
ipos = index(text,"=",back=.true.) + 1
! read integer from text after last '='
read (text(ipos:),*) n
print*,n
end program xread_input
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
| |
| Romain DUJOL 2004-11-22, 9:02 am |
| helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) wrote in message news:<cnqs4l$hnm$1@online.de>...
> In article <a0a6d8b9.0411210902.68c25718@posting.google.com>,
> romain.dujol@caramail.com (Romain DUJOL) writes:
>
>
>
>
> Presumably, the problem is that you expect the entire string to be read
> in. Of course, with no length on the A specifier, it will just read
> until a space comes.
Really ? In my case with "READ(10, '(A)') currentLine", all the line
is correctly read... even there are spaces.
My opinion is the problem is not here.
> (BLANK=NULL means blanks are blanks ; BLANK=ZERO means to interpret them as numerical) zeros---all irrelevant here.
Is there an option where you can ask the the blanks are removed (at
least, declared as non-significant) ?
> I'm not sure what you're trying to do with the internal file. Maybe
> NAMELIST is for you?
Maybe. I will have a look.
Thanks for answering.
| |
| meek@skyway.usask.ca 2004-11-22, 3:58 pm |
| In a previous article, "beliavsky@aol.com" <beliavsky@127.0.0.1:7501> wrote:
>
>romain.dujol@caramail.com (Romain DUJOL) wrote:
>
>If file 'test_input.txt' contains the line
>
>VALUE = 4
>
>or
>
>VALUE=4
>
>you can read an integer from it as follows:
>
>program xread_input
>implicit none
>integer, parameter :: in_unit=20
>character (len=255) :: text
>integer :: n
>integer :: ipos
>open (unit=in_unit,file="test_input.txt",action="read")
>read (in_unit,"(a)") text
>ipos = index(text,"=",back=.true.) + 1
>! read integer from text after last '='
>read (text(ipos:),*) n
>print*,n
>end program xread_input
>
>
or you could just say
read (iunit,'(6x,i)')n
.. not as impressive, but will work in most cases.
Chris
| |
| Richard E Maine 2004-11-22, 3:58 pm |
| romain.dujol@caramail.com (Romain DUJOL) writes:
> READ(currentLine, '(''VALUE'',''='',I)') n
Others have given constructive answers about how to fix
your read statement (using A edit descriptors).
But I'll share the question about what you think this is doing.
Character string edit descriptors (your ''VALUE'' and ''='')
are not allowed on input at all. If your compiler even accepts
them, then that is some kind of extension, and who knows how
it would work. I can only speculate, but I could imagine
several possibilities. If you think that it will search for
the strings "VALUE" and "=".... well that's one of the
possibilities, but it is one of the most esoteric ones. I
certainly wouldn't count on it.
(In pre-f77 days, there was a somewhat related use of Hollerith
edit descriptors for input. It was pretty esoteric... unlikely
to be what you want even if it were still available).
While I'm mentioning the standard, note that the plain I format
is also not standard on input. That form is allowed only on
output. At a guess, you might be assuming that it will act
like list-directed input and read an arbitrary-length field.
If your particular compiler happens to do that (and maybe it
does), be prepared for the code to fail when you try almost
any other compiler.
Your input looks much like namelist input. If so, namelist might
be a simple way of doing it, though that depends on things that
I don't know. Otherwise, well...
If you don't use namelist and you want to be flexible about whether
there are or are not spaces around the "=", then I think you need
to parse the fields out yourself. There isn't a handy language
feature that will do that for you if namelist doesn't fit.
List-directed would be picky about the blanks.
You can use an internal read to convert the individual values
from the numeric field after you've determined what part of
the string is the numeric field.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Michael Metcalf 2004-11-22, 8:57 pm |
|
"Richard E Maine" <nospam@see.signature> wrote in message
news:m1wtwdlow9.fsf@MLMCE0000L22801.local...
>
> While I'm mentioning the standard, note that the plain I format
> is also not standard on input. That form is allowed only on
> output.
Richard,
I think you mean I0. Plain I is simply invalid. The plain form exists
only for A.
Regards,
Mike Metcalf
| |
| Richard E Maine 2004-11-22, 8:57 pm |
| "Michael Metcalf" <michael.metcalf@t-online.de> writes:
> "Richard E Maine" <nospam@see.signature> wrote in message
> news:m1wtwdlow9.fsf@MLMCE0000L22801.local...
>
> Richard,
> I think you mean I0. Plain I is simply invalid. The plain form exists
> only for A.
Oops again. Yes. I'm not entirely sure why the standard doesn't
allow I0 to be spelled as just I, which seems simpler to me. But
it doesn't. Some compilers do, but not the standard. I suppose that
has at least half a chance of being why the standard doesn't allow
it - that perhaps the common compiler extensions there don't quite
exactly match how the standard feature works. (I'm speculating on
that; I don't actually know it, but it seem s plausible).
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Phillip Helbig---remove CLOTHES to reply 2004-11-22, 8:57 pm |
| In article <a0a6d8b9.0411220010.53c0cd6e@posting.google.com>,
romain.dujol@caramail.com (Romain DUJOL) writes:
>
> Really ? In my case with "READ(10, '(A)') currentLine", all the line
> is correctly read... even there are spaces.
Sorry, I meant end-of-line, not space.
| |
| glen herrmannsfeldt 2004-11-23, 3:57 am |
| Richard E Maine wrote:
(snip)
> Oops again. Yes. I'm not entirely sure why the standard doesn't
> allow I0 to be spelled as just I, which seems simpler to me. But
> it doesn't. Some compilers do, but not the standard. I suppose that
> has at least half a chance of being why the standard doesn't allow
> it - that perhaps the common compiler extensions there don't quite
> exactly match how the standard feature works. (I'm speculating on
> that; I don't actually know it, but it seem s plausible).
And also why X isn't allowed, but only 1X if you
only need one?
-- glen
| |
| Romain DUJOL 2004-11-23, 3:58 pm |
| romain.dujol@caramail.com (Romain DUJOL) wrote in message news:<a0a6d8b9.0411210902.68c25718@posting.google.com>...
> Hello,
>
> This must not be a new problem, but here's the issue :
>
> CHARACTER(255) :: fileName
> CHARACTER(255) :: currentLine
>
> OPEN(UNIT = 10, FILE = fileName, &
> STATUS = 'OLD' , &
> ACCESS = 'SEQUENTIAL', &
> ACTION = 'READ' )
> READ(10, '(A)') currentLine
> READ(currentLine, '(''VALUE'',''='',I)') n
>
> In the file 'fileName' I have the line :
>
> VALUE = 4
>
> The program compiles but executes with error on the '='.
> I tested without blanks around the '=' and it goes well.
> I looked for old posts and found the option BLANK = 'NULL' :
> unfortunately, it does not work.
>
> Is it possible to solve the problem in a simple way ?
>
> Thanks in advance.
I found the solution using list-directed I/O :
CHARACTER(255) :: key
CHARACTER(255) :: equalsSign
INTEGER :: value
READ(10, *) key, equalsSign, value
Thanks to all posters for their answers.
PS : I won't use NAMELIST, because I want to have my own syntax for
the input file. If it wasn't the case, I would have use it : it seems
very efficient.
| |
| Richard E Maine 2004-11-23, 3:58 pm |
| glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
[about formats]
> And also why X isn't allowed, but only 1X if you
> only need one?
Although I can see that it would make sense to allow just X (as some
compilers do), at least the 1X makes sense, even though it seems
verbose. To me, the I0 (that's a "zero" after the "eye", even if it
doesn't look like it in whatever font you see this) doesn't even make
sense. It isn't 0 field width. The zero value just got co-opted as
one that couldn't make any other sense, so it is given a special
meaning.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
|
|
|
|
|