Using wild character under command line mode

[bob]

Wildcards aren't actually a compiler issue. If you're running in Unix/Linux, then the shell will expand them to everything fitting the pattern (all .cpp files in the current directory in this case). Under Windows, the command prompt would have to fill that function; I'm not sure if it does. If you use Cygwin it certainly will, as that's just an emulation of bash or whatever.

This is not entirely true. DJGPP executables automatically include wild card expansion. It's possible that the old Mingw used the same technique, but the new version doesn't. The Mingw GCC on my system does handle "gcc *.c", and I'm pretty sure that's not a feature of Windows98.

That's not quite the same as what Zach was explaining, however. In Unix, an application does not have to deal with wildcards as the shell processes them _before_ the application gets executed. The application will never see the "*" unless the operator escapes it with a "" or surrounds it with '*' or something...

[trojanfoe]

I get different results, using the standard Windows Command Prompt (cmd.exe):

Code: Select all

C:\Source>cd \temp\test

C:\TEMP\test>cl a.c
Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.01 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

a.c
Microsoft (R) Incremental Linker Version 9.00.30729.01
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:a.exe
a.obj

C:\TEMP\test>dir
 Volume in drive C is Drive-C
 Volume Serial Number is 3E53-9752

 Directory of C:\TEMP\test

04/01/2009  01&#58;58    <DIR>          .
04/01/2009  01&#58;58    <DIR>          ..
04/01/2009  01&#58;58               179 a.c
04/01/2009  01&#58;58            51,712 a.exe
04/01/2009  01&#58;58               940 a.obj
               3 File&#40;s&#41;         52,831 bytes
               2 Dir&#40;s&#41;  86,157,369,344 bytes free

C&#58;\TEMP\test>a.exe
&#91;0&#93; a.exe

C&#58;\TEMP\test>a.exe *.*
&#91;0&#93; a.exe
&#91;1&#93; *.*

C&#58;\TEMP\test>a.exe *.c
&#91;0&#93; a.exe
&#91;1&#93; *.c

C&#58;\TEMP\test>

The difference being the compiler and the start-up code that Greg mentioned?

[Michel]

Unix, an application does not have to deal with wildcards as the shell processes them _before_ the application gets executed.

On bash that is not quite true I think. If an argument containing wildcards does not match anything it will not be "expanded" (unless nullglob is set).

Programs like scp and rsync use this to allow wildcards in remote paths.

[Michel]

Spend the time creating a nice managable Makefile

On Unix at least you should not create Makefiles yourself. Let autoconf/automake deal
with it. In this way you get makefiles which automatically understand all the standard GNU targets and will automatically install things in the correct directories.

[hgm]

Is it possible that you have CygWin involved in your system environment, so that it's not just a native Windows command prompt?

Not that I know of. But I cannot give any cygwin commands, like 'gcc' from this prompt, and I cannot run any executables that I did not compile with -mno-cygwin.

But what Greg says would explain it. If -mno-cygwin compiled applications would use this start-up file, though, I would expect that the mingw C++ compiler would use it too. (I never use mingw, I always compile from the Cygwin prompt, where bash expands the wildcards for sure.)

I was under the impression that it was a DOS feature, because native DOS commands like DIR, TYPE, DEL and CD expand '*' too.

[bob]

Unix, an application does not have to deal with wildcards as the shell processes them _before_ the application gets executed.

On bash that is not quite true I think. If an argument containing wildcards does not match anything it will not be "expanded" (unless nullglob is set).

Programs like scp and rsync use this to allow wildcards in remote paths.

If nothing matches, there is nothing it can do, to be sure. But for all other cases, you have to escape/hide the "*" character or it will turn into a list of files before the shell does a fork()/exec() to execute the program you named.