mingw-msys Mailing List for MinGW - Minimalist GNU for Windows

FWIW here's an old school win32 in-console manpage viewer. Needs:
groff and less from http://gnuwin32.sf.net
and perl from http://activestate.com
in your path, and a semicolon-separated Windows filename-format MANPATH,
e.g. C:\Program Files\GnuWin32\man;G:\usr\share\man (if G:'s your Linux root).
Suggest installing this as 'man' in your path and copying
runperl.bat from ActiveState Perl's bin into the same directory,
naming it 'man.bat'; that way both MSYS sh.exe and cmd.exe sessions
will be able to run it.

Some console usability recommendations:
* run MSYS's sh.exe directly (not via rxvt or msys.bat).
rxvt screws up gdb's command line editing when you run gdb.
* Install "Bitstream Vera Sans Mono" (find it on gnome.org) as
the console font - this makes it available in the console,
per http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q247815
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Console\TrueTypeFont]
"00"="Bitstream Vera Sans Mono"
* enable "QuickEdit" mode in the console's Options tab for cut/paste
* change the default console foreground color to bright white (from grey)
* make a ~/.inputrc and set INPUTRC to point to it like so:
C:/msys/1.0/home/whatever/.inputrc (note the fwd slashes)
Example vi-mode .inputrc:

set editing-mode vi
TAB: complete
Control-d: possible-completions

... now set -o vi is not needed (it's broken anyway), sh does filename
completion, and gdb will work right in console. On filename completion,
this makes TAB do it in cmd.exe:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor]
"CompletionChar"=dword:00000009
"PathCompletionChar"=dword:00000009

... now I can get back to coding. -Huw

<quote who="Dominique Orban">
>
> df -I"/c/a/b/c" prog.f90
>
> fails. The compiler still complains that /msys is an unknown switch.
> It's a shame.
>

But ``df -I'c:\a\b\c' prog.f90'' should work!  I don't expect ``df
-I"/c/a/b/c" prog.f90'' to work.  I also don't expect ``df -I"c:\a\b\c"
prog.f90'' to work.

Earnie

--
http://www.mingw.org
http://sourceforge.net/projects/mingw
https://sourceforge.net/donate/index.php?user_id=15438

> Date: Tue, 22 Feb 2005 16:21:16 -0500 (EST)
> Subject: Re: [Mingw-msys] Re: Msys and Fortran 90
> From: "Earnie Boyd" <ea...@us...>
> To: min...@li...
> Reply-To: min...@li...

> Complain to Digital Fortran, they had to go out of their way to enforce \
> instead of /.  From MSYS -I/a/b/c/d passed to a non MSYS program becomes
> -Ia:/b/c/d.  Every API from MS accepts / instead of \; it is the tool
> frontend that forces one to use \ instead of /.
> 
> Earnie

Well thanks a lot for the info Earnie (and the historical remarks,
Keith). I hadn't tried enclosing the include path between quotes.
Interestingly enough, Digital Fortran 6.6 accepts forward slashes if
between quotes from CMD.EXE, eg

df -I"c:\a\b\c" prog.f90

works well. Unfortunately, it doesn't from Msys, eg

df -I"/c/a/b/c" prog.f90

fails. The compiler still complains that /msys is an unknown switch.
It's a shame.

It fails in Cygwin for the same reason. For info, the same test with
Microsoft's C/C++ compiler found in Visual Studio 6 succeeds from Msys
and fails from Cygwin, ie:

cl -I/a/b/c prog.c

works ok at an Msys prompt but fails from a Cygwin prompt. Cygwin wants to have

cl -Ia:/b/c

with forward slashes. It doesn't want backslashes. Now I must make
clear that I haven't updated my Cygwin in a little while; that
behavior might have changed. My Msys is the latest though.

Thanks again,
Dominique

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3012549
By: nalav

Ahh I think I did do that. Thanks, I'll go and reinstall it all then. Maybe
I should actually read the docs.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575

Earnie Boyd wrote:
><quote who="Keith MARSHALL">
>>>> Why is that? Why do some windows program accept the msys path and
>>>> others don't? How do i work around that?
>>>
>>> Complain to Digital Fortran, they had to go out of their way to
>>> enforce \ instead of /.  From MSYS -I/a/b/c/d passed to a non MSYS
>>> program becomes -Ia:/b/c/d.  Every API from MS accepts / instead of
>>> \; it is the tool frontend that forces one to use \ instead of /.
>>
>> Off topic, but of possible historical interest.
>
> Not really off topic.

Well, I thought the reference to MS-Pascal might be considered off
topic, although the concept remains relevant.

>> Digital Fortran aren't the only offenders, in this respect -- Microsoft
>> themselves got it wrong, in their MS-DOS Pascal compiler.  Although all
>> MS-DOS kernels since version 2.xx would happily accept / in path names,
>> the file system API in MS-Pascal enforced the use of \, and, of course,
>> COMMAND.COM, and more recently CMD.EXE, think that / is reserved for
>> use as an option switch, regardless of where it appears in the command
>> line.  All the system commands which Windows has inherited from MS-DOS
>> also exhibit this behaviour.
>
> But converting / to \ isn't usually correct and would cause other 
issues. 
> Does -I 'a:\b\c\d' work for the OP?  Note the use of the single quote
> character.

One would expect that -I 'a:\b\c\d' should work.  I fully agree that
converting / to \ as a general principal would not be desirable.  I was
(again) pointing out that, IMO, Microsoft are the real offenders here,
for trying to implement a CLI which is modelled simultaneously on
UNIX and CP/M semantics, (which are incompatible), and for failing to
adequately document its file system API;  other software vendors have
simply, and perhaps unnecessarily, followed the MS example, in continuing
to slavishly implement the long defunct CP/M CLI semantics.

Regards,
Keith.

<quote who="Keith MARSHALL">
>>> Why is that? Why do some windows program accept the msys path and
>>> others don't? How do i work around that?
>>
>> Complain to Digital Fortran, they had to go out of their way to enforce
> \
>> instead of /.  From MSYS -I/a/b/c/d passed to a non MSYS program becomes
>> -Ia:/b/c/d.  Every API from MS accepts / instead of \; it is the tool
>> frontend that forces one to use \ instead of /.
>
> Off topic, but of possible historical interest.
>

Not really off topic.

> Digital Fortran aren't the only offenders, in this respect -- Microsoft
> themselves got it wrong, in their MS-DOS Pascal compiler.  Although all
> MS-DOS kernels since version 2.xx would happily accept / in path names,
> the file system API in MS-Pascal enforced the use of \, and, of course,
> COMMAND.COM, and more recently CMD.EXE, think that / is reserved for
> use as an option switch, regardless of where it appears in the command
> line.  All the system commands which Windows has inherited from MS-DOS
> also exhibit this behaviour.
>

But converting / to \ isn't usually correct and would cause other issues. 
Does -I 'a:\b\c\d' work for the OP?  Note the use of the single quote
character.

Earnie

--
http://www.mingw.org
http://sourceforge.net/projects/mingw
https://sourceforge.net/donate/index.php?user_id=15438

>> Why is that? Why do some windows program accept the msys path and
>> others don't? How do i work around that?
>
> Complain to Digital Fortran, they had to go out of their way to enforce 
\
> instead of /.  From MSYS -I/a/b/c/d passed to a non MSYS program becomes
> -Ia:/b/c/d.  Every API from MS accepts / instead of \; it is the tool
> frontend that forces one to use \ instead of /.

Off topic, but of possible historical interest.

Digital Fortran aren't the only offenders, in this respect -- Microsoft
themselves got it wrong, in their MS-DOS Pascal compiler.  Although all
MS-DOS kernels since version 2.xx would happily accept / in path names,
the file system API in MS-Pascal enforced the use of \, and, of course,
COMMAND.COM, and more recently CMD.EXE, think that / is reserved for
use as an option switch, regardless of where it appears in the command
line.  All the system commands which Windows has inherited from MS-DOS
also exhibit this behaviour.

Regards,
Keith.

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3011724
By: keithmarshall

