È considerata una buona pratica non usare lettere maiuscole nella denominazione dei file?


28

Le persone dicono che non dovresti usare spazi nella denominazione dei file Unix. Ci sono buoni motivi per non usare le lettere maiuscole nei nomi dei file (cioè, File_Name.txtvs. file_name.txt)? O è solo una questione di preferenze personali?


Puoi usare i tappi ma di norma non usarli. Usa solo lettere minuscole e _ quindi file_name.txt è buono.
Shabir A.

9
Ci sono alcune cose Unixy che usano nomi di file con lettere maiuscole ... alcuni esempi includono Makefile, INSTALL, CHANGELOG e ovviamente il venerabile README.
Thomas,

PSR-2 - lo standard di denominazione di fatto del mondo PHP, che funziona per la maggior parte su Linux, utilizza camelCase php-fig.org/psr/psr-2
jdog

Risposte:


46

La gente dice che non dovresti spazi nella denominazione dei file Unix.

Le persone dicono molte cose. Ci sono alcuni strumenti che possono rovinare, ma si spera che in questo momento siano pochi in numero, poiché gli spazi sono un virus proliferato da gigantesche società di sistemi operativi proprietari di consumatori e ora impossibile da evitare.

Gli spazi rendono scomodo specificare nomi di file sulla riga di comando, ecc. Questo è tutto. Gli unici caratteri categoricamente proibiti sui sistemi * nix sono NUL (non ti preoccupare, non è sulla tua tastiera o di chiunque altro) e /, dal momento che è il separatore di percorso. 1 A parte questo, tutto va bene. I singoli elementi del percorso (nomi file) sono limitati a 255 byte (una possibile complicazione se si utilizzano set di caratteri estesi) e completano i percorsi per 4 KiB.

O è solo una questione di preferenze personali

Direi che lo è. La maggior parte di DE sembrano creare un gran numero di directory capitalizzati nel vostro $HOME( Downloads, Desktop, Documents- il Dè molto popolare), quindi non c'è niente di strano su di esso. Ci sono anche file tradizionali molto comuni con le maiuscole, come .Xclientse .Xauthority.

Un valore di capitalizzare le cose all'inizio è che quando elencate lessicograficamente verranno prima delle cose in minuscolo - almeno, con molti strumenti e soggetti a impostazioni locali.

Sono un fan del caso dei cammelli (aka. CamelCase) e lo uso con nomi di file, ad esempio, /home/goldilocks/blueSuedeShoesnon importa cosa c'è dentro. Sicuramente una questione di preferenze personali, ma deve ancora causarmi dolore.

I file di classe Java tendono a contenere maiuscole per natura, perché i nomi delle classi Java lo fanno. E ovviamente, non dimentichiamoci NetworkManager, anche se alcuni di noi preferirebbero.


1. Esiste un metodo molto più delimitato, raccomandato da POSIX "Set di caratteri per i nomi di file portatili" che non include lo spazio, ma include lettere maiuscole! POSIX specifica anche la restrizione più generale riguardante "il carattere barra e il byte null" altrove nello stesso documento . Ciò riflette o si riflette in pratiche convenzionali di lunga data .


5
Mia: "È un dato di fatto?" Vincent: "No non lo è, è proprio quello che ho sentito." Mia: "Chi te l'ha detto?" Vincent: "Loro". Mia: "Parlano molto, no?" Vincent: "Lo fanno certamente."
corsiKa,

4
"Il valore di capitalizzare qualcosa all'inizio è che quando elencati lessicograficamente [...], verranno prima di ogni altra cosa." - Naturalmente, questo funziona solo se la maggior parte dei nomi di file sono minuscoli, dandoti un motivo per riservare i limiti ( almeno leader caps) per le READMEs e Makefiles e così via.
Blacklight Shining,

4
Su molte tastiere, ctrl-spazio o ctrl- @ o alt-0 digiterà un NUL.
dubiousjim,

2
@dodgethesteamroller Credo che tu stia sbagliando completamente la barra (o più precisamente, il byte con valore 0x2F) in ext *. In realtà, non credo che arriverà nemmeno al filesystem; il livello VFS non lo consentirà indipendentemente dall'archivio di backup.
zwol,

3
semplicemente non usare spazi nei nomi di file e directory. anche se tecnicamente il tuo sistema lo consente, causerà solo il tuo dolore. Utilizzare invece "_" il carattere di sottolineatura.
SnakeDoc,

9

Un motivo per evitare i limiti nei nomi dei file è che l'ordinamento in Unix fa distinzione tra maiuscole e minuscole, quindi i file che iniziano con una lettera maiuscola appariranno fuori servizio. Questo è il motivo per cui di Makefilesolito viene chiamato usando la maiuscola M: è uno dei file che vuoi vedere per primo, senza scorrere / saltare giù a-l.

Detto questo, puoi fare molto peggio in termini di nomi di file:

  • l'uso degli spazi romperà alcuni programmi e script scritti male che non citano correttamente i nomi dei file
  • l'avvio di un nome file con un -può causare problemi in quanto molti programmi lo vedranno come un'opzione della riga di comando anziché come nome di un file (ad es. rm -rnon rimuoverà un file denominato -r).
  • l'avvio di un nome di file con a .lo nasconderà da molte utility e da shell globbing (ad es. rm *non rimuoverà file come .config)
  • l'utilizzo di caratteri speciali come |<>*?e anche caratteri non stampabili come newlineè tecnicamente possibile, ma può spezzare script / programmi simili al carattere spaziale. La differenza è che il carattere spaziale viene spesso utilizzato, quindi i programmatori tendono a testare i loro programmi contro di esso, mentre i personaggi meno popolari spesso non vengono testati.

4
Questo non tende più ad essere vero, l'ordinamento in locali moderni tende ad essere insensibile al giorno d'oggi e molti strumenti e globbing della shell onorano il locale per l'ordinamento dei nomi dei file.
Stéphane Chazelas,

2
Intendevi dire: rm *non rimuoverai file come .config?
Wildcard il

1
@Wildcard non proprio, ma forse il tuo esempio è più realistico del mio. Il mio punto era mostrare che i nomi di file che iniziano con un punto sono immuni ai globbing anche se l'utente specifica esplicitamente quel punto.
Dmitry Grigoryev,

1
@DmitryGrigoryev, no non lo sono. Prova ls -ald. ?? * in qualsiasi directory che ha file dot.
Bill Barth,

1
Credo che sarebbe più appropriato dire "Se scegli di usare le lettere maiuscole nei nomi dei file, dovresti tenere presente che l'ordinamento in Unix è (a volte) sensibile al maiuscolo / minuscolo". L'utente può desiderare questo comportamento Makefilee ne READMEè un perfetto esempio. Nota anche che questo effetto è trascurabile se la lettera non è la prima lettera nel nome, quindi non è un grosso problema se usi camelCase. Certo, potresti essere sorpreso di vedere anOctagonprima angle, ma almeno sarebbero stati insieme nella lista.
G-Man dice "Reinstate Monica" il

6

Se hai intenzione di interfacciarti con un ambiente Windows, dovresti evitare le maiuscole perché Windows minuscola tutto. Questo è più spesso un problema che va dall'altra parte; un collegamento a Page_2.htmltroverà page_2.htmlin Windows, ma fallirà in Unix.


10
Non è vero. NTFS, VFAT ed exFAT sono tutti senza distinzione tra maiuscole e minuscole, ma conservano la distinzione tra maiuscole e minuscole, il che significa che ignorano il caso ai fini della ricerca, ma conservano comunque il caso. Lo stesso vale per HFS +, il filesystem predefinito su OSX. NTFS ha anche uno spazio dei nomi POSIX che funziona esattamente come tutti gli altri Unices, ovvero nomi di file molto lunghi di ottetti non interpretati, con solo NULe /proibito.
Jörg W Mittag,

5
Più precisamente, "maiuscole e minuscole" è un altro modo di dire "capace di sovrascrivere silenziosamente il file A perché il suo nome differisce solo nel caso dal file B" (o viceversa, a seconda di quale è stato salvato in seguito). In altre parole, se si utilizza una shell * nix per accedere a una condivisione NTFS, cat > Foosovrascriverà il file foo. Questo comportamento è probabile che sia inaspettato e confusione se siete abituati a preservare caso e file system case-sensibili come ext *.
dodgethesteamroller,

1
@ JörgWMittag A meno che non mi sbagli, NTFS non fa distinzione tra maiuscole e minuscole, è solo che Windows funziona in modo misterioso.
Cthulhu,

