Byla vydána (Mastodon, 𝕏) druhá RC verze GIMPu 3.2. Přehled novinek v oznámení o vydání. Podrobně v souboru NEWS na GitLabu.
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 160 (pdf).
Izrael od února zakáže dětem používat v prostorách základních škol mobilní telefony. Podle agentury AFP to uvedlo izraelské ministerstvo školství, které zdůraznilo negativní dopady, které na žactvo používání telefonů má. Izrael se tímto krokem přidává k rostoucímu počtu zemí, které dětem ve vzdělávacích zařízeních přístup k telefonům omezují.
Internetová společnost Google ze skupiny Alphabet pravděpodobně dostane příští rok pokutu od Evropské komise za nedostatečné dodržování pravidel proti upřednostňování vlastních služeb a produktů ve výsledcích vyhledávání. V březnu EK obvinila Google, že ve výsledcích vyhledávání upřednostňuje na úkor konkurence vlastní služby, například Google Shopping, Google Hotels a Google Flights. Případ staví Google proti specializovaným
… více »Byl oznámen program a spuštěna registrace na konferenci Prague PostgreSQL Developer Day 2026. Konference se koná 27. a 28. ledna a bude mít tři tracky s 18 přednáškami a jeden den workshopů.
Na webu československého síťařského setkání CSNOG 2026 je vyvěšený program, registrace a další informace k akci. CSNOG 2026 se uskuteční 21. a 22. ledna příštího roku a bude se i tentokrát konat ve Zlíně. Přednášky, kterých bude více než 30, budou opět rozdělené do tří bloků - správa sítí, legislativa a regulace a akademické projekty. Počet míst je omezený, proto kdo má zájem, měl by se registrovat co nejdříve.
Máirín Duffy a Brian Smith v článku pro Fedora Magazine ukazují použití LLM pro diagnostiku systému (Fedora Linuxu) přes Model Context Protocol od firmy Anthropic. I ukázkové výstupy v samotném článku obsahují AI vygenerované nesmysly, např. doporučení přeinstalovat balíček pomocí správce balíčků APT z Debianu místo DNF nativního na Fedoře.
Projekt D7VK dospěl do verze 1.0. Jedná se o fork DXVK implementující překlad volání Direct3D 7 na Vulkan. DXVK zvládá Direct3D 8, 9, 10 a 11.
Byla vydána nová verze 2025.4 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení na blogu.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) zveřejnil Národní politiku koordinovaného zveřejňování zranitelností (pdf), jejímž cílem je nejen zvyšování bezpečnosti produktů informačních a komunikačních technologií (ICT), ale také ochrana objevitelů zranitelností před negativními právními dopady. Součástí je rovněž vytvoření „koordinátora pro účely CVD“, jímž je podle nového zákona o kybernetické … více »
#!/bin/bash . /opt/Man Back Editor/run.sh || exit $?a tohle taky nefunguje (soubor ~/.bashrc)
alias mbe='/opt/Man Back Editor/run.sh' alias mbe="/opt/Man Back Editor/run.sh"
Řešení dotazu:
#!/bin/bash . '/opt/Man Back Editor/run.sh' || exit $?V případě toho aliasu musí být uvozovky dvoje – ty první se rozvinou v okamžiku, kdy definujete alias, proto tam musí být ty vnitřní, které s epoužijí, když alias použijete.
alias mbe='"/opt/Man Back Editor/run.sh"' alias mbe="'/opt/Man Back Editor/run.sh'"Nebo můžete mezeru uvodit zpětným lomítkem:
#!/bin/bash . /opt/Man\ Back\ Editor/run.sh || exit $?
alias mbe='/opt/Man\ Back\ Editor/run.sh'
/opt/Man\ Back\ Editor/run.shA to ve všech výše uvedených případech. Nebo, jak navrhoval předřečník, obalit to v uvozovkách:
'/opt/Man Back Editor/run.sh' "/opt/Man Back Editor/run.sh" alias mbe='"/opt/Man Back Editor/run.sh"' alias mbe="'/opt/Man Back Editor/run.sh'"No a pak je tu ještě pár drobností. Proč o to ten první skript sourcuje a nevolá? Není to spíše omyl než záměr? No a pokud je to celém tak
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
|| exit $? nedává ani trochu smysl, protože ať to tam je, nebo ne (a nebo taky && exit $?, či ; exit $?. Tak to dopadne vždycky stejně.
předně, mezery v názvech souborů jsou zlo. Nejlépe byste udělal, kdybyste to přejmenoval.Lidé víceslovné názvy běžně používají, a slova pak oddělují mezerami. Počítače jsou od toho, aby sloužily lidem, ne naopak. Mezery v názvech souborů jsou běžná věc, programy s tím umí zacházet – a pokud s tím nějaký konkrétní program má problém, je potřeba ho opravit. Používat mezery v názvech souborů je stejné „zlo“, jako používat shell místo assembleru nebo používat klávesnici a monitor místo děrných štítků a tiskárny.
Dodal bych jen, že používat v dnešní době počítač k řešení tak triviálních úloh je stejné "zlo", jako místo gelové propisky používat husí brk, či dokonce obyčejnou tužku!předně, mezery v názvech souborů jsou zlo. Nejlépe byste udělal, kdybyste to přejmenoval.Lidé víceslovné názvy běžně používají, a slova pak oddělují mezerami. Počítače jsou od toho, aby sloužily lidem, ne naopak. Mezery v názvech souborů jsou běžná věc, programy s tím umí zacházet – a pokud s tím nějaký konkrétní program má problém, je potřeba ho opravit. Používat mezery v názvech souborů je stejné „zlo“, jako používat shell místo assembleru nebo používat klávesnici a monitor místo děrných štítků a tiskárny.
Jenže v názvech souborů mezera jako oddělovač nefunguje – jako oddělovač tam slouží jen a pouze lomítko.V názvech souborů ne, ale v shellu a při třídění parametrů ano. Aby počítač sloužil člověku a ne naopak, zda se bytí jednodušší používat v názvu souborů podtržítko místo mezery a dělá to to, co má, i když někdo někde něco zapomněl ošetřit, protože špatně sloužil. Je asi jenom otázkou osobní preference, jestli otročim vzdáním se mezery ve jménu nebo escapováním při každém použití, kde na jméno narazím. A protože vím, co lidi píšou, tak raději žiju bez mezer. Nakonec pak sám mohu být trochu lenivější ve onelinerech (tedy méně sloužím). A při více sloupcích výstupu se mi to i lépe čte. Protože položky a slova v jedné položce se na první pohled liší.
31.12.2017 01:41
find (jo jasně, můžu mu posloužit a na obou stranách dopsat, ať oddělí položku "nulou") nebo něco do smyčky nebo xargs či co. To je přesně ten případ, kdy oddělovač slov a položek kolidují.
Ale teď už jsem to pochopil. Jádro pudla je ta poznámka o GUI. Ale pořád je to ta samá otázka preferencí a pohledu na věc. Nechci počítači sloužit, tak se trochu naučím, abych úkony prováděl rychle a snadno? Nebo mu nechci sloužit učením a raději si to pro každé interakci odsloužím tím, že budu honit myš po stole a dirigovat ukazováčkem.
find s -exec. Ale nešlo jenom o find a i u něj jsou situace, kdy nebudu chtít forkovat nový proces pro každou položku.
Je to fakt jen otázka pohledu a preference, jak chci ne/sloužit. Jediný způsob jak pro ten počítač nic neudělat je ho vůbec nepoužívat.
Ale nešlo jenom o find a i u něj jsou situace, kdy nebudu chtít forkovat nový proces pro každou položku.
find -exec {} + znáte?
find jako nevhodný příklad a už se k němu nebudeme vracet. Omlouvám se, že jsem ho chybně uvedl. Zkusme třeba grep -l. Prostě něco vrací seznam souborů a něco dalšího s tím shell dělá. To je to, o co mi šlo. Vy možná ne, já to docela používám. Proto máme různé potřeby a postupy. A různé věci nás více nebo méně obtěžují.
S GUI se to bude řešit jinak. A podle mě více interaktivně a asi déle, proto to není moje volba. Ale určitě to jde. A komu to vyhovuje, nic proti tomu nemám.
Nicméně i pro uživatele GUI platí. Pokud se moc nechce učit, ale sem tam si zkopírujete nějaký skript z netu na přejmenování nebo kdo ví co, tak bude mít bez mezer méně nepříjemných překvapení. Jak ostatně svědčí i původní dotaz.
find -exec {} předává jméno souboru správně jako jeden parametr, bez ohledu na to, jaké znaky obsahuje. zsh, které používám, nejprve rozdělí vstup na jednotlivé argumenty, a teprve pak expanduje proměnné – takže ve smyčce nemám problém s mezerami v názvech souborů.
Pokud byste někde mezery ošetřit měl a neděláte to, asi spoléháte na to, že nemáte žádné soubory s mezerou. Já se na něco takového určitě spolehnout nemůžu, protože si spoustu souborů vyměňuji s ostatními, a rozhodně nemíním trávit čas tím, že budu soubory neustále přejmenovávat sem a tam.
Psal jsem o GUI, to vy jste si vymyslel honění myši po stole. Myslím, že se soubory pracuji rychle a snadno, a žádné mezery v názvech souborů mi v tom nepřekážejí.
Ať si každý (ne)používá, co (ne)chce. Když někdo dá na web soubor s mezerami v názvu, každý má právo si ten soubor nestáhnout.
Počítače slouží lidem, nikoliv lidé počítačům. Pokud lidé uznají za nezbytné mít v názvech souborů mezery, ať tam klidně mezery jsou. Samozřejmě by bylo nejlepší tohle nějak standardizovat a používat třeba znak neoddělitelné mezery místo 0x20. Ale to už je spíš otázka budoucnosti.
Microsoft všem zmrvil kódování v jazycích, kterým nestačí 7 bitů z ASCII, na dobrá tři desetiletí. To je původní příčina všech absurdních debat o tom, jak se může/nemůže jmenovat soubor nebo co může/nemůže být napsáno tam či onde. Kvůli embrace-extend-extinguish experimentům s kódováním bylo roky problematické psát maily normálně česky. Kniha od jednoho raději nejmenovaného českého internetového taky-publicisty vybízela v podstatě k psaní celých webů v Notepadu bez zřetele ke kódování, protože v „obvyklém“ browseru se to zdálo být v pořádku.
Kdyby byly všechny názvy souborů už dávno povinně v UTF-8, nedělitelná mezera v názvech souborů už dávno mohla být běžná věc. Terminály by ji mohly ukazovat třeba jako golfový důlek oblíbený u některých učitelů programování.
Ještě k tomu problému + řešení: Buď můžu problém donekonečna obcházet — což je nejhorší varianta —, nebo ho můžu pořád dokola řešit — což napovídá, že moje řešení je pořád špatné, i po mnoha opakováních —, nebo ho můžu vyřešit pořádně a natrvalo — čemuž Microsoft úspěšně zabránil, co se kódování týká.
Netvrdím přece, že mezera není platný znak.
Měl jsem možná explicitně říct, že hlavní (a asi jedinou) výhodou nedělitelných mezer by byla redukce počtu kňouralů, kterým tak nepřekonatelně vadí mezery v názvech souborů. Mně osobně mezery až tolik nevadí, ale nějaká konvence kolem nedělitelných mezer by se mi celkem líbila.
Jediný, kdo má s non-ASCII znaky problém, jsou anonymové na ABCLinuxu, zdá se. Nebo je tohle komentář z roku 1995?
Údajný problém s unicodem je nesmyslná fáma, kvůli které dodnes tu a tam přežívá hnusná zkomolená pseudo-čeština bez diakritiky. V posledních víc než 10 letech jsem nenarazil na software, který by měl problém normálně používat unicode.
Jaký je standard v dnešní době - UTF-8, UTF-16, UTF-16BE, UTF-16LE, UTF-32, UTF-32BE, UTF-32LE nebo UTF-32/UCS-4?
Standard je UTF-8.
Ten seznam je hodně přehnaně dlouhý, protože všechna ta kódování, která mají fixní šířku znaku a potřebují BOM, jsou zbytečně uvedená třikrát — big endian, little endian a blíže neurčený endian. Jinak je to ale v principu pořád totéž, že ano. (Pořadí bytů se naštěstí UTF-8 příliš netýká a UTF-8 nepotřebuje BOM, i když ho z jakýchsi historických mít může.) Pokud vím, 16- a 32-bitová kódování s fixní šířkou znaku se ve filesystémech moc nenosí.
Těžko říct, proč se vůbec zabývat MySQL, když PostgreSQL je po všech stránkách asi tak o světelný rok dál.
Nepoužívá Windows 10 UTF-16?
Tak to bych se klidně podíval. Kde to najdu na GitHubu?
Předně, proč by měl někdo řešit nějaké Shitdows? Tohle je fórum o Linuxu a na Linuxu diakritika už minimálně desetiletí a půl není nejmenší problém. Někdy v roce 2003 jsem musel jeden čas používat Outlook Express, takové to nejbéčkovější free provedení, a nikdy jsem nenarazil na problém s češtinou nebo diakritikou. Ano, dalo se tenkrát narazit na obstarožní software, který neuměl UTF-8, ale zvolit ISO-8859-2 (a mít kódování správně specifikované v hlavičkách mailu) opravdu šlo už tenkrát.
Taky se mi už minimálně 15 let nestalo, že bych napsal mail s diakritikou — samozřejmě píšu všechny maily buď s diakritikou nebo anglicky; český text bez diakritiky považuji za sérii vulgarismů a krajní neslušnost — a že by snad měl příjemce s takovým mailem problém. Stačí mít rozumného mailového klienta (Thunderbird i KMail mi fungují bez problémů) a mít nastavené bezproblémové odchozí kódování, tedy UTF-8, protože nic jiného v podstatě nedává smysl.
Samozřejmě, pokud někdo v mailovém klientovi naschvál zvolí například ISO-8859-1, potom do příslušného widgetu pro text mailu napíše české znaky a na závěr ještě odklikne varovné hlášky o kódování (tedy o tom, že se zvoleným kódováním bude text nutně zprasený), může takovým způsobem (uměle a zbytečně) vytvořit problém s češtinou. Jenže proč by to někdo dělal?
Navíc drtivá většina BFU beztak používá webmail, ve kterém je kódování taktéž už dobrých 15 let vyřešená záležitost.
Tiskni
Sdílej:
