7
Variablen beschraenkt auf 1024 Bytes (Zeichen)
Hallo zusammen,
ich habe ein batchfile in der ich eine Textfile in eine Variable einlese. Jetzt kann es sein das die Textdatei auch mehr als 1024 Zeichen hat.
Code:
@set /p data=< %BSE%\tmp\device_queue.txt
@echo %data%
dann bekomme ich nur die ersten 1024 Zeichen angezeigt.
Kann mann da was gegen machen, oder ist man da beschränkt??
danke & gruß Olli
ich habe ein batchfile in der ich eine Textfile in eine Variable einlese. Jetzt kann es sein das die Textdatei auch mehr als 1024 Zeichen hat.
Code:
@set /p data=< %BSE%\tmp\device_queue.txt
@echo %data%
dann bekomme ich nur die ersten 1024 Zeichen angezeigt.
Kann mann da was gegen machen, oder ist man da beschränkt??
danke & gruß Olli
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: 89116
Url: https://administrator.de/contentid/89116
Ausgedruckt am: 22.11.2024 um 10:11 Uhr
7 Kommentare
Neuester Kommentar
Hallo olliwest!
Die Variable selbst hätte mehr Platz zu bieten (siehe am Ende der Command shell overview; getestet mit XP SP2); das Problem ist es, die Daten hineinzubekommen, da beim Lesen aus der Datei tatsächlich nach 1023 Zeichen Schluss ist.
Falls die Eingabedatei nur eine Zeile umfassen sollte, könnte es so klappen:
[Edit] Der Ordnung halber noch die Variante "Nur erste Zeile von mehreren verwenden":
[/Edit]
Grüße
bastla
Die Variable selbst hätte mehr Platz zu bieten (siehe am Ende der Command shell overview; getestet mit XP SP2); das Problem ist es, die Daten hineinzubekommen, da beim Lesen aus der Datei tatsächlich nach 1023 Zeichen Schluss ist.
Falls die Eingabedatei nur eine Zeile umfassen sollte, könnte es so klappen:
for /f "delims=" %%i in (%BSE%\tmp\device_queue.txt) do set "data=%%i" set "data="
for /f "delims=" %%i in (%BSE%\tmp\device_queue.txt) do if not defined data set "data=%%i" Grüße
bastla
hi bastla,
ja es funktioniert!!!
vielen Dank
ja es funktioniert!!!
vielen Dank
@bastla
Hast du mal ausprobiert, ob das Environement wirklich 65,536KB (IMO = 64 MB) aufnehmen kann?
(siehe am Ende der Command shell overview; getestet mit XP SP2);
Hast du mal ausprobiert, ob das Environement wirklich 65,536KB (IMO = 64 MB) aufnehmen kann?
ne, habe ich noch nicht gemacht.
olli
olli
Moin blubbdi,
explizit getestet hat es sicherlich niemand hier, obwohl wir schon ein, zwei Threads hier hatten mit "Wieviel Variablen kann ich gleichzeitig per SET setzen" oder ähnlich.
wie dort geschrieben wurde... eine Zählschleife, die 10000 oder
100000 Variablen %Test1%.....%Test99999% setzen soll/mit einem textstring füllen soll, läuft NICHT auf einen Fehler. No problem.
Der Knackpunkt ist IMHO ein anderer:
Andere CMDLine-Utitities haben eine nicht dokumentierte MAXSTRINGLEN (lag in der freien Entscheidung der zuständigen M$-PraktikantInnen).
Und ab einer gewissen "ungewöhnlichen" Länge wird es experimentell.
Bzw. wie der sympathische Weltmarktführer sagen würde "...will cause unpredictable results..".
Beispiel: Der Find.exe-Befehl kann nicht in Zeilen suchen (bzw. finden) , wenn diese länger als 2000 und ein paar Zeichen lang sind.
Die FindStr.exe hat dieses Limit nicht.
Dafür aber vielleicht das Limit 4096.
Beispiel 2: wenn eine CMD-Variable 8192 Zeichen lang sein dürfte, was nützt es mir, wenn die maximale Länge einer Befehlszeile 2068 Zeichen ist?
Oder was passiert, wenn ich einen Batch aufrufe mit 9 Parametern
Ich denke nicht, dass die Größe des Environments "nur durch die Größe des zur Verfügung stehenden Hauptspeichers begrenzt" wird (so war/ist ja eine der beliebten Verkaufsformulierungen).
die Sollbruchstellen sind viel banaler... ein flapsiger #define MAXLEN eines Urlaubs-Aushilfscoders aus dem Jahr 1993 wird das Arbeiten am offiziell dokumentierten Limit schon nach einem Drittel der Strecke beenden.
Siehe Thema "Lange Verzeichnis/Dateinamen... bis zu 32767 Zeichen."
...muahaha....
... ab 253 Zeichenlänge des Namens kannst Du Dateien zwar noch schreiben, aber nie wieder lesen.
Grüße
Biber
explizit getestet hat es sicherlich niemand hier, obwohl wir schon ein, zwei Threads hier hatten mit "Wieviel Variablen kann ich gleichzeitig per SET setzen" oder ähnlich.
wie dort geschrieben wurde... eine Zählschleife, die 10000 oder
100000 Variablen %Test1%.....%Test99999% setzen soll/mit einem textstring füllen soll, läuft NICHT auf einen Fehler. No problem.
Der Knackpunkt ist IMHO ein anderer:
Andere CMDLine-Utitities haben eine nicht dokumentierte MAXSTRINGLEN (lag in der freien Entscheidung der zuständigen M$-PraktikantInnen).
Und ab einer gewissen "ungewöhnlichen" Länge wird es experimentell.
Bzw. wie der sympathische Weltmarktführer sagen würde "...will cause unpredictable results..".
Beispiel: Der Find.exe-Befehl kann nicht in Zeilen suchen (bzw. finden) , wenn diese länger als 2000 und ein paar Zeichen lang sind.
Die FindStr.exe hat dieses Limit nicht.
Dafür aber vielleicht das Limit 4096.
Beispiel 2: wenn eine CMD-Variable 8192 Zeichen lang sein dürfte, was nützt es mir, wenn die maximale Länge einer Befehlszeile 2068 Zeichen ist?
Oder was passiert, wenn ich einen Batch aufrufe mit 9 Parametern
testbatch.cmd %var8192Lang% %var8192Lang% %var8192Lang% %var8192Lang% ...Ich denke nicht, dass die Größe des Environments "nur durch die Größe des zur Verfügung stehenden Hauptspeichers begrenzt" wird (so war/ist ja eine der beliebten Verkaufsformulierungen).
die Sollbruchstellen sind viel banaler... ein flapsiger #define MAXLEN eines Urlaubs-Aushilfscoders aus dem Jahr 1993 wird das Arbeiten am offiziell dokumentierten Limit schon nach einem Drittel der Strecke beenden.
Siehe Thema "Lange Verzeichnis/Dateinamen... bis zu 32767 Zeichen."
...muahaha....
... ab 253 Zeichenlänge des Namens kannst Du Dateien zwar noch schreiben, aber nie wieder lesen.
Grüße
Biber
Hi, Biber,
so wahre Lust habe ich im Moment nicht, das wirklich mal auszutesten. Ich dachte allerdings eher an einen Fehler im Technet-Artikel mit dem Komma. ;) Früher, ganz früher (im vorigen Jahrtausend) gab es da mal eine Beschränkung auf 32 KB für das Environment pro MCB. Egal. Bei Gelegenheit setze ich mich da vielleicht mal ran.
Ich habe aus einem anderen MS-Artikel noch im Hinterkopf, dass die Zeichenbegrenzung für einen Pfadnamen bei ~1020 Zeichen liegen soll, die man über den UNC-Pfad erreichen kann. Irgendwo ist der verewigt.
Gruß
blubbdi
In Ansi liegt die max. Länge wohl bei 260 Zeichen,
http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx
in Unicode bei 32767 WideChars
http://msdn.microsoft.com/en-us/library/aa364980(VS.85).aspx
Noch was zu Längen:
max. Länge von Pfad-Umgebungsvariablen:
http://support.microsoft.com/kb/180410/de
Der Artikel, den ich meinte, behandelte imo die max. Pfadlänge in einem Netzwerk, und das waren 1020 Zeichen (1024 - "\\?\"). Den Artikel habe ich aber so gut versteckt, dass ich ihn im Moment nicht finde. ;)
so wahre Lust habe ich im Moment nicht, das wirklich mal auszutesten. Ich dachte allerdings eher an einen Fehler im Technet-Artikel mit dem Komma. ;) Früher, ganz früher (im vorigen Jahrtausend) gab es da mal eine Beschränkung auf 32 KB für das Environment pro MCB. Egal. Bei Gelegenheit setze ich mich da vielleicht mal ran.
Ich habe aus einem anderen MS-Artikel noch im Hinterkopf, dass die Zeichenbegrenzung für einen Pfadnamen bei ~1020 Zeichen liegen soll, die man über den UNC-Pfad erreichen kann. Irgendwo ist der verewigt.
Gruß
blubbdi
In Ansi liegt die max. Länge wohl bei 260 Zeichen,
http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx
in Unicode bei 32767 WideChars
http://msdn.microsoft.com/en-us/library/aa364980(VS.85).aspx
Noch was zu Längen:
max. Länge von Pfad-Umgebungsvariablen:http://support.microsoft.com/kb/180410/de
Der Artikel, den ich meinte, behandelte imo die max. Pfadlänge in einem Netzwerk, und das waren 1020 Zeichen (1024 - "\\?\"). Den Artikel habe ich aber so gut versteckt, dass ich ihn im Moment nicht finde. ;)
Hallo Ihr,
unsere Anwender haben des Öfteren das Limit in der Vergangenheit erreicht und überschritten. Wie Biber sagte konnten die Dateien noch geschrieben, aber nicht mehr geöffnet werden:
Word 97: 210 Zeichen (incl. Laufwerksbuchstaben, Backslashes und Doppelpunkt)
Excel 97: 209 Zeichen (incl. Laufwerksbuchstaben, Backslashes und Doppelpunkt)
Bei Office 2000/2003 gab/gibt es ebenfalls ein Limit, finde jedoch gerade das Dok dazu nicht mehr... müßte aber in der Größenordnung liegen, die Biber schon erwähnte. (Explorer Problem?)
Wir haben uns in der Vergangenheit dann mit dem subst Befehl helfen können, um an die Dateien heranzukommen und zu verschieben...
Ach ja, irgendjemand wollte dann 'mal testen, wieviele Schachtelungstiefen man denn noch verwenden kann, wenn ein Verzeichnis und eine Datei nur einen Buchstaben haben, er hat dann ein Script erstellt hatte, das rekursiv Verzeichnisse anlegte ...
(nach einem Reboot des Fileservers, einigen Ermahnungen und dem Hinweis, dass man das auch manuell machen kann oder ausrechnen kann, konnten wir dann das Verzeichnis löschen...)
mfg
Axel
unsere Anwender haben des Öfteren das Limit in der Vergangenheit erreicht und überschritten. Wie Biber sagte konnten die Dateien noch geschrieben, aber nicht mehr geöffnet werden:
Word 97: 210 Zeichen (incl. Laufwerksbuchstaben, Backslashes und Doppelpunkt)
Excel 97: 209 Zeichen (incl. Laufwerksbuchstaben, Backslashes und Doppelpunkt)
Bei Office 2000/2003 gab/gibt es ebenfalls ein Limit, finde jedoch gerade das Dok dazu nicht mehr... müßte aber in der Größenordnung liegen, die Biber schon erwähnte. (Explorer Problem?)
Wir haben uns in der Vergangenheit dann mit dem subst Befehl helfen können, um an die Dateien heranzukommen und zu verschieben...
Ach ja, irgendjemand wollte dann 'mal testen, wieviele Schachtelungstiefen man denn noch verwenden kann, wenn ein Verzeichnis und eine Datei nur einen Buchstaben haben, er hat dann ein Script erstellt hatte, das rekursiv Verzeichnisse anlegte ...
(nach einem Reboot des Fileservers, einigen Ermahnungen und dem Hinweis, dass man das auch manuell machen kann oder ausrechnen kann, konnten wir dann das Verzeichnis löschen...)
mfg
Axel
