SOURCES: monodoc.desktop (NEW) - desktop file

[Andrzej Krzysztofowicz]

=?iso-8859-2?Q?Pawe=B3?= Sakowski wrote:
> > > 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".
> 
> True. Trzeba po prostu osobiście dopilnować, żeby na obu końcach używać
> tego samego enkodingu. Nieważne, ISO czy UTF-8 czy US-ASCII.

I wlasnie o to chodzi, ze zeby to osiagnac trzeba dokonywac gimnastyki. Nie
wystarczy samo przeniesienie srodowiska, bo LANG=pl_PL ma to i tu inna
interpretacje. A LANG=pl_PL.ISO88952, pl_PL.ISO_8895_2 itp. niektore systemy 
moga nie rosumiec (moga rozumiec jedna z tych form, kazdy inna).

> > 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:
> 
> Rozumiem, że chcesz, żeby bajty o kodach 0x80-0xff wyświetlał jako ich
> kody a nie znaki spoza US-ASCII?

Nie. Chce, zeby mi wyswietlal zgodnie z ustawionym locale.
 
$ echo $LANG
pl_PL.ISO88952

> LESSCHARSET=ascii less -f /bin/bash

Sprobuj ustawic zmienna PAGER, zeby to tak dzialalo i czego innego nie
popsuc...
 
> Swoją drogą nie rozumiem dlaczego less wprowadza własną zmienną
> LESSCHARSET zamiast używać ustawień locale (które, nawet przy braku
> LESSCHARSET, ignoruje).
> 
> > # less -fr /bin/zsh
> > Segmentation fault
> 
> SOA#1

Pewnie kwestia ustawien.

> > Wprowadzajac nowe
> > standardy trzeba zakladac jakas forme zgodnosci wstecz. Inaczej taki
> > standard mozna OKDR.
> 
> Amen.
> 
> > > 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".
> 
> ?? A co innego?

Ciag bajtow ;)
Przynajmniej dla zgodnosci wstecz...

Dla ciagu znakow (w rozumieniu odp. kodowania) nalezy wprowadzic nowe
pojecie.

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