-> (LINUX) Dateien ohne endungen verschieben

[Aquariophile]

Hallo!

Derzeit räume ich grad meinen Computer auf
und Brenne dann die Daten weil ich morgen auf Debian wechsle.

Beispiel fürs aufräumen:

mv *.mp3 /daten/mp3
mv *.dat /daten/dat
mv *.txt /daten/txt

Das System ist klar? *g*

Gut, Problem:
Ich habe VIELE Files ohne Endung! (meistens notizen)

Wie kann ich die reinbekommen?
*.[endung] geht ja in dem Fall nicht?

Eventuell eine REGEXP spielerei?

Bitte um Hilfe!

Danke!
Aquariophile

[Bio]

Sup!

Tja, so Dateien haben noch ein paar Merkmale mehr, die helfen könnten, z.B. könnte das Datum der Erstellung helfen meist sind die eigenen Dateien später erstellt als die mitgelieferten - oder, Du bastelst ein Skript, daß die Ausgabe des "file" Befehls auswertet und dann Dateien kopiert oder nicht.

Ob das bis morgen geht, ist natürlich die Frage, evtl. solltest Du Deine Dateien einfach mal besser zusammenhalten oder so.

Gruesse,

Bio

[Michael Schröpl]

Hi,

Beispiel fürs aufräumen:
mv *.mp3 /daten/mp3
mv *.dat /daten/dat
mv *.txt /daten/txt
Das System ist klar? *g*

Ich halte das für ganz schlecht.

Ich habe nie verstanden, wieso die UNIX-Methode, Dateien gleichen Typs und völlig unterschiedlicher Bedeutung zusammen zu fassen, nur um damit dann irgendwelche PATH-Mechanismen mit kürzeren Werten füttern zu können, Sinn machen würde.

Ich habe VIELE Files ohne Endung! (meistens notizen)
Wie kann ich die reinbekommen?
*.[endung] geht ja in dem Fall nicht?

1. Diese Dateien würden nach der Verschiebung aller Dateien _mit_ Endung automatisch übrig bleiben - Du mußt also nicht versuchen, sie explizit zu erkennen (was aber auch nicht schwer wäre).

2. Da Du nicht angegeben hast, inwiefern Du diese Dateien dann unterschiedlichen Ablageorten zuordnen möchtest, halte ich Deine Aufgabenstellung für unterspezifiziert.

Viele Grüße
      Michael

P.S.: Dir ist bekannt, daß ein Dateiname ggf. auch mehr als einen Punkt enthalten darf?

[Sven Rautenberg]

Moin!

Ich habe nie verstanden, wieso die UNIX-Methode, Dateien gleichen Typs und völlig unterschiedlicher Bedeutung zusammen zu fassen, nur um damit dann irgendwelche PATH-Mechanismen mit kürzeren Werten füttern zu können, Sinn machen würde.

Ist keine Unix-Methode. Zumindest keine mir bekannte. Und der Unix-Dateibaum faßt Dateien nach ihrem Sinn zusammen, nicht nach ihrer Endung. In "/etc" stehen z.B. Konfigurationsdateien, keine *.etc-Dateien.

1. Diese Dateien würden nach der Verschiebung aller Dateien _mit_ Endung automatisch übrig bleiben - Du mußt also nicht versuchen, sie explizit zu erkennen (was aber auch nicht schwer wäre).

Richtig. Ich persönlich würde ja auch immer ganze Verzeichnisse verschieben, und Dateien nur dann sortieren, wenn sie irgendwie durcheinandergekommen sind. Insofern ist das Sortiermuster etwas unbefriedigend.

P.S.: Dir ist bekannt, daß ein Dateiname ggf. auch mehr als einen Punkt enthalten darf?

Das ist aber für die bereits angegebene Bewegungsoperation irrelevant, die paßt auf alles, was viele Punkt und sonstige Zeichen hat, und am Ende eben die passende Endung. :)

- Sven Rautenberg

[Michael Schröpl]

Hi Sven,

