Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Read parameters from config file

175 views
Skip to first unread message

Jim

unread,
May 3, 2013, 7:15:33 AM5/3/13
to
I've wrote a program containing some parameters.
This program is used for engineering scopes and
for different projects.
So any time I use it for a new project I have to
change parameters values editing source code.
Then I have to compile it and finally I can use
it. It's not so usefull...

I'd like to define parameters values in a config
file and not to edit and compile source any time.

So I've defined few rules for that confgi file
"format":

1- blank lines are ignored
2- lines begining with "#" are comments so ignored
3- parameters are defined as follows:
____________________________________

First_Parmeter_Name = <1st_value>
Second_Parameter_Name = <2nd_value>
...
------------------------------------


Notes:
Let's imagine a stupid program...
Program gets a numerical array written in a simple
ascii file. I want to define this too at config time.
example:

Data_File = /path/to/datafile.txt

A simplified example:
we have two parameters "a", "b", and "data_file".
First two are teo integers.
Last variable is the name of a data file containing
a list of numbers.

data file example:
------------------
1
2
3
4
5
6
---

Program just sums data file numbers to a and b values.
So if a=7 and b=8 program returns:
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 = 36

I want to edit a config file as follow:
_______________________________________

# This file contains data
#
data_file = /path/to/data_file.dat

# Others parameters
#
a = 7
b = 8

# This is a stupid comment!

-----


I want to launch my program as follow:
$ program_name config_file

So I'll pass config file name at prompt line.
Then program has to parse config file and get
parameters values.
And finally it will do its arithmetic operations
and returns result.

What do you think about?
Can you suggest a way to parse config file.
If you can, it would be a good answer an example
that solves easy sum sample reported above.

PS.
Sorry for my bad english.
And Thanks in advance! :)

Bye



Rudra Banerjee

unread,
May 3, 2013, 7:32:00 AM5/3/13
to
Define a module is probably what you are looking for.

!This is file : constants.f90
module constants
implicit None

!Kind Definations
integer,parameter :: rs=selected_real_kind(p=4,r=8)
integer,parameter :: rd=selected_real_kind(p=8,r=8)
integer,parameter :: rl=selected_real_kind(p=16,r=8)

!Fundamental Constants (units are in SI)
real(rl),parameter :: pi=4*atan(1.0_rd)
end module constants

Then use is in main program.

!This is file : try_c.f90
use constants
Implicit None

write(*,*)pi
end

Louis Krupp

unread,
May 3, 2013, 7:49:34 AM5/3/13
to
On Fri, 3 May 2013 11:15:33 +0000 (UTC), Jim <jim...@jmail.invalid>
wrote:
Your English serves the purpose. You speak it better than I will ever
speak Italian.

You might want to look up the Fortran namelist feature. It isn't
exactly what you're describing, but if it's close enough, it might
save you some work.

Louis

e p chandler

unread,
May 3, 2013, 8:21:20 AM5/3/13
to
On Friday, May 3, 2013 7:15:33 AM UTC-4, Jim wrote:
> I've wrote a program containing some parameters.
> This program is used for engineering scopes and
> for different projects.
> So any time I use it for a new project I have to
> change parameters values editing source code.
> Then I have to compile it and finally I can use
> it. It's not so usefull...

[snip]

First, parameter has a specific meaning in Fortran. Essentially it is a named *constant*. If this is what you want, then to change one of these you *do* have to edit a source file or a module source file or an include file and re-compile.

Otherwise, you are assigning a value to a variable after reading it from an external file. If you are always reading in A, then B, just use an ordinary READ. However, if you want to decide to which variable the value is assigned at the time the program runs, this is something different. Fortran's namelist feature may help. I have never used it. Otherwise, you write an interpreter that has a dictionary of name-value pairs and possibly a parser.

I suspect that all of these are much more complicated than what you actually need.

---- e

Gordon Sande

unread,
May 3, 2013, 9:00:29 AM5/3/13
to
The Fortran feature NAMELIST was intended to solve this sort of problem.
It uses its own syntax which is close to yours.

A common way of using NAMELIST is for your program to set default values for
its "parameters" which are just variables in the program that you probably do
not change and then to read the new values for those variables. If a variable
does not appear in a NAMELIST it will not be changed and the default
will be used.
Very useful for setting debugging switches when the default is no debugging.
To get no debugging you just never mention the debugging switch!

