¿Debo poner extensiones de archivo * .sh y * .rb en todos mis scripts?

Tengo un montón de scripts ejecutables enrollados a mano en mi directorio $ HOME / bin. Algunos están escritos en bash, otros en Ruby. Todos ellos tienen la línea shebang en la parte superior que le dice al intérprete qué intérprete usar (bash o Ruby, en mi caso).

Me pregunto si es mejor poner extensiones de archivo en estos scripts para indicar en qué lenguaje de scripts están escritos. Por ejemplo, los scripts en Ruby tendrían el sufijo * .rb, y los bash tendrían el sufijo * .sh.

Actualmente, estos scripts solo tienen nombres simples sin extensión de archivo.

¿Cuál es la mejor práctica?

Puede hacer comandos comodín como ls *.rbo cp *.shsi desea organizar sus scripts en el futuro.

Comience temprano o lamento más tarde, en mi opinión.

Los editores como vimtambién podrán aplicar el resaltado de sintaxis correcto basado en shebang o extensión de archivo.

Esto también se puede lograr mediante el uso de modelos en varios editores. Por ejemplo, para vim:

# vim: ft=sh

Bueno, como la mayoría de las cosas en la vida: depende de tus necesidades.

Usted declaró que estos scripts residen en un directorio bin y supongo que estos scripts deben llamarse desde la línea de comandos. Como usuario lo considero molesto si tengo que escribir bla.ksh o foo.bash. Además, si el codificador decide pasar a otro intérprete, el nombre del comando también cambiaría y tendría que enmendar otros scripts que hacen uso de estas herramientas, muy molesto, incluso si el usuario y el codificador son la misma persona.

Pero, por otro lado, uso extensiones como .sh o .tcl en los directorios de compilación de mi proyecto. De esta manera, puedo usar las funciones make para implementar los archivos en sus directorios de destino, pero en esta etapa elimino el sufijo del archivo.

Obviamente, hay algunas diferencias entre los archivos ejecutables en los bindirectorios y los archivos "fuente" editables.

• Para los archivos de origen, es útil tener un sufijo para que pueda ver qué es qué y para ayudar a algunas herramientas menos inteligentes que no pueden escanear la #!línea.
• Para los módulos, solo los usan un conjunto relacionado de programas, todos los cuales usan el mismo intérprete (o ningún intérprete), y es convencional incluirlos .pm, .sho .soen tales casos.
• Para los programas ejecutables, su nombre es parte del "contrato de programación" por el cual los usuarios y otros scripts lo invocan. Es importante que el nombre no cambie incluso si la implementación lo hace; así que obviamente el nombre del archivo no debería tener un sufijo

En el caso de un programa compilado, la diferencia entre "fuente" y "ejecutable" es obvia: una contiene código fuente, la otra contiene lenguaje de máquina o código de bytes interpretado. En el caso de un script, no hay una diferencia obvia, pero el makecomando mantiene una separación teórica entre el "código fuente de un script" y la "versión ejecutable de un script": su "compilador" predeterminado para "shell script" es simplemente cp.

Recomendaría mantener un $HOME/sourcedirectorio separado y:

• mantener un enlace simbólico, como el realizado por ln -s ../source/foo.sh $HOME/bin/foo; o
• copiarlos manualmente después de hacer cambios (y probarlos), usando install -m 755 foo.sh ../bin/foo; o
• usando una Makefileregla para realizar una comprobación de sintaxis antes de copiar el archivo de origen desde $HOME/sourcedentro$HOME/bin

Nota al pie: un módulo de script de shell solo puede ser utilizado por otro script de shell y modifica el contexto interno de ese script utilizando los comandos .o sourcelos comandos integrados. Esto es diferente de un script ejecutable, que (como cualquier programa) se ejecuta como un proceso separado y no puede modificar su proceso padre. Como una convención aproximada, los módulos entran /usr/lib/name_of_program/name_of_module.shmientras que los comandos entran /usr/bin/name_of_command(sin ningún sufijo).

No es necesario. El kernel ya está informado del intérprete correcto que debe usar (por #!línea), y todos los editores de texto populares también lo leen, por lo que agregar una extensión no haría nada útil, solo aumentaría la escritura. El único momento en que un programa ejecutable tiene una extensión es cuando es de alguna manera importante (para el programa o el usuario o ambos).

Los módulos y bibliotecas, por otro lado, casi siempre tienen extensiones ( .rbpara módulos Ruby, .sopara bibliotecas compartidas ELF, etc.).