Domanda:
Usare shell diverse da bash
EMiller
2017-06-01 20:29:48 UTC
view on stackexchange narkive permalink

Come qualcuno che sta iniziando ad approfondire la bioinformatica, sto notando che come la biologia ci sono standard di settore qui, simili a Illumina in genomica e papillon per l'allineamento, molte persone usano bash come conchiglia.

Usare una shell oltre a bash mi causerà problemi?

Modificherei gli esempi che hai fornito. Illumina è uno standard per letture brevi, ma ci sono molti laboratori di genomica che lavorano principalmente con PacBio o Nanopore. Il papillon non è certo uno standard. Anche le versioni 1 e 2 sono molto diverse.
@burger cosa suggerisci allora?
Nessun suggerimento. Anche se sono d'accordo con tutte le risposte finora, la bioinformatica non è buona con gli standard. Anche qualcosa come un file SAM / BAM che è tecnicamente uno standard definito correttamente che quasi tutti in genomica utilizza hanno molti campi che vengono trattati in modo diverso, causando problemi a molti strumenti.
Un'affermazione "questo non deve essere supponente" non aiuta molto con una domanda così ampia come questa. Hai una particolare applicazione per la quale vorresti usare una shell, o un'indicazione di quale "settore" ti interessa?
@burger: Hai in mente specifici campi SAM / BAM problematici? Potresti sollevare problemi su https://github.com/samtools/hts-specs/issues o almeno questo suggerisce un'altra domanda da porre qui ...
@JohnMarshall Non credo che ci sia un "bug" con lo standard SAM / BAM. È solo che è aperto e strumenti diversi richiedono campi diversi. Ho dovuto modificare i miei file BAM molte volte in passato perché alcuni strumenti lo prevedevano in un formato leggermente diverso. Tecnicamente, è ancora un BAM valido prima e dopo, ma uno è compatibile e l'altro no. Se hai un BAM, non hai idea se funzionerà con uno strumento che richiede un file BAM.
@burger: Se vuoi che questa situazione migliori, dovrai dire quali campi particolari hai dovuto modificare e quali erano le aspettative dei vari strumenti. Se lo fai, le specifiche possono essere chiarite, gli strumenti possono essere modificati e le pipeline di bioinformatica di tutti possono funzionare un po 'più agevolmente. Altrimenti, è solo FUD.
VCF d'altra parte ... :-)
Cinque risposte:
#1
+18
John Marshall
2017-06-01 20:53:21 UTC
view on stackexchange narkive permalink

