di  -  mercoledì 29 aprile 2009

Nella letteratura informatica quello dei filesystem è un argomento particolarmente caro, ampiamente trattato e sul quale la ricerca non manca; anzi. D’altra parte è anche prevedibile, considerata la loro importanza: è questo “pezzo di codice” a cui affidiamo i nostri dati (a cui ovviamente teniamo).

Si parla spesso di prestazioni, di ottimizzazione dello spazio occupato, di deframmentazione di file e cartelle, ma molto raramente viene affrontato l’argomento del case per i nomi.

Sì, perché esistono fondamentalmente due “scuole di pensiero”: quella che li vorrebbe insensitive (non c’è differenza fra maiuscole e minuscole nei nomi) e l’opposta che parteggia per il case sensitive. Da anni sembra scontato che quest’ultima sia LA strada da seguire, ma siamo veramente sicuri che debba esser così?

Innazitutto è da premettere che esiste un’altra qualità che un filesystem può avere: essere case preserving, ossia mantenere il case delle lettere che compongono il nome del file (o della cartella; più avanti parlerò solo di file, intendendo sempre entrambi gli oggetti).

Quindi se scrivo “Pippo.Txt” il filesystem non ne altererà il case, mentre uno come il FAT12, che non rispetta il case preserving, memorizzerà e restituirà sempre “PIPPO.TXT“. Ovviamente un filesystem case sensitive è anche case preserving, mentre uno insensitive può esserlo oppure no.

Prima di continuare a parlare di case, però, penso sia necessario aprire una necessaria parentesi per capire meglio il senso della domanda che è all’origine del titolo dell’articolo.

Sappiamo che un filesystem ha il compito di conservare le informazioni che gli sottoponiamo. Come sono strutturate queste informazioni? Le informazioni fondamentali che le caratterizzano sono sicuramente due: i dati (o contenuto) veri e propri e il nome che gli abbiamo associato.

Tralasciamo per il momento altri metadati, come la dimensione del file, la posizione del medesimo all’interno dell’albero del filesystem, numero e blocchi allocati, inode, ecc. ecc., perché non sono funzionali all’argomento in discussione.

Come utente, quindi, ho la necessità di conservare dei dati, e dargli un nome. Nome che dovrebbe fornire sufficienti informazioni a descrivere il contenuto, in modo da renderne più facile la ricerca o semplicemente l’interpretazione.

Assegnare nomi a oggetti e cose in generale è un’operazione naturale, quasi scontata per un essere umano, che da tempo immemore è abituato a “classificare” ed “etichettare” ciò con cui ha avuto a che fare. Da questo ha, poi, avuto origine il linguaggio, che gli ha consentito di fare un enorme passo in avanti rispetto al resto del regno animale.

Con un filesystem ciò non è soltanto “naturale”, ma diventa anche obbligatorio: un file deve necessariamente essere accompagnato da un nome, in modo da permettergli di poterlo collocare opportunamente nella struttura che utilizza per memorizzare sia i dati che gli altri metadati.

Arrivati a questo punto si chiude la copiosa parentesi e si pone il problema del case, quindi diventa lecito chiedersi: qual è la soluzione più “naturale”? Riflettiamo un momento su alcuni esempi che possono aiutare a comprendere meglio.

Ha senso nominare “a” e “A” due file nella stessa cartella? Se ho due foto del mio cane, le etichetterò forse con “Lassie” e “lassie”? Passando ad altro, due tabelle diverse di un database le potrò mai chiamare “Clienti” e “clienti”? E ancora, se faccio una ricerca su internet, ha senso ottenere risposte diverse se scrivo “microprocessore” e “Microprocessore“?

La domanda più importante, che è anche la chiave per capire tutto il discorso, e a cui bisogna rispondere in questi casi, è la seguente: quale (utile) informazione riesco a ricavare dalla sola differenza in termini di case?

E’ in questi termini che, a mio avviso, va inquadrato il problema della scelta del case in un filesystem.

Per me entità diverse comportano che la loro nomenclatura non possa differire soltanto per il case, perché tenderei a sovrapporle, ad assimilarle come eguali, e a renderle sostituibili. E’ nel mio naturale ordine di cose farlo.

Anzi, definire due oggetti diversi che differiscano per il solo case può facilmente portare a commettere errori: se sbaglio il case di una lettera vado a specificare una cosa diversa da ciò che volevo. Utilizzare il case sensitive offre poco valore aggiunto astrattamente, ma nessuno o addirittura negativo concretamente.

Ecco perché come essere umano trovo che la risposta che più rispecchia il mio modo di fare, la mia essenza, è: il filesystem dev’essere case insensitive.

Per lo meno questo il pensiero a cui sono arrivato dopo diversi anni di esperienza, che sarà sicuramente diverso da quello di tanti altri, ma che spero di avere sufficientemente e chiaramente illustrato affinché possa servire almeno da stimolo per una riflessione diversa sull’argomento.