The great advantage of NAMELIST is that it already exists and even includes
capabilites for reading arrays, various types, etc. No work required on
the part of the programmer. The major disadvantage of NAMELIST is that it
already exists so has its syntax already specified.



Jim

unread,
May 3, 2013, 9:57:51 AM5/3/13
to
Gordon Sande <Gordon...@gmail.com> wrote:
>
> The Fortran feature NAMELIST was intended to
> solve this sort of problem.
> It uses its own syntax which is close to yours.
>
> A common way of using NAMELIST is for your
> program to set default values for its "parameters"
> which are just variables in the program that you
> probably do not change and then to read the new
> values for those variables. If a variable does
> not appear in a NAMELIST it will not be changed
> and the default will be used.
> Very useful for setting debugging switches when
> the default is no debugging.
> To get no debugging you just never mention the
> debugging switch!
>
> The great advantage of NAMELIST is that it already
> exists and even includes capabilites for reading
> arrays, various types, etc. No work required on
> the part of the programmer.
> The major disadvantage of NAMELIST is that it
> already exists so has its syntax already specified.

I've just read something about NAMELIST feature jet.
But I'd like soemthing more versatile, expecially to
use my simple configuration file format.

Anyway, could you report an example of NAMELIST use
based on my "stupid program" described in my first
message?

Gordon Sande

unread,
May 3, 2013, 11:09:58 AM5/3/13
to
Your choice is to either use the NAMELIST format or to
do all the text processing to use your format.

> Anyway, could you report an example of NAMELIST use
> based on my "stupid program" described in my first
> message?

I both use NAMELIST for my testbeds and have a full blown
free format for my production codes. At this point I have
a library that supports my application and an idiom of how
to use it. Neither was a one day "just toss it off" exercise.

My suggetion is that you "hold your nose" and use the NAMELIST
format to get the job done this afternoon and then you can spend
the next couple months doing the free format version. If you
restrict your ambitions it may only be the next couple weeks.
Once you have a working NAMELIST demonstration my guess is that
full version will suddenly be much less urgent.

Or you might make a REXX program to read the free format and produce
the NAMELIST version. That way you canuse all the features of REXX
to make the free format processing much easier. If you don't like REXX
then AWK or any of a dozen others. Some might be charmedif you had a
Visual Basic interactive program the asked for the "parameters" and
then constructed the NAMELIST input to the actual program. This is
the sort of thing that is nicely done in a multiple programming languages.

My currect testbeds are reading 1000 x 1500 sparse matrices so are much too
large to include here.



Ivan D. Reid

unread,
May 3, 2013, 12:57:15 PM5/3/13
to
On Fri, 3 May 2013 11:15:33 +0000 (UTC), Jim <jim...@jmail.invalid>
wrote in <km068l$799$1...@speranza.aioe.org>:
> I've wrote a program containing some parameters.
> This program is used for engineering scopes and
> for different projects.
> So any time I use it for a new project I have to
> change parameters values editing source code.
> Then I have to compile it and finally I can use
> it. It's not so usefull...

> I'd like to define parameters values in a config
> file and not to edit and compile source any time.

> So I've defined few rules for that confgi file
> "format":

> 1- blank lines are ignored
> 2- lines begining with "#" are comments so ignored
> 3- parameters are defined as follows:
> ____________________________________
>
> First_Parmeter_Name = <1st_value>
> Second_Parameter_Name = <2nd_value>
> ...
> ------------------------------------


There's an informal standard called INI that's very like
that[1]. If you google for iniparse or iniparser you'll find lots in
C, python etc. One link I found led to a version in Fortran:
http://www.fortranlib.com/iniFile.for

[1] http://en.wikipedia.org/wiki/INI_file

--
Ivan Reid, School of Engineering & Design, _____________ CMS Collaboration,
Brunel University. Ivan.Reid@[brunel.ac.uk|cern.ch] Room 40-1-B12, CERN
KotPT -- "for stupidity above and beyond the call of duty".

Jim

unread,
May 3, 2013, 1:13:08 PM5/3/13
to
Gordon Sande <Gordon...@gmail.com> wrote:
>
> My suggetion is that you "hold your nose" and
> use the NAMELIST format to get the job done this
> afternoon and then you can spend the next couple
> months doing the free format version.