Gli strumenti bioinformatici scritti nella shell e altri script di shell generalmente specificano la shell che vogliono usare (tramite #! / bin / sh o ad esempio #! / bin / bash se è importante), quindi non sarà influenzato dalla scelta della shell utente.

Se stai scrivendo script di shell significativi, ci sono ragioni per farlo in una shell in stile Bourne. Vedi Csh Programming Considered Harmful e altri saggi / polemiche.

Una shell in stile Bourne è praticamente lo standard del settore e se scegli una shell sostanzialmente diversa dovrai traduci parte della documentazione dei tuoi strumenti bioinformatici. Non è raro avere cose come

Imposta alcune variabili che puntano a dati di riferimento e aggiungi lo script al tuo PATH per eseguirlo:

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

Questi saranno tipicamente mostrati nella sintassi della Bourne-shell. Usando una shell diversa devi tradurre i comandi export nella tua sintassi locale, e specialmente il munging PATH dipende in qualche modo dalla shell.

Se hai esperienza in Unix, questo sarà solo un piccolo inconveniente. Se sei un principiante, IMHO questo aggiungerà una quantità di attrito non trascurabile in cima a tutte le altre cose che stai imparando.

** Non ** usare "#! / Bin / bash" nello shebang. Avere Bash installato in una posizione non standard è abbastanza comune che farlo si romperà spesso. Usa invece "#! / Usr / bin / env bash", non dovrebbe avere alcuno svantaggio.
#2
+11
Karel Brinda
2017-06-01 20:59:23 UTC
view on stackexchange narkive permalink

SH aderisce a uno standard industriale ufficiale, ma non è adatto per il calcolo scientifico. Bash è considerato uno standard informale (ad esempio, da Google). Bash 3 è preferibile nella maggior parte delle situazioni nel mondo della bioinformatica.

Risposta lunga

Come già descritto in altre risposte, SH ( / bin / sh , semplice shell Bourne, la shell UNIX originale) dovrebbe aderire completamente a POSIX che è un vero standard del settore. Tuttavia, SH è troppo limitato per il calcolo scientifico poiché molte funzionalità chiave sono state incorporate successivamente nei successori di SH, specialmente in Bash ( / bin / bash , Bourne Again Shell): set -o pipefail , [[...]] o sostituzioni di processo < () per citarne almeno alcune.

In pratica, è molto è più difficile scrivere script "sicuri" in SH puro e solo gli esperti di shell sono generalmente in grado di prevenire comportamenti imprevisti. Ad esempio, potrebbe essere difficile garantire che nessun comando in una pipeline abbia avuto esito negativo durante il calcolo. Per Bash, sono state sviluppate varie raccomandazioni di programmazione difensiva facili da seguire e dovrebbero prevenire tutti questi problemi. Per questo motivo, molti informatici, ingegneri del software e aziende utilizzano Bash come una sorta di standard. Ad esempio, la politica interna di Google consente solo Bash per la scrittura di script di shell.

Anche se non possiamo aspettarci che Bash sia presente completamente su ogni macchina Unix (ad esempio, su dispositivi mobili come ha sottolineato @terdon), la stragrande maggioranza delle macchine * nix usate per il calcolo scientifico dovrebbe averlo. Dobbiamo anche essere consapevoli del fatto che Bash può essere più lento di SH e che recentemente ha sofferto di importanti problemi di sicurezza. Inoltre, esistono varie versioni di Bash e gli script che funzionano su moderne macchine Linux con Bash 4 potrebbero non funzionare su OS X, che è ancora basato su Bash 3.

Per riassumere, Bash 3 è probabilmente la scelta più ragionevole per il calcolo scientifico.

Ho risposto ai commenti di @terdon e @John Marshall. In particolare, ho aggiunto una spiegazione del perché Bash è più adatto per il calcolo scientifico rispetto a SH (a mio parere).

Bash non è presente in tutte le macchine Unix, "sh" lo è e non è la stessa cosa. Sì, Linux tende ad avere `/ bin / sh` che punta a bash, ma Linux non è Unix e, comunque, anche in Linux` / bin / sh` non è sempre `bash` (i sistemi basati su Debian usano invece il trattino, per esempio ). Ci si può tranquillamente aspettare che la Bourne shell (sh) sia presente su un sistema conforme a POSIX, ma non necessariamente la Bourne again shell (bash).
@terdon Potreste fornire qualche riferimento, per favore? Secondo https://wiki.debian.org/Bash, bash è la shell predefinita in Debian. Conosci qualche distro (moderna) * nix in cui bash non sarebbe installato?
@terdon Risponderò alla mia domanda - ad esempio, FreeBSD. https://www.freebsd.org/doc/en/articles/linux-users/shells.html dice che "Bash non è incluso nell'installazione predefinita". Hai un esempio di una distribuzione Linux senza bash?
Alcuni (tutti?) Sistemi Linux incorporati non avranno bash e avranno invece busybox sh. Il problema principale è che le persone tendono a pensare che "sh" e "bash" siano la stessa cosa ma non lo sono. Sono simili e bash è un'estensione di sh, ma non sono la stessa cosa.
@Karel: Chiedere informazioni sulla "shell predefinita" è ambiguo. Come per https://wiki.debian.org/Shell, in questi giorni su Debian l'impostazione predefinita `/ bin / sh` è un trattino mentre la shell di accesso predefinita (come elencata in` / etc / passwd`) rimane `/ bin / bash ". Ciò significa che gli script di shell portatili che si identificano con `#! / Bin / sh` devono limitarsi alle strutture della shell POSIX, mentre gli script che vogliono usare le estensioni bash devono usare` #! / Bin / bash`. Questo è stato sistemato nel modo più duro alcuni anni fa quando varie distribuzioni sono passate al trattino per `/ bin / sh` ...
@terdon @John Marshall Grazie per i tuoi commenti. Rispetto a bash, considero sh "puro" molto limitato e inappropriato per il calcolo scientifico, in particolare a causa di alcune caratteristiche mancanti, ma molto importanti, come `set -o pipefail` o` [[...]] `. La mia esperienza è che gli script sh possono essere molto suscettibili a comportamenti imprevisti (a meno che lo sviluppatore non sia un esperto di shell, cosa che di solito non è il caso della bioinformatica). Esistono diverse buone e semplici strategie di programmazione difensiva per il calcolo scientifico per bash.
Questo è il motivo per cui vorrei sapere se `/ bin / bash` potrebbe non restituire nulla, o restituire una shell non bash (ho visto un problema del genere solo una volta con qualche oscura distribuzione bioinformatica).
Non farei "calcolo scientifico" in una shell, non importa quale sia la shell. Il guscio dovrebbe essere utilizzato, al massimo, per la gestione delle tubature per utilità e applicazioni di base. L'elaborazione dovrebbe essere gestita da utilità e applicazioni progettate per tali attività.
@Kusalananda Come si fa il calcolo scientifico senza shell? Credo che lo usi almeno per eseguire i tuoi programmi. Se è così, sei d'accordo che il modo in cui gestisce gli errori è importante?
@Karel Non farei calcoli di alcun tipo _senza_ una shell, ma non _in_ (con) una shell.
Sono un po 'perplesso perché questa risposta consiglia l'antico Bash 3 invece di Bash 4, che a sua volta ha quasi 10 anni (annunciato nel 2009). Bash 3 manca di funzionalità cruciali come gli array associativi, quindi è una grave restrizione. È vero, macOS viene ancora fornito con Bash 3, ma allora? macOS è generalmente noto per essere in ritardo nei suoi strumenti unix (e anche per i suoi Ruby e Python). Inoltre, nitpick: è "Bash", non "BASH".
@KonradRudolph Grazie per il commento. Ho risolto il problema delle maiuscole. Per quanto riguarda Bash 4, sono completamente d'accordo sul fatto che abbia molte funzioni utili. Tuttavia, se non può essere utilizzato su una parte sostanziale di macchine, è un problema fatale. Mentre Python 3 può essere facilmente installato (ad esempio, usando Conda), l'aggiornamento di Bash è complicato e provoca facilmente seri problemi. Per quanto riguarda gli array associativi, lo standard di Google dice quanto segue: "Se trovi che devi usare gli array per qualcosa di più dell'assegnazione di $ {PIPESTATUS}, dovresti usare Python."
@Karel Ho qualche parola di scelta per le linee guida di codifica di Google, nessuna delle quali è accettabile in compagnia educata. Ad ogni modo, l'aggiornamento di Bash è in realtà banale. Sostituirlo per la * shell di login * potrebbe non essere, ma in pratica non è necessario: su macOS specifichi la shell nell'app del terminale e altri sistemi vengono forniti con Bash 4.
sono assolutamente d'accordo con @Kusalananda, che provare a scrivere le tue pipeline interamente * in * shell è un errore. Esistono molti [framework di flusso di lavoro] (https://github.com/common-workflow-language/common-workflow-language/wiki/Existing-Workflow-systems); Sono parziale con Nextflow e molti dei miei colleghi usano Snakemake. Le pipeline interamente basate su shell diventano rapidamente ingestibili, eccessivamente complesse, confuse da comprendere ed estremamente difficili da eseguire il debug. Se * devi * usare Bash, allora dovresti mirare a implementazioni conformi a POSIX.
inoltre, un sacco di orribile codice Bash per script più semplici può essere realizzato meglio con i Makefile. Per i principianti, dovresti mirare a imparare come usarli dopo aver acquisito familiarità con gli script di shell di base.
#3
+7
Kusalananda
2017-06-02 11:54:02 UTC
view on stackexchange narkive permalink

The Open Group Base Specifications Issue 7IEEE Std 1003.1 ™ -2008, 2016 Edition, o "The POSIX Standard" in breve, è lo standard che definisce le interfacce e le utilità fornite da un sistema Unix. Tra questi c'è il linguaggio e gli strumenti della shell della riga di comando (vedi "Shell & Utilities" nell'indice principale della pagina collegata sopra).

