Convenção de Nomenclatura de Arquivos Unix [fechada]


61

Eu queria saber qual é a convenção de nomenclatura para arquivos no Unix? Não tenho certeza disso, mas acho que talvez exista uma convenção universal de nomes que se deva seguir?

Por exemplo, quero nomear um arquivo como: backupcom part 2erandom

Devo fazê-lo assim:

backup_part2_random

OU

backup-part2-random

OU

backup.part2.random

Espero que a pergunta seja clara. Basicamente, quero escolher um formato que esteja de acordo com a filosofia do Unix.


4
Como um comentário geral sobre as "convenções" ... Acabei de ler todas as respostas até agora, e me pareceu estranho que exista quase uma obsessão em usar apenas um caso em um sistema em que (acho) um dos seus pontos fortes é a capacidade de usar significativamente ambos os casos ... foi o design original um (case-sensitive) sobre o projeto) ... apenas meditando
Peter.O

minha opinião: não há convenção. nomes de arquivos são apenas strings. escolha seu estilo favorito.
Glenn Jackman

11
É porque ninguém quer se lembrar da capitalização de comandos, então todos usam o mesmo.
LtWorf

Respostas:


58

.é usado para separar uma extensão de tipo de arquivo, por exemplo foo.txt.

-ou _é usado para separar palavras lógicas, por exemplo, my-big-file.txtou algumas vezes my_big_file.txt. -é melhor porque você não precisa pressionar a tecla Shift (pelo menos com um teclado de PC em inglês dos EUA), outros preferem _porque parece mais um espaço.

Então, se eu entendo o seu exemplo, backup-part2-randomou backup_part2_randomseria o mais próximo da convenção normal do Unix.


O CamelCase normalmente não é usado em sistemas Linux / Unix. Dê uma olhada nos nomes de arquivos em /bine /usr/bin. O CamelCase é a exceção e não a regra nos sistemas Unix e Linux.

( NetworkManageré o único exemplo em que posso pensar que usa o CamelCase, e foi escrito por um desenvolvedor do Mac. Muitos se queixaram dessa escolha de nome. No Ubuntu, eles realmente renomearam o script para network-manager.)

Por exemplo, /usr/binno meu sistema:

$ ls -d [A-Z]* | wc -w    # files starting with a capital
6
$ ls -d *_* | wc -w       # files containing an underscore
178
$ ls -d *-* | wc -w       # files containing a minus/dash
409

e mesmo assim, nenhum dos arquivos iniciados com capital usa o CamelCase:

$ ls -d [A-Z]*
GET  HEAD  POST  X11  Xvnc  Xvnc4

O .char também pode ser usado para girar as coisas, não apenas para especificar uma extensão. Por exemplo my.log my.log.1 my.log.2.gz.
Depado 19/11/2015

Portanto, o hífen / menos / hífen é mais comum que o sublinhado.
Hugo

@Hugo Sim. O acima mostra menos (409) vs sublinhado (178).
Mikel

Obrigado. Você tem alguma referência para essas convenções?
Proletariado

3
+1 para as referências. (@Proletariat, a lssaída a partir de /usr/bin é . Uma referência Esta é uma questão sobre convenções. )
Wildcard

35

Muito mais importante que uma convenção específica está sendo consistente. Escolha um estilo e fique com ele.


19

Minha opinião sobre as convenções de nome de arquivo Unix / Linux:

  • Os sistemas de arquivos Unix / Linux não suportam inerentemente a noção de extensão. O conceito de uma extensão de arquivo existe completamente como algo apoiado por utilitários como cp, lsou o shell você está usando. Acredito que seja assim também no NTFS, mas posso estar errado.

  • Executáveis, incluindo scripts de shell, geralmente nunca têm nenhum tipo de extensão. Os scripts terão uma linha hashbang (ie #!/bin/bash) que identifica qual programa deve interpretá-lo.

  • Qualquer executável com duas letras é super importante. Portanto, não nomeie os nomes de arquivos de duas letras dos executáveis. Qualquer arquivo em /etcterminando em tabtambém é super importante, como fstab, mtab, inittab.
  • Às vezes, .dé anexado aos nomes de diretório, principalmente em /etc, mas isso não é generalizado (UPDATE: https://serverfault.com/questions/240181/what-does-the-suffix-d-mean-in-linux )
  • rcé amplamente usado para scripts ou arquivos de configuração, com prefixo (por exemplo rc.local) ou sufixo ( .vimrc)
  • A comunidade Unix / Linux nunca teve um limite de três caracteres para extensões e franziu o cenho ao encurtar extensões bem conhecidas para se ajustarem. Por exemplo, não use .htmno final dos arquivos HTML no Unix / Linux, use .html.
  • Em um conjunto de arquivos, um nome de arquivo às vezes está em maiúsculas ou em maiúsculas e, portanto, aparece no início de uma lista de diretórios. O exemplo clássico está Makefilenos pacotes de código-fonte. Faça isso apenas para coisas como README.
  • ~é usado para identificar um arquivo de backup ou um diretório, como em important_stuff~, ou /etc~. Muitas conchas irá expandir um solitário ~para $HOME.
  • Os arquivos da biblioteca quase sempre começam com lib. A exceção é zlibe provavelmente algumas outras.
  • Às vezes, os scripts chamados pelo inetd são marcados com um líder in., como in.tftpd.
  • O final z em vmlinuzsignifica zipado, mas eu nunca vi nenhum outro arquivo chamado dessa maneira.

2
Costumo ver scripts de shell com uma .sh"extensão" neles. Pessoalmente, acho isso um pouco chato, mas tenho que admitir que posso desconhecer algumas boas razões para usar o .sh.
Dan Molding

4
Lembre-se de que é útil enfatizar o fato de que é um script baseado em texto e não um binário.
LawrenceC

11
@DanMoulding, pessoalmente, uso .shem scripts que (1) não devem ser executados de maneira interativa, mas apenas a partir de outros scripts / programas ou (2) são projetados para fornecimento e não para execução. Para os primeiros, eles devem ser executáveis; para o último, deixo o bit executável e uso a linha shebang apenas para documentação de qual shell as funções são escritas.
Curinga

3
@Wildcard que eu tenho desde (6 anos atrás) entrou neste mesmo hábito. A extensão realmente faz muito sentido para obter bits de script. Por exemplo, a partir de um script executável escrito para zsh (ou seja, #!/bin/zshna parte superior), você sabe que pode obter outro arquivo com segurança com a extensão .zsh e verifique se ele contém código zsh legal. Se o seu script executável for estritamente compatível com o Bourne Shell (ou seja, #!/bin/shna parte superior), você saberia que a fonte desse arquivo .zsh será problemática.
Dan Molding

4
Acho que usar ".sh", ".py", ".pl" etc. é conveniente, e alguns editores de texto (por exemplo, Geany) os usam para fazer uma primeira estimativa do esquema de realce de sintaxe adequado.
bgvaughan

7

No unix, o nome do arquivo é apenas uma string, ao contrário do DOS, onde o nome do arquivo foi composto a partir do nome e da extensão. Portanto, qualquer um dos nomes de arquivos é totalmente aceitável.

Porém, muitos programas ainda usam sufixos de arquivo começando com ponto para distinguir diferentes tipos de arquivos, ou seja, o Apache Web Server usa sufixos para definir o tipo MIME correto nos cabeçalhos de resposta.


5
Embora o gelraen esteja 100% correto: o Unix / Linux, por si só, não se preocupa com extensões de arquivo, os sabores modernos do Linux se importam, na medida em que algumas extensões de shell fornecem identificação especial (cores ou não) de certos tipos de arquivos e gerenciadores de arquivos fornecem associações automáticas com programas. Mas o mais importante é que o usuário humano saiba qual arquivo é qual tipo. Para isso, é conveniente seguir um esquema padrão, não apenas consistente para si mesmo, mas com os outros. Nesse aspecto, as coisas não devem ser muito diferentes do que o MS Windows (ou MIME).
asoundmove

Dito isto, às vezes vários estilos de extensão diferentes podem corresponder ao mesmo objetivo. Portanto, .tar.gz é equivalente a .tgz, .tar.bz2 = .tbz, .ps.gz é frequentemente reduzido como .ps (confusamente) e tenho certeza de que existem muitos outros.
asoundmove

@asoundmove .ps.gz significa que é um arquivo .ps compactado. Assim como .tar.gz significa arquivo .tar compactado.
jonescb

11
@ Jonescb, sim, é claro. Meu argumento sobre isso é confuso é que, quando vejo .ps, espero um arquivo não compactado (que eu devo conseguir ou menos), mas geralmente os arquivos .ps são compactados e, na verdade, devem ser .ps.gz para maior clareza ( porque eles exigem zcat ou zless para visualização do código-fonte). Algumas pessoas decidiram sufocar os arquivos PostScript compactados com .ps de qualquer maneira, porque alguns usuários comuns de PS não se importam se estão compactados ou não.
asoundmove

6

Dois pensamentos:

  1. Na Naming Variables, Functions, and Filesseção dos Padrões de Codificação GNU, você encontrará:

    Use sublinhados para separar as palavras em um nome, para que os comandos da palavra Emacs possam ser úteis dentro deles. Atenha-se em minúsculas;

    Embora a IMO diga "Você deve usar _porque o emacs" parece um pouco antiquada, ela está no documento de 'padrões'.

  2. Vamos supor, por um momento, que todos concordemos que o kernel do linux é o tudo-e-todo-o-todo * dos projetos do linux, e que as convenções usadas nele são o que poderia ser considerado uma convenção 'padrão'.

    grep-ing source para o kernel do linux, você encontrará o seguinte:

    • 44,6% das vezes em que apenas traço é usado
    • 54,1% das vezes destacam apenas
    • 1,2% do tempo que um arquivo usa os dois.

Curiosamente, a fonte do git pesa 85% para traços, 3,8% para sublinhados e 11,1% para ambos.

A escolha é clara, o debate acabou. ;)

Opinião pessoal: uso traços por motivos estéticos e por turnos. Se você estiver trabalhando em uma equipe, faça um voto. Mas, para reiterar o que foi dito, seja consistente .

* ou "be_all e end_all" se você quiser


4

Caracteres que você não deve usar nos nomes de arquivos:

| ; ,! @ # $ () <> / \ "'` ~ {} [] = + & ^

Delimitadores de caracteres que você deve usar para facilitar a leitura dos nomes:

_ -. :

(Em alguns casos, ":" tem um significado especial)


5
Obviamente, você não pode nem usar "/" nos nomes de arquivos. Tudo o resto é possível. E se você quiser torná-lo difícil acesso, mesmo útil ;-)
Jürgen A. Erhard

A lista é realmente muito mais longa, incluindo caracteres de controle e não ASCII. Sim, você pode ter um backspace como parte de um nome de arquivo * nix.
L0b0

11
Mais exatamente, a maioria dos sistemas * nix não permite apenas dois caracteres específicos nos nomes de arquivos: o /separador de caminho e o terminador de seqüência de caracteres \ 0 (ASCII zero).
um CVn

4

Para adicionar ao que os outros disseram, eu diria que, embora letras acentuadas e muitos caracteres especiais sejam legais nos nomes de arquivos, eles podem causar problemas em qualquer um dos seguintes cenários:

  • Você compartilha seu sistema de arquivos com outros computadores, particularmente com diferentes sistemas operacionais;
  • Você compartilha arquivos com outras pessoas (e, embora o email tenda a ser muito bom com conversões, às vezes ele simplesmente não funciona);
  • Você usa scripts de shell para automatizar algumas tarefas (os espaços são particularmente problemáticos, embora existam muitas maneiras de lidar com eles);
  • Você usa um compartilhamento de arquivo de outro computador.

...


3

Atenha-se aos nomes de arquivos alfanuméricos. Evite espaços ou substitua espaços por sublinhados (_). Limite a pontuação nos nomes dos arquivos a pontos (.), Sublinhados (_) e hífens (-). Geralmente, os nomes de arquivos são minúsculos, mas eu uso o CamelCase quando tenho várias palavras no nome do arquivo.

Use extensões que indicam o tipo de arquivo. Os programas não precisam de extensões, pois o bit de execução é usado para indicar programas, e os shells sabem como executar programas de vários tipos. É comum, mas não é obrigatório, (.sh) para scripts de shell e (.pl) para scripts de perl. As extensões executáveis ​​do Windows .bat, .com, .scr e .exe indicam executáveis ​​do Windows no Unix.

Escolha um padrão e cumpri-lo. Mas não vai quebrar as coisas se você evitá-lo.

Arquivos ocultos (ou pontos) têm nomes que começam com um ponto. Normalmente, eles não aparecem nas listagens de diretórios. Use 'ls -a' para incluir os arquivos de ponto na lista.


5
CamelCase é um anti-padrão no Unix. O OP estava perguntando sobre convenções.
Mikel

2
Não é "ruim" versus "bom". É "é assim que geralmente é feito". É uma convenção que o OP estava pedindo. O motivo? Pode ser porque o pessoal do Unix não gosta de pressionar Shift, pode ser porque os sistemas antigos só tinham MAIÚSCULAS ou por outro motivo. Não tenho certeza.
Mikel

@ Mikel Eu também programo Java, onde o CamelCase é uma convenção. Às vezes, padrões e convenções entram em conflito.
BillThor

.scr também é uma extensão executável do Windows.
22411 LawrenceC em

11
@ultrasawblade Obrigado, mostra com que frequência eu escrevo o Windows. Tentei pular as extensões executáveis ​​mais raras, como cmd, pif, vb *, wsh e o restante.
BillThor

2

Uma convenção é usar "_" para substituir espaços como separadores entre palavras. Outros caracteres podem ser usados ​​para substituir espaços, mas há usos convencionais um pouco mais fortes para "-" e "." em nomes de caminho, então "_" é geralmente preferido.

Os espaços são legais nos nomes dos caminhos, mas convencionalmente são evitados, porque exigem a citação do nome do caminho ("foo bar") ou a fuga dos espaços (foo \ bar). Um shell script escrito corretamente citará variáveis ​​que podem incluir espaços, principalmente nomes de caminho, mas não fazer isso é uma supervisão comum e é muita digitação extra ao executar um comando único digitado na linha de comando.

Usar "-" para separar grupos de números, como carimbos de data e hora ou números de série, é uma convenção comumente usada fora do contexto de sistemas de arquivos. Usando "." separar "extensões de arquivo" que indiquem que o tipo de arquivo é muito comum e algumas ferramentas importantes dependem dele. Por exemplo, o sistema de gerenciamento de pacotes no Red Hat Enterprise Linux e seus derivados, RPM, espera que os arquivos do pacote terminem com ".rpm". O tarball tradicional é um arquivo tar (".tar") que foi compactado com gzip (".gz") e, portanto, termina em ".tar.gz".

Então, juntando tudo isso, você geralmente termina com nomes de arquivos parecidos com "home_backup_2017-07-01.tar.gz"


2

use -ou _para nomear arquivos
_para funções
.para extensões

cat << EOF > foo-bar.sh  
foo_bar() {  
echo baz  
}  
EOF  

0

Eu concordo com David Oneill que você deveria ir com alguma coisa.

Mas é bom que os arquivos possam ser classificados no mesmo diretório, portanto, não use o número 0 .. 10, mas o número 00 .. 10.

Ao usar datas em nomes, use um formato de data padrão como ISO8601 .

E não tenha medo de usar vários caracteres para separar partes lógicas no nome. Se você usar _ (que era 3 _), poderá simplificar os regexps nos nomes de arquivos posteriormente.

Portanto, seu exemplo pode ser algo assim:

backup_2011-06-19T114012___part002___random

Fácil de ler e fácil de analisar com scripts.


0

As palavras em um nome de arquivo podem ser separadas com _ou de -acordo com a convenção do Unix.

Se você usar -, é mais fácil digitar, evitando que você pressione SHIFT. Mas, como -ocupa tão pouco espaço, é um pouco difícil ler separações de palavras em comparação com _. Usar _para separar palavras faz com que pareça muito mais limpo, pois _ocupa mais espaço.

No script de shell e em outra programação de computador, _são usados ​​para variáveis ​​com várias palavras, como MY_ENVIRONMENT_FILE. Fazendo os nomes de arquivos usar _bem mantém consistente: MY_ENVIRONMENT_FILE=~/my_environment_file.

No desenvolvimento web, -é preferível para nomeação de arquivos. Um dos motivos é provavelmente porque o sublinhado nos links da web pode ocultar os sublinhados e dificultar a digitação manual do link da web.

Na maioria dos editores e também em páginas da Web, this_long_wordpode ser totalmente selecionado com um clique duplo, mas não this-long-word.


Hmmm, por que você está lendo seus nomes de arquivo em uma fonte de largura variável? Abra seu terminal e -e _ocupar exatamente o mesmo espaço! :)
Curinga

