Textdateien, Zeilenumbrüche und Betriebssysteme
Weiterlesenhilfreiches skripttool
WeiterlesenDa wollte ich mal schnell ne Dateiliste ziehen um damit weiterzuarbeiten. Unter Windows kann man folgenden Befehl erfolgreich einsetzen:
C:\> dir /b
Kann man unter Linux auch probieren. Klappt nicht so. Statt dessen nimmt man ls. Aber ls hat so schöne viele verschiedene Parameter. Schnell in die Man-Page nachgeschaut:
/> ls -1b
So, jetzt haben wir die Liste. Elektronisch verarbeitbar wäre sie aber erst, wenn ich das in einer Datei hab. Also shiften wir die Ausgabe einfach in eine Datei um:
C:\> dir /b >> list.txt
oder in Linux
/> ls -1b >> list.txt
Macht einem die Arbeit wirklich leichter.
Wenn man Dateien sucht, ist das gerade, wenn Dateien vom System erstellt werden, immer etwas mühselig. Das wird sogar noch schlimmer, wenn man die dann löschen will. Unter Linux, wo auch sonst, gibt es einen tollen Befehl, der einem die Arbeit deutlich erleichtert:
find
Mithilfe von find kann man einfach Dateien anhand eines Filter finden und dann sogar direkt löschen. Das kann zum Beispiel so aussehen:
find -name "*.cs" -type f
Hier suche ich alle cs Dateien im aktuellen Ordner. Ich schränke auch auf Dateien ein (-type f)
find -not -name "*.cs" -type f
Hier suche ich nach allen Dateien, die keine cs Dateien sind. So einfach.
find ./ -not -name "*.cs" -type f
Durch den verweis auf einen Pfad geben ich an ob auch Unterordner durchsucht werden sollen. Und das Ganze kann ich jetzt sogar noch kombinieren:
find ./ -name "*.*_*" -not -name "*.cs" -type f
Und wenn ich mir dann habe ausgeben lassen, was die Suche so ergibt, kann ich, entsprechende Rechte vorausgesetzt, das Ganze direkt löschen:
find ./ -name "*.*_*" -not -name "*.cs" -type f -delete
Aber aufpassen, der fragt nicht nochmal nach.
Gibt's das auch für nativ Windows? Bestimmt, aber da würde ich es wahrscheinlich lieber selber schreiben...
Eine Textdatei ist nicht nur eine der ältesten Möglichkeiten Informationen auf einem PC abzulegen, sondern auch Dateien in einem Format zu speichern, dass sich gut zwischen verschiedenen Betriebssystemen übertragen lässt. Die Buchstaben werden mit Hilfe einer Tabelle (z.B. ASCII-Tabelle) in einen Binärcode übersetzt und solange die Gegenseite die Tabelle auch kennt, kann das Ganze wieder zurück übersetzt werden.
Nun ist eine Standard ASCII-Tabelle nicht ausreichend, um die ganzen möglichen Schriftzeichen der Welt aufzunehmen. Ist einfach nicht genug Platz. Also gibt es mehrere Tabellen, für jedes Land quasi eine. Da diese Listen irgendwann nicht mehr ausgereicht haben, beziehungsweise man immer wissen musste, mit welcher Tabelle man die Datei lesen musste und die PCs in immer mehr Bereichen zu Einsatz kommen, gib es auch neue Tabellen, die mehr Zeichen fassen können. Die Textdatei wird dann auch größer, doppelt so groß um genau zu sein. Aber Speicher ist ja heute kein so großes Thema mehr. Zudem hat man sich dazu durchringen können, in bestimmten Fällen in der Datei ein Startzeichen zu hinterlegen, mit dem die Kodierung (Welche Tabelle muss benutzt werden?) durch Auslesen ermitteln kann. Stichwort: Byte Order Mark.
Dadurch, dass das Interpretieren der Datei jeweils dem Betriebssystem überlassen wird, kann eine Datei normalerweise unkompliziert zwischen Betriebssystemen hin und hergeschoben und auch bearbeitet werden. Zudem ist für das Bearbeiten solcher Dateien eigentlich immer ein Editor mit an Bord.
Aber ein kleiner Unterschied kann einen immer mal wieder großen und aufwendigen Suchaufwand verursachen.
Der Zeilenumbruch
Also Cursor nach unten und zurück zum Anfang. Dieses Zeilenende wird in verschiedenen Betriebssystemen auch nicht immer gleich gehandhabt. Während Windows hier die nicht druckbaren Zeichen CR (Carriage return - Wagenrücklauf) und LF (Line feed - Zeilenvorschub) verwendet, wollen UNIX- Derivate (Linux, macOS und so weiter) nur ein LF. Das ist im Normalfall gar nicht so schlimm. Die meisten Texteditoren erkennen einfach den benutzten Zeilenumbruch und nutzen ihn einfach weiter. Problematisch kann die Sache werden, wenn man diese Datei irgendwo im Betriebssystem nutzen möchte und das Programm davon ausgeht, dass der richtige Zeilenumbruch verwendet wurde. Bei Unixdateien muss nur ein Zeichen zum Trennen benutzt werden. Benutzt man eine Windowsdatei bleibt ein nicht druckbares Zeichen übrig: CR.
Programme, die dies nicht berücksichtigen, haben dann ein Zeichen in den Skripten oder Einstellungen, welches Probleme verursachen kann. Wenn man die Datei in Windows erstellt und dazu noch einen Texteditor benutzt, der versucht einem die Arbeit des Zeilenumbruchs abzunehmen und automatisch die Betriebssystemwahl trifft, kann es unter Umständen sein, dass man seinen Fehler beim Übertragen der Datei auf Linux gar nicht bemerkt. Unter Linux könnte es dann komische Fehlermeldungen geben, die beim Betrachten der Datei gar nicht auffallen, weil es ja nicht druckbare Zeichen sind.
Nur LF ohne CR funktioniert auch unter Windows gut, weshalb alle neuen Dateien in meinen Texteditoren immer nur noch direkt mit LF als Zeilenumbruch gespeichert werden. Einmal einstellen und fertig. Das kann eigentlich jeder gute Texteditor. Ansonsten sollte man über ein Alternative nachdenken. Was machen wir aber mit Dateien, die schon irgendwo abgelegt sind und über eine falsche Kodierung verfügen? Klar, man kann die Datei jetzt umständlich in einem Editor der Wahl öffnen, ändern und neu speichern. Das ist aber unter Unix-Systemen ohne grafische Oberfläche unter Umständen ein bisschen aufwändig. Unter Unix gibt es ein tolles Tool für die Kommandozeile, mit dem man (unter anderem) den Zeilenumbruch in einer Zeile für x-beliebig große Dateien ändern kann. Der sed - stream editor. Dieses Tool ist eine Standardausstattung und dürfte in jeder Linuxdistribution immer mit an Bord sein.
Mit folgender Zeile lässt sich das Zeilenende anpassen:
Es gibt noch mehr solche tollen Einzeiler für jede Menge Anwendungsfälle.
Problemstellung:
Wir haben ein Serverskript das wir immer als Administrator ausführen.
Dieses Skript führt ein Serverupdate bei uns durch.
Wenn das Skript nicht als Administrator ausgeführt, wird führt dies zu einem unvollständigen Update, da für bestimmte Dateien die Berechtigung fehlt.
Daraus resultiert unter Umständen eine unvollständige Installation.
Um eine Fehlerquelle auszuschließen haben wir nach einer Möglichkeit gesucht wie sichergestellt werden kann, dass das Skript immer als Administrator ausgeführt wird.
Lösung:
$EUID stellt die Identität des angemeldeten Users dar der für die Rechteprüfung genutzt wird hierbei hat er root Nutzer die 0.
-ne ist der Operator für ungleich
Das Skript prüft ob es sich bei dem angemeldeten Benutzer um den Root handelt.
Ist das nicht der Fall: Ruft sich das Skript erneut mit Rootrechten auf.