On 2012/11/21 00:49, Lars von den Driesch wrote: > Hi again, > > On Sat, Nov 17, 2012 at 11:56 PM, Lars von den Driesch > <larsvondendrie...@gmail.com> wrote: > > >> Here's a diff, which needs the attached cd-discid port. I've patched > >> it to use id3tag from audio/id3lib for now, eyed3 could be ported > >> separately if wanted (though that requires python, so it might be > >> better to just mention it as an option rather than force the > >> dependency). > > I finally came around to test this. It worked pretty well so far. > Thanks for the patch! > The only thing I haven't solved yet are problems with german "umlauts" > like (öäü) in the resulting files. I have set LC_CTYPE to use > en_US.UTF-8 and I see the correct output of CDDB (with all special > characters) in my xterm but the files created on the disk have broken > names like: "Alles im gr??nen Bereich" or "Ich schmei?? mein Auto auf > den M??ll.mp3" > > I haven't spend much time in reading about this yet - but is it > possible that OpenBSD filesystem doesn't support this?
This is just ls's output. ls(1) replaces the characters that make up the UTF-8 multibyte sequences with ?, but you can use the colorls package instead. Some people alias ls=colorls. (Charset/locale support is limited; in general the standard system tools don't really handle it; in some cases substitutes are available from ports e.g. you'll find a UTF-8 capable nvi there) > P.S: Interesting behaviour using ssh connection to my OpenBSD from > MacOSX Terminal. Executing 'ls -la' gives me the broken output above > while using tab-completion gives me the correct output "Alles\ im\ > grünen\ Bereich". Maybe MacOSX is doing some umlaut-magic here? > Can anybody give me a pointer where to look? tab-completion in /bin/ksh will display the characters in a UTF-8 terminal (e.g. uxterm or rxvt-unicode), but the shell doesn't really handle this; if you try and delete a multibyte character it will only remove part of that character from the input buffer.
