• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Wieviele Files in nem Directory?+Gibts Enviroment-Variablen?

Deepblue

Member
Hallo,

Bestimmt gehts ganz einfach nur bin ich wieder zu blöd...

Ich hab zb /media/mp3s und möchte ganz einfach wissen wieviele Mps3 nun in dem Ordner sind. Wie stellt man das am schnellsten (also ohne grossartig Systemressourcen zu beanspruchen) fest?

Gibts da irgendwas, ich würde das gern in ein Pythonscript einbauen für mein Superkarambatheme.

Desweiteren gibts irgendwie sowas wie unter MS-DOS, also Umgebungsvariablen? Ich müsste generell nur 2 Stringwerte speichern und will die nicht extra immer auf die Festplatte speichern. Wenn ja wie setzte ich diese Werte bzw wie lese ich sie aus?

Evtl kann mir ja jemand helfen, danke schonmal :)
 

andreasw

Member
Die Anzahl bestimmst du z. B. so:

Code:
find -type f | wc -l

dazu musst du den Befehl im selben Verzeichnis ausführen, oder du gibst find einen Pfad als Parameter mit.

Umgebungsvariablen werden mit der Bash so gesetzt.

export BLA="wert"

in der Bash kannst du dann mit $BLA darauf zugreifen.

mfg

Andy
 
A

Anonymous

Gast
Deepblue schrieb:
Desweiteren gibts irgendwie sowas wie unter MS-DOS, also Umgebungsvariablen?
Ja dat jibbet.
Eine Umgebungsvariablen aus einer laufenden Shell kannst du dir zum Beispiel so setzen.
Code:
cd /media/mp3s ; export ANZAHL=`ls -1 | wc -l`
In der Umgebungsvariablen 'ANZAHL' ist dann das Ergebnis gespeichert, das du dir dann folgendermassen anschauen kannst.
Code:
echo "$ANZAHL"
Auf diese Umgebungsvariablen kannst du dann von einem Script zugreifen.
Beim schliessen der Shell ist auch die Variable weg............ wenn dauerhaft benötigt, dann musst du sie in der '.profile' oder '.bashrc' in deinem Home erzeugen. Oder Systemweit in der '/etc/profile'.

Gruß...
 
OP
Deepblue

Deepblue

Member
Danke schonmal, werd ich nacher gleichmal austesten. Das Kommando von dir untersützt es auch rekursive Suchen? Weil ich net alles in einem Verzeichnis drinhabe, manche Mp3s sind auch nach Alben sortiert in Unterordnern
 

TeXpert

Guru
den find-Befehl würde ich noch mit -name "*.[mM][pP]3" eingrenzen, falls da auch noch mal Playlists oder Coverbilder mit drinliegen

bei der Version mit dem ls hast Du Problemchen bei dem Rekursiven zählen, ls -lR produziert zwar eine Rekursive Ausgabe, aber mit zusätzlichen Verzeicnisinformationen zwischen allen Dateien, auch bekommst Du hier Probleme mit der Einschränkung auf MP3s. Da müsste dann noch ein grep mitlaufen, also ein

Code:
ls -1RF | grep .[mM][pP]3 | wc -l
und ob das schneller als ein Find-Konstrukt ist weiß ich nicht.

daher würde ich das mit einem
Code:
ANZAHL=`find /mnt/mp3archiv -name "*.[mM][pP]3" -type f | wc -l`
machen
 

regexer

Advanced Hacker
TeXpert schrieb:
Code:
ls -1RF | grep .[mM][pP]3 | wc -l
und ob das schneller als ein Find-Konstrukt ist weiß ich nicht.
Habe es gerade mit einem großen Verzeichnis ausprobiert. Der find ist schneller. Das liegt meines erachtens am doch recht lansamen grep. Was ich aber an deinem ls- Vorschlag verbessern würde:
1. Den Punkt beim grep entwerten und ein Dollarzeichen hinten anfügen. Sonst findet dieser z.B. auch die Zeile Klassik_mp3_neu.
2. "grep -c ..." geht etwas schneller als "grep ... | wc -l". Trotzdem wird dein find die beste Lösung bleiben.
3. Nur zur Information: Der Parameter -1 muss beim ls nicht angegeben werden, wenn die Ausgabe "gepipet" wird. In diesem Fall ist er also redundant. Aber ich neige auch zu Redundanz. Und manchmal wiederhole ich mich auch :wink:
 

TeXpert

Guru
zu 1. stimmt! gutes Argument :)
zu 2. wenn man auf den RegEx mit groß und Kleinschreibung verzichtet, wäre u.u. auch grep -f noch etwas schneller
zu 3. ack :)

aber bei der Geschwindigkeit: das Problem ist hier der Plattencache, der das u.u. verfälscht, so dass hier die Reihenfolge Unterschiede produzieren kann, d.h. bei dem ersten Lauf des Suches werden alle Dateien gefunden und gecached, beim 2. müssen die dann nicht mehr gesucht werden, sondern es kann schneller drauf zugegriffen werden, so dass dieser Vergleich problematisch ist
 
Oben