Quantcast

Problems with expanding wildcards to a program

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Problems with expanding wildcards to a program

Thomas Steinbach
Hello NG,

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.

compile the following example program:

---snip---
#include <stdio.h>
#include <string.h>

int main(int argc, char * argv[])
{
 char szVec[255] = "";
 int i = 0;

 strcpy(szVec, "");
 for(i=0; i<argc; i++) {
  strcat(szVec, argv[i]);
  strcat(szVec, " ");
  i++;
 }
 printf("\n CommandLine is: %s\n", szVec);
 printf("\n Argument 0 is: %s\n", argv[0]);
 printf("\n Argument 1 is: %s\n", argv[1]);
 printf("\n Argument 2 is: %s\n", argv[2]);
 printf("\n Argument 3 is: %s\n", argv[3]);

 return 0;
}
---snap---

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---

but it should be an output like:

---snip---
CommandLine is: test.exe *.*

Argument 0 is: test.exe

Argument 1 is: *.*

Argument 2 is: (null)

Argument 3 is: (null)
---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?


Thomas



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problems with expanding wildcards to a program

Uli Hertlein
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.

You can simply quote the string and the expansion won't be done:
$ example.exe "*.*"

--
Uli Hertlein
Research and Development   Phone: +61-3-9549-1122
XDT Pty Ltd                Web:   www.xdt.com.au

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problems with expanding wildcards to a program

Greg Chicares
In reply to this post by Thomas Steinbach
On 2008-10-21 06:15Z, Thomas Steinbach wrote:
>
> 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.
[...]
> Perhaps it is possible to patch the MinGW Runtime
> files crt0 etc.?

http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/CRT_noglob.c?annotate=1.2&cvsroot=src

The easiest way IMO is to copy line fifteen of that file
into your program.

> btw: which are the stdlibs of the gcc linker
> for *.exe files?

MinGW uses the C runtime library provided by the
operating system.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problems with expanding wildcards to a program

Роман Донченко
In reply to this post by Uli Hertlein
> 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.

On Windows, applications parse their command lines themselves.

Roman.

--
Manually typed signature.



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problems with expanding wildcards to a program

Brian Dessent

> On Windows, applications parse their command lines themselves.

It is true that this is the traditional behavior of windows
applications.  But the behavior depends on the shell.  POSIX shells on
Windows do in fact expand wildcards before passing them to the program
being invoked, so if you try the testcase from MSYS bash prompt, the
program will never have a chance to see the wildcard because the shell
will already have expanded it.  Wildcards that you want to be passed to
the app must be quoted if you are using a POSIX shell.

To add to the confusion, the MinGW runtime startup contains code to
expand wildcards, as a compatibility aide.  Note that the runtime ships
with the additional CRT_noglob.o object which you can link into your
application to disable this.

Brian

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problems with expanding wildcards to a program

Keith Marshall
In reply to this post by Uli Hertlein
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
noted...

> 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).

Regards,
Keith.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Loading...