tree(1) für arbiträre Daten

[paedubucher]

Ich habe vorhin wieder einmal bemerkt, wie schön übersichtlich doch die Ausgabe von tree(1) ist:

Code: Alles auswählen

$ tree
.
├── archetypes
│   └── default.md
├── config.toml
├── content
├── data
├── layouts
│   └── index.html
├── static
└── themes

Sowas könnte ich gelegentlich auch in Dokumenten gebrauchen, jedoch nicht für Dateien, sondern für beliebige Hierarchien. Ich würde gerne sowas eingeben:

Code: Alles auswählen

- C
    - C++
- Smalltalk
- Erlang
    - Elixir
- Basic
- Fortran

Und dann sowas erhalten:

Code: Alles auswählen

├── C
│   └── C++
├── Smalltalk
├── Erlang
│   └── Elixir
├── Basic
└── Fortran

Ein lustiger Unix-Hack wäre es natürlich, die obige Datenstruktur tatsächlich im Dateisystem unter /tmp zu erstellen, und dann effektiv tree(1) darauf zu verwenden. Andererseits sollten die Strings auch Sonderzeichen enthalten können, ohne mühsames hin- und herescapen.

Hat jemand eine Idee? Ich habe gerade nicht den Kopf, das Ding selber auszuprogrammieren.

[JTH]

Ein lustiger Unix-Hack wäre es natürlich, die obige Datenstruktur tatsächlich im Dateisystem unter /tmp zu erstellen, und dann effektiv tree(1) darauf zu verwenden.

Das ist schnell ausprobiert, passt ja auch zum alles-ist-eine-Datei-Motto

Code: Alles auswählen

$ cat treeprint 
#!/bin/sh
set -eu

cleanup()
{
	rm -fr "$tmpdir"
}

