Hallo Stefan, Am Mittwoch, 31. Januar 2001 21:07 schrieb Stefan Troeger:

Hi,

On Wed, Jan 31 2001 at 21:28 +0000, Rolf Scheurer wrote:

...

In einem Verzeichnis befinden sich über 30000 Dateien. Die Dateinamen sind ALLE in Großbuchstaben. Das ist aber alles falsch, es müssen ausschliesslich Kleinbuchstaben sein. (Dateien wurden mit Windows-Client auf Netware-Server zwischengelagert, dabei ist das Malheur passiert, das Emoticon dazu spare ich mir und Euch, weil's inzwischen verboten ist...)

mmv "*" "#l1"

danke für den Tip. Ich habe ich zwar im Subject vertan (Danke Thomson), vermute aber, dass Du mein Problem verstanden hast. Habe das Paket derzeit nicht installiert, vermute aber dass das kleine "L" für "lower case" steht. In der Hoffnung, dass das auch irgendwie rekursiv klappt werde ich das Paket morgen mal installieren und testen. Wenn's klappt knutsch' ich Dich bis Du schielst ;-) Bye, Rolf (Ich glaub', mir ist die leere Antwort schon mal rausgeflutscht, sorry an Alle)

sollte helfen (evtl. musst Du das Paket mmv nachinstallieren).

SCRN! On Fre, 02 Feb 2001, Jan Trippler wrote:

On Don, Feb 01, 2001 at 08:36:23 +0100, Joerg Thuemmler wrote: Damit's rekursiv wird: for dn in `find . -type f -print`; do dnn=`dirname $dn`/`basename $dn | tr '[A-Z]' '[a-z]'` test "$dn" = "$dnn" || mv $dn $dnn done

Argl. Ich hasse Backticks. Die machen das so schnell unuebersichtlich! Besonders wenn's mehrstufig wird... \'`a '\'b\''`\' oder so. *g* for alt in $(find . -type f); do # -print ist default neu="$(dirname $alt)/$(basename $alt | tr '[A-Z]' '[a-z')" test "$alt" = "$neu" || mv "$alt" "$neu" done Wenn man gleichzeitig noch Leerzeichen durch _ ersetzen will kann man das prima mit einbauen: neu=" ... /$(basename ${alt// /_} | tr ...)" Und noch ein "Trick" (siehe 'man bash', nach '\$\{p' suchen), der zumindest in manchen Faellen funktioniert: $(basename $foo) = ${foo##*\/} $(dirname $foo) = ${foo%\/*} Wow (mussich mir merken): $ time for i in `seq 999`; do echo $(basename $f) >/dev/null; done real 0m10.623s $ time for i in `seq 999`; do echo ${f##*\/} > /dev/null; done real 0m0.170s $ time for i in `seq 999`; do echo $(dirname $f); done real 0m11.955s $ time for i in `seq 999`; do echo ${f%\/*}; done real 0m0.209s CU David, immer wieder begeistert vom der bash :) --

Blame directed at the wrong vendor tends to get reclassified as whining. No worries, I'm good at that too. -- Chris Hacking and Jay Mottern in asr

Hallo, On Sam, 03 Feb 2001, Peter Blancke wrote:

On Sat, 3 Feb 2001, David Haller wrote:

...

On Fre, 02 Feb 2001, Jan Trippler wrote:

...

On Don, Feb 01, 2001 at 08:36:23 +0100, Joerg Thuemmler wrote: Damit's rekursiv wird: for dn in `find . -type f -print`; do dnn=`dirname $dn`/`basename $dn | tr '[A-Z]' '[a-z]'` test "$dn" = "$dnn" || mv $dn $dnn done

[...]

for alt in $(find . -type f); do # -print ist default neu="$(dirname $alt)/$(basename $alt | tr '[A-Z]' '[a-z')" test "$alt" = "$neu" || mv "$alt" "$neu" done

Wenn man gleichzeitig noch Leerzeichen durch _ ersetzen will kann man das prima mit einbauen:

neu=" ... /$(basename ${alt// /_} | tr ...)"

Oder die Leerzeichen gleich in den obigen Ausdruck eingebaut. Bei mir demonstriert das folgender Befehl einwandfrei:

find . -type f -exec echo {} \ | tr '[A-Z ]' '[a-z_]' ^. Stuempt! :) `- da fehlt ein ';', scnr. Aber das '-exec echo' ist eh ueberfluessig. Ein "find . -type f | tr '[A-Z ]' '[a-z_]'" tut's auch.

...

CU David, immer wieder begeistert vom der bash :)