I agree...


> Or you might make a REXX program to read the free
> format and produce the NAMELIST version.

Yes I've imagined a similar solution.
I don't know REXX, my idea was using a bash script
to parse config file and isolate values of variables.
Then call my program with that values as arguments.

-----------
#!/bin/bash

CONFIG=$1

parse_config()
{

parsing operations
...
# vars assign.
#
var1 = value1
var2 = value2

}

parse_config $CONFIG
fortran_program.out var1 var2 var3
---------------------------

And in program.f I would have used a couple of
builtin functions:

command_argument_count()
get_command_argument(*,*)

In that way there's no needed NAMELIST use.
But you have to run bash script in a "bash
environment". And this is not so good especcially
if I will borrow my program to others collegues.
Due to this fact I'd prefer a "all in one" solution:
"you have executable file and you can use it anywere
without any other dependecies needed".

Anyway, editing source code and recompiling is the
speedy way. And now I'm alreay using it like that.
So... no hurry. ;)


> Visual Basic interactive program the asked for the
> "parameters" and then constructed the NAMELIST input
> to the actual program. This is the sort of thing that
> is nicely done in a multiple programming languages.

I'm using a linux based OS, and a visual basic made
interface could not be a good idea so like a bash
script ported on windows..
As regards graphic interfaces I think a well documented
config file can be enought for now.

I'll read more about NAMELIST.

mlo...@gmail.com

unread,
May 6, 2013, 10:10:21 AM5/6/13
to
Aside from the namelist suggestion given by others, if you're working on a larger project and the number/complexity of the inputs will be growing, look into linking your fortran to boost's program_options, or pythons argparse.

Jim

unread,
May 7, 2013, 2:16:57 PM5/7/13
to
Jim <jim...@jmail.invalid> wrote:
>
> I'll read more about NAMELIST.

Ok, here we go folks, namelist statement seems
good for my needs.
A simple self explaining example:

fortran source:
___________________________________________
program namelist

! Get config file (namelist formatted) as
! command line argument.
! Read variables value from that.
! Write values to std output.

! Vars declarations and namelist definition
!
implicit none
character(30) :: configfile, datafile
integer :: s, l, ios
namelist /config/ s, l, datafile

! get config file name passed as first arument
! at command line
!
call get_command_argument(1,configfile)
write(*,*) 'Config file is: ',configfile


! Open config file using its variable value
!
open(10,file=configfile,status='OLD',delim='apostrophe')

! Read namelist "config" section and write
! vaules to std out
!
read(10,nml=config,iostat=ios)
write(*,*)'Area: ', s,' Km2'
write(*,*)'Leinght: ', l,' Km'
write(*,*)'Rec Data File: ', datafile

end program namelist
--------------------


config file:
____________________________
bash-4.2$ cat configfile.nml
! This is just a Stupid Comment
&config
s=10
l=20
datafile='data.dat'
/
--------------------------------


Output:
_______________________________________
bash-4.2$ ./namelist.out configfile.nml
Config file is: configfile.nml
Area: 10 Km2
Leinght: 20 Km
Rec Data File: data.dat
---------



Any your comments will be usefull for sure!
Thanks a lot again for your hints!
See you!

Arjen Markus

unread,
May 7, 2013, 2:27:31 PM5/7/13
to

> Any your comments will be usefull for sure!
>
> Thanks a lot again for your hints!
>
> See you!

Just a (probably superfluous) suggestion:
Since the configuration file is likely to be used by others,
use descriptive variable names. That way their purpose will be clearer.
This is especially important since namelists expose the names of the
program's variables.

(Of course, you can simply use a variable name as "area_in_km2" and
copy its value into a variable like "area", if the longer name is
convenient.)

Regards,

Arjen

Gordon Sande

unread,
May 7, 2013, 3:20:43 PM5/7/13
to
You may also want to have a character variable which has some sort of
comment or
explanation of why this run was done. The output should also include a
good date.

All to keep track of the output from the several runs a month from now.


Jim

