raylib (Wikipedie), tj. multiplatformní open-source knihovna pro vývoj grafických aplikací a her, byla vydána ve verzi 6.0.
Nové verze AI modelů. Společnost OpenAI představila GPT‑5.5. Společnost DeepSeek představila DeepSeek V4.
Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 164 (pdf) a Hello World 29 (pdf).
Bylo oznámeno, že webový prohlížeč Opera GX zaměřený na hráče počítačových her je už také na Flathubu and Snapcraftu.
Akcionáři americké mediální společnosti Warner Bros. Discovery dnes schválili převzetí firmy konkurentem Paramount Skydance za zhruba 110 miliard dolarů (téměř 2,3 bilionu Kč). Firmy se na spojení dohodly v únoru. O část společnosti Warner Bros. Discovery dříve usilovala rovněž streamovací platforma Netflix, se svou nabídkou však neuspěla. Transakci ještě budou schvalovat regulační orgány, a to nejen ve Spojených státech, ale také
… více »Canonical vydal (email, blog, YouTube) Ubuntu 26.04 LTS Resolute Raccoon. Přehled novinek v poznámkách k vydání. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 11. vydání s dlouhodobou podporou (LTS).
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Gitea (Wikipedie) byla vydána v nové verzi 1.26.0. Přehled novinek v příspěvku na blogu.
Ve středu 29. dubna 2026 se v pražské kanceláři SUSE v Karlíně uskuteční 7. Mobile Linux Hackday, komunitní setkání zaměřené na Linux na mobilních zařízeních, kernelový vývoj i uživatelský prostor. Akce proběhne od 10:00 do večerních hodin. Hackday je určen všem zájemcům o praktickou práci s Linuxem na telefonech. Zaměří se na vývoj aplikací v userspace, například bankovní aplikace, zpracování obrazu z kamery nebo práci s NFC, i na úpravy
… více »LilyPond (Wikipedie) , tj. multiplatformní svobodný software určený pro sazbu notových zápisů, byl vydán ve verzi 2.26.0. Přehled novinek v aktualizované dokumentaci.
Byla vydána nová verze 11.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 237 vývojářů. Provedeno bylo více než 2 500 commitů. Přehled úprav a nových vlastností v seznamu změn.
#!/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:
