質問:
bash以外のシェルを使用する
EMiller
2017-06-01 20:29:48 UTC
view on stackexchange narkive permalink

バイオインフォマティクスを探求し始めている人として、生物学のように、ゲノミクスのイルミナやアライメント用のボウタイと同様に、多くの人がbashをシェルとして使用していることに気づいています。

bash以外のシェルを使用すると問題が発生しますか?

私はあなたが提供した例を調整します。イルミナは短い読み取りの標準ですが、多くのゲノミクスラボが主にPacBioまたはNanoporeを使用しています。ボウタイはほとんど標準ではありません。バージョン1と2でさえ非常に異なります。
@burgerでは、何を提案しますか?
提案はありません。私はこれまでのすべての答えに同意しますが、バイオインフォマティクスは標準に適していません。ゲノミクスのほとんどすべての人が使用する、技術的に適切に定義された標準であるSAM / BAMファイルのようなものでさえ、異なる方法で処理される多くのフィールドがあり、多くのツールで問題を引き起こします。
「これは意見を述べることを意図したものではない」という声明は、このような幅広い質問にはあまり役立ちません。シェルを使用したい特定のアプリケーション、または関心のある「業界」の指標がありますか?
@burger:特定の問題のあるSAM / BAMフィールドを念頭に置いていますか? https://github.com/samtools/hts-specs/issuesで問題を提起することができます。または、少なくともこれは、ここで尋ねる別の質問を示唆しています…
@JohnMarshall SAM / BAM標準に「バグ」はないと思います。それはオープンエンドであり、さまざまなツールがさまざまなフィールドを必要とするということだけです。一部のツールがわずかに異なる形式でBAMファイルを予期していたため、過去に何度もBAMファイルを変更する必要がありました。技術的には、それは前後でまだ有効なBAMですが、1つは互換性があり、もう1つは互換性がありません。 BAMを使用している場合、BAMファイルを必要とするツールで動作するかどうかはわかりません。
@burger:この状況を改善したい場合は、どの特定のフィールドを変更する必要があり、さまざまなツールの期待が何であったかを言う必要があります。これを行うと、仕様を明確にし、ツールを変更でき、すべての人のバイオインフォマティクスパイプラインをもう少しスムーズに実行できます。それ以外の場合は、FUDです。
一方、VCF…:-)
五 答え:
#1
+18
John Marshall
2017-06-01 20:53:21 UTC
view on stackexchange narkive permalink

