LC_CTYPE: ISO-8859-2 vagy ISO8859-2

Újabb nagy diadala a szabványoknak és az együttműködésnek: egyik unix így szereti, a másik meg amúgy... Ha én meg ssh-ból megyek egyikből a másikba (vö: SendEnv és AcceptEnv), akkor vagy jó lesz a másikfajta, vagy nem. Hirtelen ennyit tudok javasolni megoldásként:

http://web.axelero.hu/lzsiga/ekezet.html#Q0094

20140127.1003: És ehhez egy kis kiegészítés

http://web.axelero.hu/lzsiga/ekezet.html#Q0096

( hrgy84 | 2014. 03. 25., k – 12:31 )

Ki kell dobni a locale valtozokbol az encodingot, a hu_HU locale-nak az ISO 8859-2 -es szabvany az alapertelmezese, az UTF-8 -hoz explicite ki kell irni (ebben viszont tenyleg van vita, hogy UTF-8 vagy utf8).
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Az sem rossz ötlet... (Off: Még azt kellene egyszer kipróbálni, mi történne, ha unixhoz csinálna valaki windows-1250-es codeset-et: megsemmisülne a világegyetem, vagy csak a mi galaxisunk?)

Szerk (2018-06-06 12:38): működik, lásd itt: http://lzsiga.users.sourceforge.net/ekezet.html#Q0177

Nem vagy te veletlenul kicsit fiatalka? CWI-1, CWI-2, iso-8859-2 (vagy jobb hijjan iso-8859-1), meg ugye a CP852 (meg cp850), meg a CP1252, meg a. Meg a. Szoval nem lehet kidobni belole. Ha a rendszer haklis, akkor kezelje le legalabb a nagyjabol hasonlokat valami aliasing mechanizmussal. (Remlik, h FreeBSD-n tudja kotojellel, alahuzassal, kis es nagybetusen - egyebkent maga az X is ilyen. De van valami altaluk preferalt *is*.)
Volt olyn is, ahol egyebkent ISO_8859-2 volt ha jol emlekszem.
Amugy pedig en ugy olvastam valamelyik FBSD forumon/levlistan, hogy az UTF-8 a szabvanyos (azaz kotojellel, nem pedig kotojel nekul.)

Elegge el nem itelheto modon pontosan ismerem a felsorolt karakterkodolasokat - fiatal korom ellenere. Ezzel egyutt Linuxon a hu_HU locale alapertelmezett kodolasa az ISO 8859-2 -es szabvanyara epit. De ahogy tapasztaltam, Free es NetBSD eseten is hasonlo a helyzet.

UTF-8: igen, ez a szabvanyos. Viszont en peldaul Fedoranal futottam bele abba, hogy a hu_HU.UTF-8 locale konkretan ismeretlen volt neki, nem tudta, mit kezdjen vele. At kellett irnom hu_HU.utf8 -ra, hogy egyaltalan valami ertelmes kimenet jojjon ki belole.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

( uid_7086 | 2014. 03. 25., k – 15:07 )

És akkor még tedd hozzá, hogy az Oracle-ben meg az Hungarian_Hungary.ISO8859P2 a "szabvány"! ;)
(lehet, hogy végig nagybetű kellene? Vagy mindegy? Erre már nem emlékszem)

Ezt tőled nem vártam. Pontsan azért van language_TERRYTORY annak a nyavalyának az elején, hogy épelméjű módon le lehessen írni ezeket a baromságokat, hogy brit angol meg ausztrál angol meg amerikai angol: en_UK, en_AU, en_US. Hasonló logika alapján le lehet írni a svájci németet meg a svájci franciát is. Szóval összefoglalva: az american_America baromság, mert legrosszabb esetben (értsd: nem tartják be, hogy kétbetűs ISO-kódokkal írják le a nyelvet és az országot) is english_America kéne legyen

Valóban. Kb mint a palóc és a székely magyarja. Azaz brit angol meg amerikai angol. De attól még angol. A nyelv (főnév). És amerikai (melléknév).
Leginkább azért, mert az american_america ilyen erővel lehetne épp spanyol. Vagy portugál. Vagy Kanadából kiindulva francia.

Pontosan. Mondjuk az amerikai angollal kapcsolatban az én tapasztalatom az, hogy:

- vannak a közismert különbségek (mint ugye lift/elevator, autumn/fall)
- és van az amerikaiaknak egy nyegle egyszerűsítő irásmódja. De az meg kb simán lekezelhető azzal, mint amikor valaki itthon egy fórumot próbál megérteni, vagy egyszerűen csak hibás helyesírásúnak tekintjük a dolgokat (night / nite) (Mondjuk amit az utóbbi években brit angoloktól tapasztaltam írásilag, az nem tekinthető komoly statisztikai mintának, de hanyatlanak ők is az írásban :-) )

Szóval én nem nagyon érzem úgy, hogy akkora baromira nagy lenne az eltérés, főleg nem írásban.

Off: Szerintem legjobb az eredeti állapotában hagyni, különben gyorsan oda jutunk, hogy az eredeti rendszerüzenet helyett a fordító félreértéseiből próbálunk tájékozódni.

De pl. van külön olyan, hogy NLS_DATE_FORMAT, abba érdemes beletenni, hogy YYYYMMDD.HH24MISS

(ide is leírtam, hogy megmaradjon)

( NevemTeve | 2014. 03. 26., sze – 17:54 )

Most éppen ott tartunk, hogy kellően modern bash esetén az előbbi javító script-részlet használhatatlan, mivel a bash át sem veszi az ssh-tól a "hibás" változókat... köszönjük, Emese!

Szerk: ezt most nem tudom reprodukálni, nyilván elnéztem valamit: ad hibaüzenetet, de azért beállítja a változót... akkor én bénáztam.... mondjuk a 'locale' parancs kimenetét néztem, nem az 'echo $LC_CTYPE'-ét

Szerk: attól függ, hogy a sshd debug-ban megy-e, vagy batch-ként...

Szerk: Oké, ez a bejegyzés most végig bénázás volt a részemről;)