Pregunta:
Usando shells que no sean bash
EMiller
2017-06-01 20:29:48 UTC
view on stackexchange narkive permalink

Como alguien que está comenzando a profundizar en la bioinformática, me doy cuenta de que, al igual que la biología, aquí hay estándares de la industria, similares a Illumina en genómica y pajarita para alineación, muchas personas usan bash como caparazón.

¿Usar un shell además de bash me va a causar problemas?

Ajustaría los ejemplos que proporcionaste. Illumina es un estándar para lecturas cortas, pero hay muchos laboratorios de genómica que trabajan principalmente con PacBio o Nanopore. Bowtie no es un estándar. Incluso las versiones 1 y 2 son muy diferentes.
@burger ¿qué sugieres entonces?
Ninguna sugerencia. Aunque estoy de acuerdo con todas las respuestas hasta ahora, la bioinformática no es buena con los estándares. Incluso algo como un archivo SAM / BAM que técnicamente es un estándar correctamente definido que casi todo el mundo en genómica usa tiene muchos campos que se tratan de manera diferente, lo que genera problemas para muchas herramientas.
Una declaración "esto no es para tener opiniones" no ayuda mucho con una pregunta tan amplia como esta. ¿Tiene una aplicación en particular para la que le gustaría usar un shell o una indicación de la "industria" que le interesa?
@burger: ¿Tiene en mente campos problemáticos específicos de SAM / BAM? Puede plantear problemas en https://github.com/samtools/hts-specs/issues o al menos esto sugiere otra pregunta para hacer aquí ...
@JohnMarshall No creo que haya un "error" con el estándar SAM / BAM. Es solo que tiene un final abierto y diferentes herramientas requieren diferentes campos. He tenido que modificar mis archivos BAM muchas veces en el pasado porque alguna herramienta lo esperaba en un formato ligeramente diferente. Técnicamente, sigue siendo un BAM válido antes y después, pero uno es compatible y el otro no. Si tiene un BAM, no tiene idea de si funcionará con una herramienta que requiera un archivo BAM.
@burger: Si desea que esta situación mejore, tendrá que decir qué campos en particular ha tenido que modificar y cuáles eran las expectativas de las distintas herramientas. Si hace esto, se pueden aclarar las especificaciones, se pueden modificar las herramientas y las tuberías de bioinformática de todos pueden funcionar con un poco más de fluidez. De lo contrario, es solo FUD.
VCF por otro lado… :-)
Cinco respuestas:
#1
+18
John Marshall
2017-06-01 20:53:21 UTC
view on stackexchange narkive permalink

