Case sensitive jmena trid a promennych je naopak velmi dulezite. Trida se jmenuje Config a jedina jeji globalni instance se jmenuje config.
V pripade souboru je to diskutabilnejsi, ale od okamziku, kdy je mozne mit v nazvu mezery a utf znaky je ignorovani velikosti pismen v podstate nemozne. V ascii jeste ano, ale nejake velke A s dvema teckama nahore a ocaskem dole, jak ho prevedes bezpecne na jeho lowecase variantu? Kdyz v dobe psani tveho programu tento znak jeste nebyl definovan a je to treba kombinace nekolika kodu (glyf)?
Trida se jmenuje Config a jedina jeji globalni instance se jmenuje config.
Jenže v různých jazycích se to intepretuje různé a je jiná konvence psaní. V Golangu Config znamená, že je to public funkce (struktura, datový typ) a lze jej použít i z jiného package. A config je private a dostupný jen v package, kde je definován.
Já sám na FS uznávám malá a velká písmena jen pro snadnou čitelnost jmen souborů. Ale pro FS to klidně může být tentýž soubor a budu moc rád, když mě upozorní na to, že soubor "Vyúčtování 2024.odt" už tam jednou je a jmenuje se "VYUCTOVANI_2024.odt". Tenhle úklid vždy jednou za rok dělám manuálně, takže letos jsem takto smazal 3x skeny stejného dokumenty z 2023. Mám scanner napojený na FreeBSD, takže tam používám pouze ASCII znaky bez znaku space. (FreeBSD je pochopitelně plně Unicode, ale mě se to na anglické klávesnici prostě nechce psát česky.)
27. 4. 2025, 11:56 editováno autorem komentáře
"samozřejmě používám v názvech souborů pouze malá písmena bez diakritiky, čísla, pomlčky, podtržítka a tečky. Holt oldschool zvyk"
To neni oldschool zvyk to je nutnost. V okamziku kdy zacne clovek vyvijet pro vic systemu nez jeden jediny pak narazi na omezeni a problemy. Uz jen takova diakritika dela paseku az, az. Takze si clovek rekne ze to bude na jistotu nez aby hodiny resil proc je jednou č a jindy ç v nazvu souboru.
Uz jen takova diakritika dela paseku az, az.
Tady by mě zajímaly konkrétní příklady. Protože všechny OS, které tvrdí, že umí Unicode, jej skutečně plně umí. Windows má fonty se všemi Unicode znaky, Linux taky, FreeBSD taky. Stahuju si kreslené obrázky z webových gallerií, protože já fotím a kreslit neumím a na disku mám soubory ze všech jazyků na světě. Tohle zálohuju na FreeBSD kde se to také zcela stejně jako ve Windows zobrazuje správně. dtto na Linuxu.
Každý programovací jazyk, který umí unicode, jej současně umí. Golang má hello world napsané ve všech jazycích, které podporuje. Takže Ahoj Světe! Česky a potom čínsky, anglicky, azbukou, všemi čínskými dialekty, japonštinou, korejštinou a jihoamerickými jazyky včetně španělštiny.
To, že Windows s velkou výhodou používají interně UTF-16 a Linux UTF-8 je věcí pouze implementace, ale na zobrazení a použití v programovacím jazyku to nemá žádný vliv. Soubor s daty v Golang GOP si klidně zobrazím na Linuxu nebo FreeBSD.
Takže žádné problémy s diakritikou nejsou a implementační detaily jazyků a OS jsou pouze detaily (a to včetně bit order Little Endiand a Big Endian na některých ARM a RISC procesorech). Java, Python, Golang jsou plně Unicode na všech HW platformách a na všech podporovaných OS. Ten kód stačí napsat jednou. A ano, už mi běží i jeden můj Unicode golang program i na bigendian RISC V-něco.
28. 4. 2025, 17:29 editováno autorem komentáře
Zapni si widle ... a napis pro ne vicemene hello world ... kdy vypises dir. A ... vopupinkujes se z toho. Protoze budes muset resit nejmin 3 ruzny charsety. V tomhle pripade UNICODE na NTFS, win-1252 v okne a cp 852 v cmd. A to uvazuju jen cestinu ... a jen ty widle.
Pak k tomu pripoj tuxe, udelej si na tom nejake ten smb share ... a kup si becku slivovice.
To si nejsem jistý, že je správný výklad vzhledem k tomu co napsal předtím...
"Case-insensitive names are horribly wrong..."
A vzhledem k tomu, že k tomu konci píše, že to je jako FAT (který nemá sensitivitu) to pro mě to byl spíše povzdech, že by se něco takového jako sensitivita nemělo řešit a znak má být prostě znak.
Je to ale úplne naopak. On píše že insensitivity je BUG, nie sensitivity... takže naopak case-sensitive je správne. A áno, je to správne. Pretože jednoducho ako tu už bolo spomenuté je tu buď všetko jeden znak, alebo môžeš riešiť výnimku s výnimky a riešiť ako určitú kombináciu spojenú do nejakého znaku ako A s chvostíkom a dvomi krúžkami a neviem čo, prevedieš na malú variantu. Navyše že je to BUG máme už skúsenosť z Windows kde to robí poriadnu paseku pri programovaní (jeden súbor môže byť interpretovaný ako subor.pdf alebo Subor.pdf alebo SUBOR.pdf alebo SuBOr.pdf alebo čokoľvek čo ťa len napadne? Potom ako toto pohandluješ? A ako vyriešiš že keď budeš musieť (a to skutočne budeš musieť) riešiť konflikty lebo case-insensitive jazyk môže mať práve rôzne varianty sensitivity pre identifier.
Už z Windows a NTFS máme skúsenosť aký problém to robí. Len sa pozrí do implementácie trebárs NodeJS alebo Pythonu alebo čo len chceš a pochopíš ako je case-sensitive FS špatná vec. Aneb, keď pre poriešenie tohoto potrebuješ sto tisíc riadkov kódu navyše.
Nie, case insensitive je BUG.
Jen poznámka k tomu vtipu: Stále mě zajímá, kdy projekt GNU bude mít použitelný vlastní kernel a z názvu zmizí ono "/Linux". O projektu Hurd vím, ale vůbec nevím, jestli by šel nainstalovat na aktuální x86 64b Procesor (AMD nebo Intel).
Hmm latest release je 2016. Takže na CPU z roku 2025 to možná půjde nainstalovat, ale o nejnovější instrukční sadě AVX512 v Ryzenech to nejspíš vůbec netuší.
27. 4. 2025, 13:37 editováno autorem komentáře
Paradoxně, to samé Windows NT. Což jsem nějakou dobu nevěděla, a docela mi to zavařilo, když jsem na Windows z Linuxu omylem vyrobila vedle existujícího adresáře "Config" adresář "config". Windows se pak k těm dvěma adresářům chová dost nevyzpytatelně :D
27. 4. 2025, 16:46 editováno autorem komentáře
On jde i macOS nakonfigurovat, aby se choval správně. Ale...
Ostatně nebyl by bez toho POSIX. Takže většinou není POSIX.
https://www.osnews.com/story/141633/apples-macos-unix-certification-is-a-lie/
V dávné době se objevila řada situací, kdy se o něčem tvrdilo, že je to case in-sensitive, ačkoliv nebylo. Příkladem je třebas FAT. Těžko říci, zda je nebo není case sensitive. Dovoluje totiž jen velká písmena. Malá písmena do názvů napsat nešlo. DOS zvolil cestu, že malá písmena zadat dovolil, ale automaticky je konvertoval na velká.
Podobně to bylo třebas s case (in)sensitive názvy objektů v Oracle. Prostě se vše konvertovalo na velká písmena. Malá písmena jste do názvu nedostali. Takže ačkoliv to bylo case sensitive, tak se to jevilo jako case in-sensitive. Teprve časem přibyla možnost použít název v uvozovkách, který nic nekonvertuje a tak jste plně case sensitive.
Historie je prostě trochu divoká a plná hacků, které nás dodnes dokáží překvapit (nemile).
Smyl hlavne nedava dat do tak lowlevel mist jako parser jazyka nebo FS neco, co resi case sensitivitu. On svet neni jen latinka a ta zmena sensitivity neni jenom pricteni/odecteni rozdilu A-a.
Nemluve o tom, ze to menit ted, znamena rozjebat vsechno na x roku dopredu.
27. 4. 2025, 12:53 editováno autorem komentáře
Ten problém je i v latince, minimálně v turečtině: https://en.m.wikipedia.org/wiki/Dotted_and_dotless_I_in_computing
Nejspíš ne. Existuje řada nesmyslných způsobů, jak pojmenovat soubor. Víc mi vadí dvě mezery za sebou a chybějící nebo naopak přebývající diakritika.
Tak proč ta fixace na velikost písmen? Proč zrovna tohle se má řešit na úrovni jádra pro něco jiného než legacy kompatibilitu (fat...)? Navíc se podle všeho dnes už ví, že to nejde vyřešit pořádně.
Samozrejme že nejde, najmä keď tu máme písmená zložené z viacerých znakov, potom tu máš znaky ktoré nemajú 2 varianty pre case-sensitivitu (napríklad veľká bodka vs malá bodka) atď... vo Windows to jednoznačne nefunguje a bežne sú tam problémy s týmto. Trebárs taký runtime pre Python alebo NodeJS majú nad prácou s FS ešte wrapper, kde toto riešia a pre NTFS (Windows) tam majú o stovku tisíc riadkov kódu viac a aj tak je na Githubu plno reportnutých BUGov že niečo sa rozbilo.
Ja sa ta spytam ale inak,
Existuje tranformacia a inverzna transformacia jednoznacka?
lowercase -> uppercade -> lowecase
tak aby vzdy za kazdych okolnosti vzniklo to iste?
Kedysi ano, dnes uz nie.
Napriklad:
print('straße'.upper()) => STRASSE
print('SS'.lower()) => strasse
straße != strasse
A toto je len ceresnicka na dorte.
V dnesnom svete je riesit nieco case insensitive je zahravanie sa s ohnom.
A je to dalsi vektor ku potencionalnych bugom, bezpecnostnych rizik ...
Tak zaverom je mozne akceptovat case insetivite napriekntomu ze neexistuje jednoznacna inverzna transformacia po tranformacij aby sme dostali vzdy povodne (male -> velke -> male) ...
Náhodou mít už v jazyku "zabudované", že je insensivite je super. Nejde o počítač, ale o lidi. Odpadá milion problémů - nejen s pojmenováním souborů - prostě config.ini a Config.ini nedáš - ale i názvů všeho možného, všechny ty různé hromady guidelines Builder class vs build instance, neskutečná srágora, tohle odpadá ...
Linus to ještě asi nezmění, ale příští generace operačních systémů - až je bude psát AI pro svoje účely - bude možná primárně v arabštině, čínštině nebo prostě v něčem case insenstive. Nebo spíš možná rovnou v bináru - 0,1. Co bude AI do lidí :-)
Nesúhlasím. Je tu xyz dôvodov prečo to dokonca môže byť veľký problém. Napríklad slovo vs skratka zložená zo stejných písmen má 2 úplne iné významy a ty to budeš musieť nejak rozlíšiť. Ak to hovoríme na úrovni "user interface". Ale inak nedáva zmysel aby bol case-insensitive. FileSystem musí byť vždy case-sensitive, inak to vedie len k problémom... v programovaní existuje jeden princíp volá sa "KISS" aneb Keep it Simple, Stupid. A jednoduché je ak máš jednoducho pravidlo že 2 zhodné reťazce = stejný názov a 2 zhodné reťazce... ak by sme mali "subor.pdf" a "SUBOR.pdf" to sú už rozdielne reťazce. Vždy to tak bude, už z princípu.
27. 4. 2025, 21:33 editováno autorem komentáře
není to super. když je něco case sensitive, chce to config.ini a ty tam cpeš CONFIG.INI, tak tě to seřve, jak malýho kluka, že tam prostě ten správnej soubor nemá, ty to napravíš a navždy to bude fungovat.
Naproti tomu, když to máš case insensitive, tak to možná bude pěkně fungovat s config.ini a CONfig.ini, ale ve složitějších abecedách se začnou kupit výjimky, výjimky z výjimek, rozdíly mezi systémy a jednotlivými implementacemi.
A najednou to někdy a někde fungovat bude a někdy a někde ne. A to je mnohem víc nahovno, protože jakýkoli hledání chyb je pak složitější, přináší to nečekané problémy (dělá to jen někdy), navíc se ti to bude měnit pod rukama, protože si někdo vzpomene, že chce přidat pár dalších písmenek nějaký další abecedy a zase ti něco někde nebude fungovat, jak by mělo.
Když se jednou zařídíš podle toho, že CoNFiG != config, tak ti to od tý doby všechno a všude funguje. Pokud ne, tak ses spletl ve velikosti písmen, opravíš a jedeš.
Navíc v nějakejch low power embeded systémech asi fakt nechceš nějakej moloch který řeší, jestli je naše velký měkký I stejný jako malý i ale odlišný od malého ı, a jak je to s velkým dotless I, jestli je stejné jako naše I a jak je to případně s velkým İ s tečkou. Je prostě daleko jednodušší říct, že jsou to vše odlišné znaky a hotovo. Souborový systém není beletrie, jde pouze o to, jak najít nebo nenajít konkrétní soubor s daty.
Jenze ty to resis uplne jinde nez je to resit treba.
Vezmemez tvuj post, proc by v databazi mel byt jako casesensitive? Necht databaze zbavi ten text nabodenicek a ulozi to vsechno jako velka pismena.
Fs neni nic jinyho nez specificky druh databaze. A minimalne presne v okamziku, kdy nekdo akceptoval, ze se nazvy budou psat s nabodenickama, tak proste musi zarove akceptovat, ze budou case sensitive.
Zajimavy je, ze ty databaze nasledne nemaji vubec zadnej problem v tom, ze kdyz to tazatel chce, muze ten dotaz (pokud to dava nejakej smys) poslat v rezimu bez nabodenicek a bez case ze? Ale ta databaze porad vi, ze tam ma 100x totez, jen s jinak velkejma pismenkama.
Náhodou mít už v jazyku "zabudované", že je insensivite je super. Nejde o počítač, ale o lidi. Odpadá milion problémů - nejen s pojmenováním souborů - prostě config.ini a Config.ini nedáš - ale i názvů všeho možného, všechny ty různé hromady guidelines Builder class vs build instance, neskutečná srágora, tohle odpadá ...
Přesně tak. Case-sensitive FS je jen výsledek zjednodušení celé problematiky (neboli lenosti), které neodpovídá realitě. Takový mezikrok - chci to (FS) pro lidi (human-readable jména), ale jsem línej to implementovat pořádně... neboli klasický nerdovský přístup.
Za mňa je bug dovoliť vytvorenie 2 súborov, ktoré sa líšia len case v nejakom znaku. Z toho môžu byť len problémy, nie je to blbuvzdorné, pre používateľa nezmyselné a niekedy to môže byť nebezpečné. Ak nejaký systém podporuje unicode znaky tak potom by mal obsahovať aj nejakú unicode knižnicu a prevod case nemôže byť problém.
A čo v prípade ak máš slovo a skratku zloženú zo zhodných znakov ako to slovo? To nebudeš rozlišovať? Ešte aj v jazykoch (teraz myslím Angličtinu, Slovenčinu, Češtinu a pod, nie prog. jazyky), rozlišujeme veľké a malé písmená. Vždy sa to musí nejak rozlišovať. Jedine že by sme zmenili jazyk a zrušili veľké písmená úplne.
Ked citam komentare musim aj ja pridat komentar.
Zoberme si to po poriadku. Ked si zobereme programovacie jazyky C, C++, C#, Golang, Rust, Python, Java, Javascript, LUA, PHP, Ruby, Perl, TypeScript atd atd
Si mozete vsimnut ze to je case-sensitive.
Nevidim ani jeden dovod, preco si komplikovat u nazovoch suborov a adresarov robit zbytocnu robotu a pridavanie dalsieho vektoru moznych chyb, bezpecnostnych rizik tym aby som mal nazvy suborov a adresarov case-insensitive. Je to nieco co je uplne zbytocne a nelogicke.
Vratme sa do minulosti. Vratme sa do doby kedy sme mali len ASCI a to ASCI bez diakritiky cize len 0-127 . Tam sa to riesilo jednoducho tam si len jeden u jedneho bitu zmenil hodnotu. Cize podmienka ORD > 64 and ORD < 91 and ORD > 96 and and ORD < 123 , tymto si podmenil a-zA-Z.
Nasledne siesty bit urcoval velkost pismena. Ak bola logicka 1 tak male pismeno aj 0 tak velke pismeno.
Takze takze nebol problem spravit podmenku ORD > 64 and ORD < 96 a nasledne bitovovy operaciu alebo jednoducho pricitame 32 cize chr(ord(b)+32) kde b je pismeno. Toto si potom daj do cyklu. Takto jednoducho sa riesilo kedysi ako v pythone string.lowercase()
U starych suborovych systemov kde si bol na nazov suboru limitovany ASCI 0-127 tak to nevadilo. Ale kedze mozeme do nazvu suboru pridat znaky z Unicode tak to problem.
Dnes? To uz je alchymia. Uz sa nemozes spolahnut rozdielom 32 (jedneho bitu) tato vlastnost sa nezdedila. Okrem zpetnej kompaktibility A-Za-z tam ti plati.
Musis mat databazu pomocou ktoreho robis prevod. To ale neni problem. Dnes kedy uz nemusime pocitat kazdy jeden byte, kazdy jeden strojovy cyklus toto nevadi.
Problem ale nastava ze existuju pismena s diakritikou, ktore nemaju svoj naprotivok vo vztahu (male - velke alebo naopak). Tak nikdy nespravis prevod spolahlivo. Na vacsinu pripadov ano, ale nie pre vsetky pripady.
A to este nehovorim ze v unicode mame pisme ktore vyzeraju velmi podobne ako klasicke A-Za-z z asci ale maju svoj vlastny unicode a nemaju naprotivok. Cize aj sme prevod aproximovali na A-Za-z tak pri zpetnej transformaci sa nedostaneme na zaciatok. Cize stratime co za pismeno to bolo.
a mohol by som este pisat dalej.
Ale tu je jasne vidiet ze case-sensitive je akysi prezitok z minulosti u ktoreho sa zistilo ze to vytvara omnoho viacej problemov ako uzitku, obzvlast ked si v nekontrolovanom prostredi ako uzivatel a jeho pomenovanie a umoznenie do nazvov suborou cpat znaky z unicode.
To, že niektoré programovacie jazyky sú case sensitive ako súvisí s filesystémom? Názvy domén sú case insensitive a majú bližšie k filesystému ako programovacie jazyky. Súbory používajú normálni ľudia a dva súbory s rovnakým názvom spôsobia len problémy a diktovať niekomu názov súboru s špecifikovaním pri všetkých písmenách či sú veľké, alebo malé nie je úplne prakticé. Case sensitive súbory sú len vecou lenivosti, alebo neznalosti programátora, existujú knižnice ako ICU (príčetná implementácia FS musí predsa aj tak vedieť zložitejšie veci, aby vedela zoradiť názvy podľa abecedy) a ak pre nejaký znak neexistuje capital varianta, tak to predsa znamená, že s ním nie je žiaden problém, lebo ho netraba nijak transformovať.
Na to aby si to mohol pouzivat musi byt aj naprogramovane. To ze to ty neprogramujes neznamena ze to niekdo pre teba neprogramoval a mas program.
Dalsia vec neexistuje jednoznacna transformacia v celom rozsahu male -> velke -> male
napriklad:
print('ß'.upper()) da na SS
print('SS'.lower()) sa ss
ß != ss
Ako som pisal vznika zbytocny priestor na bugy a ked vdaka bugu pridas o data to ti uz bude vadit
a toto co pisem je len ceresnicka na dorte kolko s tym je problemov a nemusi to byt.
Tu nejde o prikazovani. Ale o chybach, bugoch, necakanych chovaniach , vektory utoku atd.
Zbytočne hľadáš problém, všetko musí niekto naprogramovať. Ako dokázali spraviť find -iname? Aj pri tých doménach to nejak museli vyriešiť. Na overenie jedinečnosti názvu súboru nepotrebuješ prevod veľké>malé>veľké. Stačí napr. hocičo>malé. A ešte aj z toho môžeš spraviť hash pre zrýchlenie nejakého indexu. Vektor útoku je akurát keď si spravíš skript RunMe, nastavíš mú práva na seba a potom niekto iný spraví Runme a omylom spustíš Runme.