1
@Cthulhu: AFAIK, NTFS ha quattro diversi spazi dei nomi in cui è possibile creare nomi per i file. (Tuttavia, non so se un singolo file può avere un nome in più di uno spazio dei nomi.) Uno spazio dei nomi "DOS" (8.3, senza distinzione tra maiuscole e minuscole), uno spazio dei nomi "lungo" (senza distinzione tra maiuscole e minuscole, UTF-16), uno spazio dei nomi speciale per nomi "brevi e lunghi", ovvero nomi il cui caso dovrebbe essere conservato ma che rientrano in 8.3, e uno spazio dei nomi POSIX (un flusso di ottetti diverso da \0e /, sensibile al maiuscolo / minuscolo). Almeno è così che me lo ricordo. Ma sono d'accordo che è un po 'un casino. Ci sono ulteriori restrizioni nel ...
Jörg W Mittag,

1
... kernel, e anche ulteriori restrizioni nell'API (in realtà, ci sono API diverse di epoche diverse con restrizioni diverse), ci sono restrizioni dovute alla compatibilità con DOS e FAT, ci sono restrizioni nell'interprete dei comandi, ci sono restrizioni nella ( grafica) shell e ci sono restrizioni in Explorer. Ed è spesso impossibile determinare in modo affidabile in cui una restrizione proviene. È pazzesco. Una volta sono riuscito a creare un file utilizzando Explorer , che non è stato possibile aprire, copiare, spostare, rinominare o eliminare utilizzando qualsiasi strumento che ho provato. In sostanza è rimasto su ...
Jörg W Mittag il

4

Uno dei motivi per evitare i limiti è che bashil completamento con tab è sensibile al maiuscolo / minuscolo (almeno per impostazione predefinita): questo mi fa comunque inciampare ogni volta che finisco davanti a una bashconfigurazione predefinita. Certo, ci sono altre shell popolari, ma questo combinato con il fatto che bashè la shell di accesso predefinita su molti sistemi operativi significa che l'impostazione predefinita è spesso il completamento sensibile al maiuscolo / minuscolo. L'uso di nomi di file in minuscolo semplifica piuttosto le cose qui.


2
echo set completion-ignore-case On >> ~/.inputrcpuò aiutare un po ', almeno sul tuo sistema.
wchargin,

1
Non sono chiaro su quale sia il punto di questa risposta, a meno che non si possa dimenticare come si è "scritto" un nome di file. Ad esempio, se si crea un file denominato Fooe successivamente si digita cat f(Tab), non verrà eseguito. Ma la stessa cosa accade se si digita cat foo, cat Foobaro cat Fu- il fatto che si avrà difficoltà ad accedere a un file il cui nome non si ricorda correttamente non ha nulla a che fare con il completamento automatico.
G-Man dice "Ripristina Monica" il

@ G-Man Touché. Tuttavia, l'uso di nomi di file in minuscolo significa che hai una cosa in meno da ricordare al riguardo.
Blacklight Shining

3

Poiché NL_Derek ha aperto questa lattina di worm, ma non l'ha articolata correttamente, dirò questo:

Va bene usare le lettere maiuscole, ma dovresti evitare di creare file (nella stessa directory) che differiscono solo per caso , ad esempio, File_Name.txt e file_name.txt perché

  • Se in qualche modo rendi la directory disponibile per un sistema Windows, non sarà in grado di accedere ad entrambi i file. Probabilmente sarà in grado di accedere solo a quello che appare per primo nella directory, indipendentemente dal nome che usi. (Tranne: può darti accesso come FILENA~1.TXTe FILENA~2.TXT - digitare dir /xper vedere quale nome breve (se presente) corrisponde a quale nome lungo.)
  • Se il file system è in realtà un file system di Windows (ad esempio, montato da un file system exFAT o NTFS da un server NFS che esegue Windows), probabilmente i due nomi non potranno coesistere. Ad esempio, se lo fai e , potresti finire con un singolo file, contenente l'output di .cmd1 > foocmd2 > Foocmd2
  • Allo stesso modo, se si trasferiscono i file su un sistema Windows, i due nomi (probabilmente) non potranno coesistere. Ad esempio, se hai creato un archivio (ad esempio zip) contenente i due file ed estratto su un sistema Windows, il secondo file probabilmente sovrascriverà il primo. Stessa cosa se li hai trasferiti in una finestra di Windows con FTP o qualcosa di simile.

Non solo Windows, ma molti altri sistemi operativi (VMS, credo, CP / M certamente, altri ...)
Toby Speight,