Did you, by any chance, install MinGW and MSYS into the same directory?  You
*must* not do this -- the docs are quite explicit about it.

IIRC, the behaviour you have observed is symptomatic of such an improper
install.

HTH.

Keith.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3011487
By: nalav

I hope I post this in the right place. Here is what happens when trying to use
gcc:

root@rhino:~$ echo "int main() { return 0; }" > apples.c
root@rhino:~$ gcc apples.c 
gcc.exe: no input files

This is from rxvt running sh. When I try it from command.com, I think it might
work, but it can't find -luser32. I really don't care much if it works from
there though, I need it working from sh. How might I go about doing this?


______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575

<quote who="Dominique Orban">
>
>      f90 -I/a/b/c/d
>
> doesn't (where f90 is the Digital Fortran). Instead it wants me to say
>
>      f90 -Ia:\b\c\d
>
> Why is that? Why do some windows program accept the msys path and
> others don't? How do i work around that?
>

Complain to Digital Fortran, they had to go out of their way to enforce \
instead of /.  From MSYS -I/a/b/c/d passed to a non MSYS program becomes
-Ia:/b/c/d.  Every API from MS accepts / instead of \; it is the tool
frontend that forces one to use \ instead of /.

Earnie

--
http://www.mingw.org
http://sourceforge.net/projects/mingw
https://sourceforge.net/donate/index.php?user_id=15438

 Hi,
 I do use minGW together with the msys and try to make my progs p686
 compatible.
 I have this environment installed on two comps; at home and at work. At
home i have WinXp on Athlon1.8G,
at work only Win98 - 4.10.1998 on PentiumII and I try to compile at work
files produced at home.
But it fails. I can use -mpei-i686 option to g++ (I am writing in c++) to
link object files produced at home and it works - compilation results in a
right exe file without any faults.
This is unfortunately not enough to work at work  ;)
I want to reedit my files and to compile it.
Question is how to change from target/machine i386pe to 686 to have the
possibility to compile .cpp files at work?

Best regards, Andrzej
 http://tichy.fm.interia.pl   (in Polish only)
> >
>

> Date: Mon, 21 Feb 2005 07:37:31 -0500 (EST)
> Subject: Re: [Mingw-msys] Msys and Fortran 90
> From: "Earnie Boyd" <ea...@us...>
> To: min...@li...
> Reply-To: min...@li...

> >> 2. Is it possible to use g95 from within MinGW/MSYS?

> PATH=/path/to/g95/bin:$PATH /path/to/g95/bin/g95 ...

Great! It was so simple, my question was stupid. Sorry and thanks!

> To: min...@li...
> From: Mark Hadfield <m.h...@ni...>
> Date: Tue, 22 Feb 2005 16:11:39 +1300
> Subject: [Mingw-msys] Re: Msys and Fortran 90
> Reply-To: min...@li...

> Writing a shell script to serve in place of DFVARS.BAT is not that hard.

Sure, thanks a lot for the script. I realize it isn't hard to rewrite
one, but i guess i just like to have the conversion process more or
less automated, so other users don't have to rely on my own conversion
of the batch file. I was just noting that gotos and labels make the
automation harder.

Regarding my other qestion on the -I flag and the form of the path
(windows style vs. unix style), i realize it might not be the goal of
MinGW/Msys to be a full port of Unix/Linux to Windows, but i note the
following: from an msys command line, calling

     g95 -I/a/b/c/d

works fine, but calling

     f90 -I/a/b/c/d

doesn't (where f90 is the Digital Fortran). Instead it wants me to say

     f90 -Ia:\b\c\d

Why is that? Why do some windows program accept the msys path and
others don't? How do i work around that?

Thanks a lot,
Dominique

Dominique Orban wrote:

 >> From: "Luke Dunstan" <cod...@ho...>
 >>
 >>> 1. I have Digital Fortran and would like to use it. If you were
 >>> to use it from a regular Windows command window, you'd first have
 >>> to execute a batch file called DFVARS.BAT located in the Digital
 >>> Fortran tree,
 >>> which sets environment variables used by the linker. From an MSYS
 >>> command prompt, how should I go about source-ing that batch file?
 >>> Trying to simply execute it results in error (e.g., the 'rem'
 >>> commands cause errors).
 >>
 >>
 >> You can't. You would have to convert it to a shell script,
 >> e.g. change "set FOO=bar" to "export FOO=bar".
 >
 > Allright, but in most cases, that's not a viable option as batch files
 > make heavy use of goto statements (unfortunately), which doesn't have
 > a bash equivalent.


Writing a shell script to serve in place of DFVARS.BAT is not that hard.

Below my sig is a bash function that I have written to set up the 
environment variables needed to run CVF 6 under the Cygwin bash shell. I 
call it as needed from the shell, but the same code could be bundled in 
.bashrc or whatever. The corresponding code for Msys is left as an 
exercise for the reader: it will be somewhat simpler than the Cygwin 
code as the Windows-Unix path conversion stuff can be omitted.

-- 
Mark Hadfield            "Ka puwaha te tai nei, Hoea tatou"
m.h...@ni...
National Institute for Water and Atmospheric Research (NIWA)


function set-df ()
{
     echo Setting environment variables for Compaq Visual Fortran 6

     msdev='D:\Program Files\Microsoft Visual Studio'

     export MSDEVDIR=$msdev\\Common\\MSDEV98
     export TOOLSDIR=$msdev\\Common\\TOOLS

     export DFDIR=$msdev\\DF98
     export VCDIR=$msdev\\VC98

     export MSDEVDIR_POSIX=$(cygpath --unix "$MSDEVDIR")
     export TOOLSDIR_POSIX=$(cygpath --unix "$TOOLSDIR")
     export DFDIR_POSIX=$(cygpath --unix "$DFDIR")
     export VCDIR_POSIX=$(cygpath --unix "$VCDIR")

     export 
PATH=$MSDEVDIR_POSIX/Bin:$DFDIR_POSIX/Bin:$VCDIR_POSIX/Bin:$TOOLSDIR_POSIX:$PATH

     export INCLUDE=$DFDIR\\Include';'$VCDIR\\Include
     export LIB=$DFDIR\\Lib';'$VCDIR\\Lib

     export FC=df

     export DF="/nologo /traceback"
}

> Message: 1
> From: "Luke Dunstan" <cod...@ho...>

> ----- Original Message -----
> From: "Dominique Orban" <dom...@gm...>
> Subject: [Mingw-msys] Msys and Fortran 90

> > 1. I have Digital Fortran and would like to use it. If you were to use
> > it from a regular Windows command window, you'd first have to execute
> > a batch file called DFVARS.BAT located in the Digital Fortran tree,
> > which sets environment variables used by the linker. From an MSYS
> > command prompt, how should I go about source-ing that batch file?
> > Trying to simply execute it results in error (e.g., the 'rem' commands
> > cause errors).
> 
> You can't. You would have to convert it to a shell script, e.g. change "set
> FOO=bar" to "export FOO=bar".

Allright, but in most cases, that's not a viable option as batch files
make heavy use of goto statements (unfortunately), which doesn't have
a bash equivalent.

I found a workaround, which is to simply create a windows shortcut calling
     cmd /K "sequence of commands"
in which the sequence of commands sources the batch file in question,
changes to c:\msys\1.0 and executes msys.bat. At least, that's working
for me.

Now Digital Fortran (or most Windows compilers for that matter)
accepts an option of the form
    -Ic:\path\to\include\dir
to include whatever files (headers, modules, etc.). Switches to
programs in Windows usually use the forward slash '/' but most
programs also accept the dash '-'. Now, from within msys, if you want
to specify
     -I/c/path/to/include/dir
(with forward slashes), the compiler complains that it doesn't know
the switch "/msys".

This results, I am guessing, from expansion of /c/path. If i use the
backslash path separator, all works well.

Is there a way to be able to use forward slashes in the -I command-line option?

Thanks,
Dominique

<quote who="Luke Dunstan">
>
> ----- Original Message -----
> From: "Dominique Orban" <dom...@gm...>
> To: <min...@li...>
> Sent: Sunday, February 20, 2005 8:11 AM
> Subject: [Mingw-msys] Msys and Fortran 90
>
>>
>> 2. Is it possible to use g95 from within MinGW/MSYS? I have downloaded
>> it (the version for systems without Cygwin), but unfortunately, it
>> also has a linker called ld.exe which seems to conflict with MinGW's
>> ld.exe. Has anyone been able to work around that?
>>
>> Many thanks,
>> Dominique
>
> I don't know the answer to this one, so I'll leave it to someone else.
>

PATH=/path/to/g95/bin:$PATH /path/to/g95/bin/g95 ...

Earnie

--
http://www.mingw.org
http://sourceforge.net/projects/mingw
https://sourceforge.net/donate/index.php?user_id=15438

----- Original Message ----- 
From: "Dominique Orban" <dom...@gm...>
To: <min...@li...>
Sent: Sunday, February 20, 2005 8:11 AM
Subject: [Mingw-msys] Msys and Fortran 90


> Hello,
>
> I am trying to compile mixed C and Fortran 90 source files from within
> MinGW/MSYS. I downloaded the latest stable packages yesterday and have
> two questions:
>
> 1. I have Digital Fortran and would like to use it. If you were to use
> it from a regular Windows command window, you'd first have to execute
> a batch file called DFVARS.BAT located in the Digital Fortran tree,
> which sets environment variables used by the linker. From an MSYS
> command prompt, how should I go about source-ing that batch file?
> Trying to simply execute it results in error (e.g., the 'rem' commands
> cause errors).

You can't. You would have to convert it to a shell script, e.g. change "set
FOO=bar" to "export FOO=bar".

>
> 2. Is it possible to use g95 from within MinGW/MSYS? I have downloaded
> it (the version for systems without Cygwin), but unfortunately, it
> also has a linker called ld.exe which seems to conflict with MinGW's
> ld.exe. Has anyone been able to work around that?
>
> Many thanks,
> Dominique

I don't know the answer to this one, so I'll leave it to someone else.

Luke

Hello,

I am trying to compile mixed C and Fortran 90 source files from within
MinGW/MSYS. I downloaded the latest stable packages yesterday and have
two questions:

1. I have Digital Fortran and would like to use it. If you were to use
it from a regular Windows command window, you'd first have to execute
a batch file called DFVARS.BAT located in the Digital Fortran tree,
which sets environment variables used by the linker. From an MSYS
command prompt, how should I go about source-ing that batch file?
Trying to simply execute it results in error (e.g., the 'rem' commands
cause errors).

2. Is it possible to use g95 from within MinGW/MSYS? I have downloaded
it (the version for systems without Cygwin), but unfortunately, it
also has a linker called ld.exe which seems to conflict with MinGW's
ld.exe. Has anyone been able to work around that?

Many thanks,
Dominique

Hi,

After install the MSYS on WinXp, click the icon on the desktop, the
MSYS window show up in less than 2 seconds, then automatically
closed. Any idea?

Thanks,

Yu


		
__________________________________ 
Do you Yahoo!? 
Take Yahoo! Mail with you! Get it on your mobile phone. 
http://mobile.yahoo.com/maildemo 

<quote who="gr...@gm...">
> Hello,
>
> I'm trying to use the autoconf utilities under msys, but instead of the
> standard perl I would get with msysDTK, i would like to use the
> ActivePerl one.

Tried that without success.  It is the reason why I provide an MSYS
version of perl.

> I extracted the file msys-autoconf-2.59.tar.bz2 in the
> msys root diretory (on my system it's E:\msys\1.0).

That is good.

> Then I created a
> link in the /usr/bin directory for "perl" pointing to the ActivePerl
> perl.exe executable, but with no luck.

Unless you have version 1.0.11 of MSYS then copying a non MSYS binary to
/usr/bin isn't going to work.  See the /doc/msys/README.rtf file.

> When i run for example
> "autogen.sh" the program stops on the call of "autoheader" waiting for
> the input on the stdin :-) Im not expert at all about unix and scripting
>   Any hint (apart rtfm)?
>

Probably the result of the non MSYS binary in /usr/bin.


