verzeichnisse+unterverzeichnisse auslesen?

N

ngpunkt

Mitglied
. . .
 
Zuletzt bearbeitet:
ähm, dann hast du aber nicht richtig geguckt.
alleine hier im forum gibt es tausend threads dazu!

irgendwo hier habe ich mal ein rubyscript dazu gepostet, falls es auch was anderes als sh sein darf.


ciao
 
Probier mal ls -R oder schau dir denn Befehl dir an.
 
Wenns keiner außer mir sagt, dann sag ichs halt.

find
 
So isses:

Code:
kalle@hoppers:~> alias

[...]

alias dir='ls -l'

Ich finde das auch reichlich überflüssig.
 
find durchsucht doch komplett alles. durchsuchen brauch ich aber nicht, einfach nur auflistung. ok, das auflisten ginge natürlich auch, aber mich interessieren nur die verzeichnisse bei der etwas sehr großen musik sammlung (ergo die artist > alben struktur)
tree -d erfüllt da schon mehr die aufgabe

Och das kann find mit sed auch. ;)
Code:
find ./ | sed -e 's![^/]*/!+++!g;s/+++/ &|/g'

Gruß Wolfgang
 
find durchsucht doch komplett alles. durchsuchen brauch ich aber nicht, einfach nur auflistung. ok, das auflisten ginge natürlich auch, aber mich interessieren nur die verzeichnisse bei der etwas sehr großen musik sammlung (ergo die artist > alben struktur)
tree -d erfüllt da schon mehr die aufgabe
Meinst du zufällig "finde nur Verzeichnisse"?
Code:
find . -type d
Das man aber auch immer alles explizit erwähnen muss. Und ich hab jetzt hier kein tree installiert, aber wenn es eine Ausgabe wie "pstree" nur halt für Verzeichnishierarchien produziert, dann wäre das parsen dieser Ausgabe im Kontext eines Shellskripts a royal pain in the ass. Den output von find kann man direkt weiterverwenden.. Auch die Ausgabe von "ls -R" scheint erstmal "geparst" werden zu wollen, sprich einfaches Iterieren über Dateinamen ist damit auch nicht straight forward möglich.

Ich kenne "dir" btw eigentlich auch nur aus winDOS Zeiten, aber hier (ubuntu) scheints ein wirkliches Programm (und kein Alias/Wrapperscript) zu sein. Aber die manpage schaut der von ls extrem ähnlich, und ich vermute mal ganz feist, dass die einfach noch eine "ls" binary unter dem Namen "dir" ins System gepackt haben, um cmd.exe Menschen ein wenig unter die behaarten Arme zu greifen. Aber dann wiederum:
Code:
md5sum /bin/{dir,ls}
b6f0b5e8e78461f224dc778954490334  /bin/dir
96fa54ba1486bdc462a7052848c43dee  /bin/ls
Also es ist schonmal nicht exakt das gleiche.. (Was sowieso Schwachfug gewesen wäre, weil ein alias völlig ausgereicht hätte..)
Code:
dir --version
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software.  You may redistribute copies of it under the terms of
the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
There is NO WARRANTY, to the extent permitted by law.

Written by Richard Stallman and David MacKenzie.

edit: (ohne wirkliches edit) ein wenig lange geschrieben :(
 
Hm, bei meiner SuSE gibt es sowohl das alias als auch die Anwendung 'dir' incl. mapage. Wenn ich 'dir' aus meinen aliassen herauswerfe, verhält sich der Befehl auch anders als das alias-dir (allerdings auch nur minimal anders als 'ls'). *etwasverwirrt* - Wozu das alles? :)
 
Mal wieder "SuSE ist ja so anders und hält sich nicht an Standards"-Tag?

Ja, es ist mal wieder absolut typisch, daß die "Wir machen alles anders DAU-Distiri" SuSE mal wieder aus der Reihe tanzt.

Obwohl, mindestens etwas ..... bei SuSE liegt "dir" zumindest in /usr/bin und nicht z.B. in /bin, wo es ja wohl nach einhelliger Meinung kaum etwas zu suchen hätte, oder?

Da gehören nur *NIX-eigene Sachen hin und nur absolute "Kernanwendungen" (das meiste in /bin/ findet sich auch in Paketen wie coreutils, bash&Co, iputils usw. also absoluten Basispaketen wieder), richtig?

Also hat "dir" auf einem ordentlichen Linux eigentlich gar nichts zu suchen und schon zweimal nicht in /bin ....

Code:
which dir ls
/usr/bin/dir
/bin/ls

cat /etc/*release
openSUSE 10.2 (i586)
VERSION = 10.2
LSB_VERSION="core-2.0-noarch:core-3.0-noarch:core-2.0-ia32:core-3.0-ia32"

(Eine Bitte an alle "reine Lehre"-Debilianer .. macht es nicht bei Euch, es könnten Tränen fliessen .....)
 
Zuletzt bearbeitet von einem Moderator:
Ich finde schon, dass SuSE sich (abgesehen vom KDE-Pfad, der mit KDE4 jedoch auch "standardisiert" wird) recht eng an Dinge wie die FSH und dergleichen hält - dementsprechende Vorurteile kommen meist von Leuten, die sich eh nicht an SuSE annähern mögen und sind somit ziemlich uninteressant.

Nur wozu einerseits 'dir' im System ist (ein für sich offenbar ziemlich verzichtbares Beinahe-Plagiat) und selbiges per alias gewissermaßen deaktiviert wird, verstehe ich nicht so ganz.

Ups, es wird OT...
 
Der Sinn hinter der Geschichte ist mir auch nicht präsent, aber zumindest sind da alle Distries, die ich hier "griffbereit" habe, praktisch gleich "sinnlos".

Code:
rpm -qf $(which dir)
coreutils-6.4-10

(openSUSE 10.2)

dpkg -S $(which dir)
coreutils: /bin/dir

(Debian Lenny)

pacman -Qo $(which dir)
/bin/dir ist in coreutils 6.11-1 enthalten

(Archlinux)
Wobei letztere beide allerdings keinen alias (ls -l) für "dir" anlegen und somit dieses direkt ausgeführt wird.
 
hier und hier ein wenig Aufklärung. Scheint wohl eher GNU zu sein, die dafür "verantwortlich" sind.. (Also gleiche sourcen, fast exakt gleiches Verhalten, ...)
Also ich finds recht sinnfrei. Aber nunja, dafür gibts so viieel tolles gnu-Zeugs und außerdem nutzt dir ja eh keiner. Aber was haben die sich bloß dabei gedacht? Hm..
 
Zumindest müsste das "Umbiegen" des Installationspfades unter SUSI (nach /usr/bin/dir statt nach /bin/dir) dafür sorgen, daß stattdessen der alias "dir s -l" zum Zuge kommt, weil /bin vor /usr/bin in $PATH liegt und deshalb zuerst augerufen wird.

Man könnte natürlich auch gleich "dir" aus coreutils entfernen, aber das macht man wohl bei so einem zentralen Paket eher nicht, egal wie "sinnvoll" die Anwendung erscheint.

(Das ist aber reiner Spekulatius, auch wenns zum Wetter nicht passt)
 
dir war IMHO seit Sarge in den coreutils.
Da ich Suse nie wirklich benutzt habe (mal eine Stunde oder so vor Jahren), ist mir der alias auch unbekannt.
Aber so manch tools sind mit gleichen Funktionen ausgestatten, ohne einen Sinn zu brauchen. Standardstreit in einschlägigen News: rmdir.
Nutze ich auch nie, mir reicht da rm -r.

Gruß Wolfgang
 
rmdir braucht kein Mensch und ich kann mir auch nicht vorstellen welchen Vorteil das haben soll. rmdir kann nur leere Verzeichnisse löschen afaik und was soll das sich da erst mühsam mit rm durch den Verzeichnisbaum eines entpackten tar-balls zu hangeln wenn das mit rm -rf ./blah schneller geht.
 
rmdir braucht kein Mensch und ich kann mir auch nicht vorstellen welchen Vorteil das haben soll.

@codc

Oh doch, ich kenne einige Admins die nur so arbeiten.

Soll heißen:

Code:
cd /usr/local/nagios
rm -fr etc/* # auch nagios hat ein etc-Verzeichnis
rmdir etc

Der Grund ist einfach der, das dir kein

Code:
cd /usr/local/nagios
rm -fr [COLOR="Red"]/[/COLOR]etc/

passieren kann.

Und sowas kann jedem mal passieren, mit den bekannten fatalen Folgen.
 

Ähnliche Themen

Perl Zeilen Auslesen(logdatei) und auswerten

Rekursives Ersetzen

Samba Server funktioniert nach Installation von Nextcloud 26 nicht mehr

df -h anpassen für Auswertung

Zeilen auslesen und anderer Stelle wieder einfügen

Zurück
Oben