This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [patch, libfortran] PR32784 CONIN$, CONOUT$, and CONERR$ for Cygwin and mingw
Danny Smith wrote:
Pardon me Danny, I'm piggybacking on your reply here but it's mostly
directed at Jerry.
> On Sun, Jun 14, 2009 at 1:30 PM, Jerry DeLisle<jvdelisle@verizon.net> wrote:
>> Jerry DeLisle wrote:
>>> The attached patch provides mapping the special file names to standard IO.
>>> This is an extension requested quite a ways back.
>>>
>>> Applied and tested / regression tested on Cygwin running on WinNT
>>> workstation. I do not have a working mingw set-up and would much appreciate
>>> someone building and testing for that system.
>>>
>>> OK for trunk if so tested and passes?
>>>
>> Here is a simple test case i have used. Redirection on the output apears to
>> work as well.
>>
>> character(25) :: astring
>> open(unit=29,file='CONOUT$')
>> write(29,100)
>> 100 format('Hello, world!')
>> open(unit=39,file='CONERR$')
>> write(39,200)
>> 200 format('This goes to conerr$!')
>> open(unit=49,file='CONIN$')
>> read(49,'(a)') astring
>> write(29,'(a)') astring
>> end
>>
>
> The testcase fails on mingw32. This is the output, when run from DOS cmd:
>
> Hello, world!
> This goes to conerr$!
>
> The program then hangs until I press <Enter> key.
That would be it waiting for input on CONIN$, wouldn't it?
> The last output to CONOUT is lost.
> Similar problems occur if I redirect stdout or stderr output.
>
> If redirect stdin through a pipe (eg when testing the program from a
> text editor) I get:
> Hello, world!
> This goes to conerr$!
> At line 9 of file conout.f90 (unit = 49, file = 'CONIN$')
> Fortran runtime error: Bad file descriptor
Jerry, I see you describe it as an extension, but I don't understand what
this patch is meant to do. CONIN$/CONOUT$/CONERR$ are not supposed to be the
same things as stdin/out/err, particularly when redirection is in effect; in
Win32 terms, they mean "Get me a real console, I want to talk to it no matter
what". For instance, if I run this cygwin C testcase in a DOS console:
----------------------------<snip!>----------------------------
$ cat tc3.c
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <fcntl.h>
#define STRING1 "String 1 to CONOUT!\n"
int main ()
{
int fd1;
fd1 = open ("/dev/conout", O_WRONLY);
write (fd1, STRING1, strlen (STRING1));
close (fd1);
printf ("Hello world!\n");
return 0;
}
admin@ubik /tmp/console
$ gcc-4 -g -O0 tc3.c -o tc3
admin@ubik /tmp/console
$ ./tc3.exe
String 1 to CONOUT!
Hello world!
admin@ubik /tmp/console
$ ./tc3.exe > foo
String 1 to CONOUT!
admin@ubik /tmp/console
$ cat foo
Hello world!
admin@ubik /tmp/console
$
----------------------------<snip!>----------------------------
... you see that the whole point of CONOUT$ is that it doesn't get redirected
even when stdout does. This is even more dramatically demonstrated if I
launch a cygwin gui console like rxvt, which doesn't have an actual windows
console underlying it; the CONOUT$ output goes to the original DOS console
from which I launched rxvt. So, this is a somewhat strange thing for the
runtime to want to do; shouldn't it be at least under the control of some
option or flag?
cheers,
DaveK