Ja!!! Solche Konstruktionen an einem verschneiten Samstag Morgen sind eine wahre Wohltat!

*g* Jup. 'man bash' als 'Gute Nacht'-Lektuere, dazu ein Bierchen als Schlummertrunk und Pink Floyd's "Atom Heart Mother" als Begleitmusik :) *räkel* *schnurr* David --

Was willst Du denn "tunen"? Wahrscheinlich Platten tieferlegen, Prozessorspoiler montieren, die Leiterbahnen im DRAM aufbohren, einen verchromten Prozessorlüfter anbringen, Fuchsschwanz am PCI-Bus, einen Doppelvergaser auf der Grafikkarte installieren und einen Turbolader für die Netzwerkkarte installieren. [Florian Weimer und Ralph Angenendt in dcoum]

On Sam, Feb 03, 2001 at 10:07:18 +0100, Ralf Corsepius wrote:

David Haller wrote: [bash only scripts] Argl, ich hasse nicht portable Bash-Scripte am Samstagmorgen, die mit Bourneshell-Skripten nur noch am Rande zu tun haben. :)

...

David, immer wieder begeistert vom der bash :) Man merkt's :)

Im Gegensatz zum ersten, sehr sauberen Lösungsvorschlag, sind deine Vorschläge hochgradig unportabel, da sie auf bash-proprietären Features basieren.

Danke *g* Das ist immer wieder der Grund, warum ich statt $() die `` benutze. Aber wenn man nicht auf Portabilität angewiesen ist, dann ist Davids Lösung natürlich genauso anwendbar (und schneller, da keine externen Kommandos, sondern nur bash-Interna genutzt werden). Man darf sich nur nicht wundern, wenn's auf einem anderen System nicht mehr klappt. Es zeigt sich also wieder mal: 1. Es gibt immer mehrere Lösungswege 2. Persönlicher Geschmack spielt eine große Rolle 3. Die vorzuziehende Lösung richtet sich immer nach den Schwerpunkten, die man setzt (Portabilität vs. Performance z. B.) 4. Ich finde es immer wieder schick, wenn für ein Problem mehrere Lösungswege eintrudeln, das hält den Blick offen ;-) Amen Jan

David Haller wrote:

Hallo,

On Sam, 03 Feb 2001, Jan Trippler wrote:

...

On Sam, Feb 03, 2001 at 10:07:18 +0100, Ralf Corsepius wrote:

...

David Haller wrote: [bash only scripts] Argl, ich hasse nicht portable Bash-Scripte am Samstagmorgen, die mit Bourneshell-Skripten nur noch am Rande zu tun haben. :)

Besser als verkorkste DOS-Batches/WSH-Scripts an einem verregneten Montagmorgen, oder?

Jep.

Ich schreib ja auch immer schoen brav '#!/bin/bash' in die erste Zeile. In einem heterogenen Netzwerk kann man sich nicht darauf verlassen, dass die Bash überhaupt vorhanden ist, und wenn ja, wo sie liegt. Auf Nicht GNU-basierten Systemen wird sie in der Regel dort nicht zu finden sein, wenn überhaupt, dann unter /usr/bin, /usr/local/bin, /opt/bin oder ganz wo anders :)

...

...

...

David, immer wieder begeistert vom der bash :) Man merkt's :)

*g*

...

...

Im Gegensatz zum ersten, sehr sauberen Lösungsvorschlag, sind deine Vorschläge hochgradig unportabel, da sie auf bash-proprietären Features basieren.

Ist denn die Bash selbst nicht portabel? (scnr)

Weitgehend, aber * Es gibt tatsächlich Systeme, da lässt sie sich nicht übersetzen. * Sie ist schlichtweg zu gross/langsam (Beispiel: Unter Cygwin kommt deshalb die ash als /bin/sh zum Einsatz) * Sie war in der Vergangenheit als nicht übermässig stabil und sicher bekannt (und wird deshalb von vielen Sysadmins nicht systemweit installiert).

s/proprietären/spezifischen/ Die csh und zsh und was weiss ich fuer welche Shells habe sicher aehnliche Features. Ja, klar. Es spricht auch nichts dagegen, diese Features local, für den persönlichen Gebrauch oder für ein bestimmtes System auszunutzen. Nur sollte man sich im klaren sein, das die bash unter fast allen Linux-Systemen als /bin/sh verwendet wird, es sich bei /bin/sh im Allgemeinen aber nicht um die bash handelt.

