La mayoría del código que escribo está en PHP. Recientemente comencé a aprender scripting de shell. La mayoría de los recursos y tutoriales que he encontrado son específicos de Bash. Algunos advierten sobre los bashismos y otros no. He estado leyendo mucho aquí y Stack Overflow.
Cada vez que una respuesta usa bashismos , alguien inevitablemente comentará para decir:
No deberías usar <insertar bashism aquí>. No es portátil
Esto sucede incluso cuando se etiquetó la pregunta bash. Para mí, eso es como decirle a un programador de PHP que no deben usar código nuevo en PHP 5 porque no se puede usar con PHP 4. O decirle a alguien que no deberían escribir algo para Mac porque no se puede usar en Windows
Cuando escribo en PHP, elijo un requisito mínimo y escribo código compatible con reenvío . No me preocupa hacer que sea retrocompatible .
Si lo uso #!/bin/bashcomo shebang, ¿por qué no debería usar bashisms? Estoy empezando a tener la impresión de que a algunas personas les gusta golpear los bashismos (juego de palabras) solo por el simple hecho de hacerlo.
La gente a menudo usa bashe shellintercambiablemente, probablemente debido al hecho de que bash es el shell predeterminado en muchos sistemas. Así que puedo entender agregar un comentario para advertir que el código usa basismos, pero no entiendo la implicación de que está mal usarlos.
Obviamente, si estoy escribiendo un guión estrictamente para uso personal, puedo escribirlo en el idioma que desee. Pero me gustaría pensar que parte del código que escribo podría ser útil para otros.
Intenté buscar una respuesta a mi pregunta antes de publicar. Encontré mucha información sobre cómo probar la portabilidad, pero no pude encontrar nada sobre cuándo es importante hacerlo.
Entonces, ¿cuándo es importante escribir scripts portátiles?
Por ejemplo,
- ¿Qué tipos de scripts deberían ser lo más portátiles posible?
- ¿Qué tan comunes son los sistemas que no tienen instalado Bash?
- si el sistema tiene instalado Bash, ¿también tendrá la versión GNU de find y otras utilidades?
fuente
bashetiqueta sola, alguien comenta "Es bashism y no portable". Cuando respondo una pregunta que está etiquetadaC, no me importa si es portátilJavao no.bashcaracterística específica, y no portátil, tal como señalaría que se está utilizando una extensión específica de GNU para alguna utilidad (a pesar de que la pregunta fue etiquetada como Linux). Nunca he visto a nadie decir "esto es un bashism y nunca deberías usarlo".Respuestas:
Como miembro de esta comunidad, a menudo no veo personas que no tengan en cuenta los basismos para las cosas que se dirigen a bash. Cuando se habla de portabilidad, los GNUismos son mucho peores que los basismos. Mientras lo use
bashpara su shebang, puede esperar que el script se ejecute usandobash. Sin embargo, no puede garantizar la versión a menos que marque explícitamente. Bash versión 4 trajo algunas características útiles, como matrices asociativas, pero Bash v3 todavía se usa ampliamente en OS X y RHEL 5.Esto es más acerca de sus necesidades y lo que elige apoyar como desarrollador. Si está escribiendo un script de instalación para una aplicación que admite todos los tipos de * NIX, la portabilidad será muy importante.
FreeBSD y Solaris 10 son ejemplos de sistemas que no vienen con bash instalado por defecto. La mayoría de los sistemas Linux lo tendrán, con la excepción de los sistemas integrados.
No, y este es el verdadero problema con la portabilidad. Si la portabilidad es importante, solo debe usar las funciones de comando de shell definidas por el estándar POSIX. Las utilidades GNU se pueden instalar en sistemas que no sean GNU como FreeBSD, pero es poco probable que sean las primeras en PATH, y no puede confiar en que esas herramientas se instalen.
fuente
findy cualquier otra utilidad específica de GNU que yo haya usado? Obviamente, eso no sería fácil de usar para un script de instalación. Pero estoy pensando en poner algo en GitHub para que otros lo agarren si así lo desean. No me importa que no sea portátil para todos los sistemas. Simplemente no quiero que sea inútil en muchos sistemas.FIND=/opt/gnu/dispicable/bin/findal comienzo de su script y luego lo usa en${FIND}lugar definden su script, le da a la gente un (!) lugar para colocar sus rutas de instalación y hacer que su script use las herramientas correctas.Cuando los usa para su entorno de trabajo, y trabaja (o podría en el futuro) en diferentes máquinas, Y, no desea tener que reescribir sus herramientas antes de ponerse a trabajar.
por ejemplo: un script de basura /
rmreemplazoMark Stewart:
... para mi kit de herramientas de solución de problemas, supongo que solo tendré vi y Korn shell. Y trato de usar comandos que funcionan en la mayoría de los sabores de Unix.
fuente