gelöst: verzeichnisse vergleichen

[Huck Fin]

Moin,
ich möchte /mnt und /home vergleichen.
Alle Dateien, die in /home fehlen möchte ich mit Pfad auflisten.
in etwa so

Code: Alles auswählen

/home/daten/xy.txt
/home/daten/zz.abc

Ich stehe da irgendwie auf dem Schlauch.

mit diff bekomme ich

Code: Alles auswählen

Nur in /b/x: xy.txt

mit find klappt das nicht besser...

Jemand ne idee ?

[Meillo]

Wenn du die fuer Menschen gemachte Ausgabe von `diff -rq /mnt /home' nicht mit `sed' nachfiltern willst, dann kann man das auch (wunderbar old-style) so machen:

Code: Alles auswählen

find /mnt | sort >files-mnt
find /home | sort >files-home
comm -23 files-mnt files-home

[Huck Fin]

den "comm" hatte ich gar nicht mehr auf dem Schirm.


Kleines Problem gibt es noch...

Code: Alles auswählen

ZIEL1=/mnt/
ZIEL2=/home/
find $ZIEL1 |sort  >Q.txt
find $ZIEL2 |sort  >Z.txt

Ergebniss
Q.txt

Code: Alles auswählen

/mnt/
/mnt/daten

Z.txt

Code: Alles auswählen

/home/
/home/daten

Da ist mit comm -23 jede Zeile anders
Wie kann ich das /mnt und /home entfernen ?

[tobo]

Da ist mit comm -23 jede Zeile anders
Wie kann ich das /mnt und /home entfernen ?

Exklusive dem / (kein absoluter Pfad):

Code: Alles auswählen

ZIEL1=/mnt/
ZIEL2=/home/
find "$ZIEL1" | sed 's#^/mnt/##' | sort >Q.txt
find "$ZIEL2" | sed 's#^/home/##' | sort >Z.txt

[Meillo]

Wie kann ich das /mnt und /home entfernen ?

Alternativ so:

Code: Alles auswählen

(cd /mnt && find . | sort) >files-mnt
(cd /home && find .| sort) >files-home
comm -23 files-mnt files-home

[tobo]

Ja, das ist besser und schöner. Den . beim find könnte man auch noch gleich entsorgen.

[Huck Fin]

Da waren jetzt noch Verzeichnisse als Eintrag.
Ich versuch mal das hier...

Code: Alles auswählen

(cd $ZIEL1 && find -type f |sort) >Q.tx1
(cd $ZIEL2 && find -type f |sort) >Z.tx1

[tobo]

Da waren jetzt noch Verzeichnisse als Eintrag.
Ich versuch mal das hier...

Code: Alles auswählen

(cd $ZIEL1 && find -type f |sort) >$DIR1/$TTT-Q.tx1
(cd $ZIEL2 && find -type f|sort) >$DIR1/$TTT-Z.tx1

Nur der Vollständigkeit halber, es wird vermutlich keinen Unterschied machen (bei ZIEL1/2 nicht, bei DIR1 und TTT unklar) - du solltest Variablen bei der Benutzung grundsätzlich Quoten, wenn nichts dagegen spricht:

Code: Alles auswählen

(cd "$ZIEL1" && find -type f |sort) >"$DIR1/$TTT"-Q.txt
(cd "$ZIEL2" && find -type f |sort) >"$DIR1/$TTT"-Z.txt

[Huck Fin]

Habe es geändert.
Und doch, es hat geholfen mit -type f ...

[Meillo]

Den . beim find könnte man auch noch gleich entsorgen.

... nur bei GNU find, nicht aber auf anderen Unixen, wie dem FreeBSD, vor dem ich gerade sitze.

https://pubs.opengroup.org/onlinepubs/9 ... /find.html
https://man.freebsd.org/cgi/man.cgi?que ... .2-RELEASE

[JTH]

... nur bei GNU find, nicht aber auf anderen Unixen, wie dem FreeBSD, vor dem ich gerade sitze.

Ah, deshalb beschwert sich ShellCheck also ständigmanchmal

Noch als Ergänzung: Das Wechseln in die beiden zu durchsuchenden Ordner könnte man mit passendem -printf umgehen:

Code: Alles auswählen

find "$ZIEL1" -type f -printf '%P\n' | sort >"$DIR1/$TTT"-Q.txt
find "$ZIEL1" -type f -printf '%P\n' | sort >"$DIR1/$TTT"-Z.txt

Ob das ne GNU-Extension oder posix-konform ist, hab ich jetzt nicht nachgeguckt

[Meillo]

Noch als Ergänzung: Das Wechseln in die beiden zu durchsuchenden Ordner könnte man mit passendem -printf umgehen:

Code: Alles auswählen

find "$ZIEL1" -type f -printf '%P\n' | sort >"$DIR1/$TTT"-Q.txt
find "$ZIEL1" -type f -printf '%P\n' | sort >"$DIR1/$TTT"-Z.txt

Ob das ne GNU-Extension oder posix-konform ist, hab ich jetzt nicht nachgeguckt

Weder in der POSIX-Beschreibung noch in der FreeBSD-Manpage findet sich ein `-printf'.

[JTH]

Tss

[Meillo]

Tss

... vergleichen wir doch mal die Befehlslaengen:

Code: Alles auswählen

( cd "$ZIEL1" && find -type f . | sort )
find "$ZIEL1" -type f -printf '%P\n' | sort

Sogar wenn ich ueberall Spaces setze, ist der old-style Befehl noch kuerzer. Die Minimal-Space-Variante ist noch mehr kuerzer:

Code: Alles auswählen

(cd "$ZIEL1"&&find -type f .|sort)
find "$ZIEL1" -type f -printf %P\\n|sort

... und da sind beim old-style Befehl sogar noch die zwei Zeichen fuer den Punkt dabei.


Nachtrag: Nichts fuer ungut, JTH. Befehlslaengen sind ja egal, solange der Code lesbar ist. Subshells sind fuer die heutigen User nicht mehr so gebraeuchlich, wie damals, als man noch Tar-Pipes verwendet hat ... da war die Subshell mit cd noch ganz normal. Die `-printf'-Option von GNU find ist manchmal wirklich praktisch, insofern ist der Hinweis darauf durchaus hilfreich.

[chrbr]

Jetzt kann ich mir es doch nicht verkneifen. mtree-netbsd ist sehr gut zum Vergleichen von Pfaden usw, um dann gewünschte Aktivitäten anzustoßen. Auf den ersten Blick schaut es allerdings etwas ungewöhnlich aus.

[JTH]

mtree-netbsd

Ahh, noch mehr BSD

Nichts fuer ungut, JTH.

Ich hab das schon nicht falsch verstanden Ich weise einfach gerne auf Alternativen hin. Ob (GNU) find die Suchergebniss nicht direkt ohne den Suchort ausgeben kann, war vorhin nur ein Gedanke. Da das tatsächlich der Fall war, musst ich das dann auch hier erwähnen.

Sogar wenn ich ueberall Spaces setze, ist der old-style Befehl noch kuerzer.

Hmm, weniger zu tippen ist ein starkes Argument. Ich kann nur noch kontern, dass die Variante mit cd eine Subshell mehr benötigt … was mit der anschließenden Dateisuche natürlich nicht ins Gewicht fällt.

Subshells sind fuer die heutigen User nicht mehr so gebraeuchlich,

Benutz ich natürlich auch heute noch Gelegentlich auch mal für den an anderer Stelle ungewollten Effekt eines isolierten (Variablen-) Scopes.

[tobo]

Den . beim find könnte man auch noch gleich entsorgen.

... nur bei GNU find, nicht aber auf anderen Unixen, wie dem FreeBSD, vor dem ich gerade sitze.

https://pubs.opengroup.org/onlinepubs/9 ... /find.html
https://man.freebsd.org/cgi/man.cgi?que ... .2-RELEASE

Der zusätzliche Punkt bringt zwar keinen um, trotzdem macht es durchaus Sinn, dass hier übliche System zu verwenden, sofern nichts anderes gefordert wird. Habe oder bediene ich z.B. ein POSIX-System, dann darf ich kein max/mindepth benutzen...

[JTH]

trotzdem macht es durchaus Sinn, dass hier übliche System zu verwenden, sofern nichts anderes gefordert wird.

Es könnte ja ein Debian kFreeBSD sein – gut, das hätte immer noch ein GNU-Userland.

[Meillo]

OT:

Der zusätzliche Punkt bringt zwar keinen um, trotzdem macht es durchaus Sinn, dass hier übliche System zu verwenden, sofern nichts anderes gefordert wird. Habe oder bediene ich z.B. ein POSIX-System, dann darf ich kein max/mindepth benutzen...

Im Falle von max/mindepth nutze ich bewusst ein Feature, das nur eine bestimmte Implementierung anbietet. Damit binde ich mich zwangslaeufig an diese Implementierung. Die Alternative waere nur, das Problem auf ganz anderem Weg zu loesen, so dass ich das Feature nicht brauche. In manchen Faellen gibt es einen gleichwertigen portableren Weg, dann finde ich es sinnvoll, die portablere Variante zu nutzen, weil man sich damit nichts vergibt. Gibt es keine gleichwertige portablere Variante, dann bindet man sich halt an die jeweilige Implementierung.

Nachteilig fuer das Oekosystem freie Software finde ich dabei ggf. den Aspekt, dass alternative Implementierungen benachteiligt werden. Je oefters beispielsweise die Datumsfunktionserweiterungen von gawk genutzt werden, desto mehr User ersetzen ihren mawk durch gawk ... bis irgendwann nur noch gawk genutzt wird. Das sorgt fuer eine Zentralisierung von Macht, Deutungshoheit und Fehlerrisiko, die IMO dem Oekosystem schadet.

Im Falle des Punktes ist es aber ein anderer Fall, denn hier gewinnt man kein Feature, sondern verliert fuer ein winziges Bisschen Bequemlichkeit die Kompatibilitaet. Das erscheint mir unnoetig.

Hierzu moechte ich eine kleine Geschichte erzaehlen:

`grep RE foo' sucht in der Datei foo. `grep RE' sucht im Standardinput. `grep -r RE bar' sucht rekursiv unterhalb vom Verzeichnis bar. Aber was tut `grep -r RE'?

`grep -r' ist nicht Teil von POSIX, darum ist es nicht standardisiert, folglich tun verschiedene Implementierungen moeglicherweise Unterschiedliches. Und so ist es auch. Ein modernes GNU grep sucht in dem Fall rekursiv im aktuellen Verzeichnis. Das ist ein durchaus sinnvoller Fall, aber er fuehrt zu Problemen, die aus meiner Sicht vermeidbar waeren und besser haetten vermieden werden sollen.

Frueher hat GNU grep ohne Dateiargument naemlich im Standardinput gesucht, egal ob `-r' angegeben war oder nicht. Das ist auch das was BSD grep tut. Inhaltlich macht es keinen Sinn `-r' anzugeben und in stdin zu suchen, darum wohl hat GNU grep irgendwann diesen Fall geaendert. Die Folge: Vor gut einem Jahr sitze ich mal an einem alten Debian und suche rekursiv in einem riesigen Verzeichnis die Nadel im Heuhaufen ... ich warte und warte und das rekursive grep wird nicht fertig ... konnte es auch nicht, da es nie im Verzeichnis gesucht hat, sondern auf Eingabe von stdin gewartet hat.

Im Vergleich zu einem einzigen solchen Fehler im Leben, finde ich das explizite Eingeben von einem Punkt, wenn man das aktuelle Verzeichnis meint, fuer vernachlaessigbar billig -- Zeit, Frust und Denkleistung sparend.

Die Loesung bei FreeBSD finde ich am besten: Dort gibt grep eine Warnung aus, wenn man `-r' ohne Dateiargument verwendet:

Code: Alles auswählen

$ grep -r RE
grep: warning: recursive search of stdin

Wuerde man `find' heute neu entwerfen, dann haette es eine gewisse Logik, es ohne Dateiargument aufrufbar zu machen. Andererseits wiederum muss man auch sehen, dass `find' ein spezielles, irregulaeres Aufrufdesign hat, das es von anderen Tools unterscheidet. Kann man das Konzept des Aufrufdesigns dann immer noch mit einem Satz erklaeren oder verkompliziert man es, indem man eine Sonderregel hinzufuegt? Um die Tools zu beherrschen, muessen wir ja nicht nur Switches auswendig lernen, sondern auch das Aufrufkonzept jedes Tools. Bei den meisten ist es einheitlich, aber jeden Sonderfall (dd, tr, find, ...) muessen wir uns separat merken. Eine Aenderung, die fuer Gelegenheitsuser etwas bequemer zu sein scheint, wird so ein bisschen zusaetzliche Komplexitaet fuer das Gesamtsystem. Das widerspricht Unix insofern, dass dort eine moeglichst niedrige Gesamtkomplexitaet und ein moeglichst einfaches Verstaendnis aller Dinge ein zentrales Ziel waren.

Wie man sieht, ist so ein Punkt fuer mich keine Kleinigkeit, sondern es oeffnet sich eine ganze Welt dahinter.



@tobo: Ich weiss, dass wir bei diesen Dingen teilweise unterschiedliche Ansichten und einen unterschiedlichen Fokus haben. Das ist in Ordnung so. Dieser Post ist auch nicht an dich gerichtet geschrieben, sondern an die interessierten sonstigen Mitleser, als Anstoss fuer ein paar eigene Gedanken.