revans@voodoo.ucsb.edu (02/28/90)
Yesterday, I posted a request for help with an obscure problem I've been
having in this area. As yet, I've had no response, but I have managed to
localise the problem to an interaction between the FORTRAN I/O system and
the system() subroutine. The following program exhibits the problem. I
have been told that the compiler is not the latest release, by the way.
Is this a known problem? Has Sun released a fix? Or is it a 'feature'?
c buggy.f Russ Evans 27-Feb-90
c demonstrates problem of interaction between the FORTRAN I/O
c rt-system and the 'system' call on Sun 4/280. As yet untested
c in other environments. An erroneous EOF is found on the input
c unit following the call to system. Contents of infile.dat and
c of the argument to system appear to be immaterial. Behaviour
c does not depend on choice of unit 10 for file input.
character record*80
character infile*15
parameter (infile = 'infile.dat')
integer i,system
open(unit=10, file=infile, status='OLD', err=901)
10 read(unit=10, fmt='(A)', err=902, end=903) record
write(unit=6, fmt='(A)') record
i=system('lpr junk')
goto 10
901 write(unit=6, fmt='(2A)') 'Failed to open ', infile
stop
902 stop 'Read error on unit 10'
903 stop 'End of file on unit 10'
end
Russ Evans, British Geological Survey, Edinburgh UK e_gs18@va.nmh.ac.uk
.. just visiting (and working hard) at UCSB ..rmaddale@lodestar.gb.nrao.edu ( RON MADDALENA ) (03/01/90)
I've never yet saw a UNIX system in which a Fortran SYSTEM call did not do
something wrong!! In almost all cases it has been some bizarre
interaction between Fortran I/O and SYSTEM. The 'fix' I've come up with,
which works in almost all cases, is to call a c-routine (given below)
which does the actual SYSTEM call (i.e., I cheat).
int csystem_(string, len) /* Does a SYSTEM call */
char *string[];
int len;
{
return(system(string));
}
Basically, just replace the word SYSTEM with CSYSTEM in your calling
program, compile it and the c-routine CSYSTEM, and link the two.
Note, however, that the return code generated by CSYSTEM becomes corrupted
when you run your program in some Sunwindow environments like GFXTOOL --
in GFXTOOL, the return code is ALWAYS a -1, regardless of whether the
SYSTEM call succedded or not. In CMNDTOOL or SHELLTOOL, the return code
is always correct. Therefore, until someone comes up with a 'fix' to this
different bug, one should not, to be on the safe side, test or care about
the return code.
Ronald J. Maddalena <rmaddale@nrao.edu>
National Radio Astronomy Observatory