¿Se considera una práctica recomendada no utilizar letras mayúsculas en la denominación de archivos?

La gente dice que no deberías usar espacios en los nombres de archivos Unix. ¿Hay buenas razones para no usar letras mayúsculas en los nombres de archivo (es decir, File_Name.txtvs. file_name.txt)? ¿O es solo una cuestión de preferencia personal?

La gente dice que no debes espacios en la denominación de archivos Unix.

La gente dice muchas cosas. Hay algunas herramientas que pueden arruinarse, pero es de esperar que sean pocas en este momento, ya que los espacios son un virus proliferado por corporaciones gigantes de sistemas operativos propiedad del consumidor y ahora imposible de evitar.

Los espacios hacen que la especificación de nombres de archivo en la línea de comando, etc., sea incómoda. Eso es todo. Los únicos caracteres categóricamente prohibidos en los sistemas * nix son NUL (no se preocupe, no está en su teclado ni en el de nadie más) y /, dado que ese es el separador de ruta. ¹ Aparte de eso, todo vale. Los elementos de ruta individuales (nombres de archivo) están limitados a 255 bytes (una posible complicación si está utilizando conjuntos de caracteres extendidos) y rutas completas a 4 KiB.

¿O es solo una cuestión de preferencia personal?

Yo diría que lo es. La mayoría de DE parecen crear una serie de directorios en mayúsculas en su $HOME( Downloads, Desktop, Documents- el Des muy popular), por lo que no hay nada extraño en ello. También hay archivos tradicionales muy comunes con mayúsculas, como .Xclientsy .Xauthority.

Un valor de capitalizar las cosas al principio es que, cuando se enumeran lexicográficamente, aparecerán antes que las minúsculas, al menos, con muchas herramientas y sujetas a la configuración regional.

Soy fanático de camel case (también conocido como camelCase) y lo uso con nombres de archivos, por ejemplo, /home/goldilocks/blueSuedeShoesno importa lo que haya allí. Definitivamente es una cuestión de preferencia personal, pero aún no me causa pena.

Los archivos de clase de Java tienden a contener mayúsculas por naturaleza, porque los nombres de clase de Java sí. Y, por supuesto, no lo olvidemos NetworkManager, incluso si algunos de nosotros preferiríamos hacerlo.

^{1. Existe un "conjunto de caracteres de nombre de archivo portátil" mucho más delimitado, recomendado por POSIX que no incluye el espacio, ¡pero sí mayúsculas! POSIX también especifica la restricción más general con respecto al "carácter de barra diagonal y el byte nulo" en otra parte del mismo documento . Esto refleja o se refleja en prácticas convencionales de larga data .}

Una razón para evitar mayúsculas en los nombres de archivo es que el orden de clasificación en Unix distingue entre mayúsculas y minúsculas, por lo que los archivos que comienzan con una letra mayúscula aparecerán desordenados. Esa es la razón por la Makefileque generalmente se nombra con mayúscula M: es uno de los archivos que desea ver primero, sin desplazarse / saltar hacia abajo a-l.

Dicho esto, puede hacerlo mucho peor en términos de nombres de archivo:

• el uso de espacios romperá algunos programas y scripts mal escritos que no citan los nombres de archivo correctamente
• iniciar un nombre de archivo con un -puede causar problemas, ya que muchos programas lo verán como una opción de línea de comandos en lugar de un nombre de archivo (por ejemplo rm -r, no eliminarán un archivo llamado -r).
• comenzar un nombre de archivo con un .lo ocultará de muchas utilidades y el bloqueo de shell (por ejemplo rm *, no eliminará archivos como .config)
• El uso de caracteres especiales como |<>*?e incluso caracteres no imprimibles como newlinees técnicamente posible, pero puede romper scripts / programas similares al carácter de espacio. La diferencia es que el carácter espacial se usa a menudo, por lo que los programadores tienden a probar sus programas contra él, mientras que los personajes menos populares a menudo permanecen sin probar.

Si va a interactuar con un entorno de Windows, debe evitar las mayúsculas porque Windows lo pondrá todo en minúsculas. Esto es más a menudo un problema al revés; un enlace a Page_2.htmlencontrará page_2.htmlen Windows, pero fracasará en Unix.

Una razón para evitar mayúsculas es que bashla finalización de tabulación distingue entre mayúsculas y minúsculas (al menos de manera predeterminada); esto todavía me hace tropezar cada vez que termino frente a una bashconfiguración predeterminada. Claro, hay otros shells populares, pero esto combinado con el hecho de que bashes el shell de inicio de sesión predeterminado en muchos sistemas operativos significa que a menudo se completa con mayúsculas y minúsculas. El uso de nombres de archivo en minúsculas simplifica las cosas aquí.

