Hallo,
ichl habe hier zwar ein sehr einfaches Standardproblemm, aber ich sehe den Fehler einfach nicht. Vielleicht liegts es auch daran, dass VB nicht gerade meine Heimatsprache ist.
Ich habe mehrere *.dat Dateien bei denen ich die ersten 23 Zeilen jeweils löschen möchte. Dies versuche ich mit folgendem VB Script:
' Delete First n Lines of a Text File
Const FOR_READING = 1
Const FOR_WRITING = 2
Anz_Probanden = 1 'Wscript.Arguments(0)
strFileName = "1_0.dat"
counter_stelle_1_datei = 1
counter_stelle_2_datei = 0
iNumberOfLinesToDelete = 23
Set objFS = CreateObject("Scripting.FileSystemObject")
Do While counter_stelle_1_datei Do While counter_stelle_2_datei strFileName = counter_stelle_1_datei & "_" & counter_stelle_2_datei & ".dat"
Set objTS = objFS.OpenTextFile(strFileName, FOR_READING)
strContents = objTS.ReadAll
objTS.Close
arrLines = Split(strContents, vbNewLine)
Set objTS = objFS.OpenTextFile(strFileName, FOR_WRITING)
For i=0 To UBound(arrLines)
If i > (iNumberOfLinesToDelete - 1) Then
objTS.WriteLine arrLines(i)
End If
Next
objTS.Close
counter_stelle_2_datei = counter_stelle_2_datei + 1
Loop
counter_stelle_1_datei = counter_stelle_1_datei + 1
Loop
Das Skript ist dem von http://www.microsoft.com/technet/scriptcenter/scripts/misc/text/default.mspx?mfr=true angelehnt.
So weit so einfach, sollte gehen - blöd ist nur, dass meine *.dat Dateien am Ende 0 Byte lang sind.
Was übersehe ich da?
Vielen Dank schonmal
uscos
Programmieren - alles kontrollieren 4.941 Themen, 20.708 Beiträge
Vorweg: Also ich bin auch kein VBS-Experte ;-)
Ich würde aber mal prüfen welche Zeilenumbrüche Du in den Eingabedaten hast und ob die zur Def von vbNewLine (wird wahrscheinlich die Windows-Zeilenumbrüche nutzen) abgedeckt werden.
Abgesehen davon: Wirklich schön ist der Code nicht. Aber das muß man hier auch MS anlasten, daß die solche unnötig komplizierten Verrenkungen machen.
Warum nicht z.B. einfach
oder noch eleganter: Array-Operationen (keine Ahnung ob VBS solche Features kennt) anwenden und dann einfach in die Datei ausgeben ;-)
Gruß
Borlander
Ahh, auf die Zeilenumbrüche wäre ich gar nicht gekommen. AFAIK sollte vbnewline automtisch die richtig codierten Umbrüche wählen, aber vielleicht ist das wirklich das Problem. Ich werde es mal mit vbLrLf, vbCr, Environment.NewLine und ControlChars.NewLine. Hoffentilch hlilft das.
Das ganze regt mich jetzt schon ein bissl auf. Das ganze ist Teil eines Skriptes das Auswertungsdateien von einem wissenschaftlichen Programm in ein SPSS fähiges Format umwandelt. Dazu kommen dann gleich noch ein par recht komplizierte Berechnungen. Da das ganze auf WIndows läuft dchte ich mir halt, dass das WHS bzw. VBS können sollte und hab stat SED zu benutzen diesen Weg gewählt. Hätte ich SED benutzt könnte ich schon 3x damit fertig sein :-(.
Also, heute Abend kann ich das auprobieren, dann sehe ich, ob es daran liegt und melde mich dann zurück.
VG
uscos
PS: Ich hab mir halt gedacht ich nutze deren Beispiel, da ehrlich gestanden das Script erstmal nur laufen muss. Schön kann ich es dann machen wenn das Ganze (was unwahrscheinlich ist) zu lange dauern sollte. Prinzipiell Recht hast du allerdings.Ich hab das ganze halt nur peripher aufm Schirm gehabt, da ich eher mit dem (mittlerweile laufenden), viel komplizierteren Teil des Skriptes beschäftigt war. Jetzt dachte ich mir ich bau das schnell ein ..... tja, falsch gedacht *g*
Ich habe eben mal kurz nach vbNewline gesucht: Soll Plattformspezifisch (wenn alle Programmierer solche Konstanten verwenden würden hätten wir sicher weniger Probleme als mit hartcodierten Zeichencodes) sein, also ist zu erwarten, daß es unter win32 immer den Wert vbCrLf (=\r\n) hat. Würde es insbesondere auch mal mit vbLf (=\n) probieren...
Gruß
Borlander
also, es lag tatsächlich an vbnewline. Das nenne ich dann mal Betriebsblindheit.
Vielen Dank!
uscos
Prima :-)
Zeilenumbrüche und Zeichencodierungen sind eben immer wieder für Ärger bei der Verarbeitung von Textdateien gut :-\
Mit welchem Zeichumbruch lief es denn nun?
Gruß
Borlander
vbLf