argv
-
Nein, liegt nicht an der Schreibweise. "system32" war nur ein Beispiel mit vielen Dateien.
Wenn man z.B. "\\tmp\a*" eingibt, dann Verzögert sich der Einsprung bis main() um einige Sekunden (der sucht wohl im Netzwerk).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 ...
-
Nur so 'ne Idee:
if (argc > 1)...und/oder vielleicht
\*beim Aufruf weglassen.
-
Wie gesagt, das Obere ist ein Beispiel. Das richtige Programm wird auch was machen ...
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.
-
LordJaxom schrieb:
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.
-
Hallo,
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
-
Probe-Nutzer schrieb:
...
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.
-
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
-
Probe-Nutzer schrieb:
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.
-
Ja, ich könnte die Argumennte aufteilen und zusammenschreiben und ..., so das (wer auch immer) mir die jetzt nicht mehr Aufbereitet. - Woher soll ich aber wissen, dass der sich nicht auch wieder an diesen vergreift?!
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
-
thomas69 schrieb:
...
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 seinWie 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.