Vlákno názorů k článku
Správce souborů ve Windows nabídne procházení linuxových souborů ve WSL od incorporated - Já naivní si kdysi myslel, že s příchodem...

"Třeba německé ostré s nemá lowercase alternativu. Jak jsou na tom asijské jazyky se bojím jen pomyslet."

U znaku ktere nemaji dve varianty se proste sensitivita neuplatni, nebo je to jinak?

Lowercase varianta ostrého s jsou dvě obyčejná. Takže jednoznačná transformace existuje jenom jedním směrem.

Windows to samozřejmě porovnávají úplně jinak. Převádí se na uppercase (není třeba kvůli porovnání ale třeba kvůli hashům) a jazykové rozdíly se ignorují. Manuál zdůrazňuje, že to bude fungovat na NTFS ale nemusí třeba pro síťové disky. Prostě binec.

Vaše "nebo je to jinak?" naprosto přesně vystihuje situaci. Funguje to jinak než normální jazyky a bez důsledného RTFM to chování člověk spolehlivě splete. Vysvětlit uživateli, že na velikosti písmen záleží, je proti tomu brnkačka. Přece jenom do nich to, že je mezi malým a velkým písmenem rozdíl, hustí už od základky.

Tak třeba tady jsou příklady, kdy to Turečtina řeší jinak: https://docs.oracle.com/javase/7/docs/api/java/lang/String.html#toLowerCase(java.util.Locale)

Nejde tedy jen o to, kdy je k některým znakům lowercase/uppercase varianta, ale o to, že zřejmě není způsob, jak to udělat „správně“.

(Ano, je to dokumentace ze staré Javy, bylo to to první, co jsem našel a na verzi zde až tak nezáleží.)

Jiný případ, kdy je case sensitivity problém (byť už ne principiální, ale spíše komplikace pro vývojáře vedoucí k bezpečnostním problémům): https://bugzilla.redhat.com/show_bug.cgi?id=1175960

V neposlední řadě ukázka, jak toLowerCase nebo toUpperCase v Javascriptu může změnit délku Stringu:

for (let i = 0; i < 65536; i++) {
    let c = String.fromCharCode(i);
    let lower = c.toLowerCase();
    if (c.length != lower.length) {
        console.log("toLowerCase changes length", i, c, c.length, lower, lower.length);
    }
}

for (let i = 0; i < 65536; i++) {
    let c = String.fromCharCode(i);
    let upper = c.toUpperCase();
    if (c.length != upper.length) {
        console.log("toUpperCase changes length", i, c, c.length, upper, upper.length);
    }
}

„Třeba německé ostré s nemá lowercase alternativu.“

Fakt, jo?
ß
ẞ

Dle: https://en.wikipedia.org/wiki/Capital_%E1%BA%9E

The capital ẞ did not form part of official German orthography until June 2017.

Coz znamena, ze se az do nedavna jednalo o nestandardni variantu (do ty doby byla jedina standardni varianta "SS")

Dle: https://en.wikipedia.org/wiki/German_orthography#Sharp_s

Jedna se o moznost. Zas tak dobre se v nemcine nevyznam, ale predpokladam, ze "SS" je porad spravna a asi prevladajici a predevsim konzistentni varianta

V kazdem pripade i kdyby to nemci vyresili, tak to nemusi znamenat, ze obdobnej problem bude v jinym jazyce

13. 4. 2020, 12:59 editováno autorem komentáře

Z vášho vlastného linku:

Seit dem 29. Juni 2017 ist das ẞ Bestandteil der amtlichen deutschen Rechtschreibung.

Z jazykového hľadiska ide o horúcu novinku, o ktorej väčšina rečníkov nebude vedieť, nieto že by bola zapracovaná do operačných systémov a vyriešené všetky legacy problémy, ktoré vznikli pred jej zavedením.

súhlasím, je nezmysel sa snažiť o caseinsensivitu. Preto je Linux/Unix na tom výrazne lepšie než Windows a jeho NTFS

10. 4. 2020, 22:07 editováno autorem komentáře

Jen pro informaci, NTFS je vnitřně case sensitive. Case insensitivity zajišťuje až Windows API a z dobrých důvodů. Dokonce existoval (možná stále existuje) powershell příkaz, který to dovoloval nastavit i ve Windows 10 a pak bylo možné mít ve složce soubor.txt i Soubor.txt vedle sebe.

Case sensitivita je nesmysl, jde to zcela proti přirozenému vnímání jazyka. Nejsme už v dobách, kdy úsek dat (soubor) byl označen nějakým kódem a z něj se teprve "dešifrovalo" co to znamená. Dnes pojmenování souborů odpovídá přirozeným entitám. Soubor si pojmenuji podle své představy, abych podle jména chápal, co najdu uvnitř. Nevím jak pro vás, ale pro mě je "krabice", "Krabice" i "KRABICE" totéž. Bedna, která se neliší jen díky tomu, jestli byla napsána malými nebo velkými písmeny (aspoň já teda nerozlišuju velikost bedny tím, že bych ji psal malými nebo velkými písmeny).

Snad jednou ajťáci pochopí, že technika je tu pro lidi a má jim být co nejbližší. Zatím to někdy vypadá spíš tak, že ajťák očekává, že se bude člověk přizpůsobovat jeho technicky zaměřenému (a tedy i částečně omezenému) myšlení. Úspěšné technologické firmy to vyhrávají právě na tom, že umí techniku přiblížit lidskému myšlení a chování.

jde to zcela proti přirozenému vnímání jazyka

samozrejme ze kazda(u tebe to plati tuplem) blbost jde okecat tak aby se naslo "vysvetleni" ktere se hodi do kramu... jen prehlizis ze i ty sam pises velkem pismeno na zacatku vety, nick take nemas cele malejma, ze i v cestine muze byt stejne slovo s malym pocatecnim pismenem nebo s velkym a kazde znamena neco jineho,

ty sam pises velkem pismeno na zacatku vety, nick take nemas cele malejma, ze i v cestine muze byt stejne slovo s malym pocatecnim pismenem nebo s velkym a kazde znamena neco jineho

Aha, takže říkáte, že Krabice.txt a krabice.txt jsou na první pohled dva různé soubory, u kterých jsem měl potřebu je takto rozlišit? Nebo mi uveďte pár příkladů, kdy malá a velká písmena v názvu souboru jsou důležitá pro rozlišení od sebe..?

Jinak malá/velká písmena Windows zachovávají, právě z důvodů, co píšete.

Miroslav Šilhavý: Úplně stejně byste mohl argumentovat tím, že soubory krabice.txt a bedna.txt jsou přece taky to samé a souborový systém to má poznat. Nebo krabice-1.txt a krabice 1.txt Nebojte se, lidé nemají problém pochopit, že na přesném pojmenování záleží. Je to na pochopení mnohem jednodušší, než vysvětlovat milion pravidel (k čemuž by ten váš přístup vedl), podle kterých se porovnává, zda dva různé názvy náhodou nejsou stejné. To, že je rozdíl mezi malým a velkým písmenem, se učí asi tak od druhé třídy ZŠ.

Důvod, proč jsou ve Windows názvy souborů někdy case-insensitive, je jediný – je to dědictví DOSu, kde byly názvy na FAT uložené jen velkými písmeny a vše se na ně převádělo. Kdyby se to po přechodu na Windows změnilo, některé aplikace by přestaly fungovat. No a pak už bylo potřeba to držet pořád dál, protože s tím stále ty aplikace počítaly.

"v cestine muze byt stejne slovo s malym pocatecnim pismenem nebo s velkym a kazde znamena neco jineho"

Muzete dat priklad ceskeho slova kde zmena velikosti pismena meni VYZNAM toho slova?

Muzete dat priklad ceskeho slova kde zmena velikosti pismena meni VYZNAM toho slova?
Všechna slova, kde dává význam varianta s velkým i s malým písmenem na začátku . Tj. může to být vlastní jméno a i obecné slovo – pátek/Pátek, brod/Brod, trhák/Trhák, pohoda/Pohoda, černá/Černá…

Všechna slova, kde dává význam varianta s velkým i s malým písmenem na začátku . Tj. může to být vlastní jméno a i obecné slovo – pátek/Pátek, brod/Brod, trhák/Trhák, pohoda/Pohoda, černá/Černá…

