É uma prática recomendada não usar letras maiúsculas na nomeação de arquivos?

28

As pessoas dizem que você não deve usar espaços na nomeação de arquivos Unix. Existem boas razões para não usar letras maiúsculas nos nomes dos arquivos (ou seja, File_Name.txtvs. file_name.txt)? Ou isso é apenas uma questão de preferência pessoal?

filenames

— DD343
fonte

Você pode usar bonés, mas, como padrão, não o usa. Basta usar letras minúsculas e _ para que file_name.txt seja bom.

— precisa

9

Existem algumas coisas do Unixy que usam nomes de arquivos com letras maiúsculas ... alguns exemplos incluem Makefile, INSTALL, CHANGELOG e, claro, o venerável README.

— Thomas

PSR-2 - o padrão de nomenclatura de-facto do mundo do PHP, que corre por maioria no Linux utiliza camelCase php-fig.org/psr/psr-2

— jdog

46

As pessoas dizem que você não deve colocar espaços na nomeação de arquivos Unix.

As pessoas dizem muitas coisas. Existem algumas ferramentas que podem estragar tudo, mas espero que sejam poucas em número neste momento, uma vez que os espaços são um vírus proliferado por grandes empresas de OS e agora é impossível evitar.

Os espaços tornam a especificação de nomes de arquivos na linha de comando etc. complicada. É sobre isso. Os únicos caracteres categoricamente proibidos nos sistemas * nix são NUL (não se preocupe, ele não está no seu teclado ou em qualquer outra pessoa) e /, já que esse é o separador de caminho. ¹ Fora isso, vale tudo. Elementos de caminho individuais (nomes de arquivo) são limitados a 255 bytes (uma possível complicação se você estiver usando conjuntos de caracteres estendidos) e caminhos completos para 4 KiB.

Ou isso é apenas uma questão de preferência pessoal

Eu diria que é. A maioria de DE parecem criar uma enorme quantidade de diretórios capitalizados em sua $HOME( Downloads, Desktop, Documents- o Dé muito popular), então não há nada bizarro sobre isso. Também existem arquivos tradicionais muito comuns com letras maiúsculas, como .Xclientse .Xauthority.

Um valor de capitalizar as coisas no início é que, quando listadas lexicograficamente, elas aparecerão antes das coisas em minúsculas - pelo menos, com muitas ferramentas e sujeitas à localidade.

Sou fã do caso camel (aka camelCase) e o uso com nomes de arquivos, por exemplo, /home/goldilocks/blueSuedeShoes- não importa o que está lá. Definitivamente, é uma questão de preferência pessoal, mas isso ainda me causa pesar.

Os arquivos de classe Java tendem a conter maiúsculas por natureza, porque os nomes das classes Java contêm. E, claro, não vamos esquecer NetworkManager, mesmo se alguns de nós preferirem.

^{1. Há muito mais delimitado, recomendado pelo POSIX "Portable Filename Character Set" que não inclui o espaço - mas inclui maiúsculas! O POSIX também especifica a restrição mais geral referente a "o caractere de barra e o byte nulo" em outras partes do mesmo documento . Isso reflete ou se reflete em práticas convencionais de longa data .}

— Cachinhos Dourados
fonte

5

Mia: "Isso é verdade?" Vincent: "Não, não é, é exatamente o que eu ouvi." Mia: "Quem te contou isso?" Vincent: "Eles". Mia: "Eles falam muito, não falam?" Vincent: "Eles certamente fazem."

— corsiKa

4

“O valor de capitalizar algo no começo é que, quando listado lexicograficamente [...], eles virão antes de todo o resto.” - Obviamente, isso só funciona se a maioria dos nomes de arquivos for minúscula, fornecendo um motivo para reservar limites máximos ( pelo menos principais tampas) para seus READMEs e Makefiles e assim por diante.

— Blacklight Shining

4

Em muitos teclados, ctrl-space ou ctrl- @ ou alt-0 digitarão um NUL.

— dubiousjim

2

@dodgethesteamroller Acredito que você esteja completamente enganado sobre a barra (ou mais precisamente, o byte com o valor 0x2F) em ext *. Na verdade, eu não acredito que ele chegue ao sistema de arquivos; a camada VFS não a permitirá, independentemente do armazenamento de backup.

— Zwol

3

apenas não use espaços nos nomes de arquivos e nos diretórios. mesmo que seu sistema permita tecnicamente, isso só causará sua dor. Em vez disso, use "_" o caractere sublinhado.