unread,
May 7, 2013, 6:12:59 PM5/7/13
to
Gordon Sande <Gordon...@gmail.com> wrote:
> On 2013-05-07 15:27:31 -0300, Arjen Markus said:
>
>> Since the configuration file is likely to be
>> used by others, use descriptive variable names.

Another way would be to add some comments in configfile.
Example:
_______________________________

! This is just a Stupid Comment
&config
! Area[Km2]
s=10
! Leinght [Km]
l=30
! File name containing data
datafile='data.dat'
/
-------------------------------

> You may also want to have a character variable
> which has some sort of comment or explanation
> of why this run was done. The output should also
> include a good date.
>
> All to keep track of the output from the several
> runs a month from now.

It' a good idea. Thanks!

An other question I've in mind...
I'd like to let program create itself a "template"
of config file so that user can edit it by adding
various values to variables.

For example:
case 1)
user launches program and passes an existing configfile
as argument:
In this case user must know config file structure...

case 2)
user launches program without any args:
In this case program generates a template to be edited
by user.
Another way would be evaluate args passed, but it is a bit
more "expansive". I mean an usage like many command line
programs. Somethig like:

./program --make-config

...To generate a template config file.
So if I will need to add some features I will introduce
more command line options and arguments.
But for now one argument (config file name) or no one
(to generate template) is ok.
In case 2 I could also add an "usage message" that describes
how to use this command.
Something like:
___________________________________________
"You have launched program without any arg,
so a config template is created in current
directory and named program.config.

You have to edit it by adding values
to variables. Then launch:

~$ program program.config

to get results referring to your config.

You can also use another config file just
by passing it as argument when you launch
program.

Good luck!"
===========

Ok, that was just an example but I don't need
a lot more for now...

Terence

unread,
May 7, 2013, 8:05:53 PM5/7/13
to
My solution to this requirement, and which also covers the language which
which the program may need to communicate with the outside, is to have a
line-numbered table (e.g. 01--99) as a single external text control file.

The first operation the program does is to use a subroutine to read the
control file into an array of text by line index, or of a text representaion
of values, as appropriate. The program then uses the message index to
communicate or array index to get parameters.

This table could therefore just be a list of parameter values as neeed by
OP, or more generally as described, texts of specific language phases (for
asking questions or describing results and writing reports).

In my own case of usage, the first line is always a set of colour codes for
screen control, (possibly followed by language code warning), then the
European, Greek or Romaji-japanese language texts.

The beauty is that one single get-table subroutine call suits all programs
ever written by me.
Change the user and just change the language text module



Gordon Sande

unread,
May 8, 2013, 8:56:31 AM5/8/13
to
To get NAMELIST output you can use a Namelist in a write statement.
Yup! Really.

But the Namelist output will be formatted as the compiler chooses.
Since it is just formatted output so you can use several FORMAT statements
to get the same effect but under your control. I would suggest that you use
one line for each variable. When you use a format the value can be any
placeholder you might care to use to get your template.

> For example:
> case 1)
> user launches program and passes an existing configfile
> as argument:
> In this case user must know config file structure...
>
> case 2)
> user launches program without any args:
> In this case program generates a template to be edited
> by user.

Many Unix utilities give a cryptic usage indication when invoked incorrectly.
That includes with no arguements.

Jim

unread,
May 9, 2013, 1:05:30 PM5/9/13
to
Gordon Sande <Gordon...@gmail.com> wrote:
>
> Since it is just formatted output so you can use several FORMAT statements
> to get the same effect but under your control. I would suggest that you use
> one line for each variable. When you use a format the value can be any
> placeholder you might care to use to get your template.

Look at thi piece of code:
__________________________

program namelistprint
! Creates a namelist formatted file
! to be used as config file template.
character(50) :: initvar, comment
initvar='(X, A, X,"=")'
comment='(A)'
open(unit=101,file="out.config")

write(101,comment) '! Automatically generated by program.'
write(101,comment) '! Please, edit this file inserting values'
write(101,comment) '! of each variables after "=" character.'
write(101,comment) ''
write(101,comment) '&config'
write(101,comment) ' ! Area. [Kmᅵ]'
write(101,comment) ' !'
write(101,initvar) 's'
write(101,comment) ''
write(101,comment) ' ! Leinght. [m]'
write(101,comment) ' ! '
write(101,initvar) 'l'
write(101,comment) ''
write(101,comment) ' ! File name containing flow rate data [mᅵ/s].'
write(101,comment) ' ! Enclose its name between apostrophes.'
write(101,comment) ' ! (eg. ''flowrate.dat'').'
write(101,comment) ' !'
write(101,initvar) 'datafile'
write(101,comment) '/'

close(101)
stop
end program
===========

Ok, this just an example end it returns a file called "out.config":
------------------------------------
! Automatically generated by program.
! Please, edit this file inserting values
! of each variables after "=" character.

&config
! Area. [Kmᅵ]
!
s =

! Leinght. [m]
!
l =

! File name containing flow rate data [mᅵ/s].
! Enclose its name between apostrophes.
! (eg. 'flowrate.dat').
!
datafile =
/
----------------------------------------------

Now, do you know a better way to create that config
template?
If this was be written in bash scripting I've used an
"here document" style text, without any "echo", something
like:

=========
cat <<EOF
.. ..
..
...
...
EOF
=========

But I don't know if Fortran has something like that...
Thanks in advance! :)

glen herrmannsfeldt

unread,
May 9, 2013, 2:05:54 PM5/9/13
to
Jim <jim...@jmail.invalid> wrote:

(snip)

> Now, do you know a better way to create that config
> template?
> If this was be written in bash scripting I've used an
> "here document" style text, without any "echo", something
> like:

> =========
> cat <<EOF
> .. ..
> ..
> ...
> ...
> EOF
> =========

Not really, but you can create an array of CHARACTER, and initialize
it one constant per line, with continuations:


character*80 :: str(4) = [ character(len=80) :: &
'this is one', &
'this is another', &
'this is the third one', &
'this is the last one' ]
do i=1,size(str)
print '(A)',str(i)
enddo
end


-- glen

Gordon Sande

unread,
May 9, 2013, 2:28:52 PM5/9/13
to
On 2013-05-09 17:05:30 +0000, Jim said:

> Gordon Sande <Gordon...@gmail.com> wrote:
>>
>> Since it is just formatted output so you can use several FORMAT statements
>> to get the same effect but under your control. I would suggest that you use
>> one line for each variable. When you use a format the value can be any
>> placeholder you might care to use to get your template.
>
> Look at thi piece of code:
> __________________________
>
> program namelistprint
> ! Creates a namelist formatted file
> ! to be used as config file template.
> character(50) :: initvar, comment
> initvar='(X, A, X,"=")'
> comment='(A)'
> open(unit=101,file="out.config")
>
> write(101,comment) '! Automatically generated by program.'

This could also be

write ( 101, "('! Automatically generated by program.')" )

although my personal preference reverse the use of single and double quotes.
String literals are in double quotes for my eye with the single quote
used for the
whole format string. Does not matter, just do not confuse thing by
switching at random!

> write(101,comment) '! Please, edit this file inserting values'
> write(101,comment) '! of each variables after "=" character.'
> write(101,comment) ''
> write(101,comment) '&config'
> write(101,comment) ' ! Area. [Km�]'
> write(101,comment) ' !'
> write(101,initvar) 's'

Or even

write ( 101, "(' s = ')" )

as I could not quite figure out why you used such a round about way. If all
lines are just copied through you do not need to look uo and understand
you initvar format.

> write(101,comment) ''
> write(101,comment) ' ! Leinght. [m]'
> write(101,comment) ' ! '
> write(101,initvar) 'l'

I had to look several times to figure out that in my font ell(l) and
bang(!) all look-alikes.
Either use capital letters, add a blank to move the identifiers over or
use longer meaningful names.
I would put comment characters at the beginning of the balnk lines as
well as that matches my
persanal preferences.

> write(101,comment) ''
> write(101,comment) ' ! File name containing flow rate data [m�/s].'
> write(101,comment) ' ! Enclose its name between apostrophes.'
> write(101,comment) ' ! (eg. ''flowrate.dat'').'
> write(101,comment) ' !'
> write(101,initvar) 'datafile'
> write(101,comment) '/'
>
> close(101)
> stop
> end program
> ===========
>
> Ok, this just an example end it returns a file called "out.config":
> ------------------------------------
> ! Automatically generated by program.
> ! Please, edit this file inserting values
> ! of each variables after "=" character.
>
> &config
> ! Area. [Km�]
> !
> s =
>
> ! Leinght. [m]
> !
> l =
>
> ! File name containing flow rate data [m�/s].

Walt Brainerd

unread,
May 10, 2013, 1:29:47 PM5/10/13
to
On 5/9/2013 11:28 AM, Gordon Sande wrote:
> On 2013-05-09 17:05:30 +0000, Jim said:

. . .
>
>> write(101,comment) '! Please, edit this file inserting values'
>> write(101,comment) '! of each variables after "=" character.'
>> write(101,comment) ''
>> write(101,comment) '&config'
>> write(101,comment) ' ! Area. [Km�]'
>> write(101,comment) ' !'
>> write(101,initvar) 's'
>
> Or even
>
> write ( 101, "(' s = ')" )
>
> as I could not quite figure out why you used such a round about way. If all
> lines are just copied through you do not need to look uo and understand
> you initvar format.
>
>
. . .
Since this is just a matter of style, I will put in my seven votes
to put the character output data with all the other output data in
the output list, rather than in the format. That is the way it was
done in Jim's post. This seems much more consistent to me, rather
than doing it the way it was done in olden times before character
data was introduced into Fortran 77.

Jim

unread,
May 13, 2013, 6:48:55 PM5/13/13
to
Ok, this is an interesting way to obtain something similar
to "here document" style.
It's the best solution in my view because I think it's the
most confortable to "digit" than others suggested and it's
also quite "light" to read in case of future code updates.

Anyway, is there a way to let a program "eat" a text file
at compile time as an input file and automatically use it
during run time?
I mean:
1- get content of config.txt
2- compile executable
3- remove config.txt
4- use the content at (1) to do something
for example to print it on stdout...

Is there a way to do that?
Sorry if didn't explained better :|
Hope it is quite clear.

In other words:
1- I want to have an executable only to use
2- this executable has to generate some text files
3- but I want no file writing hard coded in source

Any suggests?
Links are usefull too, thanks in advance! :)

glen herrmannsfeldt

unread,
May 13, 2013, 7:23:44 PM5/13/13
to
Jim <jim...@jmail.invalid> wrote:

(snip, I wrote)

>> Not really, but you can create an array of CHARACTER, and initialize
>> it one constant per line, with continuations:

>> character*80 :: str(4) = [ character(len=80) :: &
>> 'this is one', &
>> 'this is another', &
>> 'this is the third one', &
>> 'this is the last one' ]
>> do i=1,size(str)
>> print '(A)',str(i)
>> enddo
>> end

(snip)

> Ok, this is an interesting way to obtain something similar
> to "here document" style.
> It's the best solution in my view because I think it's the
> most confortable to "digit" than others suggested and it's
> also quite "light" to read in case of future code updates.

> Anyway, is there a way to let a program "eat" a text file
> at compile time as an input file and automatically use it
> during run time?

The file would have to have quotes around each line, and
followed by ,&. That is, it would have to look like the lines
above. You could then:

character*80 :: str(4) = [ character(len=80) :: &
#include "file.txt"
"" ]

If you compiler had the C preprocessor enabled. (On some systems
that happens with the .F90 extension instead of .f90.)

You will be limited by the Fortran continuation line limit, too.

Note that all array elements (lines) have to have the same length.
If you put the character(len=80) as above, then the compiler will
extend them all to 80.

There are some C features that make this easier. For one, a trailing
comma is allowed on an array initializer. You can:

char *str[]={
"this is one",
"this is another",
"this is the third one",
"this is the last one",
};

or

char *str[]={
#include "file2.txt"
};

(The rule allowing for the trailing comma is partly to make such
include files easier to write.)

In C this is an array of character pointers, such that each line
is null terminated (usual in C) and only the actual length, plus the
null terminator is stored. Also, the C compiler will count the number
of strings and dimension the array appropriately.

I think there is a way to do a self-counting array initializer in
Fortran, but I forget how to do it.

It is easy in many languages to write a program to add the leading
quote and trailing quote, comma, and (for Fortran) &.

{ print "\"" $0 "\",&"; }

will do it in AWK.


-- glen

David Thompson

unread,
May 16, 2013, 3:13:11 AM5/16/13
to
On Wed, 8 May 2013 09:56:31 -0300, Gordon Sande
<Gordon...@gmail.com> wrote:

