Extensiones de archivo para scripts de shell de Unix [cerrado]

En wikipedia, el artículo para .sh dice:

Para el tipo de extensión de archivo .sh, vea Bourne shell .

¿Qué hay de otras conchas de Unix?

Sé que el shebang se usa dentro del archivo para indicar un intérprete para la ejecución, pero me pregunto:

• ¿Cuáles son los pros y los contras de las extensiones de archivos frente a las extensiones sin archivos?

Solo llamaría a .shalgo que está destinado a ser portátil (y espero que sea portátil).

De lo contrario, creo que es mejor ocultar el idioma. El lector cuidadoso lo encontrará en la línea shebang de todos modos. (En la práctica, .basho .zsh, etc., los sufijos rara vez se usan).

Yo diría que no existen "buenas prácticas" para las extensiones de archivos, estrictamente por un tecnicismo: los sistemas de archivos Unix / Linux / * BSD no admiten extensiones per se. Lo que está llamando una extensión es simplemente un sufijo de un solo nombre de archivo. Eso es diferente a los sistemas de archivos y sistemas operativos VM / CMS, VMS, MS-DOS y Windows donde un lugar especial en el equivalente de inodo-moral está reservado para una extensión.

Ahora que acabo de hablar, creo que es un poco tonto poner un sufijo ".sh" o ".ksh" o ".bash" en un nombre de archivo de script de shell. Un programa es un programa: no existe ningún beneficio en distinguir lo que se ejecuta. Ningún unix o linux o cualquier kernel ha decidido llamar a un intérprete en algún archivo solo por un sufijo de nombre de archivo. Todo se hace por la #!línea, o alguna otra secuencia de "número mágico" de bytes al comienzo del archivo. De hecho, decidir qué ejecutar en función de una "extensión" de nombre de archivo es uno de los factores que hace de Windows un imán de malware. Mire cuántas estafas de malware de Windows involucran un archivo llamado "something.jpg.exe". Por defecto, las nuevas versiones de Windows no muestran la extensión ".exe" y aliente al usuario a hacer doble clic en "

Lo que se podría considerar como un comando directo es a menudo un script de shell de todos modos. A veces ccha sido un script sh, firefoxes un script sh, startxes un script sh. No creo que haya un beneficio cognitivo u organizativo para marcar un script con un sufijo ".sh".

Como alguien que ha trabajado en una multitud de entornos de nix, he tenido que escribir en una amplia variedad de shells. Lo creas o no, a través de las plataformas, las conchas no son lo mismo. Por lo tanto, si mantiene su biblioteca personal en varios shells (cuando sea necesario), es muy útil usar extensiones para identificar los shells. De esa manera, cuando se mueve a otra plataforma y el shell es ligeramente diferente, sabe a qué scripts debe dirigirse para realizar modificaciones. .sh .ksh .bsh .csh ...

No debe usar una extensión para ejecutables, ya que no son intercambiables. Imagine que tiene un script de shell a.sh, luego vuelva a escribir en python a.py, ahora tiene que cambiar cada programa que lo llama script, ha filtrado detalles de implementación.

Toda la extensión de nombre de archivo en Windows de Mircosoft es un desastre: por ejemplo, lo que podría haber sido a.audio, b.audio, c.audio, es a.mp3, b.wav, c.oggy d.picture, e.picture, f.picturees d.jpeg, e.png, f.gif. La mayoría de las veces no nos importa en qué formato está el audio o la imagen. También tenemos que pasar mucho tiempo enseñando a los nuevos usuarios todas las extensiones de archivo.

Como lo dijo, las extensiones de archivo de Unix son puramente información. Solo necesita que su script tenga un shebang correcto y sea ejecutable.

No puede tener ninguna extensión o usar .sh.

Personalmente uso las siguientes convenciones, independientemente del shell utilizado (csh, tcsh, bash, sh, ...):

• sin extensión para el sistema o scripts de alto grado (extremadamente raro).
• la .shde guiones clásicos, menor a mayor grado.

Las extensiones de script de Shell son bastante útiles. Por ejemplo, a menudo escribo scripts que tienen múltiples archivos en varios idiomas (por ejemplo, bash, awk y lua) en el mismo directorio. Si necesito buscar una cadena solo en los archivos bash, la extensión lo hace muy útil para reducir los falsos positivos. O si quiero hacer un recuento de líneas de todo mi código bash para ese proyecto.

Es difícil tener que escribir la extensión al ejecutar el programa, así que también hago un enlace simbólico sin la extensión al ejecutable principal, para editarlo / ejecutarlo sin necesidad de escribir la extensión cada vez. Los enlaces simbólicos son baratos y fáciles.

Como otros han dicho, al shell no le importan las extensiones. Sin embargo, permite una rápida identificación humana de los archivos. Veo archivos que terminan en .pyo .shy rápidamente sé cuáles deberían ser (al menos). Como dice Steve, buscar por extensión de archivo o hacer un recuento de líneas también son consideraciones prácticas.