— SnakeDoc 29/10/2015

9

Uma razão para evitar limites nos nomes de arquivos é que a ordem de classificação no Unix faz distinção entre maiúsculas e minúsculas; portanto, os arquivos iniciados com uma letra maiúscula aparecerão fora de ordem. Essa é a razão pela qual Makefilegeralmente é nomeado usando letras maiúsculas M- é um dos arquivos que você deseja ver primeiro, sem rolar / pular para baixo a-l.

Dito isto, você pode fazer muito pior em termos de nomes de arquivos:

o uso de espaços quebrará alguns programas e scripts mal escritos que não citam nomes de arquivos corretamente
iniciar um nome de arquivo com a -pode causar problemas, pois muitos programas o veem como uma opção de linha de comando em vez de um nome de arquivo (por exemplo rm -r, não remove um arquivo chamado -r).
iniciar um nome de arquivo com a .irá ocultá-lo de muitos utilitários e shell globbing (por exemplo rm *, não removerá arquivos como .config)
o uso de caracteres especiais como |<>*?e até caracteres não imprimíveis como newlineé tecnicamente possível, mas pode interromper scripts / programas semelhantes ao caractere de espaço. A diferença é que o caractere de espaço é frequentemente usado; portanto, os programadores tendem a testar seus programas contra ele, enquanto os caracteres menos populares geralmente não são testados.

— Dmitry Grigoryev
fonte

4

Isso não é mais verdade, a classificação nos locais modernos tende a não diferenciar maiúsculas de minúsculas hoje em dia, e muitas ferramentas e globbings de shell honram o local por classificar nomes de arquivos.

— Stéphane Chazelas

2

Você quis dizer: rm *não removerá arquivos como .config?

— Wildcard

1

@Wildcard não é verdade, mas talvez o seu exemplo seja mais realista que o meu. Meu objetivo era mostrar que os nomes de arquivos que começam com um ponto são imunes a globbing, mesmo que o usuário especifique esse ponto explicitamente.

— Dmitry Grigoryev

1

@DmitryGrigoryev, não, eles não são. Tente ls -ald. ?? * em qualquer diretório que possua arquivos de ponto.

— Bill Barth

1

Eu acredito que seria mais apropriado dizer "Se você optar por usar letras maiúsculas em nomes de arquivos, você deve ter em mente o fato de que a ordem de classificação no Unix (às vezes) diferencia maiúsculas de minúsculas". O usuário pode querer esse comportamento Makefilee READMEsão exemplos perfeitos disso. Observe também que esse efeito é insignificante se a letra não for a primeira letra do nome; portanto, não é grande coisa se você usar camelCase. Claro, você pode se surpreender ao ver anOctagonantes angle, mas pelo menos eles estariam juntos na lista.

— G-Man diz 'Reinstate Monica'

6

Se você pretende fazer interface com um ambiente Windows, evite maiúsculas, pois o Windows minúscula tudo. Isso costuma ser um problema na outra direção; um link para Page_2.htmlserá encontrado page_2.htmlno Windows, mas falhará no Unix.

— NL_Derek
fonte

10

Isso não é verdade. NTFS, VFAT e exFAT não diferenciam maiúsculas de minúsculas, mas preservam maiúsculas e minúsculas, o que significa que ignoram maiúsculas e minúsculas para fins de pesquisa, mas mesmo assim armazenam maiúsculas e minúsculas. O mesmo se aplica ao HFS +, o sistema de arquivos padrão no OSX. O NTFS ainda possui um namespace POSIX que funciona exatamente como todos os outros Unices, ou seja, nomes de arquivos muito longos de octetos não interpretados, com apenas NULe /proibido.

— Jörg W Mittag

5

Mais exatamente, "sem distinção entre maiúsculas e minúsculas, mas preservando maiúsculas e minúsculas" é outra maneira de dizer "capaz de sobrescrever silenciosamente o arquivo A porque seu nome difere apenas no caso do arquivo B" (ou vice-versa, dependendo do que foi salvo posteriormente). Em outras palavras, se você estiver usando um shell * nix para acessar um compartilhamento NTFS, cat > Foosubstituirá o arquivo foo. Este comportamento é susceptível de ser inesperado e confuso se você está acostumado a caso de preservação e sistemas de arquivos case-sensitive tais como ext *.

— Dodgethesteamroller

1

@ JörgWMittag A menos que eu esteja enganado, o NTFS não diferencia maiúsculas de minúsculas, é só que o Windows funciona de maneiras misteriosas.