...

Das ist immer wieder der Grund, warum ich statt $() die `` benutze. Aber wenn man nicht auf Portabilität angewiesen ist, dann ist Davids Lösung natürlich genauso anwendbar (und schneller, da keine externen Kommandos, sondern nur bash-Interna genutzt werden). Man darf sich nur nicht wundern, wenn's auf einem anderen System nicht mehr klappt.

Ack! Ich versuche grad das portablen, aber nervig langsamen 'mktexpk' (und darin verwendete) sh-Scripte in (wohl unportable aber deutlich schnellere) bash-Scripte umzuscheiben... Der Aufwand rentiert sich meiner Meinung nach nicht, da der Zeitaufwand für die unterlagerten Tools den Zeitaufwand der Shell um mehrere Großenordnungen übersteigt.

Anstatt auf die Bash zu setzen würde ich dann gleich eine richtige Scriptsprache verwenden (z.B. perl, python o.ä.). Die sind auf keinen Fall überall installiert, und wenn doch, dann deutlich portabler und ähnlich schnell wie Bash-Skripte.

Gar nicht so einfach, das [1].

Tja, schau dir mal die autoconf Quellen und die autoconf Doku im Detail an. Sie stecken voller Tricks und Hinweise auf portable Shellprogrammierung :)

...

Es zeigt sich also wieder mal: 1. Es gibt immer mehrere Lösungswege 2. Persönlicher Geschmack spielt eine große Rolle 3. Die vorzuziehende Lösung richtet sich immer nach den Schwerpunkten, die man setzt (Portabilität vs. Performance z. B.) 4. Ich finde es immer wieder schick, wenn für ein Problem mehrere Lösungswege eintrudeln, das hält den Blick offen ;-) Weitgehendes ACK.

Der aus meiner Sicht entscheidende Punkt steckt in 3. versteckt: Es kommt darauf an, welche Anwendung man zum Ziel hat. Es gibt Anwendungen da sind bash Scripte OK (z.B. Linux-Bootscripte, oder zum persönlichen Gebrauch unter Linux), in anderen Fällen nicht (configure, generel anwendbare Skripte). Wenn es um Portablität geht, gibt es bessere Mittel als die Bash, IMHO. Ralf

On 04-Feb-01 Volker Mueller wrote:

Die csh ist fuer die bash das, was die sh fuer die tcsh ist. Nein. Die sh ist fuer die csh, was fuer bash tcsh ... Nein. Die bash ist fuer sh csh tsch zischhh ... *grmpf* Jedenfalls ist die zsh die Obermenge davon.

Ich glaube, hier muß man mal ein bisschen was erklären :-). Es gibt historisch 2 wichtige Shell-Familien (im Prinzip kann man auch perl oder mc als Shell benutzen wenn man will, aber das ist eher eine exotische Konfiguration) Die eine Familie ist die bourne-/Korn-Shell-Linie sh / ksh / bash In der Reihenfolge sind die Dinger auch ziemlich weitgehend abwärtskompatibel und haben eine ähnliche Syntax. Daneben gibts die Linie, die von der C-Shell (csh) abstammt, hier ist der wichtigste Vertreter die tcsh. Die jeweils "aktuellen" Vertreter mit großer Verbreitung sind bash und tcsh, die vom Funktionsumfang her ungefähr gleich mächtig sein dürften. Traditionell benutzen Systeme aus dem BSD-Stammbaum (z.B. OpenBSD) als Standard-Shell oft einen Abkömmling der csh-Linie, Systeme aus der System V Linie (z.B. Tru64) eher einen Abkömmling der sh/ksh-Linie. Beide Shell-Linien unterscheiden sich vor Allem durch die Syntax. Die csh spricht traditionell eher die Programmierer an, während die ksh von der Philosophie her mehr den Anwender im Visier hat, allerdings sind diese Ausrichtungen heute schon stark verwischt. Daneben gibts noch ne ganze Latte nicht so verbreiteter Shells, die sich zum Teil auch an speziellere Zielgruppen richten. Zum Beispiel ash. Und die zsh als Versuch, einen weiteren Schritt zu setzen, hat sich aber auch noch nicht auf breitester Ebene etabliert. -- Erhard Schwenk http://www.fto.de - http://www.akkordeonjugend.de No Spam replies please.