V tom máte sice pravdu, ale pro kategorizaci informací (k čemuž slouží filesystem) to moc význam nemá. Teoreticky sice můžu uložit soubory "Co jsem viděl v lednici.txt" a "Co jsem viděl v Lednici.txt", ale dovolím si tvrdit, že se nenajde skoro nikdo, kdo by takovou nuanci řešil tím, že to jen rozliší jen malým / velkým písmenem ve jménu souboru. Bylo by to nepraktické i pro život - mnohdy jsou výstupy (např. tiskové) formátovány verzálkami, kde už ten rozdíl zmizí úplně. Takže lidé obvykle používají v názvu i část kontextu, aby bylo patrné, jestli myslí paní Černou, nebo černou barvu.

Tak pojďme ještě o krok dál a nerozlišujme třeba mezi nulou a „O“ nebo jedničkou a „l“.

Miroslav Šilhavý: Hlavně, že tu celou dobu řešíte, jak mají uživatelé na Linuxu běžně na disku soubory rozlišené jenom velkým písmenem a pak nevědí, o kterém souboru je řeč, když to diktujete po telefonu.

Obycejny slovo uprosted vety napsany s velkym pocatecnim pismenem ma zvlastni vyznam (a proto je tak napsany). Taky mame rozdil lednice a Lednice, ktery byl tady jiz zminenej. Napriklad nakdo muze pojmenovat dva soubory "fotka-lednice" a "fotka-Lednice", oba maji smysluplnej nazev odpovidajici obsahu, ale kazdej obsahuje zcela neco jinyho (na jednom je lednice a na druhym Lednice).

> Case sensitivita je nesmysl, jde to zcela proti přirozenému vnímání jazyka.

Krásné tvrzení, bohužel trochu ignoruje realitu. Pamatujete ještě Hejla s jeho Hlodačem, lednicí a Lednicí?

Přirozené jazyky jsou vágní bordel, který je velmi těžko implementovatelný bez zásadních zjednodušení. Přirozené vnímání jazyka je fuzzy proces, který silně závisí na kontextu. Fakt chcete do tak fundamentálních operací jako je identifikace souborů zavádět tuhle černou magii?

V realitě máme jen dvě možnosti :
- Case sensitive FS, které fungují jinak než přirozené jazyky.
- Canse insensitive FS, které taky fungují jinak než přirozené jazyky.

Volíme mezi menšími zly. Jestli je pro uživatele jednodušší představa že počítač rozlišuje malá a velká písmena, nebo že je rozlišuje, akorát způsobem který je trochu _divný_.

"Přirozené jazyky jsou vágní bordel, který je velmi těžko implementovatelný bez zásadních zjednodušení."

Problem je, ze zacatky neceho v IT (FS, OS, jazky, utility, atp.) jsou casto u polo-autistickych/polo-genialnich jedincu kteri pri jejich vymysleni maji v hlave spis aby to bylo "chytre" navrzene, dobre se to rozsirovalo, integrovalo do dalsich veci a pripadne to respektovalo "konvence" (cti veci vymyslene dalsimi polo-autisty, ktere nas autista uznava, o neco drive). Nez se tyhle veci dostanou k mase lidi "nevzdelanych v zakladech IT" tak uz jsou vicemene hotove a takto zasadni zmeny tam uz nikdo delat nebude. Cest svetlym vyjimkam....

Hmmm, OK. Jaký to má ale vztah k přirozeným jazykům?

"Jaký to má ale vztah k přirozeným jazykům?"

Ja bych spis pouzival termin "zapis primarniho jazyka", coz je pro kazdeho jeho materstina. "polo-autiste" z ruznych duvodu nekladou duraz na konformitu jejich vytvoru s primarnim jazykem, nebo na "obecne lidske komunikacni zvyklosti".

Ok, jak má fungovat zařízení obsluhované jedinci s nekompatibilními primárními jazyky?

A v jakékoliv nadnárodní korporaci je právě nezávislost na těch primárních jazycích jeden z kritických požadavků. Pokud to nebude fungovat kolegovi v Bangladéši, je jakákoliv neintuitivnost naprosto nepodstatný problém. Bouchne to jednou jedinkrát a přiletí směrnice co nařizuje 7b ascii či něco podobného.

@Jiří Havel

Se soubory pracují a) programy (a jejich programátoři), b) smrtelníci.

