info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Redirectiong standard error
98 views
Skip to first unread message
Daniel Feenberg
Sep 8, 2021, 2:57:21 PM9/8/21
to
Is there a way within fortran to direct unit 0 (error output) to a file? Particularly I want to redirect it to standard out. I am hoping for something within Fortran that would be portable across major operating systems. I did try
open(unit=0,file="stuff")
and
open(unit=0,file='/dev/tty')
with gfortran under Linux, but the open statement seemed to have no effect.
Daniel Feenberg
NBER
open(unit=0,file="stuff")
and
open(unit=0,file='/dev/tty')
with gfortran under Linux, but the open statement seemed to have no effect.
Daniel Feenberg
NBER
steve kargl
Sep 8, 2021, 4:07:05 PM9/8/21
to
and then re-use that unit number. Not sure if it works.
program foo
use iso_fortran_env
close(ERROR_UNIT)
open(unit=ERROR_UNIT,file=....)
end program foo
--
steve
Daniel Feenberg
Sep 8, 2021, 5:15:09 PM9/8/21
to
On Wednesday, September 8, 2021 at 4:07:05 PM UTC-4, steve kargl wrote:
> Daniel Feenberg wrote:
>
> > Is there a way within fortran to direct unit 0 (error output) to a file? Particularly I want to redirect it to standard out. I am hoping for something within Fortran that would be portable across major operating systems. I did try
...
> Daniel Feenberg wrote:
>
> > Is there a way within fortran to direct unit 0 (error output) to a file? Particularly I want to redirect it to standard out. I am hoping for something within Fortran that would be portable across major operating systems. I did try
> You can try to close ERROR_UNIT from ISO_FORTRAN_ENV
> and then re-use that unit number. Not sure if it works.
>
> program foo
> use iso_fortran_env
> close(ERROR_UNIT)
> open(unit=ERROR_UNIT,file=....)
> end program foo
>
> --
> steve
Just tried it out in gfortran Linux and FreeBSD - no effect on the destination of error output. I did want to avoid depending on the shell for this because different shells have different syntax for this, and I don't want to explain that to users or tell them which shell to use.
> and then re-use that unit number. Not sure if it works.
>
> program foo
> use iso_fortran_env
> close(ERROR_UNIT)
> open(unit=ERROR_UNIT,file=....)
> end program foo
>
> --
> steve
Daniel Feenberg
Steve Lionel
Sep 8, 2021, 7:06:02 PM9/8/21
to
On 9/8/2021 2:57 PM, Daniel Feenberg wrote:
> Is there a way within fortran to direct unit 0 (error output) to a file?
There are two different things at work here. Unit 0 (or whatever
> Is there a way within fortran to direct unit 0 (error output) to a file?
ERROR_UNIT is defined as) is often "preconnected" to stderr. You are
free to reopen that unit on a file, but it is no longer "error output".
Any output that would normally go to stderr, other than explicit writes
to unit 0, will still go to stderr.
The only way I know of to do the redirection you seek is to do it on the
command line invoking the program.
--
Steve Lionel
ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: https://stevelionel.com/drfortran
WG5: https://wg5-fortran.org
steve kargl
Sep 8, 2021, 7:11:50 PM9/8/21
to
to some other value, but suspect that doesn't change the internal use of
stderr (as found in C). Even if an EV worked, you would to users how to
an EV for the different shells.
--
steve
gah4
Sep 8, 2021, 9:36:22 PM9/8/21
to
On Wednesday, September 8, 2021 at 4:11:50 PM UTC-7, steve kargl wrote:
(snip)
isn't so obvious. It might be not read until an actual I/O operations is needed.
(snip)
> Gfortran has an environmental variable that allows one to change the unit
> to some other value, but suspect that doesn't change the internal use of
> stderr (as found in C). Even if an EV worked, you would to users how to
> an EV for the different shells.
You can change an EV within the program. Exactly when its value is needed,
> to some other value, but suspect that doesn't change the internal use of
> stderr (as found in C). Even if an EV worked, you would to users how to
> an EV for the different shells.
isn't so obvious. It might be not read until an actual I/O operations is needed.
Gary Scott
Sep 9, 2021, 6:01:00 AM9/9/21
to
gah4
Sep 9, 2021, 9:31:26 AM9/9/21
to
On Thursday, September 9, 2021 at 3:01:00 AM UTC-7, Gary Scott wrote:
(snip, I wrote)
As it says above: "I did want to avoid depending on the shell for this because
But the other way is to supply a shell script that the user runs, which then runs
the actual program. Unix-like systems run such in a Bourne (sh) shell, unless told
otherwise, independent of the user's actual shell. It does that just for the reason
given: that it works independent of the user's actual shell.
(Except that csh and descendants, if it starts with # and not #!, will run it
in a shell like itself.)
The other other way is to start with #! and the path of a program (shell)
to use to run it.
Of course DOS/Windows use a different system, but the executable file has
to be different, too.
(snip, I wrote)
> > You can change an EV within the program. Exactly when its value is needed,
> > isn't so obvious. It might be not read until an actual I/O operations is needed.
> Depends on the operating system.
OK, back to the start.
> > isn't so obvious. It might be not read until an actual I/O operations is needed.
> Depends on the operating system.
As it says above: "I did want to avoid depending on the shell for this because
different shells have different syntax for this, and I don't want to explain
that to users or tell them which shell to use."
That happens if one asks the user to add variables to the system.
that to users or tell them which shell to use."
But the other way is to supply a shell script that the user runs, which then runs
the actual program. Unix-like systems run such in a Bourne (sh) shell, unless told
otherwise, independent of the user's actual shell. It does that just for the reason
given: that it works independent of the user's actual shell.
(Except that csh and descendants, if it starts with # and not #!, will run it
in a shell like itself.)
The other other way is to start with #! and the path of a program (shell)
to use to run it.
Of course DOS/Windows use a different system, but the executable file has
to be different, too.
0 new messages