vielleicht kann mir hier jemand helfen. Ich schreibe gerade ein Programm mit DevCpp für die Kommandozeile.

int main(int argc, char *argv[])
{
   for(int i=0; i< argc;i++)
    {
       printf("arg(%d) = %s\n",i,argv[i]);
    }
    return EXIT_SUCCESS;
}

Aufruf: args c:\winnt\system32\*
Wieso listet der mir ALLE Dateien auf? Es sind dann ca. 2000 Argumennte vorhanden!

Ein älteres Programm mach das nicht. Ich habe noch einen weiteren (modernen) Compiler verwendet - selbes Ergebnis.

Danke Euch.

Da ich das angegebene Verzeichnis selbst durchsuchen will, viel mir dieser "Fehler" erst sehr auf. Erst als ich statt "c:\tmp\a*" immer "c:\tmp\A2008" in den argv fand.
Ich ging zunächst von einer falschen Verwendung von GetFullPathName aus ...

if (argc > 1)...

und/oder vielleicht

\*

beim Aufruf weglassen.

argv[0] ist das Programm selbst und ich will die Argumennte.
Was ich nicht finde ist der Teil, der mir das automatisch Auswertet. Ich habe noch 2 weitere DevCpp probiert, 1x Normal und 1x wxDevCpp - wieder wurde Ausgewertet. Mein altes BCB macht das nicht, den kann ich aber nicht einsetzen.

IMHO wertet die Shell (cmd.exe) aus, nicht das Programm.

Kann ich so bestätigen.
Ich habe auch gerade mit diesem Problem gekämpft:
- unter MS-VS6.1/cmd.exe => arg[1] == "*"
- unter gcc4.4.3/cygwin-bash.exe => arg[1] == "Datei1", arg[2] == "Datei2", ...

War bei mir letztlich aber nicht so ein großes Problem: Ich brauchte sowieso alle Filenamen ...

Mal eine Frage an thomas69: Warum brauchst Du überhaupt unbedingt die "*"-Angabe im Programm ? Wenn Du unbedingt das Verzeichnis selbst auslesen möchtest, wäre es doch naheliegender, das Verzeichnis selbst übergeben zu bekommen (c:\winnt\system32).
... und selbst, wenn Du filtern nmöchtest (z.B. nur die .exe), dann kannst Du die Filterkriterien über weitere Parameter einlesen
arg[1] == "c:\winnt\system32"
arg[2] == ".exe" (und '' und '?' kannst Du durch andere "verbotene" oder seltene Zeichen ersetzen)
OK, das wird mit vollständigen regulären Ausdrücken schon ein wenig lästig, aber gerade das kann eine Konsole so gut, dass man es ihr eigentlich auch ruhigen Gewissens überlassen kann.
Aber vllt. fehlt mir auch nur die Phantasie, um auf einen wirklich problematischen Fallzu kommen.

Gruß,

Simon2.

die Shell spielt keine Rolle unter Windows-Systemen:

http://blogs.msdn.com/dancre/archive/2005/05/14/417547.aspx

Statt dessen ist (auch) die verwendete Entwicklungsumgebung ausschlaggebend, wie z.B. aus der MSDN-Doku ersichtlich hier:

Microsoft Specific

When running a C program, you can use either of the two wildcards — the question mark (?) and the asterisk (*) — to specify filename and path arguments on the command line.

Command-line arguments are handled by a routine called _setargv (or _wsetargv in the wide-character environment), which by default does not expand wildcards into separate strings in the argv string array. You can replace the normal _setargv routine with a more powerful version of _setargv that does handle wildcards by linking with the Setargv.obj file. If your program uses a wmain function, link with Wsetargv.obj.

To link with Setargv.obj or Wsetargv.obj, use the /link option. For example:

cl typeit.c /link setargv.obj

The wildcards are expanded in the same manner as operating system commands. (See your operating system user's guide if you are unfamiliar with wildcards.) Enclosing an argument in double quotation marks (" ") suppresses the wildcard expansion. Within quoted arguments, you can represent quotation marks literally by preceding the double-quotation-mark character with a backslash (\). If no matches are found for the wildcard argument, the argument is passed literally.

END Microsoft Specific

MfG,

Probe-Nutzer

...
die Shell spielt keine Rolle unter Windows-Systemen:
...MSDN-Doku...
...

Naja, ich denke mal, dass in der MSDN-Doku nicht unbedingt die cygwin-shell oder die gcc-runtime beschrieben sein werden - deswegen würde nicht nicht behaupten., die Shell "... spiele keine Rolle unter Windows-Systemen ...".

Aber gut, dass Du einen Weg gezeigt hast, wie man auch mit den Microsoft-Bausteinen (Shell und Runtime) zum gewünschten Ergebnis kommt.

Gruß,

Simon2.

deswegen würde nicht nicht behaupten., die Shell "... spiele keine Rolle unter Windows-Systemen ...".

Diese Aussage sollte in direktem Bezug zum verlinkten Artikel stehen, ich wollte nur klar stellen, dass die windows-eigene Shell keine Expansionen durchführt.

MfG,

Probe-Nutzer

Simon2 schrieb:

deswegen würde nicht nicht behaupten., die Shell "... spiele keine Rolle unter Windows-Systemen ...".

Diese Aussage sollte in direktem Bezug zum verlinkten Artikel stehen, ich wollte nur klar stellen, dass die windows-eigene Shell keine Expansionen durchführt.

MfG,

Probe-Nutzer

Ah - OK.
... sollte auch eher eine Randnotiz von mir sein.

Danke für die Info,

Simon2.

Ich will/brauche die Angaben um flexibel zu sein, sonst könnte ich auch fixe Pfade im Programm verwenden.
Habe gerade CodeBlock getestet - der Expandiert auch.
Wo oder wie beendet man diesen Spuk - ich habe keine Ideen mehr.
Die Shell scheint es nicht (direkt) zu sein

...
Ich will/brauche die Angaben um flexibel zu sein, sonst könnte ich auch fixe Pfade im Programm verwenden....

Und dafür brauchst Du das "Sternchen" auch ?

thomas69 schrieb:

...
Wo oder wie beendet man diesen Spuk - ich habe keine Ideen mehr.
Die Shell scheint es nicht (direkt) zu sein

Wie schon gesagt: Nur den Pfad (ohne Sternchen) als Parameter.

Übrigens denkst Du da vermutlich ein wenig zu schlecht von der Shell. Ich wette, an bestimmten Stellen möchtest Du durchaus die Mithilfe (wie z.B. beim verfolgen von symbolischen Links).
Merke: Nicht immer ist "selbstgemacht" auch "besser"(flexibel, zuverlässig, ...).

Gruß,

Simon2.