Re: Umlautproblem, nicht trivial

From: Polytropon <freebsd(at)edvax.de>
Date: Tue, 20 Mar 2012 12:43:10 +0100

On Tue, 20 Mar 2012 12:22:08 +0100 (CET), Oliver Fromme wrote:
> Polytropon <freebsd(at)edvax.de> wrote:
> > Oliver Fromme wrote:
> > > Ich hatte durchaus schon Dateien mit anderen diakritischen
> > > Zeichen und Ligaturen im Namen (ç, æ, ï, ñ, ...). Mein
> > > Skript lässt die diakritischen Zeichen einfach weg bzw.
> > > löst die Ligaturen auf. Das mag nicht in jeder denkbaren
> > > Sprache die korrekte Umschreibung sein, aber für meine
> > > Zwecke genügt das vollkommen.
> >
> > Mit Ersetzung kann man recht viel machen, solange es
> > ein "Stammzeichen" (ñ -> n) oder eine Ersetzung (ö -> oe)
> > gibt. Bei nicht-so-europäischen Sprachen wird das schon
> > schwierig.
>
> Da ich diese Sprachen nicht spreche, ist mir das sowas von
> egal.

War's mir bisher auch, bis ich Dateien namens "Klotz Klotz
Klotz Klotz Klotz" oder ????? aus China bekam. Da weiß man
gar nicht, wie man ersetzen soll. :-)

> > > Welches Problem hast Du denn mit Leerzeichen?
> >
> > Das Leerzeichen ist der Parametertrenner. Spätestens
> > in "Quick-&-dirty-Skripten" macht sich das bemerkbar.
>
> Meine Skripte kommen sämtliche damit zurecht, auch wenn sie
> nur mal schnell zusammengezimmert sind. Wenn man mal weiß,
> wie es funktioniert, macht man die Quotes automatisch an
> die richtigen Stellen, ohne nochmal darüber nachdenken zu
> müssen.

Ist sicher eine Lektion, die man mal lernen muß. Mittlerweile
habe ich mich auch dran gewöhnt, immer "..." um Dateinamen
zu machen, das hilft bei den meisten Problemfällen.

> > Der Unterstrich ist angenehmer, man muß\ nicht\ jedes
> > Leerzeichen maskieren "oder sie in" Anführungszeichen
> > einschließen.
>
> Muss ich auch nicht; das macht meine Shell automatisch.

Im Dialogbetrieb kann sogar die "altbackene" C-Shell das.
Sie maskiert " " mit \, oder wenn man mit "U<Tab>" (um
Deinem folgenden Beispiel zu folgen) beginnt, komplettiert
sie und endet mit ".

> > Programme wie XMMS ersetzen die Leerzeichen bei der
> ^^^^^^^^^^^
> (Du meinst hier vermutlich Unterstriche.)

Ja.

> > Titelanzeige beispielsweise wieder durch Leerzeichen,
> > dann sieht es besser aus.
>
> Bist Du sicher? Kann es nicht sein, dass XMMS einfach die
> Tags anstelle des Dateinamens anzeigt? Ich benutze XMMs
> nicht, daher kann ich's nicht sagen.

Bei MP3-Dateien ohne ID3-Tags wird der Dateiname verwendet,
mit "s/_/ /g" in der Anzeige. Unter Options / Preferences /
Options gibt es

        [x] Convert %20 to space
        [x] Convert underscore to space

zum Einstellen. Hab's extra nochmal verifiziert. Das gilt
aber tatsächlich nur für die Playlist- und Wiedergabe-
anzeige. An den Dateinamen selbst wird nichts geändert
(wäre ja noch schöner).

> Ich kenne auch kein
> anderes Programm, das sich so verhält. Weder mein Medien-
> player im Wohnzimmer noch das Küchenradio noch der Radio-
> wecker konvertieren irgendwelche Zeichen. Das würde ich
> mir auch verbitten: Es sollen genau die Zeichen angezeigt
> werden, die da sind. Ab und zu verwende ich ja auch
> bewusst Unterstriche, und die möchte ich dann auch als
> solche sehen und von Leerzeichen unterscheiden können.

