SOURCES: monodoc.desktop (NEW) - desktop file

[Andrzej Krzysztofowicz]

=?iso-8859-2?Q?Pawe=B3?= Sakowski wrote:
> 
> > Jakichs? Nietrudno sie domyslic jakich.
> > Zreszta wystarczy sobie sprobowac ustawic LANG=pl_PL w jaks z-UTF-izowanym
> > RH/Fedorze, sprobowac polaczyc sie z dowolnym _innym_ systemem wspierajacym
> > standardowe locale pl_PL (w iso-8859-2)
>   ^^^^^^^^^^^
> Wolę określenie "klasyczne".
> 
> >  i stwierdzic, ze polowa rzeczy nie
> > dziala jak powinna pomimo poprawnej konfiguracji.
> > W dsuga strone jest podobnie.
> 
> Zgoda, w tej sytuacji można się spodziewać problemów. Ale powodem
> problemów nie jest to, że ktoś sobie ustawił lokale według uznania.
> Powodem jest to, że na dzień dzisiejszy połowa programów pod Linuxem
> zakłada utopijną sytuację, że istnieje wzajemnie jednoznaczne
> odwzorowanie pomiędzy ciągami oktetów i ciągami znaków. Nic bardziej
> mylnego.
> 
> Przykłady: SSH/Telnet przesyłają w te i wewte oktety, nie znaki. W
> protokole FTP nazwa plików jest de facto ciągiem oktetów. Gdyby ktoś

Jezeli tak jest, to trzeba nad tym przejsc do porzadku dziannego dopoki sie
nie wprowadzi rozszerzenia "standardow".

> chciał ściągnąć sobie FTP-em plik Paweł.txt to co ma wysłać serwerowi?
> RECV Pawe\xc5\x82.txt? RECV Pawe\xb3.txt? Nie wiadomo. 

Problem w tym, ze czesto to, co chcemy ogladac to SA ciagi bajtow, dla
ktorych pojecie kodowania nie ma sensu.
I wkurza mnie, ze jesli sobie zazycze pod RH:

less -f /bin/bash

to less probuje dane _interpretowac_ jako UTF (jeslis taki ekspert, to
powiedz, co nalezy ustawic, zeby tego _nie robil_ (chce widziec
niezinterpretowane znaki)). Terminal, ktorego uzywam nie wspiera UTF.
Albo jeszcze lepiej:

# less -fr /bin/zsh
Segmentation fault

Podobnie w X-ach, ktore lokalnie nie wspieraja UTF. Wprowadzajac nowe
standardy trzeba zakladac jakas forme zgodnosci wstecz. Inaczej taki
standard mozna OKDR.

> Twórcy języków programowania mają swój wkład w mylenie pojęć "bajt" i
> "znak". W C/C++ pod nazwą char ukrył się typ liczby całkowitej
> 8-bitowej. W Javie niewiele lepiej: liczba całkowita 16-bitowa.
> strlen(const char*) zwraca liczbę, która może mieć niewiele wspólnego z
> długością ciągu znaków. Tak powstaje cała masa programów które nie
> umieją współpracować z użytkownikami znającymi ponad 256 znaków.

Ale nie mozna w tym momencie nadinterpretowac i zakladac, ze "string" =
"ciag znakow".

> Kończę, bo zaraz w depresję popadnę. Tym niemniej, widać powolną
> tendencję do normalizacji: GTK+2 jest w stanie przetwarzać pełną paletę
> znaków unikodowych. Format plików XML zawiera deklarację kodowania
> pliku, w przeciwieństwie do HTML-a (spóźnione dokładanie nagłówków HTTP
> się nie liczy).

-- 
=======================================================================
  Andrzej M. Krzysztofowicz               ankry w mif.pg.gda.pl
  phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math.,   Gdansk University of Technology