Summary of the 2008-03-11 Packaging Committee meeting

Toshio Kuratomi a.badger at gmail.com
Fri Mar 14 12:42:54 UTC 2008


Alexander Boström wrote:
> tor 2008-03-13 klockan 09:41 -0500 skrev Toshio Kuratomi:
>> Ralf Corsepius wrote:
> 
>>> Transliterate/translate them to ASCII.
>>>
>> This is a proposal I am strongly -1 to.
> 
> Ok, then allow the full Unicode range in Name:.
> 
> But a decision needs to be made. Should it be possible to do all command
> line system management with only knowledge of the basic latin character
> set? Or even: Should it be possible to do all command line system
> management with _no_ knowledge if the latin character set? (That would
> mean transliterating "yum" and "ls".)
> 
> Probably the answers are "yes" and "uhm, perhaps if someone figures out
> how".
> 
> Then the output of the command line tools (rpm -q, yum list, ls *.rpm
> etc.) needs to be such that everyone who can type the command can also
> manually copy the output from the screen to the keyboard. The command
> can of course show several names, at the same time or using different
> options.
> 
I keep reading what you are asking here but have yet to find an 
interpretation that I can think reasonable.  So let me give you my 
thoughts  and then maybe we can meet in the middle.  The questions:

1) Should the default command-line system administration commands use 
filenames that are ASCII only?

2) Should we be able to transliterate or translate those commands so 
they can be invoked from the command line using non-ASCII scripts.

My answers are yes dependent on a sensible definition of "command-line 
system administration commands" and no.

For 2 (being easier), I consider a command line application like yum or 
ls to be named by their invocation on the commandline.  To transliterate 
those is once again falling into the trap of transliterating a proper 
noun akin to my passport example (Should a passport transliterate 
Ivan-John-Johann-Juan-Jean).

For 1, system commands need to be usable to all of our users.  Taking 
the lowest common denominator of ASCII makes sense.  Note that this 
question is intentionally different than your question #1 in several ways:

1) This applies only to the command name, not to data files or other 
things on the system.  /bin/ls should be ASCII but the filenames it 
displays should be able to span the range of unicode.

2) This is not for every command name but only for "system 
administration commands".  Once you get to the level of a desktop user, 
there are valid uses for unicode.  And invalid uses are likely to have 
alternatives (Hate typing that unicode string to invoke your bittorrent 
client?  Choose a different client).

> So you still need to provide those ASCII names somehow. The only
> alternatives to transliteration I can see are serial numbers of some
> kind, lots of '\xxx' in strings or punycode (xn-collier-fonts-9gb).
> 
'\xxx' is what I would think is correct but we already have the 
capability to display this in our command line tools.  Are you proposing 
that instead of naming something with a unicode name and letting our 
tools display the code points for that when we ask them that our 
filenames are all escape sequences and our tools decode those to 
unicode?  That just seems backwards to me.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080314/3988059c/attachment-0002.bin 


More information about the devel mailing list