Las herramientas de bioinformática escritas en shell y otros scripts de shell generalmente especifican el shell que quieren usar (a través de #! / bin / sh o, por ejemplo, #! / bin / bash si es importante), por lo que no se verá afectado por su elección de shell de usuario.

Si está escribiendo scripts de shell importantes usted mismo, hay razones para hacerlo en un shell de estilo Bourne. Consulte Programación Csh considerada perjudicial y otros ensayos / polémicas.

Un shell de estilo Bourne es prácticamente el estándar de la industria, y si elige un shell sustancialmente diferente, tendrá que hacerlo. traducir parte de la documentación de sus herramientas bioinformáticas. No es raro tener cosas como

Establezca algunas variables apuntando a datos de referencia y agregue el script a su PATH para ejecutarlo:

  export FOO_REF = / path / to / stuffexport PATH = / path / to / foo-xy: $ PATHfoo blah blah  

Estos se mostrarán típicamente en la sintaxis Bourne-shell. Al usar un shell diferente, tiene que traducir los comandos export a su sintaxis local, y especialmente PATH munging es algo dependiente del shell.

Si tiene experiencia en Unix, esto será solo una pequeña queja. Si eres un principiante, en mi humilde opinión, esto agregará una cantidad no despreciable de fricción además de todas las otras cosas que estás aprendiendo.

** No ** use `#! / Bin / bash` en el shebang. Tener Bash instalado en una ubicación no estándar es lo suficientemente común como para que se rompa a menudo. Use `#! / Usr / bin / env bash` en su lugar, no debería tener ninguna desventaja.
#2
+11
Karel Brinda
2017-06-01 20:59:23 UTC
view on stackexchange narkive permalink

SH se adhiere a un estándar oficial de la industria, pero no es adecuado para la informática científica. Bash se considera un estándar informal (por ejemplo, por Google). Bash 3 es preferible en la mayoría de situaciones del mundo de la bioinformática.

Respuesta larga

Como ya se describió en otras respuestas, SH ( / bin / sh , shell Bourne simple, el shell UNIX original) debería adherirse completamente a POSIX, que es un estándar industrial real. Sin embargo, SH es demasiado limitado para la informática científica ya que muchas características clave se incorporaron más tarde en los sucesores de SH, especialmente en Bash ( / bin / bash , Bourne Again Shell): set -o pipefail , [[...]] , o sustituciones de proceso < () para nombrar al menos algunas.

En la práctica, es mucho Es más difícil escribir scripts "seguros" en SH puro y solo los expertos en shell suelen ser capaces de evitar comportamientos inesperados. Por ejemplo, puede ser difícil asegurarse de que ningún comando de una canalización falle en medio del cálculo. Para Bash, se han desarrollado varias recomendaciones de programación defensiva fáciles de seguir y deberían prevenir todos estos problemas. Por esta razón, muchos informáticos, ingenieros de software y empresas utilizan Bash como una especie de estándar. Por ejemplo, la política interna de Google permite solo Bash para escribir secuencias de comandos de shell.

Aunque no podemos esperar que Bash esté completamente presente en todas las máquinas Unix (por ejemplo, en dispositivos móviles como señaló @terdon), una gran mayoría de las máquinas * nix utilizadas para computación científica deberían tenerlo. También debemos ser conscientes del hecho de que Bash puede ser más lento que SH y que recientemente ha sufrido importantes problemas de seguridad. Además, existen varias versiones de Bash y los scripts que funcionan en máquinas Linux modernas con Bash 4 podrían no funcionar en OS X, que todavía se basa en Bash 3.

En resumen, Bash 3 es probablemente la opción más razonable para la informática científica.

Abordé los comentarios de @terdon y @John Marshall. En particular, agregué una explicación de por qué Bash es más adecuado para la informática científica que SH (en mi opinión).

Bash no está presente en todas las máquinas Unix, "sh" sí y no es lo mismo. Sí, Linux tiende a tener `/ bin / sh` apuntando a bash, pero Linux no es Unix y, de todos modos, incluso en Linux` / bin / sh` no siempre es `bash` (los sistemas basados ​​en Debian usan dash en su lugar, por ejemplo ). Puede esperar con seguridad que el shell Bourne (sh) esté presente en un sistema compatible con POSIX, pero no necesariamente el shell Bourne again (bash).
@terdon ¿Podría proporcionarnos alguna referencia, por favor? Según https://wiki.debian.org/Bash, bash es el shell predeterminado en Debian. ¿Conoce alguna distribución (moderna) * nix donde no se instalaría bash?
@terdon Responderé a mi pregunta, por ejemplo, FreeBSD. https://www.freebsd.org/doc/en/articles/linux-users/shells.html dice que "Bash no está incluido en la instalación predeterminada". ¿Tiene un ejemplo de una distribución de Linux sin bash?
Algunos (¿todos?) Sistemas Linux embebidos no tendrán bash y en su lugar tendrán busybox sh. El problema principal es que la gente tiende a pensar que "sh" y "bash" son lo mismo, pero no lo son. Son similares y bash es una extensión de sh, pero no son lo mismo.
@Karel: Preguntar sobre el "shell predeterminado" es ambiguo. Según https://wiki.debian.org/Shell, en estos días en Debian el `/ bin / sh` predeterminado es dash mientras que el shell de inicio de sesión predeterminado (como se enumera en` / etc / passwd`) sigue siendo `/ bin / bash '. Esto significa que los scripts de shell portátiles que se identifican con `#! / Bin / sh` deben restringirse a las funciones del shell POSIX, mientras que los scripts que quieren usar extensiones bash necesitan usar` #! / Bin / bash`. Esto se arregló de la manera difícil hace unos años cuando varias distribuciones cambiaron al guión para `/ bin / sh` ...
@terdon @John Marshall Gracias por sus comentarios. En comparación con bash, considero sh "puro" muy limitado e inapropiado para la informática científica, en particular debido a algunas características faltantes, pero muy importantes, como `set -o pipefail` o` [[...]] `. Mi experiencia es que los scripts sh pueden ser muy susceptibles a comportamientos inesperados (a menos que el desarrollador sea un experto en shell, que no suele ser el caso de la bioinformática). Existen varias estrategias de programación defensiva buenas y simples para la informática científica para bash.
Es por eso que me gustaría saber si `/ bin / bash` podría no devolver nada, o devolver un shell que no sea bash (he visto un problema de este tipo solo una vez con alguna distribución bioinformática oscura).
No haría "computación científica" en un caparazón sin importar el caparazón que fuera. El caparazón debe usarse para, como máximo, manipular la plomería para aplicaciones y servicios básicos. La informática debe ser manejada por utilidades y aplicaciones diseñadas para esas tareas.
@Kusalananda ¿Cómo se hace la informática científica sin shell? Creo que lo usas al menos para ejecutar tus programas. Si es así, ¿está de acuerdo en que la forma en que maneja los errores es importante?
@Karel No haría computación de ningún tipo _sin_ un shell, pero no _in_ (con) un shell.
Estoy un poco desconcertado por qué esta respuesta recomienda el antiguo Bash 3 en lugar de Bash 4, que ahora tiene casi 10 años (anunciado en 2009). Bash 3 carece de características cruciales como matrices asociativas, por lo que es una restricción severa. Es cierto que macOS todavía se envía con Bash 3, pero ¿y qué? En general, se sabe que macOS se queda atrás en sus herramientas de Unix (e incluso en Ruby y Python). Además, quisquilloso: es "Bash", no "BASH".
@KonradRudolph Gracias por el comentario. Arreglé el problema de las mayúsculas. Con respecto a Bash 4, estoy completamente de acuerdo en que tiene muchas características útiles. Sin embargo, si no se puede usar en una proporción sustancial de máquinas, es un problema fatal. Mientras que Python 3 se puede instalar fácilmente (por ejemplo, usando Conda), actualizar Bash es complicado y fácilmente da como resultado problemas graves. En cuanto a las matrices asociativas, el estándar de Google dice lo siguiente: "Si encuentra que necesita usar matrices para algo más que la asignación de $ {PIPESTATUS}, debe usar Python".
@Karel Tengo algunas palabras de elección para las pautas de codificación de Google, ninguna de las cuales es aceptable en una compañía educada. De todos modos, actualizar Bash es realmente trivial. Reemplazarlo por el * shell de inicio de sesión * puede no serlo, pero en la práctica eso es innecesario: en macOS, especifica el shell en la aplicación de terminal, y otros sistemas se envían con Bash 4.
totalmente de acuerdo con @Kusalananda, tratando de escribir sus pipelines completamente * en * shell es un error. Hay muchos [marcos de flujo de trabajo] (https://github.com/common-workflow-language/common-workflow-language/wiki/Existing-Workflow-systems); Soy parcial con Nextflow, y muchos de mis compañeros usan Snakemake. Las canalizaciones completamente basadas en shell se vuelven rápidamente inmanejables, demasiado complejas, confusas de entender y extremadamente difíciles de depurar. Si * debe * usar Bash, entonces debe apuntar a implementaciones compatibles con POSIX.
Además, una gran cantidad de código Bash horrible para scripts más simples se puede lograr mejor con Makefiles. Para los principiantes, debe intentar aprender a usarlos después de que se sienta cómodo con las secuencias de comandos básicas de shell.
#3
+7
Kusalananda
2017-06-02 11:54:02 UTC
view on stackexchange narkive permalink

Las especificaciones básicas de Open Group Issue 7IEEE Std 1003.1 ™ -2008, 2016 Edition, o "El estándar POSIX" para abreviar, es el estándar que define las interfaces y utilidades proporcionadas por un sistema Unix. Entre estos se encuentran el lenguaje y las herramientas de la línea de comandos (consulte "Utilidades de Shell &" en el índice principal de la página vinculada arriba).

Hasta donde yo sé, no hay un shell que implemente exactamente lo que especifica el estándar, pero tanto bash como ksh93 hacen un buen trabajo adhiriéndose al estándar junto con sus propias extensiones, a veces conflictivas. El shell ksh93 en particular ha tenido un gran impacto en el desarrollo pasado de la especificación del shell POSIX, pero las especificaciones POSIX futuras pueden tomar prestado más de bash debido a su amplio uso en Linux.

El shell bash es bastante ubicuo en los sistemas Linux, y también puede instalarse en todos los demás Unices. ksh93 también está disponible para la mayoría de Unices, pero generalmente no se instala de forma predeterminada en Linux. ksh93 está disponible de forma predeterminada en al menos macOS (como ksh ) y Solaris.

Si le preocupa la portabilidad al escribir un script de shell (que En mi humilde opinión, es algo bueno para preocuparse), debe asegurarse de usar solo las utilidades POSIX y sus indicadores de línea de comando POSIX, así como solo usar la sintaxis de shell POSIX. Luego, debe asegurarse de que su script sea ejecutado por / bin / sh , que se supone que es un shell que comprende la especificación POSIX. / bin / sh a menudo se implementa mediante bash que se ejecuta en "modo POSIX", pero también puede ser dash , ash o pdksh (o algo más) según el Unix que esté utilizando.

Para un usuario de Linux, la parte más difícil de escribir un script portátil a menudo no es el shell per se, sino la multitud de indicadores de línea de comandos no estándar proporcionados por la implementación GNU de las muchas utilidades del shell. Sin embargo, las coreutils GNU (utilidades de shell básicas) pueden, como bash , instalarse en todos los Unices.

También tenga en cuenta que bash , cuando se ejecuta en POSIX modo (ya sea cuando se invoca como / bin / sh o con su indicador de línea de comando --posix ), no es estricto sobre su conformidad con POSIX y puede aceptar algunas extensiones de sintaxis del estándar POSIX.

#4
+5
user172818
2017-06-01 20:44:33 UTC
view on stackexchange narkive permalink

No diría que bash es un "estándar", pero es probable que sea el shell de Unix más utilizado y esté disponible de forma predeterminada en la mayoría de las distribuciones modernas de Unix / Linux. Hay algunos otros shells más convenientes como zsh que son ampliamente compatibles con / bin / sh , pero no están tan disponibles. También existe C-shell y, en particular, su implementación de código abierto tcsh. C-shell es bastante diferente de bash. Hace más de diez años, vi que se usaba de vez en cuando, pero hoy en día, rara vez veo su uso, excepto por programadores de generaciones anteriores.

#5
+5
gringer
2017-06-02 08:42:33 UTC
view on stackexchange narkive permalink

El comando genérico sh es literalmente un estándar de la industria, un estándar POSIX, para ser precisos (IEEE 1003.2 y 1003.2a, disponibles para su compra por cientos de dólares en varios sitios web). En teoría, cualquier script que comience con #! / Bin / sh debe cumplir con este estándar. En la práctica, la mayoría de los sistemas Linux tienen un shell que se acerca a este estándar, pero tiene algunas peculiaridades y extensiones.

Los problemas surgen cuando estas peculiaridades y extensiones se convierten en una práctica estándar en los scripts de shell. El sistema operativo Debian cambió a dash como su shell sh para animar a la gente a dejar de usar "bashisms" en scripts de shell que no especificaban un shell en particular, es decir, aquellos que comenzaban con #! / bin / sh . El shell dash intenta cumplir con los estándares tanto como sea posible:

dash es el intérprete de comandos estándar del sistema. La versión actual del tablero está en proceso de ser cambiada para cumplir con las especificaciones POSIX 1003.2 y 1003.2a para el shell. Esta versión tiene muchas características que la hacen parecer similar en algunos aspectos al shell Korn, pero no es un clon del shell Korn (ver ksh (1)). Solo las funciones designadas por POSIX, más algunas extensiones de Berkeley, se están incorporando en este shell. Esta página de manual no pretende ser un tutorial o una especificación completa del shell.

No estoy familiarizado con las diferencias y, por lo general, trato de ceñirme al sh páginas de manual para instruirme con respecto a los scripts de shell correctos que cumplen con los estándares.

Tenga en cuenta que sh no es bash. Incluso en sistemas cuyo `/ bin / sh` apunta a` bash`, ser invocado como `sh` cambia el comportamiento de bash y hace que se ejecute en modo compatible con POSIX. El shell "real" `sh` (bourne shell) es otra cosa y no es lo mismo que` bash` (bourne again shell).
En Debian, el shell interactivo predeterminado, es decir, el que usará en la línea de comandos es bash https://wiki.debian.org/Shell sí `/ bin / sh` se vinculará simbólicamente a` / bin / dash` pero el que la gente usará en vivo será bash.


Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 3.0 bajo la que se distribuye.
Loading...