if [ $# -lt 1 ]; then
	echo "missing arguments" >&2
	exit 2
fi

tmpdir=$(mktemp -d)
trap cleanup EXIT INT TERM
cd "$tmpdir"

title=${1:-.}
shift
mkdir -p "$title"
for str in "$@"; do
	mkdir -p "$title/$str"
done

tree -a --noreport "$title"

Code: Alles auswählen

$ ./treeprint "Programming Languages" C C/C++ Smalltalk Erlang Erlang/Elixir Basic Fortran 
Programming Languages
├── Basic
├── C
│   └── C++
├── Erlang
│   └── Elixir
├── Fortran
└── Smalltalk

Um Sonderzeichen kann man sich kümmern, wenn ein Problem auftaucht Ein einzelner Eintrag kann so natürlich keinen Schrägstrich enthalten, nur als Unterteilung in der Hierarchie.

[eggy]

oder gleich in awk

Code: Alles auswählen

awk '{ s=index($0, "-"); l = substr($0, s +2 ); s2=s; printf "|"; while (s>0) {printf " "; s--;} ; if (s2 > 2){ printf "└" }; t=4;   while(t>0){printf "-";t--;}; print l}' datei.txt

... weder hübsch noch perfekt, nur mal als proof-of-concept

Code: Alles auswählen

| ----C
|     └----C++
| ----Smalltalk
| ----Erlang
|     └----Elixir
| ----Basic
| ----Fortran

wenn man mehr Zeit reinstecken will: vorne noch nen hübsches Zeichen einfügen und auch lieber mitzählen, in welcher Verschachtelungstiefe man ist, bzw die Leerstellen von Regechsen fressenlassen ... Meillo findet da sicher ne hübschere Variante

[paedubucher]

Wow, funktioniert beides!

@JTH: Die Idee mit dem Slash für die Hierarchie ist natürlich super. Wenn man da in der richtigen Datenstruktur denkt, hat man das Problem ja schon fast gelöst!

@eggy: Mit ein paar gut gewählten Zeichen für die Linien funktioniert das auch prima!

[JTH]

oder gleich in awk

Wird ja auch mal wieder Zeit

[reox]

tree kann auch sowas:

Code: Alles auswählen

INPUT OPTIONS
       --fromfile  Reads  a directory listing from a file rather than the file-system.  Paths provided on the command line are files to read from rather than directories to search.  The dot (.) directory
       indicates that tree should read paths from standard input.

Code: Alles auswählen

$ cat test.txt
C
C/C++
Smalltalk
Erlang
Erlang/Elixir
Basic
Fortran
$ tree --fromfile test.txt
test.txt
├── Basic
├── C
│   └── C++
├── Erlang
│   └── Elixir
├── Fortran
└── Smalltalk

2 directories, 5 files

oder so:

Code: Alles auswählen

$ echo "C C/C++ Smalltalk Erlang Erlang/Elixir Basic Fortran" | tr ' ' '\n' | tree --fromfile .
.
├── Basic
├── C
│   └── C++
├── Erlang
│   └── Elixir
├── Fortran
└── Smalltalk

2 directories, 5 files

kA ob man sich da noch mit dem IFS spielen kann

[Meillo]

Das ist schnell ausprobiert [...]

oder gleich in awk

Ich bin stolz auf auch!

... dann lehne ich mich mal weiter zurueck.

[eggy]

tree kann auch sowas:

@reox: So geht das aber gar nicht. Wo kommen wir denn da hin, mein lieber, einfach nen Programm für etwas benutzen, für dass es gedacht ist?! Was fällt Dir denn ein?!?

[Meillo]

@reox: Klasse! ... damit hast du nun JTH und eggy in die Tasche gesteckt.

[paedubucher]

Wow, --fromfile habe ich leider verpasst. Ausgerechnet die letzte Option, die in der Manpage auftaucht, da war meine Aufmerksamkeitsspanne wieder mal zu kurz

[JTH]

Ich bin ja ein bisschen überrascht über diesen neumodischen Featurebloat mit --fromfile. Wie war das mit dieser Philosophie von wegen ein Werkzeug, eine Aufgabe und die gut gelöst? Da muss man ja gar nichts mehr kombinieren und selbst lösen

Meine Lösung kann immerhin ohne extra Aufwand den . an der Wurzel mit Sinnvollerem ersetzen!

[Meillo]

Die Option scheint recht neu zu sein. Version 1.6 hat sie noch nicht, in 1.8 ist sie da.

Ich finde schon, dass sie immer noch der One-Tool-one-Task-Idee entspricht, denn tree(1) erzeugt eine grafische Darstellung von Verzeichnisbaeumen. Das passiert auch wenn die Verzeichnisbaeume von woanders herkommen.

Aber ich habe dennoch meine Kritik an der Umsetzung des Usecases. Hier der Abschnitt in der Manpage:

INPUT OPTIONS
--fromfile Reads a directory listing from a file rather than the file-
system. Paths provided on the command line are files to read from
rather than directories to search. The dot (.) directory indicates
that tree should read paths from standard input.

Erstens: Warum wird hier `.' verwendet wenn von stdin gelesen werden soll und nicht `-', wie es Konvention ist?

Zweitens: Warum braucht es hierfuer eine eigene Option und man nutzt nicht die Kommandozeilenargumente dazu? Tree kann bereits mehrere Pfadangaben auf der Kommandozeile bekommen. Warum uebergibt man nicht einfach jede Zeile der Inputdatei als Kommandozeilenargument? Dazu kann man tree dann auch so aufrufen:

Code: Alles auswählen

tree `cat infile`

Tree duerfte dann nur nicht mit einem Fehler aussteigen, wenn es den Pfad nicht gibt. (Dafuer koennte man eine Option einfuehren.) Mit so einem Ansatz haette an der Arbeitsweise von tree gar nichts geaendert werden muessen.

Drittens: Wenn man schon ein Uebergeben der Pfade aus einer Datei einbaut, warum verhaelt sich das dann nicht identisch zum Uebergeben der Pfade als Kommandozeilenargument? (Im einen Fall fuehren nicht-existente Pfade zu Fehlern im anderen Fall nicht.)

An diesen Stellen faengt die Featuritis an, deren schlimmste Folge ist, dass die konzeptionelle Klarheit verloren geht. Es sieht auf den ersten Blick halt immer so einfach aus, so eine Funktion einzubauen; erst ueber die Zeit zeigen sich die negativen Folgen.

[reox]

Ich hab das auch erst jetzt in der manpage gesehen und war ehrlich gesagt auch etwas verwundert über die Funktionsweise...

Es ist seit 1.8.0 drin und der changelog sagt:

Code: Alles auswählen

 Added an experimental --fromfile option (suggested by several people.) This may eventually be replaced or supplimented by a --fromjson option. 

Vermutlich ist es deshalb so komisch...
Ich glaube das mit dem . erklärt sich so: Es wird als verzeichnis dann der dateiname angegeben. Vermutlich wollen sie das Verhalten eines aufrufs von tree simulieren, wenn man keine argumente angibt und wollen aber nicht - in ein . umschreiben...

[Meillo]

Zeit um eine bessere Umsetzung einzureichen ...?

[eggy]

@Meillo: s/komischercode/exec(awk) ?

[reox]

Zeit um eine bessere Umsetzung einzureichen ...?

der hat ja nicht mal git - da muss man ja ne mail schreiben
oder gibts irgendwo den source von tree in versionskontrolle? Auf der offiziellen Seite hätte ich nur tarballs gesehen

[Meillo]

Zeit um eine bessere Umsetzung einzureichen ...?

der hat ja nicht mal git - da muss man ja ne mail schreiben

Ist mir persoenlich deutlich lieber als die Projekte, die nur Github haben und mit denen man ohne einen Github-Account ueberhaupt keinen Kontakt aufnehmen kann.

Ausserdem ist er als Entwickler nett. Hab da schon mal einen Bugfix eingereicht.

oder gibts irgendwo den source von tree in versionskontrolle? Auf der offiziellen Seite hätte ich nur tarballs gesehen

Debian hat ein Repo fuer die Paketerstellung: https://salsa.debian.org/debian/tree-packaging
(Das findet man ueber die Paketseite, klick auf Developer Information, dann kommt man auf den Debian Package Tracker und dort ist das Repo dann links unter VCS verlinkt.)

[reox]

Ist mir persoenlich deutlich lieber als die Projekte, die nur Github haben und mit denen man ohne einen Github-Account ueberhaupt keinen Kontakt aufnehmen kann.

Ja, nur in diesem Fall wäre es halt schön sich nur die Änderungen betreffend --fromfile ansehen zu können. Allerdings scheint die ganze Magie eh nur in file.c zu liegen: https://salsa.debian.org/debian/tree-pa ... bfcbbce382