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.txt
vs. file_name.txt
)? O è solo una questione di preferenze personali?
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.txt
vs. file_name.txt
)? O è solo una questione di preferenze personali?
Risposte:
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 .Xclients
e .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/blueSuedeShoes
non 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 .
README
s e Makefile
s e così via.
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 Makefile
solito 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:
-
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 -r
non rimuoverà un file denominato -r
)..
lo nasconderà da molte utility e da shell globbing (ad es. rm *
non rimuoverà file come .config
)|<>*?
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.rm *
non rimuoverai file come .config
?
Makefile
e 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 anOctagon
prima angle
, ma almeno sarebbero stati insieme nella lista.
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.html
troverà page_2.html
in Windows, ma fallirà in Unix.
NUL
e /
proibito.
cat > Foo
sovrascriverà il file foo
. Questo comportamento è probabile che sia inaspettato e confusione se siete abituati a preservare caso e file system case-sensibili come ext *.
\0
e /
, sensibile al maiuscolo / minuscolo). Almeno è così che me lo ricordo. Ma sono d'accordo che è un po 'un casino. Ci sono ulteriori restrizioni nel ...
Uno dei motivi per evitare i limiti è che bash
il completamento con tab è sensibile al maiuscolo / minuscolo (almeno per impostazione predefinita): questo mi fa comunque inciampare ogni volta che finisco davanti a una bash
configurazione 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.
echo set completion-ignore-case On >> ~/.inputrc
può aiutare un po ', almeno sul tuo sistema.
Foo
e successivamente si digita cat f
(Tab), non verrà eseguito. Ma la stessa cosa accade se si digita cat foo
, cat Foobar
o 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.
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é
FILENA~1.TXT
e FILENA~2.TXT
- digitare dir /x
per vedere quale nome breve (se presente) corrisponde a quale nome lungo.)cmd1 > foo
cmd2 > Foo
cmd2
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.
storageNycDcPrimary
e StorageNycDcPrimary
sono entrambi strani da leggere.
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 ...).