シェルおよびその他のシェルスクリプトで記述されたバイオインフォマティクスツールは、通常、使用するシェルを指定します(#!/ bin / sh または#!/ bin / bash などを使用)重要な場合)、ユーザーシェルの選択による影響を受けません。

重要なシェルスクリプトを自分で作成している場合は、Bourneスタイルのシェルで作成する理由があります。 有害と見なされるCshプログラミングおよびその他のエッセイ/論争を参照してください。

ボーンスタイルのシェルはほとんど業界標準であり、大幅に異なるシェルを選択する場合は、バイオインフォマティクスツールのドキュメントの一部を翻訳します。

参照データを指すいくつかの変数を設定し、スクリプトをPATHに追加して実行することも珍しくありません。

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

これらは通常、Bourneシェル構文で表示されます。別のシェルを使用するには、 export コマンドをローカル構文に変換する必要があります。特に、PATHの変更はシェルに多少依存します。

Unixの経験がある場合は、これほんの少しの微笑になります。あなたが初心者の場合、私見ですが、これはあなたが学んでいる他のすべてのことに加えて、無視できない量の摩擦を追加します。

**シェバンで `#!/ bin / bash`を使用しないでください**。 Bashを非標準の場所にインストールすることは十分に一般的であるため、インストールすると頻繁に機能しなくなります。代わりに `#!/ usr / bin / enbbash`を使用してください。不利になることはありません。
#2
+11
Karel Brinda
2017-06-01 20:59:23 UTC
view on stackexchange narkive permalink

TL; DR

SHは公式の業界標準に準拠していますが、科学計算には適していません。 Bashは非公式の標準と見なされます(Googleなどによる)。 Bash 3は、バイオインフォマティクスの世界のほとんどの状況で推奨されます。

長い回答

他の回答ですでに説明したように、SH( / bin / sh 、プレーンBourneシェル、元のUNIXシェル)は、実際の業界標準であるPOSIXに完全に準拠している必要があります。ただし、SHは、SHの後継、特にBash( / bin / bash 、Bourne Again Shell)に多くの主要な機能が後で組み込まれたため、科学的なコンピューティングには制限が多すぎます。 set -o pipefail [[...]] 、またはプロセス置換 <()を使用して、少なくともいくつかの名前を付けます。

実際には、多くのことがあります。純粋なSHで「安全な」スクリプトを作成するのはより難しく、通常、予期しない動作を防ぐことができるのはシェルの専門家だけです。たとえば、パイプライン内のコマンドが計算の途中で失敗しないようにするのは難しい場合があります。 Bashについては、さまざまなわかりやすい防御プログラミングの推奨事項が作成されており、これらすべての問題を防ぐことができます。このため、多くのコンピューターサイエンティスト、ソフトウェアエンジニア、および企業は、一種の標準としてBashを使用しています。たとえば、Googleの内部ポリシーでは、シェルスクリプトの記述に Bashのみを許可しています。

Bashが完全にすべてのUnixマシンに存在することは期待できませんが(たとえば、@ terdonが指摘したようにモバイルデバイスに)、科学計算に使用される* nixマシンの大多数にBashが存在するはずです。また、BashはSHよりも低速である可能性があり、最近、重大なセキュリティの問題に悩まされていることにも注意する必要があります。さらに、さまざまなBashバージョンが存在し、 Bash 4を搭載した最新のLinuxマシンで動作するスクリプトはOSXでは動作しない可能性があります。OSXはまだBash3に基づいています。

要約すると、Bash科学計算にはおそらく3が最も合理的な選択です。

編集

@terdonと@JohnMarshallからのコメントに対応しました。特に、BashがSHよりも科学計算に適している理由の説明を追加しました(私の意見では)。

BashはすべてのUnixマシンに存在するわけではなく、 `sh`は存在し、それは同じではありません。はい、Linuxはbashを指す `/ bin / sh`を持つ傾向がありますが、LinuxはUnixではなく、とにかく、Linuxでも` / bin / sh`は必ずしも `bash`ではありません(たとえば、Debianベースのシステムは代わりにダッシュを使用します)。 Bourneシェル(sh)がPOSIX準拠のシステムに存在することは安全に期待できますが、必ずしもBourne againシェル(bash)である必要はありません。
@terdon参考資料を教えてください。 https://wiki.debian.org/Bashによると、bashはDebianのデフォルトのシェルです。 bashがインストールされない(最新の)* nixディストリビューションについて知っていますか?
@terdon私は私の質問に答えます-例えば、FreeBSD。 https://www.freebsd.org/doc/en/articles/linux-users/shells.htmlには、「Bashはデフォルトのインストールに含まれていません」と書かれています。 bashを使用しないLinuxディストリビューションの例はありますか?
一部の(すべて?)組み込みLinuxシステムにはbashがなく、代わりにbusyboxshがあります。主な問題は、「sh」と「bash」は同じものだと思われがちですが、そうではないということです。それらは類似しており、bashはshの拡張ですが、同じではありません。
@Karel:「デフォルトシェル」について尋ねるのはあいまいです。 https://wiki.debian.org/Shellによると、最近のDebianではデフォルトの `/ bin / sh`はダッシュですが、デフォルトのログインシェル(` / etc / passwd`にリストされている)は `/ bin / bashのままです`。つまり、 `#!/ bin / sh`で自分自身を識別するポータブルシェルスクリプトは、POSIXシェル機能に制限する必要がありますが、bash拡張機能を使用するスクリプトは`#!/ bin / bash`を使用する必要があります。これは、数年前にさまざまなディストリビューションが `/ bin / sh`のダッシュに切り替わったときに大変な方法で片付けられました…
@[email protected]マーシャルコメントありがとうございます。 bashと比較すると、「純粋な」shは非常に限定的であり、科学計算には不適切であると考えています。特に、 `set -opipefail`や` [[...]] `などの機能が欠落しているが、非常に重要であるためです。私の経験では、shスクリプトは予期しない動作の影響を非常に受けやすい可能性があります(開発者がシェルの専門家でない限り、バイオインフォマティクスでは通常そうではありません)。 bashには、科学計算のための優れた単純な防御プログラミング戦略がいくつか存在します。
これが、 `/ bin / bash`が何も返さないのか、それとも非bashシェルを返すのかを知りたい理由です(このような問題は、バイオインフォマティクスの分布があいまいな場合に一度だけ見たことがあります)。
シェルがどんなものであっても、シェルで「科学計算」を行うことはありません。シェルは、せいぜい、基本的なユーティリティやアプリケーションの配管を処理するために使用する必要があります。コンピューティングは、これらのタスク用に設計されたユーティリティとアプリケーションによって処理される必要があります。
@Kusalanandaシェルなしで科学計算をどのように行いますか?少なくともプログラムの実行には使用していると思います。もしそうなら、それがエラーを処理する方法が重要であることに同意しますか?
@Karelシェルなしではいかなる種類のコンピューティングも行いませんが、シェルを使用した場合は行いません。
この回答がBash4ではなく古代のBash3を推奨している理由は少し戸惑っています。Bash4自体は現在ほぼ10年前のものです(2009年に発表されました)。 Bash 3には連想配列などの重要な機能がないため、厳しい制限があります。確かに、macOSはまだBash 3に同梱されていますが、それではどうでしょうか。 macOSは、一般に、UNIXツール(およびRubyとPython)で遅れをとっていることが知られています。また、nitpick:「BASH」ではなく「Bash」です。
@KonradRudolphコメントありがとうございます。大文字の問題を修正しました。 Bash 4に関しては、多くの便利な機能があることに完全に同意します。ただし、かなりの割合のマシンで使用できない場合は、致命的な問題になります。 Python 3は簡単にインストールできますが(Condaを使用するなど)、Bashのアップグレードは複雑で、深刻な問題が発生しやすくなります。連想配列に関しては、Googleの標準では次のように述べています。「$ {PIPESTATUS}の割り当て以外の目的で配列を使用する必要がある場合は、Pythonを使用する必要があります。」
@Karel Googleのコーディングガイドラインについていくつか選択した言葉がありますが、どれも礼儀正しい会社では受け入れられません。とにかく、Bashのアップグレードは実際には簡単です。 *ログインシェル*の代わりに使用する必要はないかもしれませんが、実際には不要です。macOSでは、ターミナルアプリでシェルを指定し、他のシステムにはBash4が付属しています。
@Kusalananda,がパイプラインを完全にシェルに書き込もうとするのは間違いであることに強く同意します。 [ワークフローフレームワーク](https://github.com/common-workflow-language/common-workflow-language/wiki/Existing-Workflow-systems)はたくさんあります。私はNextflowに偏っていて、多くの仲間がSnakemakeを使用しています。完全にシェルベースのパイプラインは、すぐに管理できなくなり、過度に複雑になり、理解が混乱し、デバッグが非常に困難になります。 Bashを*使用する必要がある*場合は、POSIX準拠の実装を目指す必要があります。
さらに、Makefileを使用すると、スクリプトを単純化するための多くの恐ろしいBashコードをより適切に実行できます。初心者の場合は、基本的なシェルスクリプトに慣れたら、これらの使用方法を学ぶことを目指す必要があります。
#3
+7
Kusalananda
2017-06-02 11:54:02 UTC
view on stackexchange narkive permalink

Open Group Base Specification Issue 7IEEE Std1003.1™-2008、2016 Edition、または略して「POSIX標準」は、Unixシステムによって提供されるインターフェイスとユーティリティを定義する標準です。これらの中には、コマンドラインシェル言語とツールがあります(上記のリンク先のページのメインインデックスにある「Shell&Utilities」を参照してください)。

私の知る限り、を実装するシェルはありません。正確に標準で指定されているものですが、 bash ksh93 はどちらも、独自の、場合によっては競合する拡張機能とともに、標準に準拠するという非常に優れた機能を果たします。特に ksh93 シェルは、POSIXシェル仕様の過去の開発に大きな影響を与えましたが、将来のPOSIX仕様は bash からより多くを借りる可能性があります Linuxで広く使用されているためです。

bash シェルはLinuxシステムでほぼ遍在しており、他のすべてのUnicesにもインストールできます。 ksh93 はほとんどのUnicesでも利用できますが、通常Linuxにはデフォルトでインストールされません。 ksh93 は、少なくともmacOS( ksh として)およびSolarisでデフォルトで使用できます。

シェルスクリプトを作成するときに移植性が心配な場合(私見は心配するのが良いことです)、POSIXユーティリティとそのPOSIXコマンドラインフラグのみを使用し、POSIXシェル構文のみを使用するようにしてください。次に、POSIX仕様を理解するシェルであると想定される / bin / sh によってスクリプトが実行されることを確認する必要があります。 / bin / sh は、多くの場合、「POSIXモード」で実行される bash によって実装されますが、 dash ash 使用しているUnixに応じて、code>または pdksh (または他の何か)。

Linuxユーザーにとって、ポータブルスクリプトを作成する上で最も難しいのは、シェル自体ではなく、多くのシェルユーティリティのGNU実装によって提供される多数の非標準コマンドラインフラグです。ただし、GNU coreutils(基本的なシェルユーティリティ)は、 bash のように、すべてのUnicesにインストールできます。

また、POSIXで実行する場合は、 bash にも注意してください。モード( / bin / sh として呼び出された場合、または -posix コマンドラインフラグを使用して呼び出された場合)は、POSIX準拠について厳密ではありません。 POSIX標準の構文拡張を受け入れる場合があります。

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

bashを「標準」とは言いませんが、実際に最も広く使用されているunixシェルであり、最新のunix / linuxディストリビューションでデフォルトで使用できる可能性があります。 zshのように、 / bin / sh と広く互換性のある便利なシェルが他にもいくつかありますが、それほど広くは利用できません。 Cシェル、特にそのオープンソース実装 tcshもあります。 Cシェルはbashとはかなり異なります。 10年以上前に時々使用されていましたが、最近では、古い世代のプログラマーを除いて、ほとんど使用されていません。

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

汎用コマンド sh は、文字通り業界標準、正確にはPOSIX標準です(IEEE 1003.2および1003.2a、さまざまなWebサイトで数百ドルで購入できます)。理論的には、#!/ bin / sh で始まるスクリプトはすべてこの標準に準拠する必要があります。実際には、ほとんどのLinuxシステムには、この標準に近いシェルがありますが、いくつかの癖と拡張機能があります。

これらの癖と拡張機能がシェルスクリプトの標準的な方法になると、問題が発生します。 Debianオペレーティングシステムは sh シェルとして dash に変更され、特定のシェルを指定していないシェルスクリプト、つまり開始されたシェルスクリプトで「bashisms」の使用をやめるように促しました。 #!/ bin / sh を使用します。 dash シェルは、可能な限り標準に準拠しようとします。

dashは、システムの標準コマンドインタープリターです。ダッシュの現在のバージョンは、シェルのPOSIX1003.2および1003.2a仕様に準拠するように変更中です。このバージョンには、Kornシェルといくつかの点で類似しているように見える多くの機能がありますが、Kornシェルのクローンではありません(ksh(1)を参照)。このシェルには、POSIXで指定された機能と、いくつかのBerkeley拡張機能のみが組み込まれています。このマニュアルページは、チュートリアルやシェルの完全な仕様を意図したものではありません。

私は違いに精通していないため、通常は sh マニュアルページで、標準に準拠した正しいシェルスクリプトについて説明します。

shはbashではないことに注意してください。 `/ bin / sh`が` bash`を指しているシステムでも、 `sh`として呼び出されると、bashの動作が変わり、POSIX準拠モードで実行されます。 「本物の」 `sh`シェル(ボーンシェル)はまた別のものであり、` bash`(ボーンアゲインシェル)と同じではありません。
Debianでは、デフォルトのインタラクティブシェル、つまりコマンドラインで使用するシェルはbash https://wiki.debian.org/Shell yes `/ bin / sh`は` / bin / dash`にシンボリックリンクされますしかし、ライブで使用するのはbashです。


このQ&Aは英語から自動的に翻訳されました。オリジナルのコンテンツはstackexchangeで入手できます。これは、配布されているcc by-sa 3.0ライセンスに感謝します。
Loading...