"Autor verzeichnisweit ergänzen" ist unbrauchbar und sollte abgeschafft werden

[Alwin Meschede]

Ich habe soeben eine Dreiviertelstunde investieren müssen, um den Flurschaden halbwegs einzuhegen, den die Funktion "Autor verzeichnisweit ergänzen" in der Siegstrecke angerichtet hatte. Diese Funktion ist einfach nicht smart genug für die ihr gestellten Aufgaben. Sie löst keine Probleme, sondern schafft nur neue Probleme. Deshalb sollte sie meines Erachtens abgeschafft werden.

Was war passiert? In der Siegstrecke gab es einige leere Autoreneinträge <AutorEintrag/>. Die wurden beim Einreichen natürlich als "Autor fehlt" bemängelt. Also dachte sich der Autor, "nutze ich doch 'Autor verzeichnisweit ergänzen' um das Problem zu lösen". Was war aber das Ergebnis? "Autor verzeichnisweit ergänzen" ersetzt die <AutorEintrag/> ja nicht, sondern hängt einfach nur weitere Autoreneinträge hinten dran. Das Problem "Autor fehlt" wird also nicht gelöst, und obendrein werden die Dateien mit unnützen zusätzlichen Autoreneinträgen befüllt, wenn zusätzlich zum <AutorEintrag/> der eigentlich gewollte Autoreneintrag schon in der Datei existiert.

Zusätzlich habe ich die Funktion im Verdacht, dass sie die Codierung der angefassten Dateien von "UTF mit BOM" zu "UTF ohne BOM" ändert. Alleine diese Glanzleistung bläht jetzt das Siegstrecken-Paket völlig unnötig noch zusätzlich auf. Mir fehlen im Moment die Möglichkeiten, um das per Batch wieder geradezuziehen.

[F. Schn.]

Mir fehlen im Moment die Möglichkeiten, um das per Batch wieder geradezuziehen.

Müsste in der PowerShell wie folgt gehen:

Code: Alles auswählen

dir -recurse test.txt | foreach { $t = [System.IO.File]::ReadAllText($_, [System.Text.Encoding]::Utf8) ; $t = $t.Replace("<AutorEintrag/>", "") ;[System.IO.File]::WriteAllText($_, $t, [System.Text.Encoding]::Utf8) }

[Alwin Meschede]

Setzt mir das auch den verlorengegangen BOM? Die Autoreneinträge habe ich ja per Suchen+Ersetzen greifen können. Aber mir fehlt im Moment eine Möglichkeit, um massenweise den UTF-BOM wieder zu setzen. Das dürfte das Volumen des Siegstrecken-Pakets von derzeit 24 MB erheblich senken.

[F. Schn.]

Ja, setzt die BOM. Das mit dem Replace habe ich als Showcase angehängt.

[Max Senft]

Hi,

wieso sollen Dateien mit BOM kleiner sein als Dateien ohne? Das hab ich ja noch nie gehört. Eigentlich sind das ja drei zusätzliche Byte am Anfang einer jeden Datei, die aber sonst am Encoding der Datei nichts ändern?

Oder hab ich irgendwas elementares verpasst?

Gruß
Max

[F. Schn.]

Die Dateien im Bestand sind mit BOM. Die geänderten Dateien ohne BOM. Also ermittelt Zusi eine Diff, wo keine ist, und schmeißt Daten in das Paket, die nicht geändert wurden. Und dadurch wird das Paket groß, obwohl es wesentlich kleiner seien könnte.

[Max Senft]

Hi,

ach sooooooo.

Gruß
Max

[Alwin Meschede]

Müsste in der PowerShell wie folgt gehen:

Dazu noch eine etwas verspätete Rückmeldung: Mit deinem Originalvorschlag tat sich bei mir erstmal nichts. Möglicherweise weil dir -recurse per default erstmal auch noch allen möglichen anderen Unsinn zusätzlich zu den gesuchten Pfadnamen outputtet.
Ich bin schlussendlich bei dieser funktionierenden Variante gelandet, die außer den BOM setzen nichts anderes mehr tut:

Code: Alles auswählen

dir -recurse -name -file | foreach { $t = [System.IO.File]::ReadAllText($_, [System.Text.Encoding]::Utf8) ; [System.IO.File]::WriteAllText($_, $t, [System.Text.Encoding]::Utf8) }

Ein verkleinertes Siegstrecken-Paket hat das nicht erbracht. Es ist sogar 10 MB größer als mein erster Anlauf. Auch die derzeit noch offizielle Version der Siegstrecke ist nämlich wie sich rausstellt bereits ein fröhliches Gemisch aus mit und ohne BOM. Ich belasse es deshalb bei meiner ersten Version des Pakets.

[F. Schn.]

Ok, bei ohne *.ls3 hätte ich befürchtet, dass sie *.dds und *.lsb anfasst.

[Alwin Meschede]

Die lsb habe ich getestet. Die waren funktionstüchtig.