Convención de nomenclatura de archivos Unix [cerrada]

Me preguntaba cuál es la convención de nomenclatura para archivos en Unix. No estoy seguro de esto, pero creo que tal vez hay una convención de nomenclatura universal que uno debería seguir.

Por ejemplo, quiero nombrar un archivo que diga: backupcon part 2yrandom

Debería hacerlo así:

backup_part2_random

O

backup-part2-random

O

backup.part2.random

Espero que la pregunta sea clara. Básicamente, quiero elegir un formato que se ajuste a la filosofía de Unix.

.se usa para separar una extensión de tipo de archivo, por ejemplo foo.txt.

-o _se usa para separar palabras lógicas, por ejemplo, my-big-file.txto algunas veces my_big_file.txt. -es mejor porque no tiene que presionar la tecla Mayús (al menos con un teclado de PC estándar en inglés de EE. UU.), otros prefieren _porque se parece más a un espacio.

Entonces, si entiendo su ejemplo, backup-part2-randomo backup_part2_randomsería más cercano a la convención normal de Unix.

CamelCase normalmente no se usa en sistemas Linux / Unix. Echa un vistazo a los nombres de archivo en /biny /usr/bin. CamelCase es la excepción más que la regla en los sistemas Unix y Linux.

( NetworkManageres el único ejemplo que se me ocurre que usa CamelCase, y fue escrito por un desarrollador de Mac. Muchos se han quejado de esta elección de nombre. En Ubuntu, en realidad han cambiado el nombre del script network-manager).

Por ejemplo, /usr/binen mi 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 incluso entonces, ninguno de los archivos que comienzan con mayúscula usa CamelCase:

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

Mucho más importante que una convención particular sea ser consistente. Elige un estilo y quédate con él.

Mi opinión sobre las convenciones de nombre de archivo de Unix / Linux:

• Los sistemas de archivos Unix / Linux no soportan inherentemente la noción de una extensión. El concepto de una extensión de archivo existe por completo como algo con el apoyo de los servicios públicos como cp, lso la cáscara que está utilizando. Creo que también es así en NTFS, pero podría estar equivocado.

• Los ejecutables, incluidos los scripts de shell, generalmente nunca tienen ningún tipo de extensión. Las secuencias de comandos tendrán una línea hashbang (es decir #!/bin/bash) que identifica qué programa debe interpretarlo.

• Cualquier ejecutable que tenga dos letras es muy importante. Por lo tanto, no nombre sus archivos ejecutables de dos letras. Cualquier archivo en /etcque termina en tabes también muy importante, como fstab, mtab, inittab.
• A veces .dse agrega a los nombres de directorio, particularmente en /etc, pero esto no está muy extendido (ACTUALIZACIÓN: https://serverfault.com/questions/240181/what-does-the-suffix-d-mean-in-linux )
• rces ampliamente utilizado para scripts o archivos de configuración, ya sea antes (por ejemplo, rc.local) o sufijos ( .vimrc)
• La comunidad Unix / Linux nunca ha tenido un límite de tres caracteres en las extensiones y frunce el ceño al acortar extensiones bien conocidas para que quepan. Por ejemplo, no use .htmal final de archivos HTML en Unix / Linux, use .html.
• En un conjunto de archivos, un nombre de archivo a veces se escribe con mayúscula o en mayúsculas, por lo que aparece en la cabecera de una lista de directorio. El ejemplo clásico está Makefileen los paquetes fuente. Solo haz esto para cosas como README.
• ~se usa para identificar un archivo de respaldo o un directorio, como en important_stuff~, o /etc~. Muchas conchas se expandirán un solitario ~a $HOME.
• Los archivos de la biblioteca casi siempre comienzan con lib. La excepción es zliby probablemente algunos otros.
• Las secuencias de comandos que inetd llama a veces se etiquetan con un encabezado in., como in.tftpd.
• La terminación z en vmlinuzsignifica comprimido, pero nunca he visto ningún otro archivo llamado de esta manera.

En unix, el nombre de archivo es solo una cadena, a diferencia de DOS, donde el nombre de archivo se compone de nombre y extensión. Por lo tanto, cualquiera de los nombres de archivo dados es completamente aceptable.

Pero muchos programas aún usan sufijos de archivos que comienzan con puntos para distinguir diferentes tipos de archivos, es decir, Apache Web Server usa sufijos para establecer el tipo MIME correcto en los encabezados de respuesta.

Dos pensamientos:

1. En la Naming Variables, Functions, and Filessección de los Estándares de codificación GNU encontrará:

   Utilice guiones bajos para separar las palabras en un nombre, de modo que los comandos de palabras de Emacs puedan ser útiles dentro de ellos. Se adhieren a minúsculas;

   Si bien la OMI dice "Deberías usar _porque emacs" parece un poco anticuado, sin embargo, está en su documento de "estándares".

2. Supongamos por un momento que todos estamos de acuerdo en que el kernel de Linux es el ser-todo-y-todo-fin * de los proyectos de Linux, y que las convenciones utilizadas allí son lo que podría considerarse una convención 'estándar'.

   grep-ing fuente para el kernel de Linux encontrará lo siguiente:

   • 44.6% del tiempo solo se usa guión
   • El 54.1% del tiempo solo subraya
   • 1.2% del tiempo que un archivo usa ambos.

Curiosamente, la fuente de git pesa 85% para guiones, 3.8% para guiones bajos y 11.1% para ambos.

La elección es clara, debate terminado. ;)

Opinión personal: uso guiones por razones estéticas y de cambio. Si está trabajando en un equipo, vote. Pero para reiterar lo que se ha dicho, sea ​​consistente .

* o "be_all y end_all" si quieres

Caracteres que no debes usar en los nombres de archivo:

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

Delimitadores de caracteres que debe usar para facilitar la lectura de los nombres:

_ -. :

(En algunos casos, ":" tiene un significado especial)

Para agregar a lo que otros han dicho, solo diría que si bien las letras acentuadas y muchos caracteres especiales son legales en los nombres de archivo, pueden causar problemas en cualquiera de los siguientes escenarios:

• Compartes tu sistema de archivos con otras computadoras, particularmente con diferentes sistemas operativos;
• Compartes archivos con otros (y aunque el correo electrónico tiende a ser bastante bueno con las conversiones, a veces simplemente no funciona);
• Utiliza scripts de shell para automatizar algunas tareas (los espacios son particularmente problemáticos, aunque hay muchas formas de tratarlos);
• Utiliza un recurso compartido de archivos de otra computadora.

...

Se adhieren a los nombres de archivo alfanuméricos. Evite espacios o reemplace espacios con guiones bajos (_). Limite la puntuación en los nombres de archivo a puntos (.), Guiones bajos (_) y guiones (-). En general, los nombres de los archivos están en minúsculas, pero uso CamelCase cuando tengo varias palabras en el nombre del archivo.

Use extensiones que indiquen el tipo de archivo. Los programas no necesitan extensiones ya que el bit de ejecución se usa para indicar programas, y los shells saben cómo ejecutar programas de varios tipos. Es común pero no es obligatorio (.sh) para los scripts de shell y (.pl) para los scripts de perl. Las extensiones ejecutables de Windows .bat, .com, .scr y .exe indican los ejecutables de Windows en Unix.

Elija un estándar y manténgalo. Pero no romperá las cosas si lo evitas.

Los archivos ocultos (o de punto) tienen nombres que comienzan con un punto. Estos normalmente no aparecen en las listas de directorios. Use 'ls -a' para incluir los archivos de puntos en la lista.

Una convención es usar "_" para reemplazar espacios como separadores entre palabras. Se podrían usar otros caracteres para reemplazar espacios, pero hay usos convencionales ligeramente más fuertes para "-" y "". en los nombres de ruta, por lo que generalmente se prefiere "_".

Los espacios son legales en los nombres de ruta, pero se evitan convencionalmente, ya que requieren citar el nombre de ruta ("foo bar") o escapar de los espacios (foo \ bar). Un script de shell correctamente escrito citará variables que pueden incluir espacios, particularmente nombres de ruta, pero no hacerlo es un descuido común, y es una gran cantidad de tipeo adicional cuando se hace un comando único ingresado en la línea de comando.

El uso de "-" para separar grupos de números, como en marcas de tiempo o números de serie, es una convención comúnmente utilizada fuera del contexto de los sistemas de archivos. Utilizando "." para separar "extensiones de archivo" que indican que el tipo de archivo es muy común, y algunas herramientas importantes dependen de él. Por ejemplo, el sistema de administración de paquetes en Red Hat Enterprise Linux y sus derivados, RPM, espera que los archivos de paquetes terminen con ".rpm". El tarball tradicional es un archivo tar (".tar") que se ha comprimido (".gz") y termina en ".tar.gz".

Entonces, al juntarlos, a menudo terminas con nombres de archivo que se parecen a "home_backup_2017-07-01.tar.gz"

usar -o _para nombrar archivos
_para funciones
.para extensiones

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

Estoy de acuerdo con David Oneill en que deberías ir con algo.

Pero es bueno si los archivos se pueden ordenar en el mismo directorio, así que no numere 0 ..10 sino número 00 ..10.

Cuando use fechas en los nombres, elija un formato de fecha estándar como ISO8601 .

Y no tenga miedo de usar varios caracteres para separar las partes lógicas en el nombre. Si usa _ (que era 3 _), puede simplificar las expresiones regulares en los nombres de archivo más adelante.

Entonces su ejemplo podría ser algo como esto:

backup_2011-06-19T114012___part002___random

Fácil de leer y fácil de analizar con scripts.

Las palabras en un nombre de archivo se pueden separar con _o -según la convención de Unix.

Si lo usa -, es más fácil escribir, le ahorra presionar MAYÚS. Pero dado que -ocupa tan poco espacio, es un poco difícil leer separaciones de palabras en comparación _. Usar _para separar palabras hace que se vea mucho más limpio ya que _ocupa más espacio.

En los scripts de shell y otras programaciones de computadora, _se usan para variables de varias palabras, como MY_ENVIRONMENT_FILE. Haciendo uso de los nombres de archivo _y la mantiene constante: MY_ENVIRONMENT_FILE=~/my_environment_file.

En desarrollo web, -se prefiere para nombrar archivos. Probablemente, una de las razones es que el subrayado en los enlaces web puede ocultar los guiones bajos y puede dificultarlo si escribe el enlace a mano.

En la mayoría de los editores y en las páginas web, this_long_wordse puede seleccionar completamente con un doble clic, pero no this-long-word.

Definitivamente hay un estándar para Linux. Si observa los nombres de archivo en cualquier sistema Linux, están en minúsculas con guiones: / usr / bin / ssh-keygen. Esto se especifica en uno de los documentos de Linux Standards Base que no puedo encontrar en este momento. También lo especifica GNU, que dice usar guiones bajos para nombres de variables y guiones para nombres de archivos.

Para agregar a lo que todos los demás han dicho:

1-A pesar de que a Linux no le importan mucho las extensiones, a Windows sí, así que asegúrese de que cualquier archivo que piense darle a alguien tenga la extensión adecuada.

2-Camel caps parece ser el guión más fácil de usar, sin caracteres especiales para preocuparse por las secuencias de escape.