Case sensitive bordel je pohodlný pro programátory (mají vše exaktně), ale není blízký smrtelníkům. Když si budu telefonovat s kolegou, kterému budu říkat: najdeš to v souboru "krabice.txt", budeme si muset ještě říkat, jestli náhodou nemyslíme Krabice.txt nebo KRABICE.txt. To je pro užívání dost k ničemu.

Proti tomu by programátoři mohli klidně s takovou situací počítat. Stejně je zvykem, že se soubory v programech ukládají jen v určité sadě znaků. Obvykle ASCII, uživatelská data pak UTF-8. Pro programátory by to nebyla větší změna, než začít počítat s tím, že nemohou existovat dva soubory lišící se jen velikostí znaků.

Představte si Google, jak by to bylo zábavné, kdyby vyhledával case sensitive :).

@Miroslav Šilhavý
Ano, se soubory pracují jak smrtelníci (já) tak různé programy. V tom je přesně ten problém.

Když budu volat s kolegou, tak krabice, Krabice a KRABICE nepředstavují problém. Prostě proto, že do jednoho adresáře dva takové soubory nikdo rozumný stejně nedá. To, že jméno musí přesně sedět aby OS ten soubor našel taky není problém. Programy psané pro smrtelníky mi stejně dovolí na ten soubor kliknout místo toho abych musel psát název.

Naopak je problém v tom, že case insensitive není jednoduchý pro programátory. Protože musím pracovat se spoustou programů, které v tom mají bugy a nekonzistence. Takže jsem v pojmenování souborů paradoxně daleko víc omezený, než kdyby byl název prostě řada bytů, která se interpretuje jenom při výpisu na obrazovku.

Jako smrtelníkovi mi case-insensitivita nic užitečného nepřináší. Naopak mě nepřímo omezuje díky tomu že zkomplikovala práci autorům sw, co používám. A ty důsledky nejsou nic moc.

A představte si, Google je case sensitive. Pro lednice a Lednice mi vrací mírně odlišné výsledky. ;)

@Jiří Havel

Právě soubor "krabice" je dost problematický. Ne jednou se mi stalo, že smrtelník, který chvíli používal Linux najednou měl stejný soubor 2x, pokaždé s jinými změnami. Prostě si nevšiml a nevšímal velikosti znaků.

Case insensitive je pro programátory jednoduchý. Volání obsluhuje OS, takže všechny myslitelné funkce zařídí. O tom myslím není potřeba diskutovat, na Windows to tak funguje dekády.

Každopádně nesouhlasím s tím, že se má ulehčovat práce programátorům a přidělávat uživatelům.

Case sensitive je správná volba na úrovni FS. Na vyšší úrovni abstrakce může být jiná volba lepší. Deal with it.

Case sensitive je správná volba na úrovni FS. Na vyšší úrovni abstrakce může být jiná volba lepší. Deal with it.

Což je právě případ Windows a NTFS, o tom se tu bavíme.

Ne jednou se mi stalo, že smrtelník, který chvíli používal Linux najednou měl stejný soubor 2x, pokaždé s jinými změnami. Prostě si nevšiml a nevšímal velikosti znaků.
No vidíte, nikdy se to nestalo (jak píšete, ne jednou), takže to není žádný problém. Ono totiž také jak by se to asi mohlo stát. Uživatel má otevřený soubor, ale místo aby ho dal uložit, dá uložit jako, napíše jméno souboru a pojmenuje ho úplně stejně, akorát změní velikost nějakého písmene. Naštěstí takhle reální uživatelé nepracují, jinak by měly disky plné souborů, které by se lišily jenom mezerami, pomlčkami, spojovníky, tečkami, podtržítky atd.

Volání obsluhuje OS, takže všechny myslitelné funkce zařídí.
Funkce jako hledání souborů nebo doplňování názvu (podkategorie hledání) jsou pro vás nepředstavitelné vymoženosti?

Každopádně nesouhlasím s tím, že se má ulehčovat práce programátorům a přidělávat uživatelům.
Case-sensitive souborový systém práci uživatelům nepřidělává. case-insensitive je akorát trochu mate, protože na všem ostatním u názvu souboru záleží, jenom na velikosti písmen zrovna ne.

