g77: assigning file names to preconnected unit numbers

[wmcc...@salamander.com]

I am moving a mass of old Fortran code to Linux, using g77. In the past the
sources were running on VAX/VMS and alpha/Tru64.

Many of the sources use OPEN with no filenames; old-style preconnected files. In
the past the names have been specified with environmental variables, eg:

export fort1=temp.txt

I've tried FORT1, FORT01, etc, but can't find a convention that works. The g77
manual is silent on this point and otherwise says that no environment variables
are used. My googling has been fruitless.

As a workaround I could add variable filenames and fetch them from the exisiting
symbols with GetEnv(). Or, perhaps being too clever, make soft links from (eg)
"for.1" to the desired file.

But it would be best for the client if I could assign some symbol as they have
been doing and not alter the fortran source.

-Bill

[Tobias Burnus]

Hi,

On Sep 17, 5:24 pm, wmccl...@salamander.com wrote:
> I am moving a mass of old Fortran code to Linux, using g77. In the past the
> sources were running on VAX/VMS and alpha/Tru64.
>
> Many of the sources use OPEN with no filenames; old-style preconnected files. In
> the past the names have been specified with environmental variables, eg:
>
> export fort1=temp.txt

I'm not sure whether it is a good idea to rely on such vendor specific
behaviour...

> I've tried FORT1, FORT01, etc, but can't find a convention that works. The g77
> manual is silent on this point and otherwise says that no environment variables
> are used. My googling has been fruitless.

If you don't insist on using g77, you could switch to g95 (http://
g95.org) which supports according to the manual:
http://ftp.g95.org/G95Manual.pdf

"G95_UNIT_x String Overrides the default unit name for unit x. Default
is fort.x"

Tobias,
who usually prefers gfortran which, however, does not seem to have
such environment variables.

[Colin Watters]

Write a tiny test prog that writes to a unit with no preceeding open. This
will create a file, and the naming convention will thus be revealed.

--
Qolin

Email: my qname at domain dot com
Domain: qomputing
"Tobias Burnus" <bur...@net-b.de> wrote in message
news:1190052504.2...@57g2000hsv.googlegroups.com...

[wmcc...@salamander.com]

The name of the resulting file is known: unit=1 makes a file "fort.1". This
doesn't tell us the corresponding environmental symbol, if any. "fort.1" is not
a legal shell symbol.

-Bill

In article <fcmgjc$3bq$1$8300...@news.demon.co.uk>, Colin Watters says...

[mecej4]

Here is one way to do what you wish:

For each unit-number/input file pair, create a link named fort.<n> to
the file to be associated with that file. For example, to read a file
called file1.txt on Unit-1:

$ cat file1.txt
Test file no. 1.
Line 2
Line 3
Last Line

$ cat rdfil.f
program readfile
rewind(1)
10 read(1,fmt=20,end=30)line
write(*,40)line
go to 10
30 stop
20 format(A)
40 format(5x,A)
end

$ g77 rdfil.f

$ ln ./file1.txt fort.1

$ ./a.exe
Test
Line
Line
Last

$

HTH.

-- mecej4

[Pierre Asselin]

wmcc...@salamander.com wrote:
> I am moving a mass of old Fortran code to Linux, using g77. In the past the
> sources were running on VAX/VMS and alpha/Tru64.

> Many of the sources use OPEN with no filenames; old-style preconnected files. In
> the past the names have been specified with environmental variables, eg:

> export fort1=temp.txt

Using the environment in this way must be a Tru64-ism to emulate
the VMS logical names (maybe Steve can confirm ?). I don't think
the Fortran runtime of Linux compilers will support that mechanism.

An alternative would be to plant symbolic links,

ln -s temp.txt fort.1

before running the program. If that creates too much clutter
among your files you can move the mess to a staging directory:

mkdir staging
cd staging
ln -s ../temp.txt fort.1
ln -s ../othertemp.txt fort.2
<etc.>
../the_executable

--
pa at panix dot com