Convenções de nomenclatura de arquivos para extensões '.cron' e '.systemd'

0

Estou começando a renomear todos os meus scripts bash existentes em /home/Me/bin e /usr/local/bin de nenhuma extensão para .sh . O motivo é exatamente o mesmo nome de arquivo com conteúdo e propósitos drasticamente diferentes, que às vezes existem em /etc/cron.d ou /lib/systemd/system-sleep . Isso está causando falsos positivos com locate --regex '<file_name>' pesquisas.

Eu pesquisei por aí e não consigo encontrar convenções de nomenclatura de extensão de arquivo para cron ou systemd .

  • Se eu fosse com as convenções do DOS 8.3, escolheria .crn e .syd
  • Se eu fosse com 4 caracteres, escolheria .cron e .sysd
  • Se eu fosse com 2 caracteres como .sh , escolheria .cr e .sd

Eu vi .py usado para o Python, .c para o programa C, .h para o arquivo de cabeçalho, .o para o objeto compilado. Isso me leva a presumir que o verso do Linux preferiria duas extensões de caracteres. Eu acho que as extensões de quatro caracteres são mais legíveis. Eu não vejo nenhuma necessidade para o formato DOS 8.3, já que o antigo componente 8.x tem tamanho 256.x ou algo parecido. Os arquivos de serviço Systemd suportam a tendência "menor é melhor" com .service arquivos em vez de .sr ou .srv .

Antes de passar pelo trabalho de renomear arquivos e editar os pais que chamam os arquivos com novos nomes, há alguma convenção de extensão de arquivo existente ?

Observe se você ou sua organização tem padrões internos que seriam uma resposta perfeitamente aceitável, na ausência de padrões do setor.

Acabamos de encontrar um relatório de erros da barra de lançamento em que o usuário chamado job /etc/cron.d/job.cron e caiu devido a . no nome. O bug foi arquivado em 2011 e confirmado, mas ainda não foi corrigido.

Isso significa que todas as minhas extensões terão que começar com - em vez de .

    
por WinEunuuchs2Unix 30.03.2018 / 02:20

0 respostas