Frage:
Verwenden Sie andere Muscheln als Bash
EMiller
2017-06-01 20:29:48 UTC
view on stackexchange narkive permalink

Als jemand, der anfängt, sich mit Bioinformatik zu beschäftigen, stelle ich fest, dass es hier wie in der Biologie Industriestandards gibt, ähnlich wie in Illumina in Genomik und Fliege für die Ausrichtung. Viele Leute verwenden Bash als Shell.

Wird die Verwendung einer Shell neben Bash Probleme für mich verursachen?

Ich würde die von Ihnen angegebenen Beispiele anpassen. Illumina ist ein Standard für kurze Lesevorgänge, aber es gibt viele Genomiklabors, die hauptsächlich mit PacBio oder Nanopore arbeiten. Fliege ist kaum ein Standard. Auch die Versionen 1 und 2 sind sehr unterschiedlich.
@burger was schlagen Sie dann vor?
Kein Vorschlag. Obwohl ich bisher allen Antworten zustimme, ist Bioinformatik nicht gut mit Standards. Sogar so etwas wie eine SAM / BAM-Datei, die technisch gesehen ein genau definierter Standard ist, den fast jeder in der Genomik verwendet, hat viele Felder, die unterschiedlich behandelt werden, was bei vielen Tools zu Problemen führt.
Eine Aussage "das ist nicht dazu gedacht, eine Meinung zu haben" hilft bei einer so breiten Frage wie dieser nicht viel. Haben Sie eine bestimmte Anwendung, für die Sie eine Shell verwenden möchten, oder einen Hinweis darauf, für welche "Branche" Sie sich interessieren?
@burger: Haben Sie bestimmte problematische SAM / BAM-Felder im Sinn? Sie könnten Probleme unter https://github.com/samtools/hts-specs/issues ansprechen, oder zumindest schlägt dies eine andere Frage vor, die Sie hier stellen sollten…
@JohnMarshall Ich glaube nicht, dass es einen "Fehler" mit dem SAM / BAM-Standard gibt. Es ist nur so, dass es offen ist und verschiedene Tools unterschiedliche Felder erfordern. Ich musste meine BAM-Dateien in der Vergangenheit viele Male ändern, weil ein Tool dies in einem etwas anderen Format erwartet hatte. Technisch gesehen ist es vorher und nachher immer noch eine gültige BAM, aber eine ist kompatibel und eine nicht. Wenn Sie eine BAM haben, wissen Sie nicht, ob sie mit einem Tool funktioniert, für das eine BAM-Datei erforderlich ist.
@burger: Wenn Sie möchten, dass sich diese Situation verbessert, müssen Sie angeben, welche Felder Sie ändern mussten und welche Erwartungen die verschiedenen Tools hatten. Wenn Sie dies tun, können die Spezifikationen geklärt, die Tools geändert und die Bioinformatik-Pipelines aller Benutzer etwas reibungsloser ausgeführt werden. Ansonsten ist es nur FUD.
VCF dagegen… :-)
Fünf antworten:
John Marshall
2017-06-01 20:53:21 UTC
view on stackexchange narkive permalink