Per quanto ne so, non esiste una shell che implementa esattamente ciò che è specificato dallo standard, ma sia bash che ksh93 fanno un buon lavoro aderendo allo standard insieme alle loro estensioni, a volte in conflitto. La shell ksh93 in particolare ha avuto un grande impatto sullo sviluppo passato della specifica della shell POSIX, ma le future specifiche POSIX potrebbero prendere in prestito di più da bash a causa del suo ampio utilizzo su Linux.

La shell bash è praticamente onnipresente sui sistemi Linux e può essere installata anche su tutti gli altri Unix. ksh93 è disponibile anche per la maggior parte degli Unix ma di solito non è installato di default su Linux. ksh93 è disponibile per impostazione predefinita almeno su macOS (come ksh ) e Solaris.

Se sei preoccupato per la portabilità quando scrivi uno script di shell (che è IMHO una buona cosa di cui preoccuparsi), dovresti assicurarti di utilizzare solo le utilità POSIX e le loro opzioni della riga di comando POSIX, oltre a utilizzare solo la sintassi della shell POSIX. Dovresti quindi assicurarti che lo script venga eseguito da / bin / sh che dovrebbe essere una shell che comprende le specifiche POSIX. / bin / sh è spesso implementato da bash in "modalità POSIX", ma può anche essere dash , ash o pdksh (o qualcos'altro) a seconda di quale Unix stai usando.

Per un utente Linux, la parte più difficile nella scrittura di uno script portatile spesso non è la shell in sé, ma la moltitudine di flag della riga di comando non standard forniti dall'implementazione GNU delle numerose utilità della shell. Tuttavia, i coreutils GNU (utilità di shell di base) possono, come bash , essere installati su tutti gli Unix.

Si noti inoltre che bash , quando viene eseguito in POSIX mode (sia quando invocato come / bin / sh o con il suo flag della riga di comando --posix ), non è rigoroso riguardo alla sua conformità POSIX e può accettare alcune estensioni di sintassi allo standard POSIX.

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

Non direi bash come "standard", ma in effetti è probabile che sia la shell unix più utilizzata e disponibile di default sulla maggior parte delle moderne distribuzioni unix / linux. Ci sono alcune altre shell più convenienti come zsh che sono ampiamente compatibili con / bin / sh , ma non sono così ampiamente disponibili. C'è anche la shell C e in particolare la sua implementazione open source tcsh. C-shell è abbastanza diverso da bash. Più di dieci anni fa, ho visto che veniva usato di tanto in tanto, ma oggigiorno lo vedo raramente, tranne che da programmatori di generazioni precedenti.

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

Il comando generico sh è letteralmente uno standard del settore, uno standard POSIX, per essere precisi (IEEE 1003.2 e 1003.2a, disponibili per l'acquisto per centinaia di dollari su vari siti web). In teoria, qualsiasi script che inizi con #! / Bin / sh dovrebbe essere conforme a questo standard. In pratica, la maggior parte dei sistemi Linux ha una shell che è vicina a questo standard, ma ha alcune stranezze ed estensioni.

I problemi sorgono quando queste stranezze ed estensioni diventano una pratica standard negli script di shell. Il sistema operativo Debian è cambiato in dash come shell sh per incoraggiare le persone a smettere di usare "bashismi" negli script di shell che non specificano una particolare shell, cioè quelli che hanno iniziato con #! / bin / sh . La shell dash cerca di essere il più conforme agli standard possibile:

dash è l'interprete dei comandi standard per il sistema. L'attuale versione di dash è in procinto di essere modificata per conformarsi alle specifiche POSIX 1003.2 e 1003.2a per la shell. Questa versione ha molte caratteristiche che la fanno sembrare simile per alcuni aspetti alla shell Korn, ma non è un clone della shell Korn (vedere ksh (1)). Solo le funzionalità designate da POSIX, più alcune estensioni di Berkeley, vengono incorporate in questa shell. Questa pagina man non vuole essere un tutorial o una specifica completa della shell.

Non ho familiarità con le differenze e generalmente cerco di attenermi a sh pagine di manuale per istruirmi riguardo agli script di shell conformi agli standard.

Nota che sh non è bash. Anche su sistemi in cui `/ bin / sh` punta a` bash`, essere invocato come `sh` cambia il comportamento di bash e lo fa funzionare in modalità conforme a POSIX. La "vera" shell `sh` (bourne shell) è un'altra cosa e non è la stessa di` bash` (bourne again shell).
In Debian la shell interattiva predefinita, ovvero quella che userete sulla riga di comando è bash https://wiki.debian.org/Shell sì `/ bin / sh` sarà collegato a` / bin / dash` ma quello che le persone useranno dal vivo sarà bash.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...