— Cthulhu

1

@Cthulhu: AFAIK, NTFS possui quatro namespaces diferentes nos quais você pode criar nomes para arquivos. (Não sei se um único arquivo pode ter um nome em mais de um espaço para nome.) Um espaço para nome "DOS" (8.3, que não diferencia maiúsculas de minúsculas), um espaço para nome "longo" (que não diferencia maiúsculas de minúsculas, que preserva maiúsculas e minúsculas, UTF-16), um namespace especial para "short longos" nomes, nomes ou seja, cujo caso deve ser preservada, mas que se encaixam em 8,3, e um espaço de nomes POSIX (um fluxo de diferentes octetos \0e /, case-sensitive). Pelo menos é assim que eu lembro. Mas concordo que é meio que uma bagunça. Existem outras restrições no…

— Jörg W Mittag

1

... kernel, e ainda mais restrições na API (na verdade, existem APIs diferentes de diferentes épocas com restrições diferentes), existem restrições devido à compatibilidade com o DOS e o FAT, há restrições no interpretador de comandos, há restrições no ( gráfico) e existem restrições no Explorer. E muitas vezes é impossível determinar com segurança de onde vem uma restrição. É louco. Uma vez, consegui criar um arquivo usando o Explorer , que não pôde ser aberto, copiado, movido, renomeado ou excluído usando qualquer ferramenta que eu tentei. Basicamente, ficou em…

— Jörg W Mittag

4

Um motivo para evitar limites é que basho preenchimento de guias faz distinção entre maiúsculas e minúsculas (pelo menos por padrão) - isso ainda me excita toda vez que eu acabo na frente de uma bashconfiguração padrão. Claro, existem outros shells populares, mas isso combinado com o fato de que bashé o shell de login padrão em muitos sistemas operacionais significa que o padrão geralmente é a conclusão que diferencia maiúsculas de minúsculas. O uso de nomes de arquivos minúsculos simplifica bastante as coisas aqui.

— Luz Negra brilhando
fonte

2

echo set completion-ignore-case On >> ~/.inputrcpode ajudar um pouco, pelo menos em seu próprio sistema.

— Whargin #

1

Não sei ao certo qual é o objetivo desta resposta - a menos que você esqueça como soletrou um nome de arquivo. Por exemplo, se você criar um arquivo nomeado Fooe depois digitar cat f(Tab), ele falhará. Mas o mesmo acontece se você digitar cat foo, cat Foobarou cat Fu- o fato de você ter problemas para acessar um arquivo cujo nome não se lembra corretamente não tem nada a ver com o preenchimento automático.

— G-Man diz 'Reinstate Monica'

@ G-Man Touché. Ainda assim, usar nomes de arquivos minúsculos significa que você tem menos uma coisa a lembrar sobre eles.

— Blacklight Shining

3

Desde que NL_Derek abriu essa lata de worms, mas não a articulou corretamente, vou dizer o seguinte:

Não há problema em usar letras maiúsculas, mas evite criar arquivos (no mesmo diretório) que diferem apenas por caso , por exemplo, File_Name.txt e file_name.txt , porque

Se você, de alguma forma, disponibilizar o diretório em um sistema Windows, ele não poderá acessar os dois arquivos. Provavelmente será capaz de acessar apenas o que aparece primeiro no diretório, independentemente do nome que você usar. (Exceto: ele pode fornecer acesso a eles como FILENA~1.TXTe FILENA~2.TXT - digite dir /xpara ver qual nome abreviado (se houver) combina com qual nome longo.)
Se o sistema de arquivos for realmente um sistema de arquivos do Windows (por exemplo, montado a partir de um sistema de arquivos exFAT ou NTFS de um servidor NFS executando o Windows), os dois nomes (provavelmente) não terão permissão para coexistir. Por exemplo, se você fizer e , poderá acabar com um único arquivo, contendo a saída de .cmd₁ > foocmd₂ > Foocmd₂
Da mesma forma, se você transferir os arquivos para um sistema Windows, os dois nomes (provavelmente) não poderão coexistir. Por exemplo, se você criou um arquivo (por exemplo, zip) contendo os dois arquivos e o extraiu em um sistema Windows, o segundo arquivo provavelmente substituirá o primeiro. A mesma coisa se você os transferiu para uma caixa do Windows com FTP ou algo semelhante.

— G-Man Diz 'Reinstate Monica'
fonte

Não só o Windows, mas vários outros sistemas operacionais (VMS, penso eu, CP / M, certamente, outros ...)