Es geht ja nur um die "schöne Anzeige" in der Playliste.
Im Dateiauswahldialog stehen die Dateinamen natürlich 1:1
drin - alles andere wäre ja auch unschön.

> > > Die haben
> > > doch immer den Code 32, egal ob ASCI, ISO-8859 oder UTF.
> > > Ich benutze durchaus Leerzeichen in Dateinamen. Ich finde,
> > > Unterstriche in längeren Dateinamen sehen schrecklich aus,
> > > und bestimmte wortorientierte Edit-Funktionen der Shell
> > > funktionieren dann nicht mehr so gut.
> >
> > Mittlerweile hat beispielsweise Opera gelernt, Ctrl+[<-]
> > und Ctrl+[->] auf _ als Wortgrenzen anzuwenden.
>
> Interessant, Du verwendest Opera als Shell? Cool. :-)

Natürlich, weil ich doch online bin! :-)

> Aber im Ernst. Ich bin (unter anderem) Programmierer und
> verwende Unterstriche in Namen von Variablen, Funktionen
> und so weiter. Die sind Teil des Namens und werden wie
> Buchstaben behandelt, und beim wortweisen Springen und
> Löschen sollen sie auch so behandelt werden. So bin ich
> es gewohnt.

Hmmm... interessanter Ansatz, finde ich gut (da ich die
Unterstriche der KaMehlSchreibWeise vorziehe). Da muß man
wohl wirklich einen professionellen Editor verwenden, um
diese (sinnvolle) Funktion effektiv nutzen zu können.

> > Natürlich
> > hast Du ansonsten recht, daß Editierfunktionen auf solchen
> > Dateinamen etwas unelegant werden. Aber wann editiert man
> > schon mal einen 100stelligen Dateinamen... :-)
>
> Die müssen ja nicht gleich so lang sein.

Im aktuellen Fall (der mir solche Grenzen mal wieder nahe-
gebracht hat) war es so, daß Dateinamen aus Dateiinhalten
automatisch generiert worden sind, und zwar aus einem "Batzen"
Datenwiederherstellungsergebnisse. Statt mit 000383665625238.doc
zu enden, sind inhaltliche Elemente in die neuen Dateinamen
eingeflossen. Leider war das aber für ein ISO-9660-Dateisystem
zu lang.

> Ich habe z.B. Verzeichnisse, die »Urlaub 2011« heißen (mit
> Fotos drin). Das ist nicht 100stellig. Und ich habe nicht
> den geringsten Grund, da auf ein Leerzeichen zu verzichten.
> Das ist lesbar, sieht gut aus und ist noch dazu korrektes
> Deutsch.

Der Computer ist aber englisch! :-)

> > Ein anderer Fall, wo man vorsichtig sein sollte, ist ISO-9660.
> > Mit sehr langen Dateinamen (ebenso wie mit sehr großen Dateien)
> > läßt sich das ISO-Image nicht mehr korrekt aufbauen (mkisofs -J).
>
> Ich brenne nur noch selten Dateien auf CDs oder DVDs.

Bei mir war's leider eine Kundenanforderung. Grund: Ein
USB-Stick wäre zu teuer. (Das typische Gejammer, wenn man
seine "wichtigen Geschäftsdaten" lieblos behandelt, sie
dann weg sind, sie sich wie durch ein Wunder wiederher-
stellen lassen und das noch zum Schnäppchenpreis, aber
trotzdem alles "zu teuer".)

> Und
> wenn, dann verwende ich RockRidge (mkisofs -R oder -r), das
> sich um die ganzen Dateinamen kümmert, oder ich verpacke die
> Dateien in ein Containerformat, oder ich brenne gleich ein
> UFS auf die Scheibe.

Das können die Hanseln in MICROS~1-Land doch wieder nich lesen...
Man hätte tatsächlich eine UFS-DVD oder eine tar-DVD draus
machen können - für _mich_ wäre das die richtige Wahl gewesen.

> Kommt immer auf den Anwendungsfall an.
> Dass es bei Joliet (-J) wieder obskure Einschränkungen gibt,
> ist ja klar, schließlich stammt es von Microsoft. ;-)

Jaja, die Leute wollen das so kompliziert und rückständig. :-)

-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Tue 20 Mar 2012 - 12:43:28 CET

search this site