Haha, você está certo. Eu uso a fonte corrigida SourceCodePro + Powerline + Awesome Regular. Mesmo com fontes monoespaçadas, _parece mais limpo, embora ocupe o mesmo espaço que -. Eu deveria ter usado a palavra "aparentemente". Em relação ao _e -ao usar fontes monoespaçadas, a diferença pode ser melhor explicada com esta imagem analógica: evsc.net/v8/wp/wp-content/uploads/2010/09/…
GMaster

-1

Definitivamente, existe um padrão para Linux. Se você olhar os nomes dos arquivos em qualquer sistema Linux, eles estarão em minúsculas com traços: / usr / bin / ssh-keygen. Isso é especificado em um dos documentos da Linux Standards Base que não consigo encontrar no momento. Também é especificado pelo GNU, que diz usar sublinhados para nomes de variáveis ​​e traços para nomes de arquivos.


-2

Para adicionar ao que todos os outros disseram:

1-Embora o Linux não se importe muito com extensões, o Windows sim, portanto, verifique se qualquer arquivo que você planeja fornecer a alguém possui a extensão apropriada.

O uso de 2-camel caps parece ser o mais fácil de usar scripts, sem caracteres especiais para se preocupar com seqüências de escape.


5
-1. O CamelCase NÃO é usado no Linux.
Mikel
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.