@Miroslav Šilhavý
Zajímavé. Můžete to trochu rozvést? Zajímalo by mě, jakým způsobem k té situaci došlo. Co dělal, že si nevšiml dvou podobně pojmenovaných souborů. A vyřešil jste to nějak jinak než přechodem na case-insensitive FS? Protože si dokážu představit obrovské množství podobných překlepů, které můžou vzniknout i na Windowsech. Takže nějaké systematické řešení mě dost zajímá.

Jinak OS rozhodně nezařídí všechny myslitelné funkce. Ten zařídí leda tak korektní přístup k souboru. Zpracování jmen souborů moc neulehčí. Porovnávání, řazení, nebo hashování jmen v aplikaci obvykle OS nedělá. A takové case insensitive hashování musí 1:1 odpovídat tomu, co s tím názvem dělá OS.
Co jsem se dočetl, tak jediný spolehlivý způsob na windowsech je daný soubor otevřít a vyčíst surové jméno z hlubin filesystému. Pokud mám jen jméno souboru, tak spolehlivý způsob AFAIK neexistuje.

Představte si Google, jak by to bylo zábavné, kdyby vyhledával case sensitive :).
Představte si, že jde napsat case-insensitive vyhledávání souborů nad case-sensitive souborovým systémem. Ano, vědci už to opravdu dokázali a v posledním století se tak můžete v linuxových distribucích potkávat s příkazem find, který touto naprosto zázračnou technologií disponuje.

Vy si zase zkuste představit, jak by bylo zábavné, kdyby Google s adresami (které odpovídají názvům souborů, na rozdíl od obsahu, ve kterém Google především hledá) zacházel case-insensitive a velká a malá písmena v URL by prostě vybral náhodně.

> Představte si Google, jak by to bylo zábavné, kdyby vyhledával case sensitive :).

Google robí aj stemming. Predstavte si, aké by bolo zábavné, keby to robil aj operačný systém pri otváraní súborov :)

k tej krabici, aj škatula je krabica je to to isté, má to byť to isté aj v PC? To som zvedavý ako tam implementuješ synonymá.

k tej krabici, aj škatula je krabica je to to isté, má to byť to isté aj v PC? To som zvedavý ako tam implementuješ synonymá

Myslím, že když někomu po telefonu řeknu "najdeš to v souboru krabice tečka té-iks-té", tak si škatuli nedomyslí. Ale nedomyslí si ani to, jestli jsem "mluvil" malými nebo velkými písmeny.

Chlapi, trochu se dívejte do praxe, co lidi potřebují. Jinak ajťáci budou dál považováni za autistická paka.

Miroslav Šilhavý: My se do praxe díváme, co lidé potřebují. Akorát to děláme v našem vesmíru, ne ve vašem. V našem vesmíru, když někomu řeknete do telefonu jméno souboru [krabice tečka té-iks-té], najde si ten soubor ve správci souborů, v dialogu pro otevření souboru, nebo si ho nechá doplnit – pokud název souboru bude psát (což ale bude dělat jedině ajťák).

Ve vašem vesmíru samozřejmě nic toho neexistuje a jediná možnost, jak uživatel zadá jméno souboru, je ta, že název souboru přesně napíše.

Je pozoruhodné, když o praxi píše někdo, kdo praxi nahrazuje svou bujnou fantazií.

V našem vesmíru, když někomu řeknete do telefonu jméno souboru [krabice tečka té-iks-té], najde si ten soubor ve správci souborů, v dialogu pro otevření souboru, nebo si ho nechá doplnit

Možná uvedu jiný příklad: ulož mi svoji práci do krabice.txt.
Uživatel bezmyšlenkovitě napíše krabice.txt a nevšimne si, že už tam existuje i Krabice.txt a vytvoří nesmyslný "reálný" duplikát.

Case sensitivita v OS při práci s filesystemem nemá žádný smysl, kromě podpory líných programátorů a adminu, kteří si nechtějí připustit nic jiného než to, co vzniklo někdy v sedmdesátých letech (kdy pro to existovaly opravdové důvody).

Zajímavé je, že opravdu úspěšné uživatelské systémy jsou case insensitive - asi mají málo odborníků, aby přišli na to, co je vhodnější.

Filesystém v macOS je samozřejmě case sensitive.

Filesystém v macOS je samozřejmě case sensitive.

