Para la portabilidad, puede asumir con seguridad que #!/bin/sh
encontrará un shell mayormente compatible con POSIX en cualquier sistema Unix o Linux estándar, pero eso es realmente.
En FreeBSD, OpenBSD y NetBSD ( junto con DragonFly, PC-BSD y algunos otros derivados), bash se encuentra en /usr/local/bin/bash
(si está instalado), por lo que /usr/bin/env
El enfoque proporciona portabilidad entre Linux y BSD.
Android no es un sistema Unix o Linux estándar. En mi teléfono Android no rooteado, ninguno de /usr/bin/env
, /bin/bash
o r incluso /bin/sh
existen, y el shell del sistema es /system/bin/sh
.
Un script de shell al que le falta el #!
(shebang) intentará ejecutarse en el shell que lo llamó en algunos sistemas, o puede usar un intérprete predeterminado diferente (/bin/bash
por ejemplo) , en otros sistemas. Y aunque esto puede funcionar en Android, no está garantizado que funcione en otros sistemas operativos, donde los usuarios pueden optar por utilizar un shell interactivo que no sea bash
. (Yo uso tcsh en FreeBSD, donde es el shell predeterminado, y el script sin shebang es interpretado por el shell de llamada.)
Entonces, desde donde me siento, parece que está no es posible crear un script de shell que sea portátil entre sistemas Android y no Android (Linux o Unix), porque Android hace las cosas de manera diferente.
Comentarios
- En mi experiencia,
/bin/sh
se supone que apunta a algo más parecido a bsh
o dash
que bash
, que está relativamente hinchado y, por lo tanto, se prefiere para uso interactivo.
- Algunos errores aquí. Todavía hay muchos (en su mayoría comerciales) Unices por aquí (la mayoría de ellos Solaris 10 y anteriores) donde
/bin/sh
es el Bourne shel l, no es un shell POSIX, POSIX no ' t especifica la ruta de sh
. La mayoría de las conchas (y execp
/ env
/ find -exec...
) interpretarán un she-bang- menos script con el sistema ' s sh
, pocos lo interpretan con ellos mismos y cuando lo hacen, lo hacen en modo de compatibilidad POSIX. Esa ' es la forma estándar / POSIX de ejecutar un script, pero eso supone que la persona que llama está en un entorno POSIX .
- Con respecto a * BSD
bash
es opcional. Significa que hay buenas posibilidades de que incluso /usr/local/bin/bash
no exista en los sistemas (sin mencionar los sistemas propietarios como Solaris, AIX o HP-Ux).
- @ StephaneChazelas – re POSIX, estoy de acuerdo, por supuesto, y eso ' s por qué las palabras que usé fueron " en su mayoría ". Pero esta pregunta se refería a la portabilidad, más que a dónde encontrar POSIX, y uno no puede ' t confiar en que siempre se encuentre un shell en una ubicación. Con respecto al intérprete predeterminado, un script sin shebang que se ejecuta en tcsh es interpretado por tcsh en FreeBSD. Obviamente, también hay ' inconsistencia, así que ' he actualizado la respuesta en consecuencia.
- @Ouki – sí, por supuesto, simplemente no ' creía que eso fuera relevante para la pregunta. Pero ' he agregado esa aclaración a la respuesta para mayor claridad.
Según mi experiencia, #!/bin/sh
y #!/bin/bash
siempre han encontrado el entorno adecuado en los pocos sistemas en los que he trabajado . Todavía tengo que encontrar una excepción. También encuentro que se usa de forma rutinaria en textos relacionados con secuencias de comandos de shell que supongo que están escritos teniendo en cuenta la portabilidad debido a la diversidad de audiencia.
No puedo decir lo mismo con #!/usr/bin/env
.Algunos sistemas lo tienen instalado como #!/bin/env
y han roto mis scripts de Python en el pasado. Entonces, iré con la segunda viñeta.
Aquí hay algo de apoyo para mi declaración anterior:
En la versión 5.7 de CentOS obtengo lo siguiente:
$ which env /bin/env
En Ubuntu 12.04 Precise Pangolin:
$ which env /usr/bin/env
Además, al menos en un sistema anterior, recuerdo a los administradores instalado coreutils
en /opt
por algún motivo (puede que no sea una práctica recomendada). Dado que env
es parte de coreutils
, los usuarios terminaron obteniéndolo en /opt/coreutils/bin/env
. Es cierto que no he usado todos los sistemas, así que la respuesta se basa en mi experiencia limitada.
Comentarios