In Shell und anderen Shell-Skripten geschriebene Bioinformatik-Tools geben im Allgemeinen die Shell an, die sie verwenden möchten (über #! / bin / sh oder z. B. #! / bin / bash Wenn es darauf ankommt), wird dies nicht von Ihrer Wahl der Benutzer-Shell beeinflusst.

Wenn Sie selbst wichtige Shell-Skripte schreiben, gibt es Gründe, dies in einer Shell im Bourne-Stil zu tun. Siehe Csh-Programmierung als schädlich und andere Aufsätze / Polemiken.

Eine Shell im Bourne-Stil ist so ziemlich der Industriestandard, und wenn Sie eine wesentlich andere Shell wählen, müssen Sie dies tun Übersetzen Sie einen Teil der Dokumentation Ihrer Bioinformatik-Tools. Es ist nicht ungewöhnlich, dass Dinge wie

einige Variablen festlegen, die auf Referenzdaten zeigen, und das Skript zu Ihrem PATH hinzufügen, um es auszuführen: 

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

Diese werden normalerweise in der Bourne-Shell-Syntax angezeigt. Wenn Sie eine andere Shell verwenden, müssen Sie die Befehle export in Ihre lokale Syntax übersetzen, und insbesondere das Munging von PATH ist etwas von der Shell abhängig.

Wenn Sie mit Unix vertraut sind, ist dies der Fall wird nur ein kleines Problem sein. Wenn Sie ein Anfänger sind, wird dies meiner Meinung nach eine nicht zu vernachlässigende Reibung zusätzlich zu all den anderen Dingen, die Sie lernen, hinzufügen.

** Verwenden Sie nicht `#! / Bin / bash` im Shebang. Die Installation von Bash an einem nicht standardmäßigen Ort ist häufig genug, damit dies häufig nicht funktioniert. Verwenden Sie stattdessen "#! / Usr / bin / env bash", es sollte keinen Nachteil haben.
Karel Brinda
2017-06-01 20:59:23 UTC
view on stackexchange narkive permalink

TL; DR

SH entspricht einem offiziellen Industriestandard, ist jedoch nicht für wissenschaftliche Berechnungen geeignet. Bash wird als informeller Standard angesehen (z. B. von Google). Bash 3 ist in den meisten Situationen in der Welt der Bioinformatik vorzuziehen.

Lange Antwort

Wie bereits in anderen Antworten beschrieben, ist SH ( / bin / sh (einfache Bourne-Shell, die ursprüngliche UNIX-Shell) sollte POSIX, einem echten Industriestandard, vollständig entsprechen. SH ist jedoch für wissenschaftliche Berechnungen zu begrenzt, da viele wichtige Funktionen später in SH-Nachfolgern integriert wurden, insbesondere in Bash ( / bin / bash , Bourne Again Shell): set -o pipefail , [[...]] oder Prozessersetzungen < () , um nur einige zu nennen.

In der Praxis ist es viel Es ist schwieriger, "sichere" Skripte in reinem SH zu schreiben, und nur Shell-Experten sind normalerweise in der Lage, unerwartetes Verhalten zu verhindern. Beispielsweise kann es schwierig sein, sicherzustellen, dass während der Berechnung kein Befehl in einer Pipeline fehlgeschlagen ist. Für Bash wurden verschiedene leicht zu befolgende Empfehlungen für die defensive Programmierung entwickelt, die all diese Probleme verhindern sollen. Aus diesem Grund verwenden viele Informatiker, Softwareentwickler und Unternehmen Bash als eine Art Standard. Beispielsweise erlaubt die interne Richtlinie von Google, dass nur Bash Shell-Skripte schreibt.

Obwohl wir nicht erwarten können, dass Bash auf jedem Unix-Computer vollständig vorhanden ist (z. B. auf Mobilgeräten, wie @terdon hervorhob), sollte es eine große Mehrheit der für wissenschaftliche Berechnungen verwendeten * nix-Computer haben. Wir sollten uns auch der Tatsache bewusst sein, dass Bash langsamer als SH sein kann und kürzlich unter großen Sicherheitsproblemen gelitten hat. Darüber hinaus gibt es verschiedene Bash-Versionen, und Skripte, die auf modernen Linux-Computern mit Bash 4 funktionieren, funktionieren möglicherweise nicht unter OS X, das immer noch auf Bash 3 basiert.

Zusammenfassend: Bash 3 ist wahrscheinlich die vernünftigste Wahl für wissenschaftliches Rechnen.

Bearbeiten

Ich habe die Kommentare von @terdon und @John Marshall angesprochen. Insbesondere habe ich eine Erklärung hinzugefügt, warum Bash für wissenschaftliches Rechnen besser geeignet ist als SH (meiner Meinung nach).

Bash ist nicht in jedem Unix-Rechner vorhanden, sh ist und das ist nicht dasselbe. Ja, Linux neigt dazu, `/ bin / sh` auf bash zu zeigen, aber Linux ist nicht Unix und auch unter Linux ist` / bin / sh` nicht immer` bash` (Debian-basierte Systeme verwenden stattdessen stattdessen dash ). Sie können sicher erwarten, dass die Bourne-Shell (sh) auf einem POSIX-kompatiblen System vorhanden ist, aber nicht unbedingt die Bourne-Again-Shell (bash).
@terdon Könnten Sie bitte eine Referenz angeben? Laut https://wiki.debian.org/Bash ist bash die Standard-Shell unter Debian. Kennen Sie eine (moderne) * nix-Distribution, in der bash nicht installiert wäre?
@terdon Ich werde meine Frage beantworten - z. B. FreeBSD. https://www.freebsd.org/doc/en/articles/linux-users/shells.html besagt, dass "Bash nicht in der Standardinstallation enthalten ist". Haben Sie ein Beispiel für eine Linux-Distribution ohne Bash?
Einige (alle?) Embedded Linux-Systeme haben keine Bash und stattdessen Busybox sh. Das Hauptproblem ist, dass die Leute denken, dass "sh" und "bash" dasselbe sind, aber sie sind es nicht. Sie sind ähnlich und bash ist eine Erweiterung von sh, aber sie sind nicht gleich.
@Karel: Die Frage nach der „Standard-Shell“ ist nicht eindeutig. Gemäß https://wiki.debian.org/Shell ist heutzutage unter Debian der Standardwert "/ bin / sh" ein Strich, während die Standard-Anmeldeshell (wie in "/ etc / passwd" aufgeführt) "/ bin / bash" bleibt `. Dies bedeutet, dass tragbare Shell-Skripte, die sich mit "#! / Bin / sh" identifizieren, sich auf POSIX-Shell-Funktionen beschränken müssen, während Skripte, die Bash-Erweiterungen verwenden möchten, "#! / Bin / bash" verwenden müssen. Dies wurde vor einigen Jahren auf die harte Tour aufgeräumt, als verschiedene Distributionen auf "/ bin / sh" umstellten ...
@terdon @John Marshall Vielen Dank für Ihre Kommentare. Im Vergleich zu Bash halte ich "pure" sh für sehr begrenzt und ungeeignet für das wissenschaftliche Rechnen, insbesondere wegen einiger fehlender, aber sehr wichtiger Funktionen wie "set -o pipefail" oder "[[...]]". Ich habe die Erfahrung gemacht, dass Sh-Skripte sehr anfällig für unerwartetes Verhalten sein können (es sei denn, der Entwickler ist ein Shell-Experte, was in der Bioinformatik normalerweise nicht der Fall ist). Für Bash gibt es mehrere gute und einfache defensive Programmierstrategien für das wissenschaftliche Rechnen.
Aus diesem Grund möchte ich wissen, ob `/ bin / bash` möglicherweise nichts zurückgibt oder eine Nicht-Bash-Shell zurückgibt (ich habe ein solches Problem nur einmal bei einer obskuren Verteilung der Bioinformatik gesehen).
Ich würde kein "wissenschaftliches Rechnen" in einer Shell durchführen, egal um welche Shell es sich handelt. Die Hülle sollte höchstens für die Handhabung der Rohrleitungen für grundlegende Dienstprogramme und Anwendungen verwendet werden. Die Datenverarbeitung sollte von Dienstprogrammen und Anwendungen durchgeführt werden, die für diese Aufgaben entwickelt wurden.
@Kusalananda Wie macht man wissenschaftliches Rechnen ohne Shell? Ich glaube, dass Sie es zumindest zum Ausführen Ihrer Programme verwenden. Wenn ja, stimmen Sie zu, dass die Art und Weise, wie mit Fehlern umgegangen wird, von Bedeutung ist?
@Karel Ich würde keinerlei Daten ohne Shell ausführen, aber nicht mit einer Shell.
Ich bin ein bisschen verwirrt, warum diese Antwort den alten Bash 3 anstelle von Bash 4 empfiehlt, der selbst jetzt fast 10 Jahre alt ist (angekündigt im Jahr 2009). In Bash 3 fehlen wichtige Funktionen wie assoziative Arrays, sodass dies eine schwerwiegende Einschränkung darstellt. MacOS wird zwar immer noch mit Bash 3 ausgeliefert, aber was nun? Es ist allgemein bekannt, dass macOS in seinen Unix-Tools (und sogar in Ruby und Python) zurückbleibt. Nitpick: Es ist "Bash", nicht "BASH".
@KonradRudolph Vielen Dank für den Kommentar. Ich habe das Kapitalisierungsproblem behoben. In Bezug auf Bash 4 stimme ich voll und ganz zu, dass es viele nützliche Funktionen hat. Wenn es jedoch nicht auf einem wesentlichen Teil der Maschinen verwendet werden kann, ist dies ein schwerwiegendes Problem. Während Python 3 einfach installiert werden kann (z. B. mit Conda), ist das Upgrade von Bash kompliziert und führt leicht zu schwerwiegenden Problemen. In Bezug auf die assoziativen Arrays lautet der Google-Standard Folgendes: "Wenn Sie feststellen, dass Sie Arrays für mehr als die Zuweisung von $ {PIPESTATUS} verwenden müssen, sollten Sie Python verwenden."
@Karel Ich habe ein paar ausgewählte Wörter für die Google-Codierungsrichtlinien, von denen keines in höflicher Gesellschaft akzeptabel ist. Wie auch immer, ein Upgrade von Bash ist eigentlich trivial. Das Ersetzen für die * Login-Shell * ist möglicherweise nicht erforderlich, in der Praxis jedoch nicht erforderlich: Unter macOS geben Sie die Shell in der Terminal-App an, und andere Systeme werden mit Bash 4 ausgeliefert.
stimme voll und ganz mit @Kusalananda, überein, dass der Versuch, deine Pipelines vollständig * in * Shell zu schreiben, ein Fehler ist. Es gibt viele [Workflow-Frameworks] (https://github.com/common-workflow-language/common-workflow-language/wiki/Existing-Workflow-systems); Ich bin ein Teil von Nextflow und viele meiner Kollegen verwenden Snakemake. Vollständig Shell-basierte Pipelines werden schnell unüberschaubar, übermäßig komplex, verwirrend zu verstehen und äußerst schwierig zu debuggen. Wenn Sie Bash * verwenden * müssen, sollten Sie POSIX-kompatible Implementierungen anstreben.
Außerdem kann mit Makefiles viel schrecklicher Bash-Code für einfachere Skripte besser ausgeführt werden. Für Anfänger sollten Sie lernen, wie man diese verwendet, nachdem Sie sich mit grundlegenden Shell-Skripten vertraut gemacht haben.
Kusalananda
2017-06-02 11:54:02 UTC
view on stackexchange narkive permalink

Die Open Group Base-Spezifikationen, Ausgabe 7IEEE Std 1003.1 ™ -2008, Ausgabe 2016, oder kurz "The POSIX Standard", ist der Standard, der die von einem Unix-System bereitgestellten Schnittstellen und Dienstprogramme definiert. Dazu gehören die Befehlszeilen-Shell-Sprache und -Tools (siehe "Shell & Utilities" im Hauptindex auf der oben verlinkten Seite).

Soweit ich weiß, gibt es keine Shell, die implementiert genau , was vom Standard festgelegt wird, aber sowohl bash als auch ksh93 leisten einen ziemlich guten Beitrag zur Einhaltung des Standards zusammen mit ihren eigenen, manchmal widersprüchlichen Erweiterungen. Insbesondere die ksh93 -Shell hatte einen großen Einfluss auf die frühere Entwicklung der POSIX-Shell-Spezifikation, aber zukünftige POSIX-Spezifikationen können mehr von bash ausleihen Aufgrund seiner weit verbreiteten Verwendung unter Linux.

Die bash -Shell ist auf Linux-Systemen nahezu allgegenwärtig und kann auch auf allen anderen Unices installiert werden. ksh93 ist auch für die meisten Unices verfügbar, wird jedoch normalerweise nicht standardmäßig unter Linux installiert. ksh93 ist standardmäßig unter mindestens macOS (als ksh ) und Solaris verfügbar.

Wenn Sie beim Schreiben eines Shell-Skripts (welches) über die Portabilität besorgt sind Ist IMHO eine gute Sache, über die Sie sich Sorgen machen sollten), sollten Sie sicherstellen, dass Sie nur die POSIX-Dienstprogramme und ihre POSIX-Befehlszeilenflags sowie nur die POSIX-Shell-Syntax verwenden. Sie sollten dann sicherstellen, dass Ihr Skript von / bin / sh ausgeführt wird, einer Shell, die die POSIX-Spezifikation versteht. / bin / sh wird häufig durch bash implementiert, das im "POSIX-Modus" ausgeführt wird, es kann sich aber auch um dash , ash handeln code> oder pdksh (oder etwas anderes), je nachdem, welches Unix Sie verwenden.

Für einen Linux-Benutzer ist das Schwierigste beim Schreiben eines tragbaren Skripts häufig nicht die Shell an sich, sondern die Vielzahl von nicht standardmäßigen Befehlszeilenflags, die von der GNU-Implementierung der vielen Shell-Dienstprogramme bereitgestellt werden. Die GNU-Coreutils (grundlegende Shell-Dienstprogramme) können jedoch wie bash auf allen Unices installiert werden.

Beachten Sie auch, dass bash unter POSIX ausgeführt wird Der Modus (entweder beim Aufrufen als / bin / sh oder mit dem Befehlszeilenflag --posix ) ist hinsichtlich seiner POSIX-Konformität und nicht streng akzeptiert möglicherweise einige Syntaxerweiterungen des POSIX-Standards.

user172818
2017-06-01 20:44:33 UTC
view on stackexchange narkive permalink

Ich würde Bash nicht als "Standard" bezeichnen, aber es ist wahrscheinlich die am weitesten verbreitete Unix-Shell und standardmäßig auf den meisten modernen Unix / Linux-Distributionen verfügbar. Es gibt einige andere bequemere Shells wie zsh, die weitgehend mit / bin / sh kompatibel sind, aber nicht so weit verbreitet sind. Es gibt auch C-Shell und insbesondere die Open-Source-Implementierung tcsh. C-Shell ist ganz anders als Bash. Vor über zehn Jahren habe ich gesehen, dass es von Zeit zu Zeit verwendet wurde, aber heutzutage sehe ich es nur noch selten, außer von Programmierern älterer Generationen.

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

Der generische Befehl sh ist buchstäblich ein Industriestandard, genauer gesagt ein POSIX-Standard (IEEE 1003.2 und 1003.2a, erhältlich für Hunderte von Dollar auf verschiedenen Websites). Theoretisch sollte jedes Skript, das mit #! / Bin / sh beginnt, diesem Standard entsprechen. In der Praxis haben die meisten Linux-Systeme eine Shell, die diesem Standard nahe kommt, jedoch einige Macken und Erweiterungen aufweist.

Probleme treten auf, wenn diese Macken und Erweiterungen in Shell-Skripten zur Standardpraxis werden. Das Debian-Betriebssystem wurde in dash als sh -Shell geändert, um die Benutzer zu ermutigen, die Verwendung von "Bashisms" in Shell-Skripten zu beenden, in denen keine bestimmte Shell angegeben wurde, dh in den begonnenen mit #! / bin / sh . Die dash -Shell versucht, so standardkonform wie möglich zu sein:

dash ist der Standardbefehlsinterpreter für das System. Die aktuelle Version von dash wird derzeit geändert, um den POSIX 1003.2- und 1003.2a-Spezifikationen für die Shell zu entsprechen. Diese Version hat viele Funktionen, die sie in gewisser Hinsicht der Korn-Shell ähnlich erscheinen lassen, aber es ist kein Korn-Shell-Klon (siehe ksh (1)). In diese Shell werden nur von POSIX bezeichnete Funktionen sowie einige Berkeley-Erweiterungen integriert. Diese Manpage ist nicht als Tutorial oder vollständige Spezifikation der Shell gedacht.

Ich bin mit den Unterschieden nicht vertraut und versuche im Allgemeinen, mich an den sh Manpages, um mich in Bezug auf korrekte standardkonforme Shell-Skripte zu unterweisen.

Beachten Sie, dass sh nicht bash ist. Selbst auf Systemen, deren `/ bin / sh` auf` bash` zeigt, ändert das Aufrufen als` sh` das Verhalten von bash und führt dazu, dass es im POSIX-kompatiblen Modus ausgeführt wird. Die "echte" `sh` Shell (Bourne Shell) ist wieder etwas anderes und nicht dasselbe wie` bash` (Bourne Again Shell).
In Debian ist die standardmäßige interaktive Shell, dh die, die Sie in der Befehlszeile verwenden, bash https://wiki.debian.org/Shell yes `/ bin / sh` wird mit` / bin / dash` verknüpft Aber derjenige, den die Leute live benutzen werden, wird Bash sein.


ⓘ
Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...