Earnie

P.S. ``ln -s foo bar'' just copies foo to bar; foo must exist, bar must be
specified; these two caveats are non standard for symlink.

--
http://www.mingw.org
http://sourceforge.net/projects/mingw
https://sourceforge.net/donate/index.php?user_id=15438

Hello,

I'm trying to use the autoconf utilities under msys, but instead of the 
standard perl I would get with msysDTK, i would like to use the 
ActivePerl one. I extracted the file msys-autoconf-2.59.tar.bz2 in the 
msys root diretory (on my system it's E:\msys\1.0). Then I created a 
link in the /usr/bin directory for "perl" pointing to the ActivePerl 
perl.exe executable, but with no luck. When i run for example 
"autogen.sh" the program stops on the call of "autoheader" waiting for 
the input on the stdin :-) Im not expert at all about unix and scripting 
  Any hint (apart rtfm)?

Greetings,
Luca

<quote who="Dave Hylands">
>> A bug in the pty emulation with a spawned ``native'' program.
>>  I'm working
>> on trying to find a fix.  I don't know that one can be found.
>>  AFAIK, the
>> problem exists with the Cygwin RXVT as well.  Using fflush is the only
>> known work around.
>
> Sounds like a buffering issue. Maybe stdout isn't line buffered in the
> spawned program?
>

I'm thinking that maybe stdout is line buffered in the spawned program. 
But stdout is basically just a pipe.  The fix has to be in the MSYS dll
itself and not in RXVT.  I've narrowed it to the pty emulation and MSYS
not having control of the processes from MSVCRT.DLL.  Try ``start
/bin/rxvt -e /c/windows/system32/ftp'' for an experiment.


Earnie

--
http://www.mingw.org
http://sourceforge.net/projects/mingw
https://sourceforge.net/donate/index.php?user_id=15438

> A bug in the pty emulation with a spawned ``native'' program.=20
>  I'm working
> on trying to find a fix.  I don't know that one can be found.=20
>  AFAIK, the
> problem exists with the Cygwin RXVT as well.  Using fflush is the only
> known work around.

Sounds like a buffering issue. Maybe stdout isn't line buffered in the
spawned program?

--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/=20

<quote who="Massimiliano Cialdi">
> I tried the following:
>
> #include <stdio.h>
> #include <Windows.h>
> int main(void)
> {
>   while(1)
>   {
>     printf("abcd\n");
>     Sleep(1000);
>   }
>   return 0;
> }
>
> compiled with:
> gcc -mconsole -Wall test.c -o test
>
> if I execute test.exe from msys it seems that printf doesn't works. If I
> execute test.exe from a windows console it works fine.
>
> If I try to remove the Sleep(1000) line and recompile with the same
> command,
> the test.exe work also from msys.
>
> Is this a bug?
> Is it possible to make it works in msys too?
>

A bug in the pty emulation with a spawned ``native'' program.  I'm working
on trying to find a fix.  I don't know that one can be found.  AFAIK, the
problem exists with the Cygwin RXVT as well.  Using fflush is the only
known work around.


Earnie

--
http://www.mingw.org
http://sourceforge.net/projects/mingw
https://sourceforge.net/donate/index.php?user_id=15438

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=2990058
By: earnie

A bug in the pty emulation with a ``native'' program.  I'm working on trying
to find a fix.  I don't know that one can be found.  AFAIK, the problem exists
with the Cygwin RXVT as well.  Using fflush is the only known work around.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=2989230
By: mastupristi

I tried the following

#include <stdio.h>
#include <Windows.h>

int main(void)
{
  int i;
  for(i=0;i<5;i++)
  {
    printf("abcd %d\r\n",i);
//    fflush(stdout);
    Sleep(1000);
  }
  return 0;
}

compiled with
gcc -mconsole -Wall test.c -o test

without fflush the printf output is flushed only at the end.
The printf should flush the buffer when a '\n' characters is read, isn't it?
So why the fflus is necessary?

note that when I execute test.exe from a windows XP console all works fine,
also without fflush.

is this behaviour depends on printf or on msys?

thanks


______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575