107 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    Apicio
     scrive: 

    Non posso che trovarmi che d’accordo con te.

    Infatti molte volte su Ubuntu mi è capitato di cadere in errori di ricerca/esecuzioni per il case-sensitive. :)

  • # 3
    D
     scrive: 

    Io mi chiedo un’altra cosa.
    Una volta i file non potevano avere nomi più lunghi di tot lettere e adesso quel limite è stato spostato alla lunghezza massima del percorso assoluto però aldilà di questi pensieri, non vedo praticamente un os (anche tra quelli per i comuni mortali) sfruttare degnamente questa funzionalità.
    Una volta col dos era 8+3 quindi file venivano nominati in modo strano, adesso che potrebbero tenere nomi più lunghi e teoricamente più chiari, accumulano una sfilza di lettere e numeri senza senso in un spazio più lungo, ma la comprensibilità di quello che scrivono continua a venire meno.
    Questo vale per windows ma anche per linux che tanto vuole spacciarsi per migliore e più semplice da usare.
    Come fa ad essere più semplice un os che pur potendo usare nomi lunghi si ostina a far stare in 4 caratteri acronimi su acronimi ?

  • # 4
    pabloski
     scrive: 

    non dimentichiamo che la case sensitivity è figlia dell’informatica degli anni ’60, figlia di persone che pensavano in byte e non in caratteri, quindi non meravigliamoci del perchè le cose fossero state pensate in quel modo

    ovviamente quando i file erano massimo 8 caratteri + 3 per l’estensione, faceva comodo avere a disposizione più simboli ascii

    i programmatori C concorderanno, perchè ancora oggi usiamo maiuscole e minuscole nel nostro codice? perchè alle struct diamo nomi che iniziano con la maiuscola? e alla singola istanza diamo lo stesso nome ma maiuscolo

    è chiaro che per un sistema orientato all’utente la sensitività al casing può addirittura essere un problema, ma se è per questo è il concetto di file e directory che è un problema e che andrebbe eliminato per far posto ad un sistema relazionale

  • # 5
    Marco
     scrive: 

    Permettetemi di fare la voce fuori dal coro…
    Secondo me anche le maiuscole/minuscole dovrebbero fare la differenza per il semplice fatto che se decido di chiamare un file pippo.txt e l’altro Pippo.txt vuol dire che *per me* una differenza tra i due c’è, magari tale da giustificare *solo* il cambio di case.
    E poi tra le due stringhe di byte dei nomi d’esempio sopra c’è differenza, perché mai il file system dovrebbe ignorarla, decidendo lui cosa conta e cosa no?

  • # 6
    minatore
     scrive: 

    Il bello di linux è proprio che è case sensitive bisogna per prima cosa sapere come si memorizzano i dati. Ogni carattere corrisponde ad un codice ascii che è diverso, anche in italiano le maiuscole e le miniscole sono messe in modo diverso. Quando andavate a scuola forse che scivevate tutto in stampatello maiuscolo? Per chi poi non sa distinguere maiuscolo da minscolo (pochi spero) si può sempre fare una ricerca non includendo differenza tra maiuscolo e minuscolo. Anni di Windows vi hanno atrofizzato il cervello? Po indubbiamente se a metà file un fiume o qcosa cane è un animale come distinguo i cognomi e i nomi di persona? Rosso Bruno Cane…. E’ indubbio che avere la possibilità di registrare dati diversi (maiscole e minuscole) è una posssiblità in più mentre se non ne ho la possibilità è una possibilità in meno. Quanto è stato pagato questo articolo da casa Microsoft? Usavo il dos registravo lo stesso i dati ma per questo non vuol dire che è meglio avere la possibilità di mettere i nomi file in 8 caratteri e 3 di estensione sia meglio. Chi programma poi ha la necessità di distinguere i file con maiuscole e minuscole aiutano a dividere le parole es: DrvXpProfSP2-2345-345-4567.cab è meglio di DRVXPPROFSP2-2345-345-4567.CAB.

  • # 7
    amadeus
     scrive: 

    infatti si è detto che il file system deve essere CASE INSENSITIVE e NON che non debba preservare il case.
    quindi se tu vuoi chiamare un file mioFileWord.doc sei libero di farlo, ma allora con miofileword.doc farai riferimento allo stesso file (ed ha MOLTO SENSO IMHO)
    anche perchè nei web server linux proprio per questo motivo è PIENO ZEPPO di link simbolici per rednere i link più raggiungibii. Per esempio se l’URL è http://miosito.com/Amadeus, sarò probabilmente costretto a creare un link simbolico che rediriga tutti quelli che digitano http://miosito.com/amadeus. Non so se si tratti di fortuna o di una scelta precisa, ma in questo caso Microsoft ha fatto una cosa buona IMHO

  • # 8
    Globus
     scrive: 

    @minatore : l’autore parlava di “case preserving” , un fs “case unsensitive” puo’ anche essere ( “case preserving”. In un case insensitive di questo tipo la leggibilità di un nome file rimane, ma altresi’ si da’ anche maggiore accessibilità. Anche per gli smaliziati non è facile individuare la differenza tra
    “DrvXpProfSP2-2345-345-4567.cab” e “DrvXpPRofSP2-2345-345-4567.cab” e per uno shift rimasto premuto piu’ del necessario si potrebbe perdere del tempo che sarebbe stato meglio impiegato altrove.
    Atrofizzazione del cervello o piuttosto ottimizzazione dei tempi e dei costi?
    Oltretutto : dato che non siamo piu’ ai tempi del 8+3, e che ci è data la possibilità di dare nomi lunghi agli oggetti dei FS, perchè differenziare gli oggetti dalla presenza o meno di una maiuscola?

  • # 9
    Cesare Di Mauro
     scrive: 

    @D: quella è una tradizione del mondo Unix, dove si utilizzano fortemente gli acronimi.
    Se prendi AmigaOS, invece, permetteva di utilizzare nomi lunghi fino a 30 caratteri (se non ricordo male), e aveva comandi come ChangeTaskPri. :D

    @pabloski: linguaggi come Fortran, Cobol, Algol e Pascal sono ben più vecchi (i primi specialmente) del C, eppure… avevano identificatori case insensitive. ;)

    Sull’utilizzare un sistema relazionale concordo. Purtroppo MS ha fatto un buco nell’acqua con WinFS, perché sarebbe stato interessante (e utile).

    @Marco: è chiaro che ognuno può interpretare i nomi come vuole, ma se dovessi passare quei due file a qualunque altro essere umano, secondo te a colpo d’occhio capirebbe che significato hanno quei due file che hanno un nome identico, a parte il case diverso nella prima lettera?

    Negli esempi che ho fatto la differenza c’è chiaramente, ma è una “decorazione”.
    Mettiamo che abbiamo una canzone che si chiama “Questa è vita.mp3″: soltanto la prima lettera è maiuscola, perché è così che “decoriamo” la prima lettera di una frase.
    Ma se tu avessi un altro file nella stessa cartella che si chiama “questa è vita.mp3″, quale informazione addizionale ti fornirebbe il case diverso della sola prima lettera per capire la differenza fra i due?

    E’ questo il concetto che vorrei sottolineare con questo articolo.

    @minatore: MS non ha pagato nulla, e sei pregato di non continuare con calunnie di bassa lega come queste, altrimenti i tuoi messaggi verranno cancellati la prossima volta.
    Poi se ne sei capace, puoi benissimo argomentare senza scadere nelle offese personali.

    Che il case venga utilizzato anche italiano è cosa ovvia, ma l’articolo non dice di eliminare il case, eliminando la possibilità di registrare minuscole e minuscole, se leggi meglio.

    Puoi benissimo memorizzare un file come “cane” oppure come “Mario Rossi”, e come essere umano sapresti riconoscere la differenza fra i due.

    Come puoi fare benissimo con quel Windows che ti dà tanto fastidio, e parecchi anni prima con AmigaOS, che permetteva di memorizzare maiuscole e minuscole nei nomi di file e cartelle, pur mantenendo il filesystem case insensitive…

    @amadeus e @Globus: avete centrato perfettamente la questione. Grazie :)

  • # 10
    Ilruz
     scrive: 

    Quoto completamente l’articolo – io vorrei anche path di lunghezza infinita: il nome del file e’ … parte delle informazioni che ci sono dentro! (affermazione ricorsiva? :P)

  • # 11
    Cesare Di Mauro
     scrive: 

    Ed eliminare il concetto di file e cartella, come diceva pabloski, non t’attira? Così eliminiamo alla radice il problema. :D

  • # 12
    Riccardo
     scrive: 

    non è efficiente un filesystem che differisce tra pippo e Pippo perchè ci vuole più tempo ad accorgersi della differenza che altro. è un po lo stesso discorso del == contro = nel il C e nel C#..

    forse è da principianti, o meglio non da super geek linuxiani, ma quelli scrivono codice in binario..

  • # 13
    avvelenato
     scrive: 

    Chissà perchè l’ autore usa le maiuscole per i nomi propri come il suo nominativo, dato che il case dei caratteri deve essere umanamente insensitive, non vedo perchè non applichi la sua filosofia anche su tutto il resto.

  • # 14
    Cesare Di Mauro
     scrive: 

    Semplicemente perché l’autore conosce la differenza fra case preserving e case insensitive… ;)

    @Riccardo: non ho capito bene se è una domanda o una constatazione la tua.

  • # 15
    goldorak
     scrive: 

    Globnus ha scritto :

    “Oltretutto : dato che non siamo piu’ ai tempi del 8+3, e che ci è data la possibilità di dare nomi lunghi agli oggetti dei FS, perchè differenziare gli oggetti dalla presenza o meno di una maiuscola?”

    Sbaglio o nei sistemi windows e’ ancora presente il maledetto limite dei 3 caratteri per l’estensione ? ^_^
    Vediamo di fare il passo piu’ importante, e cioe’ slegare il nome del file dalla sua estensione (che dovrebbe essere totalmente inutile). Poi potremo discutere se vale la pena avere un fs case insensitive.
    Da parte mia credo che sia uno sbaglio, il linguaggio naturale ci da sia le lettere maiuscole che le minuscole per un motivo ben preciso. Avere un fs che mi riduce Casa, casa, cAsa, CASA allo stesso oggetto e’ una idiozia oltreche’ un atto di presunzione.

  • # 16
    KloWn
     scrive: 

    Secondo me il case-sensitiveness di un fs può essere utile, per esempio voglio sovrascrivere un comando… Lo scrivo in maiuscolo e col minuscolo ho quello originale, senza dover ricordare eventuali suffissi/prefissi che aggiungo. Nel caso di script ad esempio che espandano o semplifichino il comportamento del comando originale… Su ciò si potrebbe scrivere fino al giorno del giudizio e probabilmente non si arriverebbe a conclusione.

    Hola!

  • # 17
    Cesare Di Mauro
     scrive: 

    @goldorak: no, quel limite non è più presente.

    Il problema delle estensioni è, appunto, un altro problema. Ad esempio Apple con MacOS non aveva mai avuto bisogno di estensioni, eppure con OS X è diventato praticamente “mandatory”.

    Non si può, comunque, subordinare il problema del case a quello delle estensioni: sono due cose diverse e, poi, la logica ce lo vieta (visto che non esiste nessuna base né implicazione logica fra le due cose).

    Quanto al linguaggio naturale, è vero che ci dà la possibilità di utilizzare le maiuscole e le minuscole. Mai negato questo, e infatti non a caso ho parlato di “case preserving”.

    Ma ciò che tu trovi un’idiozia e addirittura un atto di presunzione, è invece una cosa che, da essere umano, trovo perfettamente naturale.

    Anzi, trovo che agli albori l’informatica si preoccupava di essere più vicina all’uomo, mentre col tempo cerca di piegarlo alla macchina. Vedi, appunto, il case degli identificatori nei linguaggi di programmazione, e di file e cartelle nei filesystem…

    @KloWn: ma distinguere il file originale dalla sua copia / modifica dal solo case è una cosa che puoi fare soltanto tu, e… se hai una buona memoria. :D

    Se un’altra persona si trova davanti ai due file, si troverà LEGGERMENTE in difficoltà, e potrebbe anche far danni. :D

    Da essere umano preferisco avere “comando” e “comando_old” anziché “comando” e “Comando”: a colpo d’occhio capisco già tutto. ;)

  • # 18
    TheFoggy
     scrive: 

    Secondo me l’FS dovrebbe essere case insensitive. (ma preserving..). E’ vero che la lingua parlata ci fornisce maiuscole e minuscole, ma quando parlo non dico “>asa”, ma semplicemente “casa”.. Quindi, il linguaggio parlato è case INSENSITIVE, perchè non dovrebbe esserlo l’os?

  • # 19
    TheFoggy
     scrive: 

    Uhm..mi è stata tagliata una parola! :P Intendevo dire che non dico ” ‘cimaiuscola’ asa”, ma solo “casa”..

  • # 20
    Andrea R
     scrive: 

    Spreco: milioni di chiamate a to_upper, codice più difficile eccetera.
    E i nomi unicode? è diventa È, ed è un casino da riconoscere.

    Poi c’è gente che manipola file su Windows, li passa su linux e smettono di funzionare, perchè lì il fs è sensitive. Mentre da sensitive ad insensitive il problema non c’è.

    Un fs sensitive è anche un buono stimolo per dare dei nomi puliti ai propri file.

  • # 21
    D
     scrive: 

    “@D: quella è una tradizione del mondo Unix, dove si utilizzano fortemente gli acronimi.
    Se prendi AmigaOS, invece, permetteva di utilizzare nomi lunghi fino a 30 caratteri (se non ricordo male), e aveva comandi come ChangeTaskPri. :D”

    Ed infatti Amiga OS continua ad essere il miglior sistema operativo del mondo. Finchè non si preoccuperanno anche di queste finezze, nessuna evoluzione di windows o linux potrà sperare di tenergli testa.

  • # 22
    massimo m.
     scrive: 

    io preferirei avere un fs case preserving ma non sensitive.
    io odio il case sensitive. infatti odio il c/c++ per questo (e per mille altre cose che mi fanno pensare che il c/c++ sia un linguaggio per geek), e con ada ho trovato l’eldorado :)

  • # 23
    Cesare Di Mauro
     scrive: 

    @TheFoggy & massimo m.: la pensiamo esattamente allo stesso modo.

    Solo che io parteggio per Python che, purtroppo, è case sensitive, e la cosa mi affligge non poco. :(

    @Andrea R: se questo spreco c’era ai tempi del Fortran, quando la potenza di calcolo era ridotta al lumicino, perché non dovrebbe esserci oggi che la potenza di elaborazione è di diversi ordini di grandezza superiore?
    Poi non serve una chiamata a toupper() ogni volta: è sufficiente una sorta di strcmpi, che esegue direttamente il confronto tenendo conto del case, senza usare quella funzione.

    Per lo Unicode non c’è problema: lo standard è preciso nel definire le operazioni di upper e lower case delle lettere.

    Il passaggio da Windows a Linux di file non è un problema, perché si passa da un filesystem case insensitive a uno case sensitive, quindi non c’è pericolo di “doppioni” (file unici con lo stesso nome) che, invece, si verifica in direzione opposta.

    C’è però da tener conto che alcune applicazioni, come MySQL, cannano clamorosamente passando da Windows a Linux, proprio a causa delle differenza di case. Ma qui è più che altro un problema di cattivo design dell’engine SQL.

    Non capisco l’ultima parte: i nomi “puliti” si possono dare a prescindere dal case del filesystem. Non vedo come possano facilitare i “casini” quelli case insensitive.

    @D: Windows utilizza filesystem case insensitive e case preserving. Come AmigaOS. :D

  • # 24
    Fede
     scrive: 

    Mi rendo conto che molte persone che hanno immesso il proprio commento a questo articolo lo hanno fatto pur non avendo delle minime conoscenze di programmazione, NON CAPISCO PERCHE’ OGGI SI HA LA TENDENZA AD INTERVENIRE SU DISCORSI IN CUI NON SI HA UNA MINIMA CONOSCENZA DEL CONTESTO, salvo da questa ammucchiata l’utente “minatore” che ritengo abbia detto cose veramente sensate e ha dimostrato di avere una minima conoscenza delle problematiche informatiche …
    A livello di programmazione le cose sarebbero molto più semplici se il software che si vuole realizzare dovrà essere case sensitive, il motivo? be è presto detto, come ha giustamente osservato “minatore”, i caratteri sono codificati in binario dal codice ASCII nel quale per esempio il carattere minuscolo “a” ha un codice diverso dal codice associato al carattere “A” ed è giusta la distinzione tra i due caratteri perché ci sono situazioni in cui è fondamentale che siano ben distinti si pensi per esempio alle password di sicurezza soprattutto quelle in cui ne è imposto a priori la lunghezza (è ovvio che se il sistema che legge la password è case sensitive a parità di lunghezza si avranno maggiori combinazioni di caratteri, è matematico questo e non sono opinioni).
    Nel contesto della programmazione scrivere del software NON case sensitive costringe il programmatore ad aggiungere parecchie linee di codice, si pensi per esempio ad un database relazionale che gestisce una semplice rubrica composta da due tabelle in relazione 1 a molti (una persona univocamente individuabile in tutto l’universo può benissimo avere più numeri di cellulari ma viceversa un numero di cellulare non può essere intestato a più persone, insomma la relazione binaria deve essere surgettiva) … dunque nella prima tabella ogni record (Row) conterrà per esesempio i campi (Columnes) “NOME”, “COGNOME”, “INDIRIZZO DI RESIDENZA”, “NUMERO CIVICO”, “CAP”, “COMUNE DI RESIDENZA”, “PROVINCIA”, “CAMPO CHIAVE” (è la cosidetta CHIAVE ESTERNA DELLA RELAZIONE), nella seconda tabella i records saranno composti dai seguenti campi “CAMPO CHIAVE”, “PREFISSO TELEFONICO”, “NUMERO DI TELEFONO” …. insomma avremmo la bellezza di 13 campi …. ora vi rendete conto che fatica dovrà fare il programmatore per far si che nell’interfaccia di immissione dei dati i dati immessi non siano case sensitive, sarà costretto a scrivere delle istruzioni di controllo del flusso di esecuzione tipo “SWITCH” (C/C++)

    Ovviamente ci sono delle situazioni in cui non ha senso distinguere i caratteri maiuscoli da quelli minuscoli, per esempio giustamente se nomino un file “pippo” dovrà essere la stessa cosa di “PIPPO”, di “Pippo” di “PiPPo” ecc. ecc.

    Ancora una volta i Latini risultano avere ragione “Nel mezzo c’è sempre la virtù” ossia in certe situazioni è bene distinguere i caratteri maiuscoli da quelle minuscoli e in altre è bene non distinguere la cosa

    Poi si pensi se avessero creato una codifica dei caratteri in cui “a” è uguale “A”, “b” è uguale “B”, “c” è uguale “C”, ecc. ecc. immaginate le conseguenze di una simile scelta …. insomma è ovvio che la logica di base deve essere necessariamente case sensitive e solo nei singoli casi puùò essere sfruttata o meno questa caratteristica intrinseca

  • # 25
    TheFoggy
     scrive: 

    Di certo..ciò che rende, a detta di molti, Windows meno efficiente di Linux, non è l’uso di toupper/tolower/strcmpi..

  • # 26
    Cesare Di Mauro
     scrive: 

    @Fede. Prima di tutto ti consiglio di non mettere in dubbio le conoscenze di programmazione di chi ha scritto i commenti: potresti avere delle sorprese.

    Passiamo alle questioni tecniche. Parli di codice ASCII, di distinzione fra “a” e “A”, salvo poi venire a parlare di password che è meglio che siano case sensitive.

    Beh, l’errore di fondo che hai commesso è quello di non tenere conto della differenza che esiste fra un IDENTIFICATORE, quale può essere il nome di una variabile oppure quello di un file appunto, e un DATO, qual è appunto la password di cui parli.
    Si tratta di informazioni completamente diverse e che… hanno giustamente esigenze diverse.

    Cose che, come programmatore con “una minima conoscenza delle problematiche informatiche” come dici tu, dovresti ben sapere. Stiamo parlando delle BASI.

    L’esempio che riporti sulle due tabelle, poi, non ti dà ragione. Al contrario. Sarà una fatica per il programmatore scrivere codice case insensitive che tenga conto di ciò che hai detto, ma… è NECESSARIO.
    Dimmi tu che senso avrebbe dare la possibilità di immettere i dati di un utente senza effettuare un controllo sul case su tutti i campi testuali. Potresti immettere più volte i dati della STESSA persona, soltanto a causa della differenza di case di qualche lettera.
    E’ chiaramente inaccettabile: i controlli vanno fatti, e devono essere case insensitive. Di fatti gli engine SQL permettono facilmente di effettuare confronti ignorando il case, visto che si tratta di necessità piuttosto frequenti.

    Tra l’altro l’esempio del file “Pippo” conferma che per i filesystem sei sulla stessa linea della maggior parte di quelli che hanno scritto i commenti, e cioé che dovrebbero essere case insensitive.

    Non concordo ancora una volta sull’ultima parte: non ha senso partire “di base” sul case sensitive. La sensibilità al case la si sceglie in base al problema da risolvere. Non è case sensitive “di default”.

  • # 27
    TheFoggy
     scrive: 

    @Fede: ehm..non per dire, ma..nell’articolo si parlava di FileSystem, non di programmazione.. (e nessuno dice che la codifica dovrebbe associare lo stesso codice ad ‘a’ e ad ‘A’ (da buon programmatore c/c++ uso l’apice singolo: è un carattere! :P)) E, in riferimento allo stesso, pure tu dici che “pippo.txt” dovrebbe essere uguale a “Pippo.txt” (e sue varianti maiuscole/minuscole).
    Inoltre non capisco cosa intendi dire nell’esempio.. Ovvio che se cerco il numero di “mario rossi”, dovrà restituirmi gli stessi risultati di “Mario Rossi”..anche perchè SQL è case insensitive..e quindi nessuna sbattita per il programmatore!

  • # 28
    Gibbo
     scrive: 

    @Fede

    “ora vi rendete conto che fatica dovrà fare il programmatore per far si che nell’interfaccia di immissione dei dati i dati immessi non siano case sensitive, sarà costretto a scrivere delle istruzioni di controllo del flusso di esecuzione tipo “SWITCH” (C/C++)”

    Usare un strcasecmp o rendere tutto maiuscolo/minuscolo pareva brutto?

  • # 29
    THe_ZiPMaN
     scrive: 

    CARO cesare dI mauro EVIDENTEMENTE per TE La CASE Sensitivity NON HA moltA IMportanZA, ma ovviamente può aVERne mOLta per altra GENTE.

    Il fatto che tutti i FS moderni siano case preserving è ovviamente perché il “case” ha un significato che DEVE essere preservato. Se deve essere preservato deve anche essere gestito.

    Le frasi “signor dentista” e “signor Dentista”, anche nel mondo reale non informatico rappresentano due concetti diversi e sono trattati in modo diverso.
    Analogamente per un computer sono oggetti diversi dato che ogni lettera è rappresentata numericamente, e a lettera diversa corrisponde un numero diverso anche se le lettere differiscono solo nel “case”.
    Il computer DEVE trattare entità diverse in modo diverso; non farlo, oltre a generare numerosi problemi sia a livello di programmazione che di coerenza di comportamento, può penalizzare in modo considerevole le performance del filesystem (la gestione files di Windows su NTFS è difatti penosa quando i files sono più di qualche centinaio).

    La case insensitivity deve essere gestita eventualmente a livello di interfaccia utente, mettendo a disposizione degli utenti pigri un checkbox per ricerche case insensitive, o presentando i files ordinati in ordine case insensitive.
    Il filesystem deve fare quel per cui è progettato.

  • # 30
    Andrea R
     scrive: 

    @Cesare
    Anche con strcmpi hai comunque due if per ogni lettera invece che uno. Al giorno d’oggi è ben poca cosa, sicuro. Ma lo sappiamo che ‘a’ è diverso da ‘A’ per il computer e far finta di no aggiunge complicazioni.
    Il problema poi non è solo di fs. Si espande in altre aree. Se ho una applicazione che apre mp3 dovrò ricordarmi di cercare i .mp3, ma anche i .MP3 e forse anche i .Mp3. Poi c’è un problema di coerenza: il web è case sensitive e gli utenti lo usano…

    Applicazioni che cannano quando passano da insensitive a sensitive ce ne sono eccome. Per farti capire, un progetto di netbeans creato da windows e poi aperto da linux ha creato un problema di case. Quindi il problema c’è e pesa di più dei doppioni (quello manco lo considero un problema reale).

    Per unicode ci sarà uno standard per il case. Ma prova un po’ quanti ambienti lo trattano correttamente. Io ho provato e non funziona dovunque. E poi per i non unicode chissà?

    I nomi puliti uno lì da perchè è obbligato. Da quando uso Linux non do più nomi che iniziano con una maiuscola da una parte e nomi tutti minuscoli dall’altra. Mi sono trovato una convenzione e la uso.

    Il requisito più stringente è quello giusto in questo caso, poichè implica quello più lasco.

  • # 31
    whiplash
     scrive: 

    -iname o -iregex sono ottimi amici dell’uomo, anche quello
    più stolto.
    Un bel ‘man find’ può evitare di spararle grosse.

  • # 32
    Cesare Di Mauro
     scrive: 

    @THe_ZiPMaN. Ma noi non siamo computer: è questo il punto. E trattiamo la sensibilità al case in maniera diversa dal computer. ;)

    Poi se per me la sensibilità al case non avesse importanza non c’avrei scritto un articolo specificato, e… avrei cambiato anche lavoro. :D

    Le performance sono un discorso relativo. Intanto faccio notare nuovamente che linguaggi come il Fortran erano case insensitive quando la potenza di calcolo era irrisoria.
    Poi vorrei capire quale relazione c’è fra la sensibilità al case e il numero di file che gestisce un filesystem come NTFS, perché da quel che dici non mi è chiara.

    Infine il filesystem deve conservare dati e relativi metadati, e questo lo fa a prescindere dalla sensibilità al case: è per questo che è nato.

    Ma nel momento in cui affermi che una lista di file dovrebbe essere ordinata in maniera case insensitive, stai pensando da essere umano e come un computer, proprio perché noi abbiamo esigenze diverse da loro.

    E personalmente non ho voglia di piegarmi alla macchina: preferisco sia lei a farlo. ;)

  • # 33
    D
     scrive: 

    “@D: Windows utilizza filesystem case insensitive e case preserving. Come AmigaOS. :D”

    Però i nomi dei file in windows sono un miscuglio insensato di caratteri

  • # 34
    roberto
     scrive: 

    mi sa che tutti quelli che sono contrari al case insensitive sono programmatori che programmano per se stessi e non per chi dovrà usare il programma..

    farete moltissima strada così :)

  • # 35
    Cesare Di Mauro
     scrive: 

    @Andrea R: ma vedi che il punto è sempre lo stesso? “‘a’ è diverso da ‘A’ per il computer”. Certo, ma… noi non siamo computer! E non vedo perché dovremmo piegarci al SUO funzionamento. :D

    L’esempio delle estensioni .mp3, poi, mi sembra calzi a pennello: è una chiara dimostrazione di come l’esigenza primaria sia quella di trattarle come case insensitive.
    Se cerco file .mp3, non mi aspetto che vengano restituiti soltanto quelli che sono esattamente così, ma anche quelli .MP3, .Mp3, .mP3… ;)

    Quanto al web, beh, non mi sembra proprio che siano case sensitive. Al contrario, protocollo e dominio sono sicuramente case insensitive, specifiche alla mano.
    E’ il resto dell’URL che può essere case sensitive o meno in base all’implementazione dei server. Quindi se sto mappando un’URL su una cartella e il filesystem è case sensitive, lo sarà anche il resto dell’URL, altrimenti no.
    Come vedi la sensibilità al case crea problemi anche qui, quando avrebbe poco senso per un’URL, che identifica una risorsa sul web.

    Poi non ho affermato che non ci siano problemi per le applicazioni passando da un sistema case insensitive a case sensitive. Ma dipende sempre dal filesystem, come vedi.

    Sullo unicode, beh, mi dici di controllare quanti lo trattano in maniera corretta, ma questo non è né un problema di questo standard né della sensibilità al case, quanto di cattiva (o bacata) programmazione.

    Per i non unicode, non ho capito a cosa ti riferisci: potresti essere più chiaro, cortesemente?

    Sulla “pulizia” dei nomi dei file, continuo a non vedere il problema col case insensitive: anch’io ho una mia convenzione e la seguo. A prescindere dalla sensibilità al case.

    @whiplash: non ho quei comandi nel mio sistema. :D

    Poi se magari spieghi quello “spararle grosse”, mi faresti una cortesia, visto che il tuo messaggio è abbastanza indecifrabile.

  • # 36
    Cesare Di Mauro
     scrive: 

    @D: non mi risulta. A me sembra di lavorare allo stesso modo tanto su AmigaOS quanto su Windows. Perché dici che in quest’ultimo caso ci sia “un miscuglio insensato di caratteri”? Potresti farmi qualche esempio, cortesemente?

    @roberto: :D :D :D Come programmatore pongo sempre l’utente al centro dei miei pensieri.

    Mi pare il minimo, visto che i programmi che realizzo devono finire a loro, e non a me. :)

  • # 37
    gerlos
     scrive: 

    Questa tua riflessione sul case sensitivity mi sembra profondamente superflua.

    Se è vero che quando c’è distinzione tra File e file io posso fare confusione, è anche vero che ci sono millemila modi per sciogliere questa confusione.
    Per esempio, andare a guardare il nome del file ;-)

    Inoltre, se anche non mi ricordassi i dettagli del nome del file che mi serve, qualsiasi sistema operativo degno di questo nome mi fornisce gli strumenti per recuperarlo.
    Dai tradizionali find e locate di unix (find ha opzioni specifiche, locate ignora queste differenze), fino alle interfacce “cerca file” di tutti gli ambienti grafici (c’è sempre “distingui maiuscole/minuscole”), passando per i moderni sistemi di indicizzazione come strigi, beagle, spotlight o google desktop, tutti consentono di ignorare il case dei file nelle ricerche, per cui il problema davvero non si pone. Se ho “perso” il nome di un file, è fin troppo facile recuperarlo.

    D’altra parte, la distinzione maiuscole/minuscole rende il sistema coerente nei confronti dell’utente (sì, il case preserving confonde le idee: due cose uguali appaiono in due modi diversi) ed è una comodità in più: perché mai FILE e file devono essere la stessa cosa?
    Nei libri, nella carta stampata, sono sì associati allo stesso significato, ma non portano necessariamente gli stessi contenuti: magari SCRIVO MAIUSCOLO PERCHÈ VOGLIO GRIDARE, e scrivo minuscolo per il resto del tempo, o uso le lettere maiuscole per i Nomi: la ragione non è una scelta, è La Scelta. :-)

    Magari mi piace scrivere in maiuscolo il nome di un file che voglio mettere in evidenza.
    Oppure ho un programma che deve generare dei file temporanei, e devo dare a questi file temporanei dei nomi casuali. Con la distinzione tra maiuscole e minuscole, posso avere più combinazioni, ed in definitiva nomi più brevi e leggibili.

    Insomma, ho delle possibilità in più, non sono obbligatorie, e se non le voglio usare, perché sono pigro o ho il tasto maiuscolo rotto, posso infischiarmene e scrivere tutto minuscolo.

    Tanto poi all’utente comune, che usa interfacce grafiche, tutto questo fa poca o nulla differenza: per agire su un file non deve digitare il nome, ma cliccare su un’icona o una voce di un elenco.

    Concludendo, vorrei aggiungere che NON è la case sensitivity di unix un relitto del passato, quanto piuttosto la case INsensitivity… ricordate DOS, e quei limiti assurdi sui nomi dei file? Ecco, per retrocompatibilità con quelle scelte profondamente stupide, ancora oggi Windows è case insensitive. Alla faccia dell’innovazione!

  • # 38
    Tasslehoff Burrfoot
     scrive: 

    Mah… a me questa sembra la tipica questione di lana caprina…

    Per come la vedo io il problema non è il filesystem, anzi un filesystem case sensitive è più “ricco” dato che permette una maggiore definizione di file e directory.
    Il problema vero che si sta ribaltando sul filesystem è un altro, ovvero la brutta tenedenza dell’utente tipo a non classificare i propri file in modo ordinato, tenendo tutto a casaccio su filesystem senza organizzare nulla o senza usare strumenti che aiutino a organizzare i propri dati (che pure ci sono e alla portata di tutti).

    Il problema della ricerca semplicemente non esiste dato che qualunque software che permette di effettuare ricerche nei file o nei filesystem include anche apposite opzioni per effettuare ricerche case insensitive.

    PS x la redazione: a quando un forum con vbulletin con i post in calce alla news stile hwupgrade?
    E’ un supplizio ridurre una discussione simile a semplici commenti scritti su una textarea con tanto di captcha :(

  • # 39
    Giulio
     scrive: 

    In molti fanno l’errore di confondere la rappresentazione col suo significato (che in genere diamo noi)…

    Al computer non importa il “significato”.

  • # 40
    floc
     scrive: 

    ossignur, questa ancora dovevo leggerla…

    Esistono in “natura” (ossia in ascii ad esempio, informaticamente parlando) due valori diveri per “P” e “p” ? e allora perche’ mai il mio fs dovrebbe trattarli come identici, siamo fuori di testa? Queste forzate semplificazioni da “utenza bovina” mi fanno davvero venire la pelle d’oca :| il vero problema e’ che nessuno sa’ dare un nome decente ai propri file, tant’e’ vero che c’e’ chi si lamenta degli acronimi costantemente usati ad esempio nei sistemi linux (ma anche in quelli win)

  • # 41
    Cesare Di Mauro
     scrive: 

    @gerlos. Un file puoi scriverlo tutto maiuscolo per metterlo in evidenza, ma poi nella stessa cartella metti un altro file con lo stesso nome, ma magari tutto minuscolo? Ha senso per te, essere umano?

    Per i file temporanei sono d’accordo: sarebbe comodo. Ma è sempre un’esigenza che riguarda il computer: sono a suo uso e consumo. Ecco anche perché i nomi generati sono abbastanza illeggili.

    Se hai il tasto maiuscolo rotto e giochi col case, con un filesystem case sensitive puoi “far danni”, visto che il case è importante. :D

    Sulla parte finale, beh, non vedo cosa c’entri il DOS, quando:
    – era case insensitive, ma anche non case preserving (tutte le lettere erano in maiuscolo);
    – esistevano filesystem case insensitive sia prima che dopo.

    Non vedo il nesso con Windows, che tra l’altro ha lo stesso approccio di AmigaOS…

    @Tasslehoff Burrfoot: mi spiace, ma AD è un blog, non un forum. Come veterano di forum, l’idea mi piacerebbe molto, ma si perderebbe anche l’immediatezza del blog.

    Comunque ne parleremo in redazione, visto che il tema è sentito.

  • # 42
    Cesare Di Mauro
     scrive: 

    @Giulio: il computer dovrebbe essere utile a noi, a prescindere da come funziona lui. ;)

    @floc: in natura esistono le “p” e le “P”, e vengono utilizzate, infatti. Il problema sta nell’interpretazione che se ne fa. ;)

  • # 43
    damxxx
     scrive: 

    Io da non programmatore ma comune utente di computer (sia Win che Linux) trovo più logico che il filesystem sia case insensitive (ma case preserving), come dice giustamente l’autore mettiamo al centro del problema l’uomo e non la macchina, quindi trovo giusto ragionare secondo le regole della grammatica prendiamo quindi un qualuqnue professore di italiano ignorante in informatica, chiediamogli quale sia la differenza fra “Pippo”, “pippo” e “pIppo” lui ci dirà nessuna, che si riferisce alla stesso persona, se non che la secinda forma è scorretta in italiano visto che i nomi propri vanno scritti con la prima lettera maiuscola e per la terza non è corretto mischiare minuscole e maiuscole in mezzo alle parole. Poi io lavoro in uno studio di ingegneria, se avessi due file denominati uno palazzo.dwg e l’altro Palazzo.dwg magari volendo intendere col primo un edificio generico con l’altro l’edificio del signor Palazzo, potrebbe nascere un bel casino se un mio collega, ignaro della differenza (o magari se io stesso dimentico questo particolare dopo uno o due anni), nel voler revisionare il progetto del signor Palazzo, apra, modifichi, stampi e consegni il contenuto del file palazzo.dwg.
    Meglio che il mio FS mi impedisca una ambiguità simile…

  • # 44
    Francesco
     scrive: 

    E’ un problema che non ho mai incontrato, da utente finale di fs case sensitive. Mi fate qualche esempio?

    Come programmatore, invece, ho avuto problemi: dovevo eseguire in Linux degli script fatti in Windows, e l’ unica ragione per cui non funzionavano era il case incostante usato dal programmatore nel riferirsi a risorse sul fs. Visto che la maggior parte dei linguaggi che conosco sono case sensitive, permettere al programmatore di sbattersene in questo particolare caso mi sembra un’ incostanza, che porta a errori.

    Quindi, se all’ utente finale non reca danno, ed obbliga i programmatori a fare le cose come si deve, meglio essere case sensitive.

  • # 45
    Cesare Di Mauro
     scrive: 

    Ti faccio un esempio: prova a usare MySQL su un filesystem case sensitive, e mettiamo che tu abbia una tabella che si chiami Clienti.

    Manuale dello standard SQL alla mano, prova a scrivere la seguente query:

    SELECT * FROM clienti;

    e dimmi se l’operazione va in porto, oppure ottieni un errore.

  • # 46
    damxxx
     scrive: 

    @gerlos Puoi scrivere tutto in minuscolo o tutto in maiuscolo per gridare o alternare minuscole e maiuscole, ma in italiano il significato che sta dietro a quelle parole non cambia. Se leggo “pAlazzo” invece di “Palazzo” dalla prima cosa che posso pensare è ad un errore di battitura, non che ci si riferisce a due cose diverse, forse il discorso sarebbe diverso se leggessi “Palazzo” e “palazzo” si poterbbe pensare che ci si stia riferendo nel primo caso ad un nome proprio nel secondo ad un nome comune ma non è immediata la differenza e tale ambiguità potrebbe riservare delle spiacevoli sorprese, forse è meglio evitarle

  • # 47
    amadeus
     scrive: 

    @Cesare

    x il discorso MySQL credo che dipenda dal SQL engine che usi. Quel che dici dovrebbe succedere solo con il vetusto MyISAM e non con il più efficace InnoDB

  • # 48
    ZeuzzO
     scrive: 

    pippo.txt
    Pippo.txt
    pIppo.txt
    piPpo.txt
    pipPo.txt
    pippO.txt
    PIppo.txt
    PiPpo.txt
    PipPo.txt
    PippO.txt
    ….
    PIPpo.txt
    ….

    pippo.Txt
    pippo.tXt
    pippo.txT
    pippo.TxT

    etc etc etc combianatele come volete

  • # 49
    gerlos
     scrive: 

    @ cesare:
    Beh, certo che per me ha senso avere un file con nome tutto maiuscolo e uno con nome tutto minuscolo: l’ho scelto io di dargli quei nomi!!!

    Anzi, dopo anni mi sono scelto alcune convenzioni, per cui scelgo come debbano essere nominati i file. Ad esempio, le directory di progetti temporanei su cui lavoro sono scritte tutte in maiuscolo. Quando il progetto si stabilizza e passa alla fase successiva, “abbasso il livello di allarme” rinominando la directory in lettere minuscole.

    Visto che posso configurare il mio file manager in modo che negli elenchi compaiano prima i file i cui nomi contengono maiuscole (“A” viene prima di “a”), per me questo dà la giusta visibilità ai lavori pendenti.

    Sono scelte personali, non c’è niente di universale, ma mi permettono di interagire con la macchina in modo più significativo per me.
    Se poi io stesso non sono capace di tenere un po’ d’ordine e di rispettare le mie stesse convenzioni, beh, allora me la sono cercata!
    È stupido fare una cosa importante (perché ci permette di reperirlo) come dare un nome a un file senza pensare.

    Insisto: sono io a decidere i nomi, per cui se ho scelto di scrivere pIppo, una ragione ci sarà stata. Sono nomi arbitrari, non mi importa che in italiano non si usa la lettera maiuscola alla seconda lettera, magari nella mia convenzione ha un senso, non devo mica far valutare il file system da un professore di italiano.
    In matematica, fisica (sono un fisico), chimica, ci sono decine di simboli in cui si alternano maiuscole e minuscole, e in questi contesti la differenza di “case” è significativa. Perché non dovrebbe esserlo anche nel file system del mio computer?

    Insomma, non è che questa cosa dell’indifferenza tra maiuscole e minuscole finisce per essere una trovata per utenti pigri? (nel senso: meno possibilità, meno problemi)

    Tanto più oggi, che abbiamo tutte le comodità possibili: programmi di ricerca, indicizzatori, file manager grafici, completamento automatico dei nomi nelle shell e anche nelle GUI (non so in Windows, non lo uso da anni, ma in KDE e Gnome è così da molto tempo).
    E sì, anche il client di mysql ha il completamento automatico dei nomi, per cui se digitando “c”-TAB non ho corrispondenze, mi basta provare “C”-TAB per avere il completamento “Clienti”. Insomma, non ci sono proprio scuse, imho.

  • # 50
    TheFoggy
     scrive: 

    @D: il fatto che i nomi dei file siano incasinati, dipende dall’utente che li gestisce, non è colpa dell’FS.. Nessuno vieta a nessuno di utilizzare nomi “puliti”..
    @Roberto: ma anche così..meglio sbattersi durante la programmazione UNA VOLTA SOLA che OGNI VOLTA CHE USO IL PROGRAMMA! Almeno..io la penso così..e non mi sono mai trovato male..e neanche chi usa i miei programmi!
    @Cesare: credo che whiplash si riferisca al fatto che i parametri -iname e -iregex rendano insensitive il nome da cercare o l’espressione regolare per il find..e quindi lo “spararle grosse” fosse riferito ai sontenitori della “comunità sensitiva”.. (da quanto mi è parso di capire, eh..potrei benissimo sbagliarmi!)
    @gerlos: metti che fai un programma esterno che accede ai file presenti in una dir con nome maiuscolo (quindi “temporanea”, e che poi rinomini in minuscolo..devi sempre ricompilare anche gli altri programmi? A me capita, di fare programmi che accedano a cartelle di altri miei programmi (alcune volte con un discreto numero di “incroci”)..dovrei ricompilare tutto ogni volta? Inoltre..e se “pIppo.txt”, derivasse da un errore di battitura? Ogni volta dovrei utilizzare un software per la ricerca? A sto punto, perdo più tempo per le ricerche che per accedere ai file..
    Non so, ma uno scenario come quello proposto da ZeussO, non mi pare troppo sensato.. Sarà una scelta per utenti privi di capacità di dare nomi sensati ai files? Citiamo il numero di caratteri disponibili per il nome dei file, e poi cerchiamo di poter creare 15^n file con lo stesso nome, solo giocando con maiuscole/minuscole?? Mi pare stupido..
    Inoltre, fate il discorso “convenzione nei nomi dei file”, su un pc che non utilizzate solo voi..tipo a scuola o lavoro. Se ognuno avesse una convenzione diversa, su un FS CS..voglio vedervi a raccapezzarvi. Ogni due per tre, lancereste find/google search e quant’altro? Bel guadagno prestazionale: per non far fare al sistema operativo quello per cui lui impiegherebbe 1ms, ne impieghiamo 10 noi. Che furbata..

  • # 51
    D
     scrive: 

    “non mi risulta. A me sembra di lavorare allo stesso modo tanto su AmigaOS quanto su Windows. Perché dici che in quest’ultimo caso ci sia “un miscuglio insensato di caratteri”? Potresti farmi qualche esempio, cortesemente?”

    Entra nella cartella di windows, prendi qualche file a caso che non sia una musichetta o uno sfondo e dimmi che capisci cosa fa quell’ammasso di dati dalla semplice lettura del suo nome.
    Cosa ti dice questo nome LZEXPAND.DLL senza ovviamente cercare su internet o in qualche libro tecnico.
    Fondamentalmente ci salviamo perchè abbiamo un’interfaccia grafica e chi l’ha progettata intelligentemente/furbescamente ha cercato di renderla abbastanza completa da ridurre al minimo l’interazione con la linea di comando ma se così non fosse (come effettivamente succede con linux, nessun kde o gnome riuscirà mai a sostituire il terminale neppure per un uso banale) buona fortuna a colpi di autofmt dcomcnfg dfrgfat (di nuovo, se usi l’interfaccia, con alcuni di questi riesci a scoprire cosa sono e cosa fanno ma dalla semplice lettura del nome nisba).

    La domanda come al solito è molto semplice: quale motivo fa si che lo stesso sistema che promuove l’uso di un file system in grado di gestire nomi lunghi, per i suoi file si accontenta del solito 8+3 ?
    Brutta abitudine ? Mancanza di fiducia nel formato ? Limitazioni tecniche che esulano dal lato software ?

  • # 52
    Fede
     scrive: 

    @Cesare Di Mauro

    Non prendere l’esempio del database alla lettera, ho solo fatto un esempio di situazioni in cui per ottenere eventualmente l’inserimento di dati in modo NON Case Sensitive indurrebbe il programmatore ad aggiungere parecchie linee di codice in più tanto è vero che ho aggiunto che dipende molto dalle particolari situazioni se imporre al software essere Case Sensitive o NO. Infine ho evidenziato il fatto che nella logica di base sarebbe un vero problema la non distinzione tra caratteri minuscoli da quelli maiuscoli.
    Per quanto riguarda la tua asserzione sulla mia ipotetica confusione tra il concetto di variabile e quello di dato (la variabile è semplicemente un’etichetta nenmonica di una certa locazione di memoria mentre il dato è l’informazione che viene memorizzata nella medesima locazione di memoria, ci mancherebbe che io non sappia di questa differenza), direi proprio che hai interpretato male la cosa, il problema della Case Sensibilità o meno è molto frequente nella gestione di maschere per l’input dei dati esattamente come succede nelle finestre di gestione dei database.
    Per esempio (ma non prenderlo alla lettera cerca di cogliere il nocciolo di quello che dico) mettiamo di voler gestire una tabella in cui c’è un colonna “Provincia” interfacciata da una finestra di input dei dati, allora è chiaro che non solo c’è da controllare che il dato immesso sia una stringa di testo lunga 2 caratteri e che non tutte le coppie di carettteri immesse siano accettabili c’è anche da gestire il fatto che la sigla deve essere rigorosamente in caratteri maiuscoli (ripeto prendilo come esempio perché in questo caso particolare basta fornire all’utente di una finestra con stile combobox ed esibire una lista ben predefinita delle province in modo che l’utente stesso è costretto semplicemente a scegliere)

  • # 53
    Fede
     scrive: 

    Scusate nel precedente intervento considerate quel “NON” inesistente, ho fatto un po di confusione nello scrivere

  • # 54
    Fede
     scrive: 

    Sempre @Cesare Di Mauro

    Sinceramente io non ci ho fatto mai caso nello scrivere comandi SQL perché quando mi occupo di programmazione e di database seguo sempre in modo rigoroso un certo standard ad esempio le tabelle le uso indicare sempre con caratteri maiuscoli e le singole colonne in caratteri sia maiuscoli che minuscoli però suppongo che la cosa dipenda non tanto dal file system ma dall’interprete dei comandi SQL.
    Una cosa strana che ho notato nel file system NT di Windows XP Professional è che in generale è case sensitive tuttavia in varie occasioni mi è capitato di ritrovarmi rifiutata la ridenominazione di un file o una cartella solo per aver cambiato semplicemente il carattere iniziale da maiuscolo a minuscolo o viceversa con l’emissione del messaggio che l’operazione richiesta non è applicabile perché esiste già un file/ cartella con il medesimo nome

  • # 55
    Flare
     scrive: 

    Penso che da questo, si potrebbe sviluppare l’argomento con un altro articolo che illustri i perché di queste due scelte e la storia che c’è dietro.

    Tornando al ragionamento dell’articolo, mi pare sensato, considerandolo dal punto di vista dell’utente. Dal punto di vista di chi programma, invece il discorso è un po’ più complesso, come è già stato fatto un po’ notare. In qualche caso (per altro raro) il case insensitive per i nomi dei file l’avevo trovato un po’ limitante, ma comunque cose aggirabili. Lì però va distinto l’uso del nome del file che fa un utente (lo vorrà presumibilmente “leggibile”) e l’uso che ne può fare un programma (a cui va benissimo una qualunque serie di caratteri, specie se si tratta di un file che l’utente probabilmente non vedrà mai; esempi che facilmente avrete visto in giro sono la cartella del profilo di Firefox, certi file temporanei, ecc).

    Il discorso potrebbe essere lungo, ma considerato generalmente che quel che si produce è destinato ad un utente e che l’utente può in ogni caso (ri)nominare dei file, IMHO si ritorna in ogni caso al punto di vista dell’utente.

    Posso pensare ad un altro esempio (che mi è capitato): supponiamo che io stia salvando delle immagini da Photojournal del JPL e che voglia dare ai file salvati nomi più leggibili all’umano che PIA10097.jpg, ad esempio “Sonda New Horizons – Giove 022.jpg” (la ventiduesima immagine di Giove che salvo dalla galleria della missione New Horizons). Capita però di essere distratti o smemorati e magari ho già salvato 22 immagini, ma mi “sbaglio” e scrivo “sonda New Horizons – Giove 022.jpg” (ma potrebbe essere anche Immagine22.jpg vs immagine22.jpg): nome identico per un umano, ma con una maiuscola in più o in meno, che può starci come no. In un fs case sensitive, a meno che non venga creata una funzione apposita, il save dialog dell’applicazione non mi avvertirà che ho “sbagliato” e che esiste già l’immagine 22. Quando andro a rivedere la mia galleria di immagini spaziali, noterò con disappunto che ho due immagini numerate 22.

  • # 56
    Cesare Di Mauro
     scrive: 

    @amadeus: con MySQL il problema è sempre presente a prescindere dall’engine. Te l’assicuro, visto che lavoro tutti i giorni con tabelle MyISAM, InnoDB, e a volte anche NDS (quelle clusterizzate).

    @ZeuzzO: perdona la limitatezza, ma da essere umano non posso che rimanere confuso. :D

    @gerlos: io continuo a non vedere come una soluzione case insensitive + case preserving possa precludere il tuo modo di lavorare.
    Se per i progetti temporanei usi i nomi maiuscoli, e li passi a minuscoli quando li hai completati, beh… puoi fare lo stesso anche con un filesystem come quello che indicavo. ;)

    Ripeto: nessuno qui ha detto che si vuol fare a meno del case. Se è questo il passaggio che cogliete, allora ho fallito nello scrivere l’articolo, e mi cospargo il capo di cenere, cercando di far meglio in futuro.

    Quanto a MySQL, i problemi rimangono. Ad esempio la query che ho scritto prima come esempio… fallisce.
    Il completamento automatico di cui parli fallisce nel momento in cui scrivo “cli” anziché “Cli”, perché per MySQL la tabella si chiama soltanto “Clienti”… in barba allo standard SQL.

    @TheFoggy: grazie, adesso ho capito cosa voleva dire whiplash. Beh, da essere umano mi ritengo fortunato a non dover usare quell’accozzaglia di caratteri, e di avere quasi sempre a disposizione un’interfaccia grafica che presenti le informazioni in maniera più vicino a me. :D

    @D: OK, adesso ho capito. Anche qui, come per Unix, è un problema di convenzioni che Windows si porta dietro dai tempi del DOS, purtroppo.

    Ma il filesystem non c’entra nulla.

    @Fede: io non vedo perché dovrei lamentarmi come programmatore. Sì, gestire il case insensitive mi complica le cose e devo scrivere codice in più, ma… è necessario!

    Io scrivo le applicazioni non per me stesso, ma per gli utenti, e quindi i requisiti che devono soddisfare sono i loro, e non i miei, anche se capisco che potrei sbrigarmi prima.

    Sui concetti di identificatore e dato, continuo a vedere una discrepanza di visione.
    Fai l’esempio delle maschere di input, ma in questo caso stiamo parlando di DATI, non di IDENTIFICATORI, come sono invece i nomi delle variabili oppure i nomi dei file e ai quali è rivolto l’articolo.

    Sui dati le problematiche sono di diverso tipo, ma dipendono strettamente dal tipo di problema che si deve risolvere. Ci sono dati che vanno gestiti case sensitive, e altri case insensitive, e noi programmatori non possiamo esimerci dal trattarli in tal modo.

    Sul SQL, ti posso dire che lo standard prevede identificatori case insensitive, ma MySQL su Linux fa diventare case sensitive esclusivamente quelli delle tabelle perché… le mappa su filesystem.
    Quindi in questi casi si pone fuori standard.

    Infine sui problemi che hai avuto con Windows NT, penso sia stato un problema di lock o qualcosa di simile, perché quelle che hai citato son tutte cose che ho fatto e faccio normalmente.

    @Flare: hai azzeccato anche tu lo spirito dell’articolo. :)

    La storia che c’è dietro è semplice: i programmatori hanno tirato fuori filesystem case sensitive, come pure linguaggi con identificatori case sensitive, semplicemente perché sono più facili da gestire per loro, e le operazioni di confronto degli elementi è molto più semplice.

    Ma è un punto di vista che riguarda strettamente chi ha creato il linguaggio X (o C :D) e il sistema operativo e/o filesystem Y).

    Queste scelte hanno poi vincolato sia i programmatori che usavano/usano questi strumenti, che gli utenti finali.

  • # 57
    Iro
     scrive: 

    Premetto che non sono un programmatore, ma per curriculum universitario m’è pure capitato di dover fare degli esami su java, php e SQL, quindi, almeno a grandi linee capisco quello che avete detto.
    Amio avviso occorre capire come e perchè nascono le maiuscole. Quando la cultura era prettamente orale si scriveva solo con un carattere, i Latini scrivevano tutto in maiuscolo ad esempio. Poi col tempo emersero esigenze di differenziazione dettate dall’emergere della scrittura come principale veicolo comunicativo.
    Attualmente però si va incontro a fenomeni di neo oralità, ovvero, anche se in forma scritta, si va sempre più verso una istantaneità della comunicazione, in cui maiuscole e minuscole si equivalgono sostanzialemnte. In chat maio e poi mai mi metto a iniziare le frasi con la maiuscola, al max metto caps lock se devo urlare, ma nulla più.
    Quello che voleva sostenere dimauro (volutamente minuscole e senza spazi ;-) ) è che a suo avviso un file system dovrebbe rispecchiare queste esigenze di immediatezza a cui si stà andando incontro.
    Personalmente mi sento di condividere la sua posizione in qualità di utente finale: mai e poi mai vorrei diventare matto a cercare dei file includento tutte le possibili varianti…e non state a dirmi che posso fare delle ricerche includento tutti i risultati, io posso, ma mia madre che a malappena ha imparato a fare le suddette ricerche se non trova i file che cerca mi chiama a qualsiasi ora per dirmi: “non va!!!!”
    eventualmente se proprio si necessita di nomifile case sensitive, come ampiamente argomentato da altri, la preservazione di case risolve molte situazioni, oppure basterebbe introdurre dei caratteri speciali (esempio apici su google) per rendere case sensitive il tutto.

  • # 58
    Gas
     scrive: 

    Sono un programmatore, e questo in effetti potrebbe essere il mio limite, ma non capisco davvero il problema nell’usare un File System case sensitive.
    Come veniva detto qualche commento fa, dare un nome ad un file NON E’ una operazione banale: Se un utente si sbaglia ad inserire il nome di un file mi sembra onesto che faccia fatica a ritrovare il file.
    Gli esempi che vengono fatti “se per errore invece di GinoPino inserisco GinOPino” mi sembrano quantomeno interessanti: perche’ non creiamo un File System che non noti differenza tra lo 0 (zero) e la lettera O (Gin0Pino). Ci sono utenti che si sbagliano a spingere la lettera.. e poi sono anche vicine.. (e, no, non e’ un esempio che mi sono inventato su due piedi: sono stato per un anno all’ufficio informatica di un comune ed ho visto cose che voi umani non potete nemmeno immaginare =) )
    A quel punto se uno invece di scrivere “ginopino” scrive “pinopino” ? E’ ancora un solo errore di battitura, no ?

    Per quanto mi riguarda un nome di file “xxxx.yyy” e’ differente rispetto a “Xxxx.yyy”.
    Il primo corrisponde ad un file “bozza”, il secondo allo stesso file alla versione “finale” (si, le due versioni spesso coesistono sul mo FS, assieme alle versioni “xxxx_1.yyy”… etc.).
    Certo, potrei usare “xxxxBozza.yyy” e “xxxxFinal.yyy” o miliardi di altre combinazioni, ma la notazione per me piu’ comoda ed immediata e’ quella che uso (ovviamente).
    Anche senza questa mia abitudine, anche se per me i file “XxXx.yyy” e “xxxx.yyy” significassero la stessa cosa, preferirei preservare la possibilita’ di usare le due notazioni contemporaneamente.

    Sono d’accordo al venire incontro alle esigenze di chi usa il computer senza essere un geek, ma che le esigenze di chi il computer lo sa usare vengano ignorate mi sembra eccessivo.

    Ovviamente.. tutto IMHO

    -Gas-

  • # 59
    ...
     scrive: 

    … Il tuo commento è stato moderato.

  • # 60
    amadeus
     scrive: 

    @Cesare
    X il discorso MySQL avevo detto una cavolata. è assolutamente come dici tu.

    x quanto riguarda la rinominazione di file cambiando solo una lettera da maiuscola a minuscola (o viceversa) confermo che su xp ho avuto quel problema anche io (e non si trattava di lock) mentre or ora ho fatto una prova con vista x64 e funziona tutto alla perfezione

    vedo con dispiacere, però, che pochi hanno capito davvero il senso del tuo articolo e continuano a confondere i concetti di case sensitive e case preserving…

  • # 61
    TheFoggy
     scrive: 

    @Gas: il problema fondamentale è che quel sistema funziona per una TUA convenzione, che sarà, probabilmente DIVERSA dalla mia e da quella di CHIUNQUE altro qui presente. Lavori in un’azienda, quindi..dovresti aver la possibilità di mettere mani sui pc degli altri. Ecco..ognuno avrà la propria convenzione. Capisci che, anche usando il completamento automatico, devi sempre provare con maiuscola e minuscola, sia se cerchi una bozza, che se cerchi un file definitivo? E poi, quelli che girano qui, sono tutti utenti abbastanza “pro” e abituati a gestire la sensitività dei nomi. Ma..i due che dicono “non siamo programmatori”, casualmente preferirebbero un fs insensitive (ma preserving). Questo dovrebbe farvi capire cosa intendeva dire Cesare e gli altri fautori dell’insensitive. Io ripeto che preferisco sbattermi da programmatore, e fare un software semplice per l’utente, piuttosto che qualcosa di iperottimizzato, ma che porta allo sclero l’utente..

  • # 62
    damxxx
     scrive: 

    Io il problema lo vedo in funzione della ambiguità che potrebbero avere due file dal nome tipo “xxxx.yyy” “Xxxx.yyy” sia perché in futuro (da semplice utente e non da programmatore) potrei dimenticare quella maiuscola per cosa stia, sia perché potrebbe presentarsi la necessità che uno di quei file debba essere modificato da un altro utente (come avviene spesso nello studio dove lavoro) che potrebbe ignorare tale differenza andando in confusione, per tanto trovo più funzionale utilizzare nomi del tipo “xxxxBozza.yyy” e “xxxFinale.yyy” e che il filesystem mi impedisca certe ambiguità a scanso di equivoci, che comunque potrebbero esserci per altri motivi, ma non vedo perché si debbano aggiungere anche il problema di dover stare attenti alle maiuscole…

  • # 63
    fx123
     scrive: 

    Quando lavoro al terminale su windows è una goduria non doversi preoccupare delle maiuscole e delle minuscole, mentre su linux ci perdo molto piu tempo ogni volta per fare le stesse cose (senza considerare il fatto che il la struttura delle directory sugli unix è assolutamente assurda, ma è una altro discorso).
    i vantaggi di un fs case sensitive alla fine quali sono? nessuno… se postessi avere un fs case insensitive pure su linux farei i salti di gioia…

  • # 64
    Cesare Di Mauro
     scrive: 

    @Iro: più che altro lo vedrei come un ritorno al passato. Mettere l’uomo al centro dell’attenzione, e non il computer. ;)

    @Gas: concordo con quanto detto dagli altri utenti dopo di te (ma proprio tutti! :D).

    @amadeus: è strano perché m’è capitato diverse volte di cambiare soltanto il case a dei file con XP, e non ho mai avuto problemi. Adesso non posso verificare, ma appena ho un PC con questo sistema lo farò sicuramente.

    @fx123: se vuoi con Linux puoi montare i filesystem in modalità case insensitive. Questo se il PC è tuo. Per quelli in produzione penso però che i sysadmin preferirebbero morire (o, meglio ancora, farti la pelle :D) piuttosto che farlo. :D :D :D

  • # 65
    @Cesare Di Mauro
     scrive: 

    Dire che rendere certe procedure case sensitive comporta maggior numero di linee di codice non significa necessariamente che ci si lamenti della cosa, di nuovo sottolineo che ho ripetutamente scritto che solo nell’analisi dei singoli casi si può stabilire se sfruttare la case sensibilità o no.
    Un’altra cosa che vorrei precisare e ci tengo a farlo è che io per ben 5 anni ho programmato non per me ma per lavoro, attualmente mi occupo di progettazione (non informatica) ma comunque mi aggiorno sempre nel settore della programmazione sia perché potrebbe essere utile nel futuro e sia perché sono uno delle pochissime persone soprattutto qua in Italia che ritengono che sia necessario studiare sempre per tutta la vita, non a caso i miei interessi spaziano verso moltissimi settori verso anche settori umanistici anche se ho titoli e competenze più che adeguate nel settore dell’elettronica/elettrotecnica in particolar modo nel settore dei controlli automatici sia analogici che digitali; in particolare tra i miei interessi c’è la matematica e la logica matematica (è una delle mie grandi passioni) per esempio sui database relazionali ho conoscenze approfondite sulle sue basi matematiche e logiche per esempio il banale principio che se ho una scatola piena di oggetti in via teorica esiste sempre un ragionamento logico che porti a scegliere alcuni oggetti nella scatola (assioma della scelta) è fondamentale per l’architettura dei database relazionali e del perché certe ralazioni n ad m devono essere implementate in un certo modo lo posso dimostrare rigorosamente.
    Ho precisato questo perché ho l’impressione che le tue risposte alle mie affermazioni siano piuttosto risposte di rivalsa … è vero sono stato un po irruente con il mio primo commento su questo articolo ma l’ho fatto perché volevo stimolare commenti più tecnici e professionali e mi sembra che lo scopo l’ho ampiamente raggiunto basta leggere i commenti successivi al mio primo commento e confrontarli con i primi commenti.
    Per quanto riguarda il discorso pertinente all’articolo mi sembra che stiamo dicendo le stesse cose anche se ho fatto alcune volte un po di confusione ma guarda l’orario di molti dei miei post e capirai …
    Non prenderla personalmente per queste mie parole, anche perché ti stimo molto e seguo molto i tuoi articoli

  • # 66
    Cesare Di Mauro
     scrive: 

    Da quel che dici immagino che tu sia l’utente Fede. :)

    No, nessuna rivalsa, te l’assicuro. Non ti nascondo che mi ha dato un po’ fastidio il tuo primo commento, ma poi, come giustamente hai fatto notare, la situazione è rientrata, e di questo sono contento.

  • # 67
    Giulio
     scrive: 

    Esatto cesare, non so se si era capito dal mio intervento ma io la penso come te, poiché appunto in questo articolo si parla di “significato” più che di rappresentazione, come qualcuno ha frainteso.

    E’ la stessa differenza che passa in SQL tra equivalenza tra tabelle (quindi il loro significato, ad esempio se ho una con Nome, Cognome e un altra con Cognome, Nome il significato per noi DEVE ESSERE lo stesso), ed uguaglianza fra tabelle (in cui conta la posizione dei campi, ad esempio quando desideriamo che le tabelle siano UNION COMPATIBILE).

  • # 68
    Cesare Di Mauro
     scrive: 

    Sì sì. Infatti ero d’accordo e ho scritto proprio per rimarcarlo. Ma forse sono stato troppo criptico. :D

  • # 69
    Fede
     scrive: 

    Ripeto … a mio avviso nella logica di base la case sensibilità deve essere intrinsicamente presente sarebbe un vero problema se le cose non stessero in questo senso.
    Tuttavia trovo superficiale discutere se è giusto o no che una certa cartella o un certo files sia la stessa cosa o una cosa diversa se nominato “PIPPO” o “Pippo” o “piPPo” ecc. ecc. è come se stessimo parlando di :
    >.
    Certamente sarà difficile trovare un file/directory nominato che ne so “piPPo” ma questo è piuttosto legato ad un discorso di usi e costumi e ad un discorso estetico/psicologico per esempio si avverte una certa riluttanza e inquietudine vedere nominata una cartella “documentipersonali” piuttosto che “Documenti personali” o al limite “DocumentiPersonali”.
    Una discussione più profonda sarebbe per esempio sul files sytem NT di Microsoft … a tutti è noto che facilmente le procedure di copia si incartano quando si copiano cartelle “matriosca” con nomi eccessivamente lunghi, in questo caso la Case Sensibilità potrebbe essere utile per risolvere il problema in quanto mette a disposizione maggior possibilità di nomenclatura pur mantenendo le etichette ragionevolmente corte.
    … per non parlare delle password e dei database dei quali ho già fatto cenno

  • # 70
    Riccardo
     scrive: 

    constatazione cesare, pura e semplice ;-)

  • # 71
    Fede
     scrive: 

    Una domanda allo staf di questa sezione che non ha nulla a che fare con l’articolo:

    PERCHE’ SE INSERISCO NEI COMMENTI DELLE CITAZIONI RACCHIUSE TRA LE DOPPIE FRECCE CIOE’ TRA “>” AL MOMENTO DI INVIO DEL COMMENTO LE STESSE CITAZIONI VENGONO OMESSE?

    GUARDATE L’ULTIMO MIO COMMENTO A QUESTO ARTICOLO

  • # 72
    Cesare Di Mauro
     scrive: 

    Purtroppo è un problema di WordPress, che a quanto pare si lascia sfuggire certi caratteri nell’eseguire l’escape. :(

    @Riccardo. OK :)

  • # 73
    FabioFLX
     scrive: 

    Ahah! Spero che questo articolo sia un pesce d’Aprile in ritardo :)
    No, dico davvero…
    E’ veramente assurdo che nessuno abbia citato il fatto ovvio per cui l’importanza del “case” nella nostra lingua è ridicolo rispetto a quello che può avere nelle altre!
    Il tedesco e lo svedese utilizzano le maiuscole per differenziare il senso delle parole, non solo la forma. Per loro il case sensitive non è una finezza estetica, ma l’unica possibilità di esprimere un nome in maniera sensata.
    Per fare un esempio inverso, immaginatevi se dall’oggi al domani le lettere accentate (che non esistono in inglese, cioè LA lingua dell’informatica) fossero tagliate fuori dai nomi dei file…

  • # 74
    Cesare Di Mauro
     scrive: 

    E chi ha mai detto questo? Mi sa che l’articolo dovresti leggerlo con più attenzione, in particolare quando si parla di “case preserving”.

    Errore che, purtroppo, hanno fatto in molti.

  • # 75
    Fede
     scrive: 

    continuo a notare che al riguardo delle doppie frecce il sistema deturpa i miei commenti … capisco che in HTML i simboli “>” e “

  • # 76
    Fede
     scrive: 

    vedo che la cosa sia più grave di quanto pensassi il precedente commento è stato pubblicato mozzato sicuramente per le frecce … non oso più scrivere i simboli incriminati così comé si presentano

    comunque volevo dire che capisco che le frecce sono caratteri privilegiati per il linguaggio HTML tuttavia con una piccola procedura JavaScript potrebbe essere risolto il problema

  • # 77
    FabioFLX
     scrive: 

    Caro Cesare, spero non te la sia presa se ho trattato il tuo articolo con ironia. D’altronde il tema è piuttosto leggero, e mi sono permesso di canzonare un po’ delle risposte…
    Il case preserving permette di memorizzare e visualizzare il nome del file con il corretto case ma anche di accedervi a prescindere da esso. Il punto è che un file-system case-insensitive, anche se case preserving, non dà la possibilità di memorizzare due file con lo stesso nome in accezioni diverse.
    E allora perché limitarci? Chi non ha bisogno del “case” scriva minuscolo, ma senza per questo costringere a farlo anche chi il “case” lo preferisce e lo sfrutta.
    Personalmente questa soluzione mi appare più logica.

  • # 78
    Cesare Di Mauro
     scrive: 

    Io ho scritto un articolo proprio per portare un punto di vista completamente diverso, che per quanto “leggero” ti possa sembrare ha delle implicazioni non banali…

  • # 79
    The3D
     scrive: 

    Da programmatore, per come la vedo io usare il case per evidenziare (o definire) un diverso contributo informativo non ha senso. Anche il paragone del linguaggio di programmazione non regge secondo me: Non mi sognerei mai di chiamare due variabili “unaVariabile” e “unavariabile” volutamente per distinguerle. Personalmente uso il case solo ed esclusivamente per favorire la leggibilità e seguire le classiche convenzioni che tutti conoscono. Non mi è mai successo e mai succederà (spero) di chiamare due variabili/classi/metodi con lo stesso identico nome e case diverso, solo per indicare che sono diverse. Sarebbe un coding horror imo. Per quanto riguarda eventuali input immessi dall’utente/dati da memorizzare in eventuali db (esempi letti precedentemente) è innegabile che nella stragrande maggioranza dei casi il case sia trascurabile, cosa che si puo fare con un effort minimo (a meno che non si programmi ancora in assembly)

  • # 80
    whiplash
     scrive: 

    > @whiplash: non ho quei comandi nel mio sistema. :D

    Io sì, ed è un sistema desktop piuttosto diffuso:
    find /cygdrive/c -name kernel32.dll
    /cygdrive/c/Windows/System32/kernel32.dll

    > Poi se magari spieghi quello “spararle grosse”

    Parlavi di difficoltà di ricerca di un file, nel caso
    di file system case-sensitive, confondendo, cioè, una
    caratteristica del file system con una feature degli
    *strumenti* di ricerca *all’interno* dei file system.

  • # 81
    Cesare Di Mauro
     scrive: 

    Il contesto, però, era importante per capire a cosa mi riferivo. Infatti il punto di vista era sempre quello dell’utente, e l’inizio della frase era piuttosto eloquente: “Come utente”.

    Non a caso ho parlato in maniera connessa non soltanto di mera “ricerca”, ma anche di “interpretazione”, e questa è un po’ più difficile da realizzare in maniera automatica (sempre sulla base del nome del file).

    Il quadro che volevo dipingere ti sarebbe più chiaro ponendoti dal punto di vista di un utente che apre una cartella e si trova davanti file e cartelle, alla ricerca di qualcosa che gli serve e che deve controllare e “interpretare”, appunto, quanto arriva ai suoi occhi.

    Quanto a Cygwin, lo conosco, c’ho anche lavorato per un certo periodo, ma lo stretto indispensabile per interfacciarmi con sistemi Linux. Per cui la mia conoscenza dei vari comandi era e rimane estremamente ridotta.
    Infatti, essendo sotto Windows, per andare a caccia di file et similia non mi affidavo certo alla shell, ma al fido Total Commander. ;)

  • # 82
    Flare
     scrive: 

    @Iro: il problema dellle ricerche non si pone neanche sui FS case sensitive: ad esempio su GNU/Linux puoi usare strumenti molto potenti come grep o frontend grafici come Searchmonkey, che non solo consentono ricerche case insensitive, ma perfino di usare regular expressions.

    @Gas: è vero anche il discorso zero ed O (una volta lo zero era distinto tramite una barretta o un puntino dentro, che lo rendeva inconfondibile) e gli errori di battitura; però, se parliamo di ricerca di file, ci sono sempre wildcards e dove disponibili anche le RE (queste ultime forse complicate per l’utente medio). Poi volendo nulla vieta la creazione di strumenti di ricerca dotati di un’opzione per una funzione in grado di sopperire ad eventuali errori di battitura.
    Ma il punto è un’altro: a meno che l’utente non si autodisciplini adottando uina convenzione nel nominare i file (es solo minuscolo), se scrive un nome comune come “gatto.jpg” o “Gatto.jpg”. in entrambi i casi non si sta sbagliato a scrivere e non si aspetta che ci siano problemi. Dunque il nocciolo della questione è: una macchina a misura/adattata all’umano o un umano che si deve adattare alla macchina?
    Pensando alla storia dell’informatica, direi che, quello di maggior successo fra i due è il primo approccio.

  • # 83
    fx123
     scrive: 

    il problema dellle ricerche non si pone neanche sui FS case sensitive: ad esempio su GNU/Linux puoi usare strumenti molto potenti come grep o frontend grafici come Searchmonkey, che non solo consentono ricerche case insensitive, ma perfino di usare regular expressions.

    strumenti per ricercare i file tramite espressioni regolari ci sono anche per windows!
    mi spieghi per quali motivi secondo te su windows non si potrebbero fare programmi come grep?
    cosa pensi che abbia linux che windows non ha per fare ricerche su file?
    e inoltre cosa c’entra col case preserving?

  • # 84
    Massimiliano
     scrive: 

    Qualcuno ha scritto che lo UNICODE definisce come convertire maiuscolo in minuscolo e viceversa… Vero, ma solo all’interno di una lingua definita a priori (la collation mi sembra).
    Esempio: in italiano i e I sono la stessa lettera (i minuscola e i maiuscola). I turchi invece si sono divertiti un pochino (http://it.wikipedia.org/wiki/Lettere_i_e_%C4%B1_in_lingua_turca)… Loro hanno la i con il puntino (in maiuscolo “İ”) e la ı senza puntino (in maiuscolo I).
    Supponiamo di avere un file system case insensitive e di aver impostato la lingua in italiano.
    Creo un file che si chiama “i” “İ” (usando la I con puntino maiuscola turca). Per il FS va bene, le lettere sono diverse (in italiano il maiuscolo di “i” è “I” e non “İ”). Ora cambio la lingua in turco (oppure porto l’HD su un computer turco). Per il computer turco i due files hanno lo stesso nome (perché “i” e “İ” sono uguali)… Bel casino eh?

  • # 85
    Andrea
     scrive: 

    Il FS deve essere case sensitive, sono le interfacce grafiche che posso aiutare l’utente. Non mi interessa che il FS si user friendly: lo voglio veloce, affidabile, con un comportamento ben definito.
    Inoltre un po’ di rigore aiuta, permettere all’utente di fare quello che vuole e pensare da umano non e` la soluzione ideale.

  • # 86
    fx123
     scrive: 

    In che modo l’essere case sensitive aiuta un FS a essere veloce, affidabile, con un comportamento ben definito?
    A me sembra solo una palla al piede…

  • # 87
    Cesare Di Mauro
     scrive: 

    @Massimiliano: lo Unicode prevede diverse modalità di “collazione” dei dati, è vero, ma lo stesso problema si presenta tale e quale nei filesystem case sensitive nella misura in cui è necessario eseguire confronti case insensitive.

    Quindi è sufficiente applicare la stessa soluzione con entrambi i tipi di filesystem.

    @Andrea: mi spiace, ma io lavoro per l’utente, e il computer non è nato per piegare l’uomo alle sue esigenze, ma per dargli una mano nel suo lavoro.

    Come programmatore il mio riferimento principale l’uomo, non la macchina.

    Detto ciò, il rigore di cui parli è anche fonte d’errore nella misura in cui un utente può generare file con lo stesso nome, ma che differiscono soltanto per il case, quando in realtà (e come avviene praticamente sempre) il file che ottenere era sempre e soltanto uno.

  • # 88
    Flare
     scrive: 

    fx123, mi spieghi dove ho scritto che su Windows non ci possono essere strumenti per ricercare i file tramite espressioni regolari? Ma soprattutto cosa caspita c’entra Windows con quel che ho scritto? Non dirmi che siamo ancora alla solita noisa e futile diatriba dei bambinetti, che appena sentono nominare Windows, Linux o Mac, non leggono più neanche il resto e si preparano direttamente a prendersi a cornate, perché ha rotto a dir poco gli zebedei.
    Ah sulle questioni relative alla mancanza del case preserving, ho proprio sorvolato, visto che è una problematica d’altri tempi (quelli del DOS, del CP/M…) e che non c’entra nulla coi FS moderni di cui qua si parla.

    Comunque basta che leggi per intero quel che ho scritto e non solo il pezzo di commento che hai estrapolato. E magari anche ciò che ho scritto in precedenza, prima di far che partire al galoppo.
    Non dovrebbe essere troppo difficile notare che mi riferivo ad un commento di Iro (“@Iro”, è proprio all’inizio del mio commento…), quindi, logicamente, basta andare a vedere il suo ultimo commento (commento numero 57) e leggere a cosa mi riferisco (chiaramente i due ultimi paragrafi). Non dovrei neanche spiegarlo.

    Ebbene, lì si parlava di ricerce e di FS case sensistive. Dunque, se parliamo di ricercare file in quei file system, allora vediamo il caso reale in cui tale situazione si verifica (ad esempio in GNU/Linux, i cui fs predefiniti sono appunto case sensitive. Ci sono altri SO che li adottano, ma preferisco fare esempi di cose che conosco) e come avviene la ricerca in questi casi (ad esempio con grep o Searchmonkey) e cosa è possibile fare (anche ricerce case insensitive e pure con RE). La conclusione, considerato quanto sopra, è che anche lavorando su un FS case sensitive, non è un problema la ricerca di nomi di file, perché esistono efficaci strumenti per fare ricerche case insiensitive, wildcards e perfino con le RE. Punto.

  • # 89
    TheFoggy
     scrive: 

    @Flare: ciò che dici è corretto (mi riferisco alla ricerca..dato che non sono fx123! :) ), ma frustrante, da un lato. Se facessi una ricerca insensitive del famosa “pippo.txt”, ma mi uscissero 15 risultati diversi tutti nella stessa cartella..quale dovrei aprire? Dovrei ricordarmi delle mie convenzioni, ok. E se ti presto il mio pc e le tue convenzioni sono diverse dalle mie? Perdi un’ora ad aprire files inutilmente. Non è più comodo, allora, chiamare i file con nomi diversi? Evitando, magari, i caratteri speciali, così da evitare il più possibile fraintendimenti nel cambio lingua? Nessuno dice di chiamare un file “foto che ho scattato sotto l’acqua 12 anni fa: è molto bella.jpg”, questo è un nome idiota. Ma “foto subacquea XXX.jpg” è pulito e corretto. Ma avere, magari per errore o “sollevamento anticipato del ditino dallo shift”, un file che si chiama nello stesso modo, ma con case diverso..può far girare le balle. Metti che siano file con ordine strettamente definito. Ne chiami uno “file 001.txt” e l’altro “File 001.txt”..te ne accorgi alla fine e..che fai? Rinomini tutto dalla fine all’inizio? (evitiamo le espressioni regolari, che sono per lo più da power user..). Meglio che mi dica subito che il file “file 001.txt” (e variazioni del case) già c’era..

    L’umano sbaglia molto più spesso del computer (o, almeno, il pc dovrebbe sbagliare meno di noi! :P), quindi lui, in quanto nostro strumento, dovrebbe prevenire il più possibile tali errori. Soprattutto quando si parla di operazioni che, realizzate in assembly, occupano poche istruzioni e cicli di clock.. Se preferite, facciamo una petizione per farle eseguire dalla GPU, forte delle sue VPU! :)

  • # 90
    Cesare Di Mauro
     scrive: 

    La GPU morirebbe proprio a causa dei confronti e dei relativi salti: non ama particolarmente i salti condizionati. :D

    Condivido ciò che hai scritto perché il mio punto di vista rimane quello dell’utente / essere umano che deve utilizzare il computer.

    Espressioni regolari et similia sono roba da poweruser, appunto: gente che potrebbe anche dirti che programmare in linguaggio macchina è divertente. :D

  • # 91
    Gas
     scrive: 

    @TheFoggy, @Cesare …
    Capisco il vostro punto di vista, e sono d’accordo sul fatto che i programmi che faccio debbano essere fatti per l’utente e non per un programmatore.
    Ed infatti quando programmo tengo conto di queste esigenze, ma pensavo questo fosse ovvio e sottointeso.

    Questo non toglie che io, sul mio File System, vorrei poter fare quello che preferisco, utilizzando le mie politiche per dare i nomi ai file e quant’altro.
    Poi, ovviamente, in azienda adeguo le mie consuetudini alle politiche dell’azienda in modo che chiunque possa lavorare sulla mia macchina senza dover conoscere od intuire le mia abitudini. Ma anche questo mi sembrava ovvio e sottointeso.

    Quello che non capisco e’ perche’, se all’utente “medio” non piace un FS case sensitive, debba rinunicare anche io a questa feature.

    Personalmente tratterei la cosa allo stesso modo della shell in linux: all’utente “medio” non piace ed infatti sono stati creati strumenti (interfacce grafiche) che gli permettono di non utilizzarla. Poi, se l’utente vuole la shell c’e’.
    Se all’utente non e’ gradito il case sensitive, occorre fare in modo che ci siano strumenti che gli nascondano questo comportamento oppure che io, utente a cui interessa, possa attivarlo.

    Ancora una volta.. IMHO =)

  • # 92
    Cesare Di Mauro
     scrive: 

    Considerato che la massa è rappresentata da gente a cui non interesserebbe un filesystem case sensitive, io opterei per un default case insensitive.

    Poi i power user, se lo desiderano, possono abilitare quello case sensitive. Sono pur sempre power user, no? :D

  • # 93
    fx123
     scrive: 

    #88 Flare
    dopo aver letto il commento di iro ho capito cosa volevi dire, avevo capito un’altra cosa.

    avrai notato che questo articolo è pieno di commenti di fan boy di linux che si schierano a favore dei FS case sensitive solo perche linux è cosi di default, ti avevo scambiato per uno di quelli.
    gia ai primi post si trova scritto:
    “Il bello di linux è proprio che è case sensitive”
    “Anni di Windows vi hanno atrofizzato il cervello?”

    senza che nessuno prima avesse citato ne windows me linux…
    vabè ci siamo capito, ‘fanculo ai troll :P

  • # 94
    Cesare Di Mauro
     scrive: 

    Per favore, cerchiamo di mantenere la discussione sul piano puramente tecnico, anche senza istigare i “troll”.

    Soprattutto evitiamo di scadere nell’n-esima diatriba Windows vs Linux, perché non c’è proprio bisogno. ;)

  • # 95
    Dreadnought
     scrive: 

    Effettivamente a livello di filesystem dove la nomenclatura dei file è esclusivamente utile all’utente per gestire il contenuto di uno storage, la case sensitivity è inutile.
    Per una volta Cesare mi trovi perfettamente d’accordo!

  • # 96
    carla
     scrive: 

    La questione è facile.

    Almeno, per la gente “normale”… non per i programmatori che hanno una visione distorta della realtà (ed infatti vediamo prodotti come Linux che razza di schifezze di usabilità siano).

    Un FS DEVE essere case insensitive e DEVE essere case preserving.

    Questo per il motivo semplicissimo dell’usabilità.

    E’ totalmente illogico ed inutile dare uno stesso nome a due file diversi, infatti “pippo” e “Pippo” SONO lo stesso nome.

    Nella lingua scritta si usa tale differenza poichè si presume che o sia la prima parola dopo il punto (il che in un FS è perfettamente inutile da sapere, non esistendo righi o capiverso), o che sia un nome proprio, il che è ugualmente un formalismo di nessuna utilità (il PC non si scompone se si manca di bon-ton) e comunque ripristinabile tramite metadati (con un tag ad esempio “Nome Proprio”).

    MOOOOLTO più utile invece il poter scrivere PiPpo e sapere verranno trovate tutte le istanze del nome, etc.

  • # 97
    Cesare Di Mauro
     scrive: 

    Anche se condivido il contenuto (l’articolo nasce proprio per questo), lo stesso non vale per il “tono”.

    Come già detto, si tratta di questioni tecniche: lasciamo perdere le “guerre di religione”, che qui non dovrebbero avere diritto di cittadinanza.

    Invito, quindi, a esporre le proprie idee / tesi nel pieno rispetto degli altri lettori.

  • # 98
    FabioFLX
     scrive: 

    Insomma, alla fine un filesystem che possa essere “case quallo-che-vuole-l’utente” potrebbe essere la soluzione della controversia.
    Chi lo vuole sensitive lo avrà tale, gli altri insensitive.
    Suppongo che con FS aperti come gli ext2/3/4 sia anche piuttosto facile aggiungere l’opzione per la scelta, così come si possono modificare le caratteristiche del filesystem per altre opzioni altrettanto critiche senza dover nemmeno riformattare.

  • # 99
    Cesare Di Mauro
     scrive: 

    Con Linux, come dicevo prima, è già possibile specificare se montare un filesystem col case sensitive o insensitive.

    A mio avviso la soluzione migliore (che copre la stragrande maggioranza delle esigenze comuni / per la gente comune) è avere di default un filesystem case insensitive, e chi ha particolari esigenze può eventualmente passare il case a sensitive.

  • # 100
    Zenigata000
     scrive: 

    Al di la dei raffronti tra windows e linux (manco fossero gli unici SO esistenti), a me è tornato spesso comodo differenziare dei files solo con la presenza o meno di caratteri maiuscoli nel nome. Per es. ci sono delle volte che faccio ricerche di immagini, e ne salvo in molte quantità, tanto che piu volte tento di salvare immagini diverse ma con nomi identici (per es. nella dir. delle immagini ho già salvato le immagini pippo.jpg, pippo1.jpg, pippo2.jpg e via dicendo), in quel caso non sapendo all’istante nome+numero ho già salvato, mi limito a riscrivere una delle lettere iniziali in maiuscolo… a volte anche omettendo l’estensione (confidando nella tecnologia del magic number). Forse è solo questione di abitudini. A ognuno la sua :-)

  • # 101
    Pluto
     scrive: 

    Dai tutti i post che ho letto mi sembra chiare che il nome di un file ha due significati diversi. E’ un identificativo di un oggetto manipolabile dal file system e anche una descrizione usata dall’utente per indovinare il contenuto a colpo d’occhio.
    Per il primo significato secondo me è meglio usare il case sensitive perché da una maggiore flessibilità e si hanno meno cose da pensare nella stesura di un programma. Nel secondo caso, concetto più recente nella storia dell’Informatica e meglio il case insensitive perché si avvicina di più al linguaggio umano.

    Che sia il caso di avere un file system che distingua questi due casi?

  • # 102
    Cesare Di Mauro (Autore del post)
     scrive: 

    Non è compito del filesystem farlo (che in genere può essere impostato per lavorare nell’uno o nell’altro modo).

    La maggiore flessibilità del primo caso bisogna vedere se risulta pratica nella vita di tutti i giorni. A mio avviso, visto che sono gli esseri umani a dover usare il computer e non il viceversa, sarebbe meglio lavorare normalmente nel secondo caso.

  • # 103
    Scolapasta
     scrive: 

    A mio avviso non si tratta di stabilire se filosoficamente sia giusto attribuire a ogni carattere il suo valore ASCII e dunque trasformare in informazione per il filesystem la distinzione tra maiuscole e minuscole, si tratta di tracciare una linea di tradeoff tra usabilità e flessibilità.

    La case sensitivity aggiunge la possibilità di dare un significato alla differenza tra Colombo (il tenente) e colombo (il volatile) in modo più semplice e concreto di quanto possa fare la case preservation.

    Ma le possibilità che mi dà questa flessibilità vale di più o di meno delle possibilità di errore umano e quindi di overhead per l’utente che vengono introdotte?

    Lo valgono in inglese, o nella mia lingua, o nelle lingue più parlate al mondo che non sono necessariamente su base alfabetica?

    A mio avviso la risposta è più no che si, quindi IMHO se in senso stretto la case sensitivity è “giusta”, in senso pratico non è la migliore soluzione possibile, e tendo a preferire, come l’autore, un filesystem non case sensitive.

  • # 104
    Paolo
     scrive: 

    ma… un file system che mi dia determinate garanzie di sicurezza (journaling) e che sia compatibile con mac, windows e linux?!? chi mi può dare un consiglio?

  • # 105
    Cesare Di Mauro (Autore del post)
     scrive: 

    Visto che hai menzionato Windows, direi che l’unica scelta plausibile rimane NTFS.

    Il problema è che, a sua volta, MacOS X pretende HFS+.

    Se ti serve soltanto per immagazzinare dati (e, quindi, non farci girare i 3 s.o.), NTFS potrebbe essere una buona scelta.

  • # 106
    Di_ME
     scrive: 

    Quello che sfugge ai vari detrattori di Linux e’ che con Linux si ha facolta’ di disattivare il case sentitive o di fare ricerche ignorando il case, poi diverse volte il case sentive di Linux mi ha aiutato in situazioni del tipo: ho fatto una raccolta di schemi di apparecchi d’epoca attingendo da parecchi siti diversi, per poi dividerli io per marca etc e capitavano tantissimi file col nome diverso solo nel case, che avevano pero’ contenuti diversi, e su un sistema windows avrei finito per sovrascriverli uno con l’altro… I Windowsiani continuano a confondere una possibilita’ un piu’ come un difetto.

  • # 107
    Cesare Di Mauro (Autore del post)
     scrive: 

    Le situazioni di cui parli non sarebbero nemmeno esistite se a monte non ci fosse stato un filesystem case-sensitive.

    Oppure, se i contenuti provenivano da fonti diverse, non sarebbe in ogni caso da escludere la possibilità che file con identico case possano avere contenuti diversi, e dunque anche un filesystem case-sensitive fallirebbe.

    Per il resto ho già ampiamente spiegato la mia visione, da essere umano, sull’argomento. Io non sono una macchina; per fortuna…

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.