— Toby Speight

3

Além de razões técnicas, tenho um aspecto prático nisso. Aderir a letras minúsculas garantirá que as pesquisas sejam mais fáceis, a menos que se goste muito de usar grep -i ou localizar -i. Às vezes, até o camelCase pode ser confuso se for necessário usar uma sequência de palavras do mesmo tipo como no storageNYCDCPrimary. Portanto, acho melhor ficar com letras minúsculas e salpicá-las com sublinhados ou hífens para facilitar a leitura, como storage_nyc_dc_primary.

— Hopping Bunny
fonte

snake_case é fácil para os olhos - storageNycDcPrimarye StorageNycDcPrimaryambos são estranhos de ler.

— go2null 6/02

1

Eu considero que é melhor prática para evitar o uso de maiúsculas e espaços em nomes de arquivos.

Alguns dirão que não concordam, mas é uma questão ou o que chamo de crenças religiosas : difícil de discutir e concordar. Aqueles que não concordam dizem que a maioria das ferramentas agora está preparada para ser adequada para capitais e espaços: elas estão certas, mas essa não é a questão.

A pergunta certa é quanto você precisa usar maiúsculas e espaços nos nomes de arquivos. Para esta pergunta, exceto quando estou programando em Java, a resposta é quase sempre: eu não preciso de maiúsculas e espaços nos meus nomes de arquivos . Todos os espaços substituídos por um _sinal de sublinhado ( ) ou sinal de menos ( -) e, por esse motivo, não utilizo camel case (aka camelCase) ao contrário de outras religiões.

Muitas pessoas me pediram besteira por fazer e ensinar que - algumas ainda o fazem - algumas tropeçaram em uma ferramenta que não era favorável ao capital / espaço e vieram até mim dizendo que eu estava certa e que elas deveriam ter me ouvido. Faça o que quiser e, se você usar letras maiúsculas e espaços no nome do arquivo, espero que você nunca tropece em uma ferramenta mal escrita. No entanto, se você usar essa ferramenta, espero que novamente, não será difícil de consertar e não custará à sua empresa e / ou muito dinheiro e / ou tempo. Mas se acabar tendo más repercussões, você se lembrará de que alguns disseram anteriormente que usar letras maiúsculas e espaços em nomes de arquivos é uma prática ruim.

E uma última coisa, se você quiser evitar todos os problemas , nenhum caractere especial nos nomes dos arquivos (apenas letras minúsculas, dígitos, sublinhado e menos [1]). Essa lista de caracteres indesejados também inclui todos os caracteres não ascii (sim, franceses e outros ingleses - e eu sou um deles) - nenhum deles: à, â, ä, ç, é, ..., ö, æ, œ , ...). Isso também se estende a muitas outras coisas, incluindo login e senha . Vou deixar você adivinhar o que acontece quando você coloca uma citação ou aspas duplas ( 'ou ") em um login ou senha que é tratado por um script bash não gravado por um administrador de sistema confirmado ....

[1]: talvez pudéssemos estender isso para ~, @, #e alguns outros, mas isso está à procura de problemas (e sim eu sei sobre arquivos emacs ...).

— jfg956
fonte

1

A última coisa é algo que deve ser tratado pelo sistema de autenticação, não pelo usuário que cria a senha. Se o sistema limitar o conjunto de caracteres permitidos nas senhas, é um sistema ruim.

— Blacklight Shining

Bem, limitar caracteres na senha é um assunto para debate: li1, oO0, ... dependendo do gosto, difícil de se comunicar. Alguns diriam que a senha não deve ser comunicada, mas uma chave de acesso Wi-Fi é um tipo de senha que eu me comunico com meus amigos quando eles estão no meu lugar ...

— jfg956

Essa é uma escolha consciente de sua parte para evitar o uso de alguns caracteres, em vez de uma limitação incorporada ao sistema (neste exemplo, os padrões Wi-Fi, implementações de AP e cliente, etc.). Se você estiver usando uma sequência de caracteres selecionados aleatoriamente como uma senha, poderá melhorar a legibilidade usando (ou incentivando os destinatários a usar) uma fonte monoespaçada ou simplesmente usando glifos mais distintos se você os escrever à mão (com letras minúsculas L, I maiúsculo e dígito 1; O minúsculo menor, O maiúsculo arredondado, dígito pontilhado ou pontilhado 0; etc). Como alternativa, você pode usar uma senha.

— Blacklight Shining