Filesystem ano, OS to ale nepovolí. Úplně stejně jako Windows a NTFS.

A jako bych ti tu už před pár hodinami nepsal, že FS má být vaše sensitive ale jiné úrovně abstrakce ne v nutně... aby sis tu pak pořád mlel svou.

A jako bych ti tu už před pár hodinami nepsal, že FS má být vaše sensitive ale jiné úrovně abstrakce ne v nutně... aby sis tu pak pořád mlel svou.

:) jenže to samé, než jste to psal Vy, jsem psal už pár hodin před Vámi i já.
V tomto vláknu se neřeší nuance mezi FS a OS API, řeší se, jak se na to dívá uživatel a jaké vnější chování očekává za správné.

Stejně řešíme sračky.

"řeší se, jak se na to dívá uživatel a jaké vnější chování očekává za správné."

+1 jen bych "ocekava za spravne" nahradil "je pro nej nejmene problemove"

Ale povolí.

V macOS je možné filesystém naformátovať buď ako case preserving alebo ako case sensitive. Ako Windows sa správa iba v prvom prípade, v druhom ako bežný Unix.

V macOS je možné filesystém naformátovať buď ako case preserving alebo ako case sensitive. Ako Windows sa správa iba v prvom prípade, v druhom ako bežný Unix.

Ale to samé je Windows a NTFS, viz příkaz fsutil.exe file setCaseSensiti­veInfo

Jenže jak Mac tak Windows to nedoporučují, jak kvůli kompatibilitě, tak i kvůli přívětivosti.

V macOS je možné pri formátovaní určiť, či má byť filesystém case sensitive alebo case preserving.

Case preserving je legacy, pretože niektoré aplikácie dodnes nezvládajú case sensitivity (a nie je to celkom problém len samotných aplikácií, ale aj súborov, ktoré používatelia majú po svojich archívoch, obsahujúcich referencie na iné súbory bez ohľadu na veľkosť písmen). Takže používatelia macOS majú odporúčanie, že pokiaľ si myslia, že niekedy budú potrebovať Photoshop, tak nech formátujú iba case preserving.

Miroslav Šilhavý: Možná by bylo lepší, než vymýšlet nesmyslné příklady, zamyslet se nad tím, co tvrdíte. Úplně stejné problémy vzniknou, když bude mít název souboru víc slov nebo diakritická znaménka. Podle té vaší teorie je jediný správný přístup 8+3 používaný na FAT. Vůbec nejde o líné programátory a adminy. Jde o uživatele, protože pro ně je nejjednoduší vědět, že jméno soubor je takové, jak ho zadal, a nemusí se učit žádná pravidla o tom, co se považuje za stejné a co ne.

Jediný úspěšný case insensitive systém jsou Windows. A tam je to právě kvůli té „lenosti“ programátorů, protože při přechodu z DOSu, který používal jen jednu velikost písmen, by se spousta aplikací rozbila. Všechny ostatní systémy velikost znaků rozlišují – Apple, Android, unixy, Google Suite, celý web, Dropbox, ownCloud…

"pro ně je nejjednoduší vědět, že jméno soubor je takové, jak ho zadal"

Nejjednodussi pro uzivatele jsou v tomto smeru Google docs (a mozna jeste neco dalsiho co neznam) kde zadna jmena souboru vubec nepotrebujete. Vytvoreny dokument (ne soubor!!!) bud nejak pojmenujete, nebo ho v seznamu vidite jako "Dokument bez nazvu" (kterych tam pod timto labelem muze byt libovolny pocet) a hledate fulltextem primo v obsahu. Pokud dokument nema obsah z nehoz by mi na pameti vytanulo nejake klicove slovo, napisu pri vytvoreni do nazvu dokumentu (ne souboru) nahodile par slov ktera obsah charakterizuji a pod kterymi bych to mohl pripadne v budoucnu chtit hledat. Od roku 2009 kdy to pouzivam se mi snad jeste nestalo ze bych neco nenasel. Ze je to v cloudu neni pro tento pripad vubec rozhodujici..

Podle me je ostuda programatoru ze v roce 2020 uzivatel jeste musi o existenci neceho jmenem soubor vubec vedet....

Ach jo.

> alebo,ze to je dokonca problem pouzivatela?

