Using wild character under command line mode

[Denis P. Mendoza]

I've learned to use wildcard character (*) under command line mode, batch file or even in makefile to build the chess engine sources. Master JA always gives me hints on many approaches that maybe trivial but very useful. Now, dependency on compiler IDE was only for debugging. In GCC, it looks like `g++ *.cpp -o name.exe*'- for those unfamiliar. Rather than writing all the codes in command line, the wildcard usage (*.cpp) becomes a shortcut. Many compilers recognize this. But lately, when I tested Mingw64 again, this function wasn't recognized, and resulted with these errors:

Code: Select all

g++: *.cpp: Invalid argument
g++: no input files

I managed to compile using the long method. I'm still looking for an IDE to use Mingw64 ('because it is still new). But I couldn't find any forums or manual to check alternatives for wildcard usage. Could somebody here help me with this problem?

Thanks.

Denis

[Zach Wegner]

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.

[Dirt]

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.

[hgm]

..., and I'm pretty sure that's not a feature of Windows98.

Why are you saying that? I think MSDOS has always done this. Anyway, if I make a program to echo its command-line arguments, and run it in a DOS box on Win2K by typing:

a *.exe

it does print all files in the current directory that have extension .exe.

[Sven]

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.

1. Shells like bash, sh, ksh, csh, tcsh, ... that are running in a UNIX-like environment (that can be a UNIX/Linux/MacOS/... operating system, or a UNIX emulation package like CygWin) provide a builtin wildcard expansion, so "MYCOMPILER *.c" will be expanded to "MYCOMPILER file1.c file2.c file3.c ..." and then passed to MYCOMPILER this way, so that MYCOMPILER does not even see the wildcard character, even if he would be able to expand it by itself.

2. DOS/Windows command line interpreters like COMMAND.COM or cmd.exe (don't call them "shell", please ...) work differently. Here the wildcard expansion is not a general feature, its availability depends on the command or program that is called. Some of the "builtin" commands have that ability, like DIR or TYPE, some others don't have it, like ECHO. And "external" programs like a compiler will normally receive wildcard characters unexpanded, so it would be their job to expand it or not.

In general I would not bother with that. Instead, write a file like "all.c" that looks like this:

Code: Select all

#include "file1.c"
#include "file2.c"
#include "file3.c"
// ...

and then just call COMPILER all.c to compile everything at once. Just ensure that you don't have definitions like preprocessor macros, typedefs, "static" variables or "static" functions with the same name in different *.c files, then it will work (and it may even improve the compiler's success in inlining functions).

Sven

[Sven]

..., and I'm pretty sure that's not a feature of Windows98.

Why are you saying that? I think MSDOS has always done this. Anyway, if I make a program to echo its command-line arguments, and run it in a DOS box on Win2K by typing:

a *.exe

it does print all files in the current directory that have extension .exe.

Have you tried it? And/or have you read about it?

Code: Select all

#include <stdio.h>
int main&#40;int argc, char *argv&#91;&#93;)
&#123;
    int i;
    for &#40;i = 0; i < argc; i++) &#123;
        printf&#40;"&#91;%d&#93; %s\n", i, argv&#91;i&#93;);
    &#125;
    return 0;
&#125;

Post the result, please.

Under DOS and Windows, wildcard expansion is not done by the command line interpreter but has to be done by the programs.

Sven

[trojanfoe]

Under DOS and Windows, wildcard expansion is not done by the command line interpreter but has to be done by the programs.

That is correct - you have to use the FindFirstFile() and friends and perform regular expression matching yourself; not very difficult but this can be a pain sometimes.

I think using 'g++ *.cpp' is a silly thing to do in the first place as you lose control of what options get used by what files (if you require that) - it's not like you are creating several projects a day so who needs shortcuts?Spend the time creating a nice managable Makefile and this will save time when you correctly define the dependencies (see makedepend under UNIX/Linux) as only those files that need recompiling after a header file change (say) will be recompiled.

Cheers,
Andy

[Dirt]

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.

1. Shells like bash, sh, ksh, csh, tcsh, ... that are running in a UNIX-like environment (that can be a UNIX/Linux/MacOS/... operating system, or a UNIX emulation package like CygWin) provide a builtin wildcard expansion, so "MYCOMPILER *.c" will be expanded to "MYCOMPILER file1.c file2.c file3.c ..." and then passed to MYCOMPILER this way, so that MYCOMPILER does not even see the wildcard character, even if he would be able to expand it by itself.

2. DOS/Windows command line interpreters like COMMAND.COM or cmd.exe (don't call them "shell", please ...) work differently. Here the wildcard expansion is not a general feature, its availability depends on the command or program that is called. Some of the "builtin" commands have that ability, like DIR or TYPE, some others don't have it, like ECHO. And "external" programs like a compiler will normally receive wildcard characters unexpanded, so it would be their job to expand it or not.

In general I would not bother with that. Instead, write a file like "all.c" that looks like this:

Code: Select all

#include "file1.c"
#include "file2.c"
#include "file3.c"
// ...

and then just call COMPILER all.c to compile everything at once. Just ensure that you don't have definitions like preprocessor macros, typedefs, "static" variables or "static" functions with the same name in different *.c files, then it will work (and it may even improve the compiler's success in inlining functions).

Sven

All true, but DJGPP (and probably the old mingw) include wildcard expansion in the C startup code, so it works in all executables built with them. I agree it's not very useful for the compilers, but it enabled the the standard Unix utilities (cat, head, etc.) to be ported with little effort and still work from the standard Dos/Windows command prompt.

[hgm]

Have you tried it? And/or have you read about it?

Of course I tried it. What do you take me for?

Copy/pasted from the command-prompt box of Win2K:

Code: Select all

F:\cygwin\home\chess\test>dir
 Volume in drive F is WIN2000PRO
 Volume Serial Number is A4A8-C8B2

 Directory of F:\cygwin\home\chess\test

01/03/2009  09&#58;00a      <DIR>          .
01/03/2009  09&#58;00a      <DIR>          ..
01/03/2009  09&#58;00a              12,235 a.exe
01/03/2009  08&#58;59a                 134 args.c
11/16/2007  09&#58;22a               8,757 fmax.ini
11/17/2007  10&#58;23a              25,888 fmax4_8k.exe
11/15/2007  11&#58;05p           1,144,320 winboard.exe
11/17/2007  01&#58;14p               9,712 winboard.ini
               6 File&#40;s&#41;      1,201,046 bytes
               2 Dir&#40;s&#41;   2,298,814,464 bytes free

F&#58;\cygwin\home\chess\test>type args.c
main&#40;int argc, char **argv&#41;
&#123;
        int i;
        for&#40;i=0; i<argc; i++)
                printf&#40;"%3d. '%s'\n", i, argv&#91;i&#93;);
&#125;

F&#58;\cygwin\home\chess\test>a *.exe
  0. 'a'
  1. 'a.exe'
  2. 'fmax4_8k.exe'
  3. 'winboard.exe'

F&#58;\cygwin\home\chess\test>

[Sven]

Have you tried it? And/or have you read about it?

Of course I tried it. What do you take me for?

Copy/pasted from the command-prompt box of Win2K:

Code: Select all

F:\cygwin\home\chess\test>dir

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

Sven