abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 01:00 | Nová verze

Známý šifrovaný komunikátor Signal od verze 3.30.0 již nevyžaduje Google Play Services. Autoři tak po letech vyslyšeli volání komunity, která dala vzniknout Google-free forku LibreSignal (dnes již neudržovaný). Oficiální binárky jsou stále distribuované pouze přes Google Play, ale lze použít neoficiální F-Droid repozitář fdroid.eutopia.cz s nezávislými buildy Signalu nebo oficiální binárku stáhnout z Google Play i bez Google účtu

… více »
xm | Komentářů: 1
včera 23:14 | Nová verze

Po třech týdnech od vydání první RC verze byla vydána první stabilní verze 17.01.0 linuxové distribuce pro routery a vestavěné systémy LEDE (Linux Embedded Development Environment), forku linuxové distribuce OpenWrt. Přehled novinek v poznámkách k vydání. Dotazy v diskusním fóru.

Ladislav Hagara | Komentářů: 2
včera 17:28 | Bezpečnostní upozornění

Byly zveřejněny informace o bezpečnostní chybě CVE-2017-6074 v Linuxu zneužitelné k lokální eskalaci práv. Jde o chybu v podpoře DCCP (Datagram Congestion Control Protocol). Do linuxového jádra se dostala v říjnu 2005. V upstreamu byla opravena 17. února (commit). Bezpečnostní chyba byla nalezena pomocí nástroje syzkaller [Hacker News].

Ladislav Hagara | Komentářů: 2
včera 15:00 | Zajímavý software

Společnost Valve vydala novou beta verzi SteamVR. Z novinek lze zdůraznit oficiální podporu Linuxu. Další informace o podpoře této platformy pro vývoj virtuální reality v Linuxu v diskusním fóru. Hlášení chyb na GitHubu.

Ladislav Hagara | Komentářů: 0
včera 06:00 | Nová verze

Po necelém roce od vydání verze 0.67 byla vydána verze 0.68 populárního telnet a ssh klienta PuTTY. Podrobnosti v přehledu změn. Řešeny jsou také bezpečnostní chyby.

Ladislav Hagara | Komentářů: 0
21.2. 21:32 | Nasazení Linuxu

Canonical představuje nejnovější verzi chytré helmy DAQRI s Ubuntu pro rozšířenou realitu. K vidění bude příští týden v Barceloně na veletrhu Mobile World Congress 2017.

Ladislav Hagara | Komentářů: 0
21.2. 21:31 | Pozvánky

Pro zájemce o hlubší znalosti fungování operačních systémů připravila MFF UK nový předmět Pokročilé operační systémy, v rámci něhož se vystřídají přednášející nejen z řad pracovníků fakulty, ale dorazí také odborníci ze společností AVAST, Oracle, Red Hat a SUSE. Tento předmět volně navazuje na kurz Operační systémy ze zimního semestru, ale pokud máte praktické zkušenosti odjinud (například z přispívání do jádra Linuxu) a chcete si

… více »
Martin Děcký | Komentářů: 6
21.2. 21:30 | Pozvánky

Czech JBoss User Group Vás srdečně zve na setkání JBUG v Brně, které se koná ve středu 1. března 2017 v prostorách Fakulty Informatiky Masarykovy Univerzity v místnosti A318 od 18:00. Přednáší Tomáš Remeš a Matěj Novotný na téma CDI 2.0 - New and Noteworthy. Více informací na Facebooku a na Twitteru #jbugcz.

mjedlick | Komentářů: 0
20.2. 23:45 | Zajímavý software

Na blogu Qt bylo představeno Qt 3D Studio. Jedná se o produkt dosud známý pod názvem NVIDIA DRIVE™ Design Studio. NVIDIA jej věnovala Qt. Jedná se o několik set tisíc řádků zdrojového kódu. Qt 3D Studio bude stejně jako Qt k dispozici jak pod open source, tak pod komerční licencí. Ukázka práce s Qt 3D Studiem na YouTube.

Ladislav Hagara | Komentářů: 10
20.2. 17:50 | Komunita

Nadace The Document Foundation (TDF) zastřešující vývoj svobodného kancelářského balíku LibreOffice slaví 5 let od svého oficiálního vzniku. Nadace byla představena 28. září 2010. Formálně byla založena ale až 17. února 2012.

Ladislav Hagara | Komentářů: 0
Jak se stavíte k trendu ztenčování přenosných zařízení (smartphony, notebooky)?
 (13%)
 (2%)
 (71%)
 (3%)
 (10%)
