Apple představil (YouTube) telefony iPhone 17 Pro a iPhone 17 Pro Max, iPhone 17 a iPhone Air, sluchátka AirPods Pro 3 a hodinky Watch Series 11, Watch SE 3 a Watch Ultra 3.
Realtimová strategie Warzone 2100 (Wikipedie) byla vydána ve verzi 4.6.0. Podrobný přehled novinek, změn a oprav v ChangeLogu na GitHubu. Nejnovější verzi Warzone 2100 lze již instalovat také ze Snapcraftu a Flathubu.
Polské vývojářské studio CD Projekt Red publikovalo na Printables.com 3D modely z počítačové hry Cyberpunk 2077.
Organizátoři konference LinuxDays 2025 vydali program a zároveň otevřeli registrace. Akce se uskuteční 4. a 5. října na FIT ČVUT v pražských Dejvicích, kde vás čekají přednášky, workshopy, stánky a spousta šikovných lidí. Vstup na akci je zdarma.
Uživatelé komunikátoru Signal si mohou svá data přímo v Signalu bezpečně zálohovat a v případě rozbití nebo ztráty telefonu následně na novém telefonu obnovit. Zálohování posledních 45 dnů je zdarma. Nad 45 dnů je zpoplatněno částkou 1,99 dolaru měsíčně.
Server Groklaw, zaměřený na kauzy jako právní spory SCO týkající se Linuxu, skončil před 12 lety, resp. doména stále existuje, ale web obsahuje spam propagující hazardní hry. LWN.net proto v úvodníku připomíná důležitost zachovávání komunitních zdrojů a upozorňuje, že Internet Archive je také jen jeden.
Jakub Vrána vydal Adminer ve verzi 5.4.0: "Delší dobu se v Admineru neobjevila žádná závažná chyba, tak jsem nemusel vydávat novou verzi, až počet změn hodně nabobtnal."
V Německu slavnostně uvedli do provozu (en) nejrychlejší počítač v Evropě. Superpočítač Jupiter se nachází ve výzkumném ústavu v Jülichu na západě země, podle německého kancléře Friedricha Merze otevírá nové možnosti pro trénování modelů umělé inteligence (AI) i pro vědecké simulace. Superpočítač Jupiter je nejrychlejší v Evropě a čtvrtý nejrychlejší na světě (TOP500). „Chceme, aby se z Německa stal národ umělé inteligence,“ uvedl na
… více »V Berlíně probíhá konference vývojářů a uživatelů desktopového prostředí KDE Plasma Akademy 2025. Při té příležitosti byla oznámena alfa verze nové linuxové distribuce KDE Linux.
Byl vydán Debian 13.1, tj. první opravná verze Debianu 13 s kódovým názvem Trixie a Debian 12.12, tj. dvanáctá opravná verze Debianu 12 s kódovým názvem Bookworm. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 13 a Debianu 12 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.
#!/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:
