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

45

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?

— Amelio Vazquez-Reina
fuente

44

A veces, se pueden encontrar scripts de shell sin shebang (o sin permisos de ejecución). En ese caso, un nombre que termina en .sh puede ser una pista para que el usuario los ejecute bash script.sh(o sh, por supuesto).

— Ansgar Esztermann

3

Si un script de shell tiene una extensión, es comúnmente .sh. Nunca he visto un script .ksh o .bash. Sin embargo, la mayoría de los scripts de shell no tienen extensión, como todos los scripts en /etc/init.d/* como ejemplo.

— Richard Holloway

Si bien una conclusión simplista (sí o no) es la opinión, las cosas a considerar no lo son.

— ctrl-alt-delor

35

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).

— Stéphane Gimenez
fuente

1

Solo desde esta página, ya podemos ver una cantidad bastante trivial de personas que la usan. ¿Por qué dices que son "raramente utilizados"? ¿Alguna cita? ¿O esto se basa simplemente en tu experiencia?

— Pacerier

23

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".

— Bruce Ediger
fuente

24

¡Estoy en desacuerdo! Mi trabajo consiste en empaquetar una aplicación que involucra miles de archivos que van desde ejecutables binarios hasta scripts de shell (ksh, bash y algunos csh heredados). Para mí, créanme que hace una diferencia para poder saber de un vistazo (o en una expresión regular) qué tipo de archivo que estamos discutiendo y que estamos buscando. Mi punto es que podría haber un beneficio en distinguir lo que se excreta y una mejor práctica debería alentar a establecer explícitamente el tipo de archivo.

— rahmu

44

@rahmu: escribe eso como respuesta. Proporcione algunos detalles sobre cómo los nombres distinguibles por expresiones regulares lo ayudan a empaquetar (y tal vez mantener) esa aplicación. Observe específicamente la interacción entre lo que interpreta el archivo y el sufijo del nombre del archivo y cómo eso lo ayuda a realizar las tareas. Estoy interesado en argumentos serios contra mi punto de vista, y estoy dispuesto a cambiar si estoy convencido. Voté tu comentario para probarlo.

— Bruce Ediger

3

Me encantaría, desafortunadamente solo puedo hablar de mi experiencia actual en mi trabajo actual. No sé mucho sobre buenas prácticas y estándares en general ; Siento que debería investigar un poco antes de publicar una respuesta aquí. Lo investigaré esta noche después del trabajo :)

— rahmu

2

@rahmu El comando "archivo" existe para determinar el tipo de archivo. Es capaz de distinguir guiones escritos para diferentes shells.

— Matt

3

Si le da una .shextensión a un script de shell , tendrá que escribirlo .shcomo parte del nombre del comando al iniciarlo. Esa es la razón principal por la que no me gusta poner esa extensión (lo mismo con cualquier cosa que tenga una línea shebang). Por cierto, el problema en Windows no es el .exeprefijo per se (es trivial hacer un ejecutable nombrado image.jpgen Linux, después de todo), sino el hecho de que Windows generalmente oculta esa extensión, combinada con el hecho de que la acción necesaria para iniciar un ejecutable y abrir un documento es exactamente lo mismo.

— celtschk

12

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 ...

— Jumpylodo
fuente

Esto parece estar de acuerdo con unix.stackexchange.com/questions/31760/…

— Pacerier

¿No tienes un #!al comienzo del script (por ejemplo #!/bin/bash)?

— ctrl-alt-delor

Gnu / Linux, BSD y UNIX son todos Unix. No hay necesidad de? Nix. Linux es un kernel, Android usa Linux pero no es Unix (a menos que agregue software adicional, en cuyo caso tiene una aplicación Unix).

— ctrl-alt-delor

@ ctrl-alt-delor: "Unix" es una marca registrada . La gente suele usar "? Nix" para evitar el problema de la marca registrada (y los pedantes).

— JS.

@JS `UNIX 'es una marca registrada de The Open Group. Unix y Unix no son greens.org/about/unix.html

— ctrl-alt-delor

6

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.

— ctrl-alt-delor
fuente

Otra razón para no usar *.shme acabo de encontrar es que Debian run-partsno ejecutará scripts con extensiones, como en /etc/cron.*/: archive.oreilly.com/pub/post/runparts_scripts_a_note_about.html

— Ross Patterson

5

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.

— Ouki
fuente

¿Qué quiere decir con "guiones clásicos, bajo a alto grado"?

— Pacerier

Creo que quise decir abstracción u nivel de organización con eso. Es decir, no le importa qué herramienta de lenguaje / script se usa detrás de algunos comandos: por lo tanto, no usa ninguna extensión. Para otros, es bueno saber que es un bash o algún script de shell ksh exótico (con la extensión adecuada). ... pero eso fue hace 2 años;)

— Ouki

3

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.

— Steve
fuente

Esto parece estar de acuerdo con unix.stackexchange.com/questions/31760/…

— Pacerier

2

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.

— qwr
fuente