Nikdo netvrdí, že se jedná o problém uživatele.

> Git server

Je jasné, že pokud spolu komunikuje case-sensitive a case-insensitive systém, je třeba se tomu nějak přizpůsobit. Můj point jen byl, že mi case-senstivie přijde zbytečně moc vyžadující přesnost u věci, kde to v drtivé většině případů nemá význam (resp. nevím o nikom, kdo by např. měl rád soubory, jejichž názvy se liší pouze velikostí některých písmen). To je celé.

> Kolko rokov mate skusenosti v obore?

13. Takže vím, že když nedejbože case sensitivity využiji, tak unixáři začnou brblat, že musí ta velká písmenka mezi malými "hledat"... a když se odvážím do názvu dát dokonce takový netradiční znak, kterým je mezera, tak to už je oheň aspoň na třech střechch...

Můj point jen byl, že mi case-senstivie přijde zbytečně moc vyžadující přesnost u věci, kde to v drtivé většině případů nemá význam (resp. nevím o nikom, kdo by např. měl rád soubory, jejichž názvy se liší pouze velikostí některých písmen). To je celé.
Nejde o to, že by někdo chtěl mít vedle sebe dva soubory, které se budou lišit jenom velkým písmenem. Problém je v tom, že nedokážete určit, kdy na velikosti písmen záleží a kdy ne. Tedy case-insensitive souborový systém nejde udělat správně. Správně jde udělat souborový systém, který zná třeba jen malá písmena. Ten je správně case-insesitive – když zadáte velká, převede se to na malá a dál se pracuje s tím. Jenže NTFS ve skutečnosti někdy velká a malá písmena rozlišuje a někdy ne. Protože byste v dnešní době nechtěl, abyste si uložil soubor „Smlouva o prodeji.txt“ a zobrazilo se „smlouva o prodeji.txt“. Záleží tedy na kontextu, v jakém s názvem pracujete, zda se má velikost písmen brát v úvahu nebo ne. Kontext nezná OS, ale aplikace. Takže by to muselo být správně implementováno v každé aplikaci. Což je utopie.

Nemyslím si, že by uživatelé měli s case-sensitive souborovým systémem problém. Zejména na Windows, kde se jména souborů píšou velmi málo, spíš se vybírají.

Tak tak...tento pan vystihol, presne tu pointu.

10. 4. 2020, 21:11 editováno autorem komentáře

"Nemyslím si, že by uživatelé měli s case-sensitive souborovým systémem problém. Zejména na Windows, kde se jména souborů píšou velmi málo, spíš se vybírají."

Stalo se mi zrovna nedavno ze jsem psal parametry programu curl a namisto -o jsem vytrvale psal -O a divil se proc to nefunguje jak chci. Trvalo chvili nez jsem se podival do dukumentace a zjistil svuj omyl. Nejen useri podvedome vnimaji 'o' i 'O' jako jedno pismeno a nedostatek pismen k poctu voleb by se klidne dal resit zpusobem -oa -ob -oc atd... pan Silhavy ma naprostou pravdu v tom, ze v IT vyhravaji firmy ktere nejvice dokazi prizpusobit techniku lidem. linux ma 1% na desktopu mimo jine proto, ze jeho komunita laickymi uzivateli pohrda (oznaceni BFU to myslim plne vystihuje i kdyz se to budete pokouset schovavat za pouhou legraci).

Case sensitivita command line parametrů je ale úplně nezávislá na case sensitivitě filesystému. I nástroje od Microsotfu v tomhle bývají case sensitive.

Commandline není úplně dobrý příklad pro přizpůsobení techniky lidem, protože je to nástroj pro pokročilé. Tyhle věci se navrhují primárně pro efektivní užívání znalým člověkem a ne pro intuitivní použití laiky. Tohle vůbec není nějaké specifikum IT. Ovládání pro profesionály se holt řídí trochu jinými pravidly.

"Commandline není úplně dobrý příklad pro přizpůsobení techniky lidem, protože je to nástroj pro pokročilé. Tyhle věci se navrhují primárně pro efektivní užívání znalým člověkem a ne pro intuitivní použití laiky. Tohle vůbec není nějaké specifikum IT. Ovládání pro profesionály se holt řídí trochu jinými pravidly."