> On 2013-05-07 19:12:59 -0300, Jim said:
<snip>
> > For example:
> > case 1)
> > user launches program and passes an existing configfile
> > as argument:
> > In this case user must know config file structure...
> >
> > case 2)
> > user launches program without any args:
> > In this case program generates a template to be edited
> > by user.
>
> Many Unix utilities give a cryptic usage indication when invoked incorrectly.

Yes.

> That includes with no arguements.

Sometimes. There are quite a lot of utilities for which zero arguments
is valid. Most programs (whether zero arguments is valid or not) have
an explicit option to request the usage message, very often -? . GNU
(thus Linux) versions of utilities (nearly always) accept 'long-form'
options with two hyphens, including --help for usage.

Jim

unread,
May 17, 2013, 9:07:04 AM5/17/13
to
glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Jim <jim...@jmail.invalid> wrote:
>
> (snip, I wrote)
>
>>> Not really, but you can create an array of CHARACTER, and initialize
>>> it one constant per line, with continuations:
>
>>> character*80 :: str(4) = [ character(len=80) :: &
>>> 'this is one', &
>>> 'this is another', &
>>> 'this is the third one', &
>>> 'this is the last one' ]
>>> do i=1,size(str)
>>> print '(A)',str(i)
>>> enddo
>>> end
>
> (snip)
>
>> [...]
>
>> Anyway, is there a way to let a program "eat" a text file
>> at compile time as an input file and automatically use it
>> during run time?
>
> The file would have to have quotes around each line, and
> followed by ,&. That is, it would have to look like the lines
> above. You could then:
>
> character*80 :: str(4) = [ character(len=80) :: &
> #include "file.txt"
> "" ]


Ok this works!
But without "#". I've edited it as follow:

character(100) :: str(19) = [ character(len=100) ::&
include "config.txt"
]


Now we have:

1- a config text file template called config.txt.
formatted as needed:
==============
'line', &
'otherline', &
'lastline'
==========

2- we can use this at compile time and then we can
delete it when we have an executable created.

3- so we don't need that text file at run time.
No need to give it to user.
User is able to run executable without any other
file...




> It is easy in many languages to write a program to add the leading
> quote and trailing quote, comma, and (for Fortran) &.
>
> { print "\"" $0 "\",&"; }

Ok, that is the "weak point":
developer (me) as to edit config template file
in that "strange" unconfortable way using "apostrophe"
and apostrophe plus comma and "&".
As you truly explained there are automatic ways to do it:
developer can write a "human-friendly" config file, and then
edit it with a program like awk, sed or others...

So developer could write his config file template.
Then automatically edit it with sed or awk and
finally obtain a fortran-friendly config file to
include in source at compile time.

But... Just as a matter of curiosity...
I've written a few lines of fortran code to automatically
edit human-friendly text file so as it can be included in
a source code with include statement.
Look at following lines:

==================================
program hr2fortfriend
character(100) :: line, prevline
integer :: eof
open(101,file='hr.conf')
open(102,file='fortfriend.conf')
prevline = 'EMPTY'
do
read(101,'(a)',iostat=eof) line
if (eof/=0) then
write(102,*) "'",prevline,"'"
exit
else
if (prevline/='EMPTY') write(102,*) "'",prevline,"', &"
prevline = line
endif
enddo
close(101)
close(102)
end program
===========

Ok, it's quite bugged, anyway.. it seems work fine.
It take hr.conf lines and put them between apostrophes etc.
creating fortfiend.conf text file taht could be included in
a fortran source with include...

But I can't see any way to use this code as part of an other
source called "main".
I'd like to obtain this:
1- manual edit of text file (a config template) in a plain way:
line1
line2
etcc

2- compile main program and obtain
2.a- config template is translated in to fortran compatible
lines (by adding ' ', & etc.) and written in a new
temporary file.
2.b- above created temp file is included in main program.
2.c- an executable that no needs any other file to work
properly

The matter is that include statment workis at compile time
but hr2fortfriend is related to run time...
So I think there's no way to do '2.a' and '2.b' at the same
time.
Peraphs it's a preprocess related question...
I don't know a solution other than separete compile time
to template editing.
If you have any other ideas...
0 new messages