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

Standard input

9 views
Skip to first unread message

Tim Springer

unread,
May 2, 2008, 7:33:36 AM5/2/08
to
Dear Group,

The program package I am using executes programs in the following way (under Unix):
program.bin < program.input

So the file "program.input" is piped in to the program "program.bin" and thus to my understanding the "program.input" is connected
to the standard input of the fortran program.

Now I would like to be able for a new programme to have some manual interaction with the program. So read something from standard
input (i.e. command line) and let the program do something based on that input. However, since the file "program.input" is now the
standard input I do not seem to be able to input anything from the command line. I tried closing and reopening unit 5 but that
does not work.

Any hints and tips how to solve this using Fortran90 or 95.

Of course the easiest for this program is to run it without piping anything into the programme. However, that would affect all the
other programs I have (although the change would just be in 1 library, so it is not impossible). However, if there is an easier
way around this I would be very interested!

Many thanks in advance!

Cheers,
Tim Springer

Charles Coldwell

unread,
May 3, 2008, 9:52:18 AM5/3/08
to
"Tim Springer" <Tim-Sprin...@t-online.de> writes:

> Dear Group,
>
> The program package I am using executes programs in the following way (under Unix):
> program.bin < program.input
>
> So the file "program.input" is piped in to the program "program.bin"
> and thus to my understanding the "program.input" is connected to the
> standard input of the fortran program.
>
> Now I would like to be able for a new programme to have some manual
> interaction with the program. So read something from standard input
> (i.e. command line) and let the program do something based on that
> input. However, since the file "program.input" is now the standard
> input I do not seem to be able to input anything from the command
> line. I tried closing and reopening unit 5 but that does not work.

Try this:

program stdin
implicit none
character(len=80) :: line

do
read (5,*,end=100) line
write (6,*) line
end do
100 close(5)
open(unit=5,file="/dev/tty")
do
read (5,*,end=200) line
write (6,*) line
end do
200 continue
end program stdin

--
Charles M. "Chip" Coldwell
"Turn on, log in, tune out"
GPG Key ID: 852E052F
GPG Key Fingerprint: 77E5 2B51 4907 F08A 7E92 DE80 AFA9 9A8F 852E 052F

Arjen Markus

unread,
May 4, 2008, 7:43:41 AM5/4/08
to
On 3 mei, 15:52, Charles Coldwell <coldw...@gmail.com> wrote:

Cute solution, but here are a few caveats:

1. The device file "/dev/tty" exists or is usuable for this purpose on
UNIX, Linux and (I assume, I have no access to it) OSX and systems
like that. This includes Cygwin under MS Windows by the way - at
least with the gfortran compiler.
2. Under MS Windows directly, it does not exist - you need a different
file name. I thought "con" would work, but it does not - at least
not with Compaq Visual Fortran. The effect is that the loop stops
immediately ... hm, maybe a slight modification will work ... no,
I thought "advance=no" might help. It does not.
3. The second loop does not terminate: there is no end-of-file
condition,
even with an empty line.
This can easily be solved by introducing a keyword like "QUIT" -
check
for that keyword to stop the loop.

Regards,

Arjen


Charles Coldwell

unread,
May 4, 2008, 10:16:28 PM5/4/08
to
Arjen Markus <arjen....@wldelft.nl> writes:

>
> Cute solution, but here are a few caveats:
>
> 1. The device file "/dev/tty" exists or is usuable for this purpose on
> UNIX, Linux and (I assume, I have no access to it) OSX and systems
> like that.

Quoting the OP

>> > The program package I am using executes programs in the following
>> > way (under Unix): program.bin < program.input

> 3. The second loop does not terminate: there is no end-of-file


> condition,
> even with an empty line.

Try "ctrl-D"

Chip

Arjen Markus

unread,
May 5, 2008, 3:14:12 AM5/5/08
to
On 5 mei, 04:16, Charles Coldwell <coldw...@gmail.com> wrote:

> Arjen Markus <arjen.mar...@wldelft.nl> writes:
>
> > Cute solution, but here are a few caveats:
>
> > 1. The device file "/dev/tty" exists or is usuable for this purpose on
> >    UNIX, Linux and (I assume, I have no access to it) OSX and systems
> >    like that.
>
> Quoting the OP

It is a rather elegant solution - I had not thought
there would be any :) - so I was interested to see
how it turned out on Windows ...

>
> >> > The program package I am using executes programs in the following
> >> > way (under Unix): program.bin < program.input
> > 3. The second loop does not terminate: there is no end-of-file
> > condition,
> >    even with an empty line.
>
> Try "ctrl-D"
>

Oops, that feature of UNIX/Linux shells had fallen into
the cracks of my memory :).

Regards,

Arjen

Charles Coldwell

unread,
May 5, 2008, 6:40:19 AM5/5/08
to
Arjen Markus <arjen....@wldelft.nl> writes:

> It is a rather elegant solution - I had not thought
> there would be any :) - so I was interested to see
> how it turned out on Windows ...

That's a very interesting question, actually. Unix grew up in the era
of real, hardware terminals and so the concept is well developed in
the OS. So well, in fact, that even after the era ended the concept
lives on as "pseudo-terminals". So if you run a terminal emulator in
Unix (xterm, gnome-terminal, kterm, what-have-you) the emulator is
connected to the shell (or a program forked and exec'd by the shell)
through a pseudo-terminal provided by the operating system kernel
(/dev/pts/N on Linux -- UNIX98 PTYs, /dev/ttypN or /dev/ttyXY on BSD).

In any process, /dev/tty is an alias for the process' controlling
terminal (you can find the real name of your controlling terminal by
running the "tty" command). So, in fact, having standard input (unit
5) connected to /dev/tty is exactly what would have happened if input
had not been redirected from a file.

I have no idea if any of these concepts (controlling terminal,
pseudo-terminal, foreground process groups, etc) exist at all on
Windows.

>> Try "ctrl-D"
>>
>
> Oops, that feature of UNIX/Linux shells had fallen into
> the cracks of my memory :).

Actually, it's not a feature of the shell at all; when the Fortran
program is running the shell is out of the picture. The Fortran
program is getting input from the terminal device (or
pseudo-terminal), and the terminal driver in the OS kernel converts
the ASCII Ctrl-D (EOT -- end of transmission) into and end-of-file
condition.

0 new messages