Vlákno názorů k článku OpenAI má zájem o Chrome, vylepšování budoucí KDE Plasmy 6.4.0 pokračuje od martyd420 - Existuje aspoň jeden jediný případ, kdy dává smysl...

Existuje aspoň jeden jediný případ, kdy dává smysl mít v adresáři 2 soubory s názvem třeba config.ini a Config.ini, přičemž každý má jiný obsah a účel? Case-sensitive v názvech souborů (tříd, namespaců, ...) je zlo.

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

Jeste jsem chtel dodat - unix ma od uplneho zacatku case sensitive file system. Linux je Unix. Takze Linux ma case sensitive file system. Jakykoliv pokus pridat do linuxu case insensitive file system je predem odsouzeny k nekompatibilitam a problemum s existujicimi programy.

Ze to ma od zacatku neznamena, ze je to spravne. Jak Linus pise na zaver sveho rantu:

"...Case sensitivity is a BUG. The fact that filesystem people
*still* think it's a feature, I cannot understand..."

:-) ???

27. 4. 2025, 09:54 editováno autorem komentáře

Tomu nerozumím. Jako člověk od fochu bych měl snad chápat, že "a" !== "A" a tečka.
Dělat nějaké výjimky, kde to neplatí, pak výjimky z výjimek... to je cesta do pekel.

podľa mňa väčšna ľudí, čo používa filesystém, nie je od fachu

Jako "člověk od fochu" 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 no...

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.

To ale byl "překlep", ze zbytku textu je naprosto jasné, že měl na mysli insensitivity.

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.

Nerikam co je nebo neni bug, pastnul sem to co Linus napsal do kernel mailing listu. Sam si to tam muzes najit...

GNU/Linux není Unix.

GNU Not Unix ? ;-D

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

Na úplně stejný problém jsem narazil na macOs. Dokud jsme měli všichni Linux, nebyl problém. Ve zdrojácích byl adresář Resources a resources. Po git clone na macOs a pár změnách se děly věci :D.

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).

Jenze si musis uvedomit, za na tu fatku slo predevsim zapsat jen a pouze ASCII znaky. A ty maji dost jasny prevod mezi malou a velkou variantou.

Legracni to zacne byt az s treba ů ... sem zvedav jak to prevedes na to velky pismeno.

Když hledám nebo chci otevřít soubor config.ini, tak neočekávám soubor CoNfIG.InI. Pak to strašně mate. Identifikátory by se měly jmenovat stejně.

27. 4. 2025, 10:28 editováno autorem komentáře

Ale riesit to vie napriklad priamo aj bash:
nocaseglob - If set, bash matches filenames in a case-insensitive fashion when performing pathname expansion

$ shopt -s nocaseglob
$ ls -d l*
LicBak
license.dat
Lists
Logs
LUTs

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) ...