Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/17/84; site hao.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!hao!woods
From: woods@hao.UUCP (Greg Woods)
Newsgroups: net.lang.f77
Subject: Re: binary i/o problem
Message-ID: <1540@hao.UUCP>
Date: Tue, 14-May-85 01:37:02 EDT
Article-I.D.: hao.1540
Posted: Tue May 14 01:37:02 1985
Date-Received: Thu, 16-May-85 05:50:39 EDT
References: <136@lamont.UUCP> <> <455@gargoyle.UChicago.UUCP>
Organization: High Altitude Obs./NCAR, Boulder CO
Lines: 34

> When there is no filename, the filename defaults
> to "fort.unitnumber", which explains the error message (fort.5 does
> not exist, hence is empty, so the first read gets EOF).  I almost
> replied saying to  "open(5, file='/dev/tty',form='unformatted',...)",
> but I don't think this will work if you use a pipe to enter the data.
> I think in all cases /dev/tty is connected to the
> terminal.  Does anyone have any other ideas?

  Yes. Use the isatty(3F) function which tells you whether standard
input is a terminal or not. If so, your open will work fine. If
not, don't ever close unit 5.

--Greg

P.S. I gave up on FORTRAN I/O a long time ago. We solved this problem here
by implementing a library of trivial C functions to give us access to the 
system calls we needed. For example:

int uread_(fd,addr,bytes) int *fd; char *addr; int *bytes;
{ return(read(*fd,addr,*bytes); }

  This can now be called from FORTRAN under BSD just like a read call in C.
Deals directly with file descriptors so no messing with FORTRAN I/O 
conventions. The disadvantage, of course, is that it's not meaningless
on a non-UNIX system and non-portable to systems that don't allow FORTRAN
and C to call each other.
-- 
{ucbvax!hplabs | allegra!nbires | decvax!noao | harpo!seismo | ihnp4!noao}
       		        !hao!woods

CSNET: woods@NCAR  ARPA: woods%ncar@CSNET-RELAY
   
     "...I may not be right but I've never been wrong
      It seldom turns out the way it does in the song..."