Como NL_Derek abrió esta lata de gusanos, pero no la articuló correctamente, diré esto:

Está bien usar letras mayúsculas, pero debe evitar crear archivos (en el mismo directorio) que difieran solo por mayúsculas y minúsculas , por ejemplo, File_Name.txt y file_name.txt , porque

• Si de alguna manera pone el directorio a disposición de un sistema Windows, no podrá acceder a ambos archivos. Probablemente podrá acceder solo al que aparece primero en el directorio, independientemente del nombre que utilice. (Excepto: puede darle acceso a ellos como FILENA~1.TXTy FILENA~2.TXT - escriba dir /xpara ver qué nombre corto (si corresponde) va con qué nombre largo).
• Si el sistema de archivos es en realidad un sistema de archivos de Windows (por ejemplo, montado desde un sistema de archivos exFAT o NTFS desde un servidor NFS que ejecuta Windows), los dos nombres (probablemente) no podrán coexistir. Por ejemplo, si lo hace y , puede terminar con un solo archivo, que contiene la salida de .cmd1 > foocmd2 > Foocmd2
• Del mismo modo, si alguna vez transfiere los archivos a un sistema Windows, los dos nombres (probablemente) no podrán coexistir. Por ejemplo, si creó un archivo comprimido (p. Ej., Zip) que contiene los dos archivos y lo extrajo en un sistema Windows, el segundo archivo probablemente sobrescribirá el primero. Lo mismo si los transfirió a un cuadro de Windows con FTP o algo similar.

Además de razones técnicas, tengo un aspecto práctico para esto. Pegarse en letras minúsculas asegurará que las búsquedas sean más fáciles a menos que uno sea demasiado aficionado a usar grep -i o localizar -i. A veces, incluso camelCase puede ser confuso si uno tiene que usar una cadena de palabras similares como en el almacenamientoNYCDCPrimary. Por lo tanto, creo que es mejor atenerse a las minúsculas y salpicarlas con guiones bajos o guiones para facilitar la lectura, como storage_nyc_dc_primary.

Puedo hacer considero que es la mejor práctica para evitar el uso de mayúsculas y espacios en los nombres de archivo.

Algunos dirán que no están de acuerdo, pero es un asunto o lo que yo llamo creencias religiosas : difícil de discutir y acordar. Los que no están de acuerdo dicen que la mayoría de las herramientas ahora están arregladas para ser mayúsculas y espacios amigables: tienen razón, pero esta no es la pregunta.

La pregunta correcta es cuánto necesita usar mayúsculas y espacios en los nombres de archivo. A esta pregunta, excepto cuando estoy programando en Java, la respuesta es principalmente todo el tiempo: no necesito mayúsculas y espacios en mis nombres de archivo . Todos los espacios los reemplazo por un guión bajo ( _) o un signo menos ( -), y por eso no uso el caso de camello (también conocido como camelCase) contrario a alguna otra religión.

Muchas personas me criticaron por hacer y enseñar eso, algunos todavía lo hacen, algunos tropezaron con una herramienta que no era amigable con el capital / espacio y vinieron a mí diciendo que tenía razón y que deberían haberme escuchado. Haga lo que quiera , y si usa mayúsculas y espacios en el nombre del archivo, espero que nunca se tropiece con una herramienta mal escrita. Sin embargo, si tropieza con dicha herramienta, con suerte nuevamente, no será difícil de arreglar y no le costará a su negocio y / o mucho dinero y / o tiempo. Pero si termina teniendo malas repercusiones, recordará que algunos le dijeron en el pasado que usar mayúsculas y espacios en los nombres de archivos es una mala práctica.

Y una última cosa, si desea evitar todos los problemas , no hay caracteres especiales en los nombres de archivo (solo letras minúsculas, dígitos, guiones bajos y menos [1]). Esta lista de caracteres no deseados también incluye todos los caracteres no ascii (sí, francés y otras personas no inglesas, y yo soy uno de ellos), ninguno de esos: à, â, ä, ç, é, ..., ö, æ, œ , ...) Esto también se extiende a muchas otras cosas, incluido el inicio de sesión y la contraseña . Te dejaré adivinar qué sucede cuando pones una cita o una cita doble ( 'o ") en un nombre de usuario o contraseña manejado por un script bash no escrito por un administrador de sistemas confirmado ...

[1]: tal vez podríamos extender el proceso a ~, @, #y algunos otros, pero esto está en busca de problemas (y sí sé acerca de los archivos de Emacs ...).