On Tuesday 21 October 2008 07:43:26 Uli Hertlein wrote:
> Thomas Steinbach wrote:
> > I would like to compile a standard C program with the
> > mingw-gcc compiler collection for a Windows system
> > (just a simple test.exe console program)
> > The problem is that the runtime of a compiled/linked
> > test.exe use the unix-like behavior of the shell and
> > expand the commandline wildcards to a list of files
> > which will passed to the test.exe .
> > But I really need to have the behavior of the MS
> > (Borland) Compiler/Linker which pass the commandline
> > ags and the wildcards directly to the program.
> > and then run:
> > example.exe *.*
> > it will produce an output like:
> > ---snip---
> > CommandLine is: test.exe testdir test.txt comp.bat
> > Argument 0 is: test.exe
> > Argument 1 is: testdir
> > Argument 2 is: test.txt
> > Argument 3 is: comp.bat
> > ---snap---
> > Does anybody a solution?
> > I can't find a linker flag or somehing like this.
> > Perhaps it is possible to patch the MinGW Runtime
> > files crt0 etc.?
> > btw: which are the stdlibs of the gcc linker
> > for *.exe files?
> There's nothing the program, compiler, or linker can do as the
> expansion is done by the shell at the time the program is executed.
Well, yes this is true, as Brian has already noted, if you use a
POSIXy shell, such as the MSYS bash; it is not true, if you use
cmd.exe, or start the program directly from a Windows shortcut.
(If you use any other shell, then you will need to consult the
appropriate documentation, or conduct experiments, to identify its
behaviour in this respect).
> You can simply quote the string and the expansion won't be done:
> $ example.exe "*.*"
No, this will not have the desired effect; while it will suppress the
wildcard expansion in the shell, that expansion will then simply take
place within the mingwrt start-up code instead, because, as Roman has
> On Windows, applications parse their command lines themselves...
and the MinGW runtime reproduces this behaviour, with wildcard
expansion enabled by default.
As both Greg and Brian have noted, the solution to the OP's problem is
*not* to patch the runtime start-up objects, but to explicitly add an
instantiation for the global variable
int _CRT_glob = 0;
either directly in your own source, (in the file which defines the
main() or the WinMain() function would be a good choice), as Greg
suggests, or by linking with CRT_noglob.o, as Brian suggests; (I
would personally favour the same solution as Greg).