Vidite, ja se rozhodne nepovazuju za laika a muj mozek obcas zachazi s 'o' a 'O' jako jednim znakem (zvlast kdyz je treba vecer a mozek uz nefunguje na 100%). Nevim cim to je, ale pozoroval jsme to behem tech let i u nekterych dalsich kolegu. Navic v tomhle binarne delit lidi na laiky a profesionaly mi neprijde statne, zvlaste pokud nemame po ruce zadny vyzkum ktery by prokazoval jak lide sensitivitu vnimaji obecne, ne jen v kontextu IT.

Já to rozhodně nedělím na dvě striktně oddělené kategorie. Ale jako hrubé neostré pravidlo beru, že pokud někdo něco dělá pravidelně, tak má trochu odlišné představy o tom, co se mu dobře používá.

A pokud mi mozek nefunguje na 100%, tak má commandline daleko horší pasti než case sensitivitu. Co třeba l, i a 1? Delší identifikátory poskytují více prostoru zase takovýmhle překlepům.
Osobně se ve stavu, kdy mám problém s o a O, snažím držet od věcí jako je commandline nebo cirkulárka co nejdál. Některé věci jsou past vedle pasti a zalepení jedné způsobí dvě další.

> a když se odvážím do názvu dát dokonce takový netradiční znak, kterým je mezera, tak to už je oheň aspoň na třech střechch...

a ste si istí, že je to medzerou? Medzi /home,. /Users a "C:\Documents and Settings" je viac rozdielov ako len medzera, a medzera nie je práve ten faktor, ktorý robí posledné menované najhoršou voľbou.

> a ste si istí, že je to medzerou?

Hůře se s takovým jménem pak pracuje v terminálu popř. ve skriptech.

> "C:\Documents and Settings"

Tohle už je dlouho (od Windows Vista?) jen symlink existující z důvodu zpětné kompatibility. Aktuální je C:\Users. Nicméně by mě zajímaly i další faktory, proč je poslední jmenované nejhorší volbou :-).

> Nicméně by mě zajímaly i další faktory, proč je poslední jmenované nejhorší volbou :-).

Pretože v časoch pred Windows 10 bolo MAX_PATH = 260, čo zahŕňalo aj disk "C:\" (3) a null-terminating byte (1), takže pre používateľa 256 znakov na celý názov súboru, vrátane všetkých adresárov. Keď si z toho ukusne "Documents and Settings" 23 znakov, (zatiaľ čo taký "home" by zobral len 4), veľmi ľahko sa stane, že bežný používateľ narazí na to, že mu niečo nejde skopírovať napr. z CD alebo USB disku.

Alternatívne sa mu mohlo stať, že keď aplikáciu, ktorá použila raw api a tá obišla Win32, tak mal adresár, ktorý nemohol zmazať, pretože Explorer Win32 neobchádzal.

(Áno, ja viem, že je to limit Win32 a nie NTFS, ten zvláda 32K, ale z pohľadu používateľa systému je to jedno, ten narazí na nižší limit).

> Alternatívne sa mu mohlo stať, že keď aplikáciu, ktorá použila raw api a tá obišla Win32, tak mal adresár, ktorý nemohol zmazať, pretože Explorer Win32 neobchádzal.

Použitím Unicode API bylo možné protáhnout délku celého názvu na 32K cca, ale uznávám, že se určitě našly funkce, na které se v tomto ohledu zapomnělo. A bylo třeba přidat magický prefix.

On měl Windows Explorer daleko větší problém v tom, že používal ANSI API, takže nebylo třeba sahat k MAX_PATH, ale stačilo v názvu použít vhodný Unicode znak, který se při překladu do ANSI "ztratil".

tohle ale přece není problém toho, jestli je lepší mít insensitive či sensitive, ale o tom, že nejsou navzájem kompatibilní. Git client na Windows by se měl přizpůsobit a zajišťovat tuhle kompatibilitu, ntfs s insensitive tady bylo dříve než přišel git client.

Za mě nejvíce problémů tvoří právě SW, který si myslí, že jen jeho cesta je nejlepší a ostatní ignoruje nebo dává překážky.

To není o tom, že by autoři gitu něco cíleně ignorovali. To je jenom o tom, že case-insensitive práce se soubory je dost komplikovaná a snáze se tam udělá chyba.