Ich habe nie verstanden, wieso die UNIX-Methode, Dateien
gleichen Typs und völlig unterschiedlicher Bedeutung
zusammen zu fassen, nur um damit dann irgendwelche PATH-
Mechanismen mit kürzeren Werten füttern zu können, Sinn
machen würde.

Ist keine Unix-Methode. Zumindest keine mir bekannte.
Und der Unix-Dateibaum faßt Dateien nach ihrem Sinn
zusammen, nicht nach ihrer Endung. In "/etc" stehen z.B.
Konfigurationsdateien, keine *.etc-Dateien.

"Endung" habe ich auch nicht gemeint.
Aber daß man durch Konzepte wie $PATH praktisch dazu gezungen wird, Produkte auf viele Verzeichnisse zu verstreuen und sich dann in /usr/local/bin Kraut und Rüben ansammeln, das widerstrebt mir zutiefst.

P.S.: Dir ist bekannt, daß ein Dateiname ggf. auch mehr
als einen Punkt enthalten darf?
Das ist aber für die bereits angegebene Bewegungsoperation
irrelevant, die paßt auf alles, was viele Punkt und sonstige
Zeichen hat, und am Ende eben die passende Endung. :)

Ich meinte nur, daß aufgrund dieser Eigenschaft ggf. der Begriff der "Endung" unterspezifiziert sein könnte.

Viele Grüße
      Michael

[Kai Lahmann]

hi

Aber daß man durch Konzepte wie $PATH praktisch dazu gezungen wird, Produkte auf viele Verzeichnisse zu verstreuen und sich dann in /usr/local/bin Kraut und Rüben ansammeln, das widerstrebt mir zutiefst.

dafür haben Unix-User nie das Problem "und wo finde ich das Programm jetzt" - ein Programm, egal wie es heißt - ist eben immer einfach da. Warum sollte man - wie unter Windows - Libraries, Programme, oft auch noch Config-Files und sogar Nutzerdaten oder zumindest Dokumentvorlagen alle an einer Stelle zusammenballern? Damit ist dann eine lib eigentlich gar nicht als lib nötig - kommt ja eh kein anderes Programm ran.

[Michael Schröpl]

Hi Kai,

dafür haben Unix-User nie das Problem "und wo finde
ich das Programm jetzt" - ein Programm, egal wie es
heißt - ist eben immer einfach da.

Vorausgesetzt, irgendwer hat ihnen ihr .profile oder .cshrc oder .bashrc oder wie auch immer richtig gesetzt.

Warum sollte man - wie unter Windows - Libraries,
Programme, oft auch noch Config-Files und sogar
Nutzerdaten oder zumindest Dokumentvorlagen alle
an einer Stelle zusammenballern?

Weil sie zusammen gehören (ausgenommen die Nutzerdaten).
Ich trenne zwischen der Produktinstallation (möglichst readonly) und den Benutzerdaten (sicherlich nicht readonly).

Einerseits kann ich dann ein Programm problemlos deinstallieren; andererseits kann ich eine Installation problemlos sichern.
Außerdem kann ich eine Installation eines Programm sehr einfach über eine Netzwerk exportieren - und zwar nur genau dieses eine Programm für genau diese eine Plattform!
(Du hast vermutlich noch keinen Fileserver betrieben, bei dem die Clients unterschiedliche UNIX-Versionen verwendeten, die zueinander _nicht_ binärkompatibel waren? Ich schon, bei AIX 3.1 und 3.2 ...)

Das "automatisch gefunden werden" löse ich anders.
Ich installiere Programme nach Möglichkeit in separate Verzeichnisse (z. B. "/usr/local/products/gcc") und setze dann in /usr/local/bin eine Reihe von symbolic links auf die einzelnen Programme aus /usr/local/products/gcc/bin".
Das gemeinsame PATH-Verzeichnis /usr/local/bin enthält in diesem Falle _ausschließlich_ symbolic links - und diese wiederum sind über die Pfadangabe zum entsprechenden Produkt-Verzeichnis selbsterklärend. Ich sehe also auf den ersten Blick für jedem Eintrag, zu welchem Produkt er gehört.

Viele Grüße
      Michael