Celkem 686 hlasů
 Komentářů: 66, poslední včera 18:57
    Rozcestník

    Dotaz: Špatné kódování v terminálu na FAT s UTF8

    Blackhex avatar 30.10.2004 13:51 Blackhex | skóre: 16 | Brno, Frýdek-Místek
    Špatné kódování v terminálu na FAT s UTF8
    Přečteno: 684×
    Dobry den. Mám několik FAT oddílů s kódováním UTF8 a připojuju je ve fstab pomocí iocharset=utf8. V Gnome aplikacích typu Gedit mi kódování funguje ale v terminálech xterm, Eterm a Gnome-terminal a v Midnight Commanderu ne. Když přepišu fstab na iocharset=iso8859-2, tak je to zase naopak. Zajímalo by mě jestli by se to nedalo nějak sladit, třeba nastavením nějakých proměnných prostředí, nebo jestli neexistuje nástroj pro převedení FAT do iso8859-2. Dík.
    المفتاح المستعمل ﻻ يصدأ

    Odpovědi

    30.10.2004 16:22 Petr Šobáň | skóre: 79 | blog: soban | Olomouc
    Rozbalit Rozbalit vše Re: Špatné kódování v terminálu na FAT s UTF8
    >Mám několik FAT oddílů s kódováním UTF8

    Toto je nějaká blbost windows používájí UTF na fatce ????

    >iocharset=utf8

    Toto je správné pokud v linuxu používáte UTF

    >ale v terminálech xterm, Eterm a Gnome-terminal a v Midnight Commanderu ne

    Musíte jim nastavit správný font v tomto bude asi zrada. Jinak MC neumí unicode musí se nějak upravit mám dojem. V FC2 to funguje.
    Blackhex avatar 30.10.2004 16:31 Blackhex | skóre: 16 | Brno, Frýdek-Místek
    Rozbalit Rozbalit vše Re: Špatné kódování v terminálu na FAT s UTF8
    No já tu FAT formátoval v XP takže tam daly UTF8. No ve FC2 to je bez problemu, tohle je akorat v Debianu, googlil jsem nějake utf8 fonty, ale nic jsem nenašel. Nejlepši by to bylo převest na iso8859-2 ale ručně se mi to dělat nechce.
    المفتاح المستعمل ﻻ يصدأ
    30.10.2004 16:41 unchallenger | skóre: 69 | blog: unchallenger
    Rozbalit Rozbalit vše Re: Špatné kódování v terminálu na FAT s UTF8
    UTF-8 fonty jsou nesmysl. Unicode fonty (tj. fonty s kódováním ISO 10646-1), jsou už dneska kdejaké -- akorát tedy ne v Debian stable. Ten nepodoruje ani UTF-8 locale, takže by to byl vůbec boj.

    Převod jmen souborů do jiného kódování lze udělat jednoduchým skriptem, netuším ovšem, co na to pak řeknou ta MS Windows...
    Blackhex avatar 30.10.2004 17:20 Blackhex | skóre: 16 | Brno, Frýdek-Místek
    Rozbalit Rozbalit vše Re: Špatné kódování v terminálu na FAT s UTF8
    Tak abych to trochu upřesnil:

    Mam debian sarge, část fat disků jsem připojil jako utf8, čast jako iso8859-2, přes dpkg-reconfigure locales jsem nastavil do /etc/environment iso8859-2, nautilus zobrazuje názvy korektně v obou připadech, gnome-terminal apod. v obou případech ne. Nejake ty iso10646-1 fonty mam, ale když jsem se zkoušel nastavit tak taky nic.
    المفتاح المستعمل ﻻ يصدأ
    Blackhex avatar 30.10.2004 18:05 Blackhex | skóre: 16 | Brno, Frýdek-Místek
    Rozbalit Rozbalit vše Re: Špatné kódování v terminálu na FAT s UTF8
    Nejdivnější je ze při nastavení systému na iso8859-2 jsou vadné jenom ty názvy adresářů, jinak všechno ostatní je normální.
    المفتاح المستعمل ﻻ يصدأ
    Blackhex avatar 31.10.2004 01:53 Blackhex | skóre: 16 | Brno, Frýdek-Místek
    Rozbalit Rozbalit vše Re: Špatné kódování v terminálu na FAT s UTF8
    Po několikahodinovém zkoumání jsem přišel na to v čem bude problém. Zatímco celé X jedou s kódováním iso8859-2, při vytváření souborů se používá, jak na fat, tak na ext3, kódování utf8. V /etc/environment mám všechno nastaveno na iso8859-2. Matně si vzpomínám, že jsem při kompilaci jádra někde nastavoval jako default kódování utf8. Musím překompilovat jádro nebo to jde někde jinde nastavit?
    المفتاح المستعمل ﻻ يصدأ
    31.10.2004 09:46 unchallenger | skóre: 69 | blog: unchallenger
    Rozbalit Rozbalit vše Re: Špatné kódování v terminálu na FAT s UTF8
    Zatímco celé X jedou s kódováním iso8859-2, při vytváření souborů se používá, jak na fat, tak na ext3, kódování utf8.

    Tomuto tedy nerozumím.

    Když spustím terminál s LC_ALL=cs_CZ.ISO-8859-2, tak v něm touch ěščřžýáíé vytvoří na ext2[*] soubor se jménem v ISO 8859-2.

    Když spustím terminál s LC_ALL=cs_CZ.UTF-8, tak v něm touch ěščřžýáíé vytvoří na ext2[*] soubor se jménem v UTF-8.

    Zkrátka v tom, co vypíše locale charmap.

    [*] nebo libovolném normálním filesystému -- ext3, riserfs --, kde se neprovádí žádné další překódovávání. CONFIG_NLS_DEFAULT má vliv jen na ty divné filesystémy, kde se překódovává.
    31.10.2004 10:15 ZAH
    Rozbalit Rozbalit vše Re: Špatné kódování v terminálu na FAT s UTF8
    Máte vůbec dobře mountováno, musí být uvedeno jak kódování vstupu výstupu tak kódování disku.
    /dev/hdxx  /mnt/XXX   vfat  noauto,owner,iocharset=iso8859-2,codepage=utf8  0 0
    
    31.10.2004 12:05 8an | skóre: 30
    Rozbalit Rozbalit vše Re: Špatné kódování v terminálu na FAT s UTF8
    Já používám codepage=cp852 (DOSovskou znakovou sadu), aby to bylo kompatibilní i s Windows (ostatně proč jinak používat FAT?). Ale podíval jsem se na image FAT disku, a ty názvy tam jsou v UTF16 (MS Unicode), takže je asi jedno co se nastaví.

    Mám nastaveno iocharset=iso8859-2,codepage=cp852 a LC_CTYPE=cs_CZ (implicitně se používá iso8859-2) a funguje mi čeština na Windows partition bez problémů.
    If you build an operating system that even an idiot can use, only idiots will use it.
    Blackhex avatar 31.10.2004 12:14 Blackhex | skóre: 16 | Brno, Frýdek-Místek
    Rozbalit Rozbalit vše Re: Špatné kódování v terminálu na FAT s UTF8
    No nastavil jsem iocharset=iso8859-2,codepage=852 a názvy v teminálu jsou v pořádku, ale zase v Gnome aplikacích jsou názvy špatně, např. Z/341loha. A to i když dám všechno v /etc/environment na cs_CZ.iso8859-2 i na cs_CZ.UTF-8
    المفتاح المستعمل ﻻ يصدأ
    31.10.2004 12:43 unchallenger | skóre: 69 | blog: unchallenger
    Rozbalit Rozbalit vše Re: Špatné kódování v terminálu na FAT s UTF8
    Zkoušej to raději přímo
    LC_ALL=cs_CZ.ISO-8859-2 gnome-cosi
    LC_ALL=cs_CZ.UTF-8 gnome-cosi
    
    protože se ti to chová nějak záhadně.
    Blackhex avatar 31.10.2004 15:14 Blackhex | skóre: 16 | Brno, Frýdek-Místek
    Rozbalit Rozbalit vše Re: Špatné kódování v terminálu na FAT s UTF8
    Vyzkoušel jsem to s gedit, file-roller a ghex2, když dám Soubor/Otevřít tak v tom standartním dialogu pro výběr souborů jsou ty názvy typu Z/341loha. Aplikace co tenhle dialog nepoužívají jako např. gnome-find jsou vpořádku.
    المفتاح المستعمل ﻻ يصدأ
    Blackhex avatar 7.11.2004 12:49 Blackhex | skóre: 16 | Brno, Frýdek-Místek
    Rozbalit Rozbalit vše Re: Špatné kódování v terminálu na FAT s UTF8
    Porad to resim a nic. Nevi nekdo jestli se locale pro gnome nebo gtk nastavuje nekde zvlast?
    المفتاح المستعمل ﻻ يصدأ
    7.11.2004 21:43 unchallenger | skóre: 69 | blog: unchallenger
    Rozbalit Rozbalit vše Re: Špatné kódování v terminálu na FAT s UTF8
    Ne, Gtk+ věci reagují na locale normálně -- tedy alespoň normálně. Tohle začíná vypadat jako bug, i když těžko říci v čem, nebo obskurní nastavení, které nikoho nenapadá...
    Blackhex avatar 8.11.2004 01:13 Blackhex | skóre: 16 | Brno, Frýdek-Místek
    Rozbalit Rozbalit vše Re: Špatné kódování v terminálu na FAT s UTF8
    Dokonce i Nautilus akčoliv v hlavním okně zobrazuje diakritiku normálně v adresním řádku (tedy v editboxu kde je zobrazena cesta k souboru) zobrazuje diakritiku zase pro změnu takhle Z%E1loha. Normálně by to zas tak nevadilo, ale kvůli tomu mi nefunguje třeba otevření pdf v gpdf když odentruju v okně Midnighc Commanderu, prtože ten pošle název souboru se správnou diakritikou a gpdf tomu "nerozumí"
    المفتاح المستعمل ﻻ يصدأ
    Stanislav Brabec avatar 8.11.2004 11:42 Stanislav Brabec | skóre: 45 | Praha
    Rozbalit Rozbalit vše Re: Špatné kódování v terminálu na FAT s UTF8
    iocharset se používá na nastavení dlouhých jmen souborů (VFAT), a pro česká jména na VFAT, JFFS, Joliet (a možná i další) je naprosto nezbytné ho mít správně. Tyto souborové systémy ukládají jména v UNICODE.

    codepage se používá pouze pro krátká jména souborů (FAT). Při připojení jako vfat se změna nemusí projevit, ale může se projevit při připojení jako fat nebo v DOSu. Správná hodnota je cp852 (pokud nechcete DOSová jména podle Kamenických nebo v čistém ASCII).

    Za stávajícího stavu není možné, aby na jednom VFAT svazku pracovali dva uživatelé, každý s jiným kódováním. To by vyžadovalo výrazné změny v glibc.
    Blackhex avatar 8.11.2004 12:33 Blackhex | skóre: 16 | Brno, Frýdek-Místek
    Rozbalit Rozbalit vše Re: Špatné kódování v terminálu na FAT s UTF8
    Diky za temer vycerpavajici odpoved. Bohuzel jsem nepochopil jak souvisi kodovani nazvu souboru v textovem rezimu s kodovanim nazvu souboru v nekterych gtk aplikacich, tedy jak ho nastavit.
    المفتاح المستعمل ﻻ يصدأ
    Stanislav Brabec avatar 8.11.2004 13:03 Stanislav Brabec | skóre: 45 | Praha
    Rozbalit Rozbalit vše Re: Špatné kódování v terminálu na FAT s UTF8
    GTK+ (verze 2, přesněji řečeno GLib) má složitější systém detekce kódování:

    Primárně se kódování detekuje standardním způsobem z LANG, LC_CHARSET, LC_ALL. Ne však pro jména souborů. Zde se předpokládá UTF-8.

    Proměnná G_BROKEN_FILENAMES=1 v glib < 2.4 definuje, že budou jména souborů podle locale (= broken) namísto v UTF-8 (tedy chování, jaké mají jiné aplikace).

    Ve verzi glib ≥ 2.4 existuje ještě proměnná G_FILENAME_ENCODING. Nastavením G_FILENAME_ENCODING můžete definovat jiné kódování pro jména souborů. Pokud dojde k selhání, zkouši se další jméno ze seznamu. Příklad nastavení:
    export LANG=cs_CZ.UTF-8
    export G_BROKEN_FILENAMES=1
    export G_FILENAME_ENCODING=@locale,UTF-8,ISO-8859-2,CP1250
    
    G_FILENAME_ENCODING. This environment variable can be set to a comma-separated list of character set names. GLib assumes that filenames are encoded in the first character set from that list rather than in UTF-8. The special token "@locale" can be used to specify the character set for the current locale.

    G_BROKEN_FILENAMES. If this environment variable is set, GLib assumes that filenames are in the locale encoding rather than in UTF-8. G_FILENAME_ENCODING takes priority over G_BROKEN_FILENAMES.
    Blackhex avatar 8.11.2004 16:49 Blackhex | skóre: 16 | Brno, Frýdek-Místek
    Rozbalit Rozbalit vše Re: Špatné kódování v terminálu na FAT s UTF8
    Vrele diky, tohle bylo presne, co jsem potreboval vedet :-)
    المفتاح المستعمل ﻻ يصدأ

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.