Bash: Tabelle mit 5 Spalten aus Ordnernamen in einem Ordner erstellen

SeppJ

@ShredderButtonOn sagte in BASH: Tabelle mit 5 Spalten aus Ordnernamen in einem Ordner erstellen:

Hm, und was sagen die übrigen dazu?

Parameterexpansion ist schon eine feine Sache, wenn man nur Effizienz betrachtet. Aber hat halt auch unerwartete Nachteile.

Hier musste siri einige Verrenkungen machen, um es überhaupt nutzen zu können. Ist das noch effizient? Wahrscheinlich sogar ja, weil die Subprozesse und Pipes, die man dadurch spart, ganz schön teuer sind. Aber dann muss man wieder fragen, wen in so einem Anwendungsfall Effizienz im Mikrosekundenbereich interessiert.

Ein weiterer, nicht offensichtlicher Nachteil ist, dass das manchmal auf unerwartete Art fehlschlagen kann. Das hier gezeigte ${file%/*} funktioniert hier nur, weil die Ergebnisse von find garantiert die richtige Form dafür haben. Wenn aber file=test.txt wäre (was ja ganz legitim ist, wenn test.txt im aktuellen Verzeichnis liegt), dann würde ${file%/*} zu nix expandiert, wohingegen dirname $file immer noch . wäre. Das heißt, hier hätte man als Zielpfad des mv dann statt ./.. auf einmal /... Ein katastrophaler Fehler, wenn jemals jemand den ersten Teil des Scripts abändert, so dass die Annahme nicht mehr gilt (zum Beispiel indem man die Dateinamen aus Nutzereingaben nimmt), ohne den kompletten Ablauf und alle Fallstricke der Expansion zu durchdenken, wo dirname die solidere Wahl gewesen wäre, weil es ohne Trickserei das ausdrückt, was man erreichen möchte.

Shell-Tricks sind zwar schön und cool, aber man trickst sich damit auch gerne selbst aus, eventuell erst nach langer Zeit, wenn man vergessen hat, dass die Funktionsweise von einem Script, das man ändert, von solch einem Kniff abhängt. Ob die daraus folgenden Kopfschmerzen den Coolnessfaktor wert sind, muss man selber wissen. Produktiv in einer Umgebung, wo das verlässlich funktionieren muss, und wo noch andere Leute daran arbeiten, würde ich so etwas tunlichst vermeiden.

ShredderButtonOn

@SeppJ sagte in BASH: Tabelle mit 5 Spalten aus Ordnernamen in einem Ordner erstellen:

wen in so einem Anwendungsfall Effizienz im Mikrosekundenbereich interessiert.

Es geht da nicht um Millisekunden. Wenn man den tatsächlichen Overhead messen würde, also abzüglich der ohnehin benötigten Zeit für das Dateiverschieben, bewegen wir uns wahrscheinlich im Mikro- oder gar im Nanosekundenbereich!

@SeppJ Könntest du bitte im Titel dieses Themas "BASH" durch "Bash" ersetzen? Das liest sich besser.

SeppJ

@SeppJ Könntest du bitte im Titel dieses Themas "BASH" durch "Bash" ersetzen? Das liest sich besser.

Ich habe es mal für dich gemacht, aber der Threadersteller (hier also du) kann das auch. Dazu einfach den ersten Beitrag editieren; die Überschrift ist Teil dieses Beitrags.

wob

@siri sagte in Bash: Tabelle mit 5 Spalten aus Ordnernamen in einem Ordner erstellen:

Man kanns sich halt auch einfacher machen. Du kannst dir eine Liste an Dateinamen erzeugen und einfach darüber iterieren, das ist dann zwar kein One-Liner mehr, jedoch viel übersichtlicher:

... und nicht in allen Fällen richtig.

$ touch "testfile                     
dquote> with 2 lines.ending"

Und whoops

In wiederverwertbaren Scripten find immer mit -print0 benutzen.

Oder eben gleich all diese Pitfalls vermeiden und eine "richtige" Programmiersprache verwenden. Wie gesagt, nichts gegen bash für kurze Progrämmchen - aber je mehr Logik man unterbringen will, desto weniger sinnvoll ist das in bash.

Finnegan

@wob sagte in [Bash: Tabelle mit 5 Spalten aus Ordnernamen in einem Ordner erstellen]

Oder eben gleich all diese Pitfalls vermeiden und eine "richtige" Programmiersprache verwenden. Wie gesagt, nichts gegen bash für kurze Progrämmchen - aber je mehr Logik man unterbringen will, desto weniger sinnvoll ist das in bash.

Das ist ein Kriterium. Wenn der Zweck des Programms allerdings ist, hauptsächlich Kommandozeilen-Befehle abzusetzen, dann dürfen Bash-Skripte meiner Meinung nach auch gerne etwas länger sein. Dass man die in Shell-Skripten einfach so hinschreiben kann, anstatt die erstmal mit Strings zusammenzubauen oder gar mit Unterprozess-Funktionen zu arbeiten kann auch ein großer Vorteil sein.

@wob Dateinamen mit Newlines ignoriere ich bewusst in meinen Scripts. Ich mein auch, was für ein Held macht auch Newlines in Dateinamen.

Immerhin kann man noch ein mapfile -t -d $'\0' filepaths < <(find ... -print0) machen. Aber ich glaube dieses -d ist in älteren Bash-Versionen nicht dabei. xargs hat auch so seine Tücken und die -exec Anwendung mit find finde ich nicht viel hübscher.

SeppJ

@siri sagte in Bash: Tabelle mit 5 Spalten aus Ordnernamen in einem Ordner erstellen:

@wob Dateinamen mit Newlines ignoriere ich bewusst in meinen Scripts.

Du lebst gefährlich. Anders als viele andere Programme reagieren Shellscripts auf unerwartete Daten nicht mit Abstürzen, sondern arbeiten fröhlich mit den Mülldaten weiter (weil halt alles ein String ist, und irgendwie passt aller Müll in Strings). Da in solchen Scripts öfters recht mächtige Befehle aufgerufen werden (zum Erstellen/Kopieren/Verschieben/Löschen von Dateien), kann das ganz schön Schaden anrichten, wenn man da unerwarteten Müll als Argument nutzt. Dann wird aus rm ${directory}/* dann plötzlich rm /* und viel Spaß!

ShredderButtonOn

... Seid doch froh, dass ihr nicht mit türkischen Datei-Encodings (non-ascii, die passen nicht in utf-8) kämpfen müsst

wob

@SeppJ sagte in Bash: Tabelle mit 5 Spalten aus Ordnernamen in einem Ordner erstellen:

Dann wird aus rm ${directory}/* dann plötzlich rm /* und viel Spaß!

Oder auch ganz toll:

# delete the two user-specified files
rm "$first_user_specified_file" "$second_user_specified_file"

Was soll schon schief gehen? Vielleicht ist first_user_specified_file="-rf"?
Oder man nennt eine Datei mal --. Ich wette, sehr sehr viele Scripte failen damit.

@ShredderButtonOn sagte:

non-ascii, die passen nicht in utf-8

-v, bitte! Welche Zeichen können nicht in utf-8 kodiert werden? Die Behauptung klingt erstmal falsch.

SeppJ

@wob sagte in Bash: Tabelle mit 5 Spalten aus Ordnernamen in einem Ordner erstellen:

@SeppJ sagte in Bash: Tabelle mit 5 Spalten aus Ordnernamen in einem Ordner erstellen:

Dann wird aus rm ${directory}/* dann plötzlich rm /* und viel Spaß!

Oder auch ganz toll:
# delete the two user-specified files
rm "$first_user_specified_file" "$second_user_specified_file"
Was soll schon schief gehen? Vielleicht ist first_user_specified_file="-rf"?
Oder man nennt eine Datei mal --. Ich wette, sehr sehr viele Scripte failen damit.

Oh, die sind gut. Ich glaube, manche meiner eigenen Scripte sind dagegen nicht gefeilt. Muss ich mal prüfen. Und dann diese Art Parameter auf die Scripte der Kollegen loslassen.

wob

@SeppJ sagte in Bash: Tabelle mit 5 Spalten aus Ordnernamen in einem Ordner erstellen:

Ich glaube, manche meiner eigenen Scripte sind dagegen nicht gefeilt.

Meine teils auch nicht, auch wenn ich es neuerdings immer versucht habe. Aber allgemein sind die mehr für mich selbst und ich weiß ja, was ich übergebe...
Meiner Feile fehlt allerdings irgendwie das L (scnr)

Was die Genauigkeit angeht habe ich kein Problem damit wenn du den Pfad vorher entweder mit dirname oder realpath normalisierst. Und statt nen riesigen One-Liner mit find zu schreiben, kann man auch ein eigenständiges Bash-Skript schreiben, das alle Vorkehrungen trifft, um sowas wie Parents/Dateinamen/Extensions korrekt zu determinieren. Auch mit Parameter Expansion.

@SeppJ sagte in Bash: Tabelle mit 5 Spalten aus Ordnernamen in einem Ordner erstellen:

Du lebst gefährlich. Anders als viele andere Programme reagieren Shellscripts auf unerwartete Daten nicht mit Abstürzen,

Nein tu ich nicht. Korrektes error checking in Bash und das sofortige Beenden des Programms ist nicht schwer zu realisieren. Eigentlich noch einfacher, als in Sprachen wie zum Beispiel C++.

ShredderButtonOn

@siri sagte in Bash: Tabelle mit 5 Spalten aus Ordnernamen in einem Ordner erstellen:

das sofortige Beenden des Programms ist nicht schwer zu realisieren

set -e

@wob sagte in Bash: Tabelle mit 5 Spalten aus Ordnernamen in einem Ordner erstellen:

Welche Zeichen können nicht in utf-8 kodiert werden? Die Behauptung klingt erstmal falsch.

Ich darf dir keinen real world code zeigen, das fällt unter den Datenschutz. Aber ich meinte damit nicht spezielle Datei- oder Verzeichnisnamen in NTFS oder so. Sondern Sourcecode, mit dem keine IDE etwas anfangen kann.

Ging am Thema vorbei. Sorry.

ShredderButtonOn

Wem ganz doll(e) langweilig ist, der könnte sich dieses Thema ja mal durchlesen: https://stackoverflow.com/questions/1976007/what-characters-are-forbidden-in-windows-and-linux-directory-names

es knüpft an diese Diskussion (unmittelbar) an.

SeppJ

@ShredderButtonOn sagte in Bash: Tabelle mit 5 Spalten aus Ordnernamen in einem Ordner erstellen:

@siri sagte in Bash: Tabelle mit 5 Spalten aus Ordnernamen in einem Ordner erstellen:

das sofortige Beenden des Programms ist nicht schwer zu realisieren

set -e

Ihr versteht beide nicht: Das Problem ist doch, dass bei den unerwarteten Parameterexpansionen eben kein formeller Fehler auftritt, aber das Programm was katastrophal falsches tut. Siehe wobs Beispiel.

ShredderButtonOn

Es geht hier ja gerade u. a. um Quotes und Randfälle ... Ich denke, ich spinne langsam. Wollte vorhin einen git commit via bash machen, mit dem Text "Update". Daraus geworden ist aber:

ÂUpdate

Das ist ein ^+A (das 1. Zirkumflex im Französischen) ... Ich kann schnell und mit zehn Fingern schreiben. Mit Sonderzeichen tue ich mich aber schwer. Dennoch glaube ich, dass etwas mit meinem System nicht stimmen könnte ... denn ich hätte unbemerkt Shift+^+A+"+Update+" eingegeben haben müssen. Das scheint mir für eine versehentliche Handlung zu kompliziert zu sein.

Worauf will ich hinaus? Ich traue meinem Windows System nicht ganz, vielleicht ein Virus, Keylogger oder Ähnliches?

Ok, vielleicht hab ich auch einfach nur zu wenig geschlafen.

@ShredderButtonOn sagte in Bash: Tabelle mit 5 Spalten aus Ordnernamen in einem Ordner erstellen:

Ok, vielleicht hab ich auch einfach nur zu wenig geschlafen.

Du hast zu wenig geschlafen.

@SeppJ ich werde jetzt nicht alles umgestallten, nur weil die Parameter Expansion in geringen Fällen zu einem total Down-Crash geraten. Mit Bash schießt du dir eh fast überall in den Fuß. Wenn du richtig codest, ziemlich unwahrscheinlich. Bash Skripte gelten getestet zu werden, und ich habe wie gesagt kein Problem damit wenn du entweder dirname oder realpath oder basename als Sanitizer-Funktion bewahrst.

ShredderButtonOn

Nabend.

Es geht wieder um die Eingangsfrage ... So hätte ich mir das vorgestellt (hier eine Java-Snippet). Aber vermutlich ist die folgende Logik für ein bash-Script einfach zu kompliziert ...

    public static void table(String dir, int cols, int overheadAt) {
        File[] files = new File(dir).listFiles();
        assert files != null;
        int n1 = files.length / cols;
        int n2 = files.length % cols;
        String[][] table = new String[n1 + n2][cols];
        for (String[] a : table) {
            Arrays.fill(a, " ".repeat(10));
        }
        for (int i = 0; i < overheadAt; i++) {
            for (int j = 0; j < n1; j++) {
                String s = getString(files, n1 * i + j);
                table[j][i] = s;
            }
        }
        for (int j = 0; j < n1 + n2; j++) {
            String s = getString(files, n1 * overheadAt + j);
            table[j][overheadAt] = s;
        }
        for (int i = overheadAt + 1; i < cols; i++) {
            for (int j = n2; j < n1 + n2; j++) {
                String s = getString(files, n1 * i + j);
                table[j - n2][i] = s;
            }
        }
        for (String[] a : table) {
            System.out.println(Arrays.toString(a));
        }
    }

    private static String getString(File[] a, int i) {
        return a[i].getName().substring(0, 10);
    }

Ich wüsste jedenfalls nicht, wie das geschickt in Bash möglich wäre...