5
Suche Strategien zur Vorgehensweise (bei der Entwicklung) - b) Unterschiede bei Doppelklick, Aufruf in der Konsole von Win2k bis zur aktuellen Version - c) setlocal, sich gegenseitig aufrufende CMDs
Hallo zusammen,
meine Suche war bislang erfolglos und meine Selbstversuche machen mich langsam irre!
Daher wird das mein erstes Posting.
Um meine Skripte, die während der Entwicklung immer länger werden, übersichtlicher zu gestalten, wollte ich Teile auslagern und dann über CALL aufrufen.
Länger werden die Skripte auch, weil während der Entwicklungszeit zusätzliche ECHOs eingebaut werden, um den aktuellen Status und Variablenwerte im Skript mit Meldungen anzuzeigen. Die könnten theoretisch später auch wieder raus. Sinnhafte Meldungen und Kommentierungen im Code, die auch nach Monaten oder Jahren am Monitor oder im Editor auf den Sinn des Skriptes oder Lösungsansätze hinweisen, verlängern noch einmal den Code.
Spätestens an einer dieser Stellen schlägt Murphy zu, der Spaß vergeht und die Produktivität sinkt gegen Null!
b1) Wie stelle ich sicher, dass die Skripte beim Aufruf über die Konsole identisch reagieren, wie beim Doppelklick? Ich habe die Vermutung, dass es dort Unterschiede gibt und wenn ich ein an der Konsole "funktionsfähiges" Skript über Doppelklick aufrufe .... Dazu kommen die Fehler, die mit der verzögerten Auswertung von Variablen resultieren. Also: %test% und !test! ... brrrr
.
WELCHE?
weitere Fehlerquellen:
- komfortable Auswertung von übergebenen Parametern (ohne eine Reihenfolge festzulegen) oder auch flexiblel mit sowas "-" "--" oder "/" umzugehen.
z.B. eine eigene Hilfe einbauen "-help" "--help" "/?" oder auch "Hilfe".
- Skripte, die mit Doppelklick eine Aufgabe lösen aber auf der Konsole Zusatzaufgaben lösen können.
- Skripte, die sich auf mehrere Teilskripte verteilen, die aber dennoch nicht über die Konsole aufrufbar sind oder sich über den Namen als "nicht auszuführen" ausweisen, weil sie einzeln keinen Sinn bringen. Diese Variante müllt aber das Verzeichnis voll. (Man könnte zu benutzende Skripte als CMD und nicht zu benutzende Skripte als BAT speichern. Das wäre aber eine Lösung, die man nicht in eine Umgebung geben könnte, die "ich" nicht kontrollieren kann.
Wie sehen die Unterschiede in den verschiedenen Windows-Versionen seit 2k aus, wenn ein Skript auf mehreren Versionen laufen soll? (Auch wenn 2k nicht mehr aktuell ist)
Gibt es in den Versionen Fehler, die sich nicht mit Logik erschließen lassen, eine Versionsabfrage benötigen oder gar einen richtigen Workaround, weil es ein (bekannter) Fehler ist?
c) Wie sieht es mit der Kombination SETLOCAL und SETLOCAL enabledelayedexpansion (auch bei sich aufrufenden Skripten) aus?
Das sind definitv zwei Funktionen, die auch gemeinsam auftreten können, sodass es dann so aussehen kann?
SETLOCAL
SETLOCAL enabledelayedexpansion
ja - es handelt sich teilweise um konkrete Probleme mehr aber um Best-Practice. Daher wollte ich die Fragen trotzdem in einer Frage lassen.
ja - ich hätte gerne die eierlegende Wollmilchsau -- nur fliegen muss sie nicht zwingend
vielen Dank für JEDEN hilfreichen Hinweis zur eigenen Vorgehensweise. Tutorials haben mir bisher nichts gebracht.
Luftpolsterfolie
meine Suche war bislang erfolglos und meine Selbstversuche machen mich langsam irre!
Daher wird das mein erstes Posting.
Um meine Skripte, die während der Entwicklung immer länger werden, übersichtlicher zu gestalten, wollte ich Teile auslagern und dann über CALL aufrufen.
Länger werden die Skripte auch, weil während der Entwicklungszeit zusätzliche ECHOs eingebaut werden, um den aktuellen Status und Variablenwerte im Skript mit Meldungen anzuzeigen. Die könnten theoretisch später auch wieder raus. Sinnhafte Meldungen und Kommentierungen im Code, die auch nach Monaten oder Jahren am Monitor oder im Editor auf den Sinn des Skriptes oder Lösungsansätze hinweisen, verlängern noch einmal den Code.
Spätestens an einer dieser Stellen schlägt Murphy zu, der Spaß vergeht und die Produktivität sinkt gegen Null!
b1) Wie stelle ich sicher, dass die Skripte beim Aufruf über die Konsole identisch reagieren, wie beim Doppelklick? Ich habe die Vermutung, dass es dort Unterschiede gibt und wenn ich ein an der Konsole "funktionsfähiges" Skript über Doppelklick aufrufe .... Dazu kommen die Fehler, die mit der verzögerten Auswertung von Variablen resultieren. Also: %test% und !test! ... brrrr
.WELCHE?
weitere Fehlerquellen:
- komfortable Auswertung von übergebenen Parametern (ohne eine Reihenfolge festzulegen) oder auch flexiblel mit sowas "-" "--" oder "/" umzugehen.
z.B. eine eigene Hilfe einbauen "-help" "--help" "/?" oder auch "Hilfe".
- Skripte, die mit Doppelklick eine Aufgabe lösen aber auf der Konsole Zusatzaufgaben lösen können.
- Skripte, die sich auf mehrere Teilskripte verteilen, die aber dennoch nicht über die Konsole aufrufbar sind oder sich über den Namen als "nicht auszuführen" ausweisen, weil sie einzeln keinen Sinn bringen. Diese Variante müllt aber das Verzeichnis voll. (Man könnte zu benutzende Skripte als CMD und nicht zu benutzende Skripte als BAT speichern. Das wäre aber eine Lösung, die man nicht in eine Umgebung geben könnte, die "ich" nicht kontrollieren kann.
Wie sehen die Unterschiede in den verschiedenen Windows-Versionen seit 2k aus, wenn ein Skript auf mehreren Versionen laufen soll? (Auch wenn 2k nicht mehr aktuell ist)
Gibt es in den Versionen Fehler, die sich nicht mit Logik erschließen lassen, eine Versionsabfrage benötigen oder gar einen richtigen Workaround, weil es ein (bekannter) Fehler ist?
c) Wie sieht es mit der Kombination SETLOCAL und SETLOCAL enabledelayedexpansion (auch bei sich aufrufenden Skripten) aus?
Das sind definitv zwei Funktionen, die auch gemeinsam auftreten können, sodass es dann so aussehen kann?
SETLOCAL
SETLOCAL enabledelayedexpansion
ja - es handelt sich teilweise um konkrete Probleme mehr aber um Best-Practice. Daher wollte ich die Fragen trotzdem in einer Frage lassen.
ja - ich hätte gerne die eierlegende Wollmilchsau -- nur fliegen muss sie nicht zwingend
vielen Dank für JEDEN hilfreichen Hinweis zur eigenen Vorgehensweise. Tutorials haben mir bisher nichts gebracht.
Luftpolsterfolie
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 253170
Url: https://administrator.de/contentid/253170
Ausgedruckt am: 25.11.2024 um 12:11 Uhr
5 Kommentare
Neuester Kommentar
Hallo Luftpolsterfolie, willkommen im Forum.
Zu a) habe ich eigentlich gar keine richtige Frage gefunden. Vielleicht so viel: Mit Batch schreibt man kleine Helferlein, die stupide, sich ständig wiederholende Abläufe automatisiert. Batchcode mit tausenden Zeilen am Stück halte ich persönlich für Batch schon für ein Designproblem. Natürlich ist es in jeder Sprache Best Practice den Code so zu kommentieren, dass man auch nach Jahren wieder den Einstieg findet. Klar kann man Code in mehrere Dateien aufsplitten. Ebenso kann man auch prozedural arbeiten und Labels per CALL aufrufen.
Zu b)
Zu c)
SETLOCAL erzeugt eine neue Subumgebung, ENDLOCAL beendet diese. Es gibt mehr als nur das Schlüsselwort "EnableDelayedExpansion" wie du der Hilfe zu SETLOCAL entnehmen kannst. Interessant ist sicher in dem Fall das "DisableDelayedExpansion".
Faustregel: Zuweisungen von Variablen sind sicher bei ausgeschalteter verzögerter Erweiterung, das Arbeiten mit der Variablen hingegen mit eingeschalteter verzögerter Erweiterung.
Grüße
rubberman
Zu a) habe ich eigentlich gar keine richtige Frage gefunden. Vielleicht so viel: Mit Batch schreibt man kleine Helferlein, die stupide, sich ständig wiederholende Abläufe automatisiert. Batchcode mit tausenden Zeilen am Stück halte ich persönlich für Batch schon für ein Designproblem. Natürlich ist es in jeder Sprache Best Practice den Code so zu kommentieren, dass man auch nach Jahren wieder den Einstieg findet. Klar kann man Code in mehrere Dateien aufsplitten. Ebenso kann man auch prozedural arbeiten und Labels per CALL aufrufen.
Zu b)
Wie stelle ich sicher, dass die Skripte beim Aufruf über die Konsole identisch reagieren, wie beim Doppelklick? Ich habe die Vermutung, dass es dort Unterschiede gibt und wenn ich ein an der Konsole "funktionsfähiges" Skript über Doppelklick aufrufe
Hast du mal ein Beispiel parat?Dazu kommen die Fehler, die mit der verzögerten Auswertung von Variablen resultieren. Also: %test% und !test! ... brrrr .
Warum? Zu SETLOCAL gibt es auch ENDLOCAL. Code so zu schreiben, dass das kein Problem macht, ist deine Verantwortung. .- komfortable Auswertung von übergebenen Parametern (ohne eine Reihenfolge festzulegen) oder auch flexiblel mit sowas "-" "--" oder "/" umzugehen.
Werte die übergebenen Parameter aus. Mit %1 - %9 kommst du da ran (ggf. mit SHIFT arbeiten oder über %* in einer FOR Schleife iterieren wenn es viele Argumente sind).- Skripte, die mit Doppelklick eine Aufgabe lösen aber auf der Konsole Zusatzaufgaben lösen können.
- Skripte, die sich auf mehrere Teilskripte verteilen, die aber dennoch nicht über die Konsole aufrufbar sind oder sich über den Namen als "nicht auszuführen" ausweisen, weil sie einzeln keinen Sinn bringen. Diese Variante müllt aber das Verzeichnis voll. (Man könnte zu benutzende Skripte als CMD und nicht zu benutzende Skripte als BAT speichern. Das wäre aber eine Lösung, die man nicht in eine Umgebung geben könnte, die "ich" nicht kontrollieren kann.
Schau dir mal die Unterschiede der %CMDCMDLINE% Variablen an, wenn du per Doppelklick, bzw. aus der Kommandozeile startest. Zumindest kannst du diese Fälle unterscheiden.- Skripte, die sich auf mehrere Teilskripte verteilen, die aber dennoch nicht über die Konsole aufrufbar sind oder sich über den Namen als "nicht auszuführen" ausweisen, weil sie einzeln keinen Sinn bringen. Diese Variante müllt aber das Verzeichnis voll. (Man könnte zu benutzende Skripte als CMD und nicht zu benutzende Skripte als BAT speichern. Das wäre aber eine Lösung, die man nicht in eine Umgebung geben könnte, die "ich" nicht kontrollieren kann.
Wie sehen die Unterschiede in den verschiedenen Windows-Versionen seit 2k aus, wenn ein Skript auf mehreren Versionen laufen soll? (Auch wenn 2k nicht mehr aktuell ist)
w2k ist so lang her, dass ich mich nicht erinnern kann. Wenn du unbedingt abwärtskompatiblen Code schreiben musst, dann verwende keine Befehle, deren Syntax sich zwischenzeitlich geändert hat oder die tw. nicht an Bord waren (z.B. CHOICE) und verwende keine Befehle, die irgendwann neu aufgenommen wurden (TIMEOUT, ROBOCOPY etc.). Ein bisschen abwärtskompatibel ist nie schlecht. Sich aber heute noch auf w2k berufen zu wollen ist Nonsens. Selbst XP solltest du langsam aber sicher aus den Gedanken verbannen ...Gibt es in den Versionen Fehler, die sich nicht mit Logik erschließen lassen, eine Versionsabfrage benötigen oder gar einen richtigen Workaround, weil es ein (bekannter) Fehler ist?
Mehr als Haare am S * * *. Die alle aufzuführen wäre ebenso müßig wie für alles ein Workaround schreiben zu wollen. Meiner Meinung nach haben die Entwickler der CMD und der zugehörigen Tools alle unter dem Einfluss merkwürdiger Substanzen gestanden, als sie den Code dafür geschrieben haben ...Zu c)
SETLOCAL erzeugt eine neue Subumgebung, ENDLOCAL beendet diese. Es gibt mehr als nur das Schlüsselwort "EnableDelayedExpansion" wie du der Hilfe zu SETLOCAL entnehmen kannst. Interessant ist sicher in dem Fall das "DisableDelayedExpansion".
Faustregel: Zuweisungen von Variablen sind sicher bei ausgeschalteter verzögerter Erweiterung, das Arbeiten mit der Variablen hingegen mit eingeschalteter verzögerter Erweiterung.
Grüße
rubberman
Hallo Luftpolsterfolie,
es gibt da ein paar "goldene Regeln", die Du Dir mal durch den Kopf gehen lassen solltest:
Von mir aus halte mich für einen Phrasendrescher oder für bekloppt - oder denk mal drüber nach.
Gruß
Friemler
es gibt da ein paar "goldene Regeln", die Du Dir mal durch den Kopf gehen lassen solltest:
- Lade Deinen Frust über eine Sache, mit der Du Schwierigkeiten hast, nicht bei den Leuten ab, die Du um Hilfe bittest.
- Ein komplexes Problem zu strukturieren und in kleinere Teilprobleme zu zerlegen, aus denen sich dann konkrete und überschaubare Fragen formulieren lassen, ist die Voraussetzung um eine Gesamtlösung entwickeln zu können. Außerdem findest Du dann auch leichter einen oder mehrere Menschen, die Dir weiterhelfen können/wollen.
- Es ist noch kein Meister vom Himmel gefallen.
- Wer zu viel auf einmal will, bekommt am Ende garnichts.
- Mühsam ernährt sich das Eichhörnchen.
- Mit einem Messer im Rücken geht man nicht nach Hause.
Von mir aus halte mich für einen Phrasendrescher oder für bekloppt - oder denk mal drüber nach.
Gruß
Friemler
Hallo Friemler,
wieso sollte ich Dich am Anfang schon dafür halten? Ist ja nicht persönlich und die abgeladenen Schwierigkeiten sollten auch nur den Kontext beleuchten. Der vorletzte Absatz von rubberman deutet aber zumindest darauf hin, dass ein bestimmtes Maß an "Bekopptheit" und/oder Hilfsmitteln hilfreich sein könnte, um zu verstehen, was in Redmond so vor sich geht/ging. Die gundlegende Erklärung von rubberman (oben) kenne ich natürlich und die Umsetzung funktioniert auch bis zu einem gewissen Maß. Aber es kommt schnell der Punkt 4 und dann sehr schnell der Punkt 6.
Zusatzfrage zu 6: Geht man früher oder bleibt man länger?
So werde ich mich also zunächst verstärkt mit den Punkten 2 und 5 auseinandersetzen. Eventuell kommt Punkt 3 ja dann doch noch. Und den vorletzten Absatz von rubberman sollte ich für den Eigenbedarf doch noch einmal in Betracht ziehen. Eventuell hilft das ja.
Danke soweit und einen Gruß
Luftpolsterfolie
wieso sollte ich Dich am Anfang schon dafür halten? Ist ja nicht persönlich und die abgeladenen Schwierigkeiten sollten auch nur den Kontext beleuchten. Der vorletzte Absatz von rubberman deutet aber zumindest darauf hin, dass ein bestimmtes Maß an "Bekopptheit" und/oder Hilfsmitteln hilfreich sein könnte, um zu verstehen, was in Redmond so vor sich geht/ging. Die gundlegende Erklärung von rubberman (oben) kenne ich natürlich und die Umsetzung funktioniert auch bis zu einem gewissen Maß. Aber es kommt schnell der Punkt 4 und dann sehr schnell der Punkt 6.
Zusatzfrage zu 6: Geht man früher oder bleibt man länger?
So werde ich mich also zunächst verstärkt mit den Punkten 2 und 5 auseinandersetzen. Eventuell kommt Punkt 3 ja dann doch noch. Und den vorletzten Absatz von rubberman sollte ich für den Eigenbedarf doch noch einmal in Betracht ziehen. Eventuell hilft das ja.
Danke soweit und einen Gruß
Luftpolsterfolie
Hallo rubberman,
Das mit den Disable werde ich mal ausprobieren und auch den Zeitpunkt, wann ich es schalte. Vielleicht erklärt das meine Phänomene, weil ich es immer nur eingeschaltet oder gar nicht verwendet habe. - hmmpf
Win2k soll natürlich keine Referenz für komplizierte Geschichten sein. Dienste "in Abhängigkeit von" an- und abschalten und Dateien verschieben sollte aber schon "noch" funktionieren UND übertragbar sein. Die "kleine/alte" Kiste (eeePC701) hat nur 4 GB als Festplatte. Da passt nix größeres / neueres drauf.
Den Rest des Textes zwischen oben und unten muss ich noch mal in Ruhe lesen.
Kann ein bisschen dauern... komme nicht täglich dazu.
Dir auch einen Dank für die Hinweise
Luftpolsterfolie
Das mit den Disable werde ich mal ausprobieren und auch den Zeitpunkt, wann ich es schalte. Vielleicht erklärt das meine Phänomene, weil ich es immer nur eingeschaltet oder gar nicht verwendet habe. - hmmpf
Win2k soll natürlich keine Referenz für komplizierte Geschichten sein. Dienste "in Abhängigkeit von" an- und abschalten und Dateien verschieben sollte aber schon "noch" funktionieren UND übertragbar sein. Die "kleine/alte" Kiste (eeePC701) hat nur 4 GB als Festplatte. Da passt nix größeres / neueres drauf.
Den Rest des Textes zwischen oben und unten muss ich noch mal in Ruhe lesen.
Kann ein bisschen dauern... komme nicht täglich dazu.
Dir auch einen Dank für die Hinweise
Luftpolsterfolie
Hallo rubberman,
Rückmeldung nach zwei "Versuchen". Es scheint so zu sein, dass die explizite Verwendung von EnableDelayedExpansion genau die Probleme löst, die aufgetreten sind:
- mal gehts - mal gehts nicht.
- beim ersten Mal gehts - beim zweiten Mal dann wieder nicht UND
- der Wechsel zwischen 2000 und Win7 beim Ausführen macht Probleme.
.
Ich werde also versuchen herauszufinden:
a) ob die Standardeinstellung von 2000 "aktiviert" war und für Win7 "deaktiviert,
b) wo diese Einstellung für EnableDelayedExpansion in der Registry ist
c) ob das auf meinem Win7 Computer "verstellt" wurde und
d) nur für die Vollständigkeit: wie ich die gesetzten Variablen auch nach der Beendigung eines Skriptes weiterverwenden (noch einmal ansehen) kann. Durch Setlocal werden sie ja bei Beendigung des Skriptes implizit gelöscht.
Mit diesem Unterschied in den Grundeinstellungen hatte ich nicht gerechnet.
Hoffentlich komme ich jetzt in größeren Schritten vorwärts.
.
Eine zusätzliche Lernerfahrung
Das Ersetzen von %Variable% durch !Variable! muss scheinbar nur innnerhalb dieser einen aktuellen Schleife passieren. Außerhalb der Schleife (danach) muss man dann scheinbar wieder %Variable% benutzen. Das muss ich aber noch mal genauer ansehen. - Bisher hatte ich ALLE folgenden % durch ! ersetzt.
Die anderen "Problembeschreibungen"
... versuche ich zukünftig einzukürzen und beim nächsten Mal konkreter zu fragen, obwohl mich die "Best Practice"-Thematik trotzdem weiterhin interessiert. Das betrifft Fragen wie:
a) komfortable Benutzerführung,
b) an welcher Stelle des Skriptes bin ich gerade, wenn eine Fehlermeldung passiert
c) wie viele Informationen will ich sehen, wenn ich nur normal "ausführe", die eigentlich nicht zum engeren Programmablauf gehören, sondern eben eher in die Kategorie Fehlersuche.
Ein Programm, dass keine Fehler produziert, muss eingentlich nur seine Fragen stellen und kann dann durcharbeiten, braucht also eigentlich gar keine Ausgaben bis es fertig ist (außer eine Fortschrittsanzeige vielleicht.) ICH hätte gerne eine "Lösung", die im Normalfall das notwendige anzeigt und im Fehlersuchmodus mehr anzeigt. -- Die Totallösung "echo on" muss es dann aber auch nicht sein.
Ich denke dabei an eine zu setzende Variable %debug% von deren Status die Menge der Anzeigen und ggf. eine Umleitung der Anzeige in eine Logdatei abhängig ist. Nur (leider?) müssten diese Codepassagen nach der Fertigstellung komplett wieder raus, damit das Ergebnis übersichtlich bleibt/wird.
.
Danke bis hierher.
Rückmeldung nach zwei "Versuchen". Es scheint so zu sein, dass die explizite Verwendung von EnableDelayedExpansion genau die Probleme löst, die aufgetreten sind:
- mal gehts - mal gehts nicht.
- beim ersten Mal gehts - beim zweiten Mal dann wieder nicht UND
- der Wechsel zwischen 2000 und Win7 beim Ausführen macht Probleme.
.
Ich werde also versuchen herauszufinden:
a) ob die Standardeinstellung von 2000 "aktiviert" war und für Win7 "deaktiviert,
b) wo diese Einstellung für EnableDelayedExpansion in der Registry ist
c) ob das auf meinem Win7 Computer "verstellt" wurde und
d) nur für die Vollständigkeit: wie ich die gesetzten Variablen auch nach der Beendigung eines Skriptes weiterverwenden (noch einmal ansehen) kann. Durch Setlocal werden sie ja bei Beendigung des Skriptes implizit gelöscht.
Mit diesem Unterschied in den Grundeinstellungen hatte ich nicht gerechnet.
Hoffentlich komme ich jetzt in größeren Schritten vorwärts.
.
Eine zusätzliche Lernerfahrung
Das Ersetzen von %Variable% durch !Variable! muss scheinbar nur innnerhalb dieser einen aktuellen Schleife passieren. Außerhalb der Schleife (danach) muss man dann scheinbar wieder %Variable% benutzen. Das muss ich aber noch mal genauer ansehen. - Bisher hatte ich ALLE folgenden % durch ! ersetzt.
Die anderen "Problembeschreibungen"
... versuche ich zukünftig einzukürzen und beim nächsten Mal konkreter zu fragen, obwohl mich die "Best Practice"-Thematik trotzdem weiterhin interessiert. Das betrifft Fragen wie:
a) komfortable Benutzerführung,
b) an welcher Stelle des Skriptes bin ich gerade, wenn eine Fehlermeldung passiert
c) wie viele Informationen will ich sehen, wenn ich nur normal "ausführe", die eigentlich nicht zum engeren Programmablauf gehören, sondern eben eher in die Kategorie Fehlersuche.
Ein Programm, dass keine Fehler produziert, muss eingentlich nur seine Fragen stellen und kann dann durcharbeiten, braucht also eigentlich gar keine Ausgaben bis es fertig ist (außer eine Fortschrittsanzeige vielleicht.) ICH hätte gerne eine "Lösung", die im Normalfall das notwendige anzeigt und im Fehlersuchmodus mehr anzeigt. -- Die Totallösung "echo on" muss es dann aber auch nicht sein.
Ich denke dabei an eine zu setzende Variable %debug% von deren Status die Menge der Anzeigen und ggf. eine Umleitung der Anzeige in eine Logdatei abhängig ist. Nur (leider?) müssten diese Codepassagen nach der Fertigstellung komplett wieder raus, damit das Ergebnis übersichtlich bleibt/wird.
.
Danke bis hierher.
