Das System kann den angegebenen Pfad nicht finden.

[ITAlexBerlin]

Hallo,

ich habe ein Problem und komme nicht weiter, vielleicht kann mir ja einer Helfen.

Vorab:
Es geht um ein Skript, welche jede Nacht bestimmte Logdatein in zip Datein wandelt und dann eigentlich auf einem Netzwerkpfad kopiert. das ganz lief jetzt Jahrelang aber seit 01.08. funktioniert es nicht mehr.

Das ist das Skript: (bitte nicht wundern, habe namen der Ordner etc abgeändert.)

e:
cd \Logdateien-Sicherung\
set gestern=%date%
set g
timeout /T 660 /NOBREAK
set g
set /a jahr=%gestern:~-4%
set j
set /a monat=%gestern:~-7,2%
set m
zip.exe E:\Ordner1\Ordner2\Logdatei_XYZ_%gestern%.zip E:\Ordner1\Ordner2\Datei* -m
cd \Ordner1\Ordner2
copy *.zip E:\TEMP /Y

Das ganze skript läuft durch, bis er zu dem punkt hier kommt:
copy *.zip \\server\server2\anwendung\software\Log-Sicherung\%jahr%\%monat%\Datei_Log_ServerXYZ\ /Y
-> hier füllt er dann noch das %jahr% mit 2022 aus aber das %monat% macht er nicht. Eigentlich sollte er dann in den Ordner 9 gehen und dort in Datei_Log_ServerXYZ und die zip Datei dort hinlegen. macht er aber nicht.

Kann mir einer vielleicht ein tipp geben. Wieso er ein Problem mit dem %monat% hat und das auch erst seit dem 01.08....

Lieben Gruß

 

[Mihawk90]

Hast du die Zeilen mal manuell/einzeln in ne CMD eingegeben?

Ich hab testweise mal set /a monat=%date:~-7,2% probiert und krieg ne Fehlermeldung:

Ungültige Zahl. Numerische Konstanten sind entweder dezimale (17), hexadezimale (0x11) oder oktale (021) Zahlen.

Das würde dann auch das Problem erklären. Allerdings weiß ich nicht ob das mit dem set j zusammenhängt (keine Ahnung was das tut? )

 

[GoofyGaston]

Ich hatte auf der bash auch mal Probleme, dass ich einer Variablen nicht den Wert "08" geben konnte. Das wird dann als etwas oktales interpretiert uns geht einfach so nicht. Ich weiß aber nicht mehr, ob man das irgendwie escapen konnte.

 

[Raijin]

Lass einfach das /a beim SET monat weg. Wie die Fehlermeldung sagt, wird der String "09" nicht als Zahl erkannt. Das liegt mutmaßlich daran, dass die Zahl nicht als Dezimal interpretiert wird, sondern durch die führende Null als Oktal. Deswegen klappte das von 01 bis 07, aber bei 08 nicht mehr, weil das oktal 10 wäre, und bei 09 entsprechend.

Wenn du /a weglässt, wird SET lediglich den String auslesen und der Variable zuweisen. /a brauchst du nur, wenn du mit der Variable rechnen willst, weil die Variable dann explizit eine Zahl sein muss. Zum Zusammenbauen von Pfaden ist das aber irrelevant und der Monat als String taugt ebenso, ganz ohne /a.

Ergänzung (20. September 2022)

Solltest du im weiteren Verlauf des Skripts dennoch mit monat rechnen wollen und man sieht es in deinem Snippet nur nicht, kannst du wie folgt vorgehen:

SET /a monat=1%date:~-7,2% - 100

Das Ergebnis ist eine dezimale 9 in monat, mit der du nach Belieben weiterrechnen kannst.

 

[ITAlexBerlin]

Das Betrifft dann aber nur die Monate 8 und 9 oder?

Das Skript soll die Logs halt in die Monats Ordner 1-12 zuteilen, jenachdem welchen Monat wir gerade haben. Wenn ich das /a bei dem set monat weglasse, sollte das ganze ja jeden Monat klappen oder? Das Skript wird an sich ja nicht bearbeitet sondern soll einfach 365 tage im Jahr seine arbeit machen.

 

[Mihawk90]

Das Betrifft dann aber nur die Monate 8 und 9 oder?

Sofern die Erläuterung von @Raijin zutrifft (wovon ich mal ausgehe, weil sie Sinn macht), dann ja.
Aufgrund der führenden 0 geht cmd von einer Oktalzahl aus. Okatale sind von 0-7. Entsprechend ist 08 eine ungültige Oktalzahl. 08 bzw 8 in Dezimalschreibweise sind 10 in Oktal.
Gleiches gilt für 09, wobei 9 = 11.

 

[s1ave77]

Das Betrifft dann aber nur die Monate 8 und 9 oder?

Nein, generell. Das /a kommt nur bei Rechenoperationen in's Spiel, ansonsten ohne.

Was soll das set g bewirken?

 

[Raijin]

Das Betrifft dann aber nur die Monate 8 und 9 oder?

Ich hab das nicht durchprobiert, aber letztendlich ist es egal für welchen Monat es gilt und für welchen nicht. Du willst ja schließlich keine Fallunterscheidung einbauen, die dann nur 08 und 09 rausfiltert. Ob meine Vermutung 100% zutrifft und das wirklich die Ursache ist, spielt eigentlich keine Rolle, weil es unerheblich ist warum die Fehlermeldung kommt. SET hat ja offenkundig Probleme bei der Interpretation von 08 bzw. 09, mutmaßlich eben, weil das als oktal interpretiert wird und somit keine gültige Zahl ist - was ja auch in der Fehlermeldung steht

Wenn ich das /a bei dem set monat weglasse, sollte das ganze ja jeden Monat klappen oder?

Ja, wie ich gleich als erstes geschrieben hatte.

Wenn du den ausgelesenen Monat inkl. führender Null einfach unverändert weiternutzen willst, kannst du ihn ganz einfach ohne /a mit SET aus %date% auslesen bzw. zuweisen, als String = Zeichenkette. In monat steht dann eben immer 01, 02, 03, .. 10, 11, 12


Vorsicht übrigens, wenn du das gleiche mal mit %time% machen willst. Wenn ich mich recht entsinne wird da die Stunde nicht mit einer führenden Null geschrieben. Da stünde also "9:23..." und nicht "09:23...".
Zudem sind sowohl %date% als auch %time% lokalisiert. Das heißt, dass du auf einem deutschen System ein anderes Ergebnis bekommst als auf einem englischen System. Die Batch-Datei ist also nur bedingt portabel, wenn du sie auf einem anderen PC mit möglicherweise englischen Windows einsetzt. Da müsste man %date% entsprechend anders auslesen.

 

[PHuV]

Bei solchen Sachen sollte man auch überlegen, mal auf die Powershell zu wechseln. Sie ist deutlich mächtiger und hat hier viel mehr Möglichkeiten. Für Datumsfunktionen gibts auch Maskierungen ( sowas wie Get-Date -format "yyyy-MM-dd ss:mm:HH"), was die Verwendung deutlich einfacher macht. Beispielsweise ist gestern dann einfach $gestern= (Get-Date).AddDays(-1).Date. Und Du kannst dann aus der Variable gestern sofort Tag, Monat, Jahr rausgenerieren, ohne viel Umstände, oder Du machst es wieder direkt über die Funktion per Maskierung $gestrigemon = (Get-date).AddDays(-1).ToString("MM")