Update a configuration file: Difference between revisions
→{{header|Fortran}}: Approach the exclusion of SeedsRemoved.
m (re-introduced original misspelling [begininning] to the original configuration file (as it is part of the data to be used by all programming entries).) |
(→{{header|Fortran}}: Approach the exclusion of SeedsRemoved.) |
||
Line 574:
WRITE (6,FRUIT)
END</lang>
Most of which is support stuff. The requirement is to declare a NAMELIST naming the variables of interest, then READ or WRITE using just the name of the NAMELIST. Just three statements, four if the file OPEN is counted. The result is a file in a standard layout.
<pre>
&FRUIT
Line 583:
/
</pre>
Evidently, the variables named in the NAMELIST are written out, one to a line in free-format with a style appropriate to its type, much as if they were assignment statements within a source file. Since Fortran compilers do not distinguish between upper and lower case, either may be used. The namelist's name starts the output, and the block of values ends with a line starting with a slash. On input, blocks will be skipped until the correct block name is found, so a single file may contain parameters for multiple usages. All output starts with column two so that column one can be used as a carriage control character if output is to go to a lineprinter. There is special provision for an array's value list whereby a run of equal values can be noted via <code>''n''*''value''</code> to save space, further, an input statement for an array can name a single element (the others being unaffected), and with F90, the usual array span facilities are available as in <code>A(6:10) = 5*3.14</code> Should an output list of values be too long for the standard line length (133, again to suit lineprinters, but this value can be changed by RECL = ''n'' in the OPEN statement) then the list will be split across lines after a comma. However, long CHARACTER variables will cross multiple lines and column one will be used, something of a mistake should such output go to a lineprinter as it may react badly to strange carriage control characters.
To remove the SeedsRemoved entry is straightforward, depending on context. If its name is removed from the NAMELIST then it will no longer be written. The parameter file could of course be edited before being read back in, perhaps by a human, or by the installation process of the new version, or by finding the unwanted line, backspacing the file one record and writing the right number of spaces to wipe it without changing the length of a record - though this ploy may not be available if the filesystem offers limited support. If however a new version of the programme is expected to read the old version's parameter file, then there will be trouble as an unknown name (or an array index out of bounds, but not a CHARACTER variable being shorter than the supplied text) will provoke an I/O error and the run will crash. This can be avoided via the ERR = ''label'' option in the READ statement, however entries after the erroneous one will not be processed.
In a more general situation, it is helpful to have a routine that reads the NAMELIST style input and isolates the assignments so that each can individually be written to a scratch file in the NAMELIST style (i.e. providing the block head and tail lines, though some Fortrans allow NAMELIST input from a text variable and without this requirement) whereupon if ERR is provoked during the READ, the troublesome entry can be displayed for user appreciation before continuing with any remaining assignments.
Otherwise, the old NAMELIST could be used for input, with the undesired value simply ignored within the new version of the programme. For output, a new NAMELIST would be devised omitting the unwanted name - the same variables can be named in more than one NAMELIST. However, every NAMELIST's name must be unique within a routine and this would be the new block header name. So, read the parameter file in one routine which declares the old NAMELIST, complete with the now unwanted name, but write it via another routine which declares the new NAMELIST using the same name but omitting the names of undesired variables. The wanted variables would be in COMMON, or with F90 onwards be common names in a MODULE, or one could mess with parameter lists.
Naturally, a parameter file could contain data in whatever format desired: such a file could be read and its components extracted via suitable code then written in the NAMELIST style to a scratch file and read back for the actual internalisation of values. The point of this is that a text name of a variable is associated with the actual computer variable via the NAMELIST facility, the programmer need not slog through some endless CASE statement on the names of the variables. This process would be reversed for output.
| |||