LANG, locale, unicode, and Debian packaging

"Martin v. Löwis" martin at
Sun Jan 13 14:17:17 CET 2008

> I guess I'm confused by that. I can ls them, so they appear and thus have 
> characters displayed. I can open and cat them and thus the O/S can access 
> them, but I don't know whether their characters are strictly in ascii-limits 
> or drawn from a larger set like unicode. I mean, I have seen Japanese 
> characters in filenames on my system, and that can't be ascii.
> You see, I have a large collection of fonts going back over 10 years and they 
> came from usenet years ago and so have filenames mangled all to hell.

If you can all ls them, and if the file names come out right, then
they'll have the same encoding.

> I can't always *type* some of their names and have to use copy/paste to, for 
> example, ls one of them.
> Again, it's working from ignorance (my own) : I assume filenames in different 
> countries will be in character sets that I have never (nor will I ever) see. 

I never heard before that font files use non-ASCII file names, and I
don't see the point in doing so - isn't there typically a font name
*inside* the font file as well, so that you'd rather use that for
display than the file name?

Of course, *other* files (text files, images etc) will often use
non-ASCII file names. However, they won't normally have mixed
encodings - most user-created files on a single system should typically
have the same encoding (there are exceptions possible, of course).

>> If the user has set up his machine correctly: yes.
> Meaning, I am led to assume, the LANG variable primarily?



More information about the Python-list mailing list