3

A parte ragioni tecniche, ho un aspetto pratico in questo. Attenersi alle lettere minuscole garantirà che le ricerche siano più facili a meno che non si sia troppo affezionati a usare grep -i o individuare -i. A volte, anche camelCase può essere fonte di confusione se si deve usare una stringa di parole come nel caso di StorageNYCDCPrimary. Quindi, trovo che sia meglio attenersi alle lettere minuscole e condirle con caratteri di sottolineatura o trattini per la leggibilità, come storage_nyc_dc_primary.


snake_case è facile per gli occhi - storageNycDcPrimarye StorageNycDcPrimarysono entrambi strani da leggere.
go2null

1

Io considero che è delle migliori pratiche per evitare l'uso di capitali e gli spazi nei nomi dei file.

Alcuni diranno che non sono d'accordo, ma è una questione o ciò che chiamo credenze religiose : difficile discutere e concordare. Coloro che non concordano affermano che la maggior parte degli strumenti sono ora fissati in modo tale da essere adatti a capitali e spazi: hanno ragione ma non è questa la domanda.

La domanda giusta è quanto è necessario utilizzare le maiuscole e gli spazi nei nomi dei file. A questa domanda, tranne quando sto programmando in Java, la risposta è per lo più continuamente: non ho bisogno di maiuscole e spazi nei miei nomi di file . Tutti gli spazi che sostituisco con un trattino basso ( _) o un segno meno ( -), e per questo motivo non uso il caso cammello (aka. CamelCase) in contrasto con alcune altre religioni.

Molte persone mi chiamavano cazzate per aver fatto e insegnato che - alcuni lo fanno ancora - alcuni inciampavano in uno strumento che non era adatto al capitale / allo spazio e venivano da me dicendo che avevo ragione e che avrebbero dovuto ascoltarmi. Fai quello che vuoi , e se usi maiuscole e spazi nel nome del file, spero che non inciamperai mai su uno strumento scritto male. Tuttavia, se viaggi su tale strumento, si spera di nuovo, non sarà difficile da risolvere e non costerà la tua attività e / o molti soldi e / o tempo. Ma se finisce per avere ripercussioni negative, ricorderai che alcuni ti hanno detto in passato che usare capitelli e spazi nei nomi dei file è una cattiva pratica.

E un'ultima cosa, se vuoi evitare tutti i problemi , nessun carattere speciale nei nomi dei file (solo lettere minuscole, cifre, trattino basso e svantaggi [1]). Questo elenco di caratteri indesiderati include anche tutti i caratteri non ascii (sì, il francese e altri non inglesi - e io sono uno di loro - nessuno di quelli: à, â, ä, ç, é, ..., ö, æ, œ , ...). Ciò si estende anche a molte altre cose, tra cui login e password . Ti farò indovinare cosa succede quando metti una citazione o una doppia citazione ( 'o ") in un login o password che è gestita da uno script bash non scritto da un amministratore di sistema confermato ....

[1]: forse potremmo estendere tale a ~, @, #e alcuni altri, ma questo è in cerca di guai (e sì, lo so sui file Emacs ...).


1
L'ultima cosa è qualcosa che dovrebbe essere gestito dal sistema di autenticazione, non l'utente che ottiene la password. Se il sistema limita il set di caratteri consentiti nelle password, è un sistema difettoso.
Blacklight Shining il

Bene, limitare i caratteri nella password è un argomento di dibattito: li1, oO0, ... a seconda dell'affezionato, difficile da comunicare. Alcuni direbbero che la password non deve essere comunicata, ma una chiave WiFi è una sorta di password che comunico ai miei amici quando sono a casa mia ...
jfg956,

Questa è una scelta consapevole da parte tua per evitare l'uso di alcuni personaggi, piuttosto che una limitazione integrata nel sistema (in questo esempio, gli standard Wi-Fi, le implementazioni di AP e client, ecc.). Se si utilizza una stringa di caratteri selezionati in modo casuale come password, è possibile migliorare la leggibilità utilizzando (o incoraggiando i destinatari a utilizzare) un carattere monospace o semplicemente usando glifi più distintivi se li si scrive a mano (minuscoli serigrafati L, I maiuscola e cifra 1; O minuscola più piccola, O maiuscola più rotonda, cifra 0 barrata o punteggiata; ecc.). In alternativa, è possibile utilizzare una passphrase.
Blacklight Shining
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.