POSIX非互換で困っていませんか？fishシェルのスクリプト記述で避けるべき致命的なアンチパターン

fishシェルは、その直感的な補完機能やカラフルな構文ハイライトによって、多くの開発者から支持を集めているシェルです。
しかし、日常的な対話用シェルとして優れている一方で、スクリプトを記述する段階になると、POSIX非互換という壁に直面する方は少なくないはずです。

そもそもfishは、bashやzshのようにPOSIX shの文法を踏襲する設計を採っていません。
変数展開の記法や条件分岐の構文、コマンド置換の書き方に至るまで、根本的に異なる思想で設計されています。
そのため、bash用のスクリプトをそのままfishに移植しようとすると、構文エラーの連続に悩まされることになります。

この非互換性そのものは仕様であり、避けようのない前提条件です。
問題なのは、その前提を理解しないままスクリプトを書き、後になって致命的な不具合を生み出してしまうアンチパターンの存在です。
具体的には、以下のような点が典型例として挙げられます。

• $?のような終了ステータス変数をPOSIX shと同じ感覚で参照してしまう
• サブシェルの挙動を誤解した状態でパイプラインを設計してしまう
• 配列とリストの扱いを混同し、意図しない展開結果を招いてしまう

本記事では、こうした落とし穴を一つずつ論理的に整理しながら、fishシェルでスクリプトを安全かつ堅牢に記述するための考え方を解説していきます。

fishシェルがPOSIX非互換である理由とその設計思想

fishシェルを初めて触った開発者の多くが最初に戸惑うのが、POSIX shの文法がほとんど通用しないという事実です。
これは実装上の不備や互換性対応の遅れによるものではなく、明確な設計思想に基づいた意図的な選択です。
まずこの前提を理解しておくことが、後々のアンチパターンを避けるうえで欠かせません。

POSIX shは、1980年代から続く歴史的経緯の中で標準化されてきた仕様です。
そのため、後方互換性を保つことが最優先され、構文の一貫性や可読性が犠牲になっている部分が少なくありません。
たとえば変数展開の際に単語分割が自動的に発生する挙動や、配列がシェルによって扱いが異なる点などは、初学者だけでなく熟練者をも悩ませてきました。

fishは、こうした歴史的な負債を引き継がないことを明確な目標として開発されました。
公式ドキュメントでも「Friendly Interactive SHell」という名称が示す通り、対話的な使いやすさと一貫した構文を最優先事項として設計されています。
具体的には、以下のような方針が根底にあります。

• 変数展開時に予期しない単語分割を発生させない
• クォートの有無によって挙動が大きく変わることを避ける
• 構文エラーを早期に検出し、実行前に警告する

この方針の違いを端的に示すのが、変数展開の挙動です。
POSIX shでは、クォートを省略した変数展開が単語分割やグロブ展開の対象となりますが、fishではリストとして扱われる変数であっても、この種の予期しない分割は発生しません。

このように、fishは既存のシェルスクリプトとの互換性よりも、一貫性のある予測可能な挙動を優先する設計になっています。
これは対話的な操作においては大きな利点となりますが、POSIX shの文法を前提にしたスクリプトをそのまま流用しようとすると、随所で齟齬が生じる原因にもなります。

したがって、fishでスクリプトを書く際には、bashやzshの知識をいったん脇に置き、fish独自の文法体系として学び直す姿勢が求められます。
次の章以降では、この設計思想の違いに起因する具体的なアンチパターンを一つずつ確認していきます。

bashスクリプトをfishに移植する際によくあるつまずきポイント

既存のbashスクリプトをfishへ移植する作業は、単純な構文の置き換えでは済まないケースがほとんどです。
これは前章で述べた設計思想の違いが、実際のスクリプト記述のあらゆる箇所に影響を及ぼしているためです。
ここでは、移植作業で特につまずきやすいポイントを整理します。

まず最初に直面するのが、変数代入の構文の違いです。
bashでは変数名=値という形式で代入しますが、fishではsetコマンドを使う必要があります。

set my_var "hello"
echo $my_var

この違いに気づかず、bashの代入構文をそのまま貼り付けてしまうと、変数への代入ではなく単なるコマンド実行として解釈され、意図しないエラーが発生します。
特にシェルスクリプトの経験が長い開発者ほど、この初歩的な違いを見落としがちです。

次につまずきやすいのが、コマンド置換の記法です。
bashではバッククォートまたは$()を用いますが、fishでは$()のみがサポートされており、バッククォートによる記法は使用できません。
この点自体は大きな障壁にはなりませんが、既存スクリプトにバッククォートが多用されている場合、置換漏れによるエラーが発生しやすくなります。

さらに厄介なのが、条件式や論理演算子の扱いです。
bashでは&&や||を用いた制御構造が多用されますが、fishでもこれらの演算子自体は使用できるものの、意味合いや評価タイミングが微妙に異なる場面があります。
特にコマンドの連結による条件分岐を多用しているスクリプトでは、移植後の挙動を必ず個別に検証する必要があります。

このほか、移植時によく見落とされる違いを以下にまとめます。

• ヒアドキュメントの記法がbashと異なる
• 関数定義にfunctionキーワードが必須であり、bashのような省略記法が使えない
• 環境変数のエクスポートにset -xのような専用オプションが必要になる
• コメントアウトの範囲や複数行コメントの扱いに癖がある

これらの違いは一つひとつを見れば些細なものですが、複数が組み合わさることで、移植作業全体の見通しを悪くします。
特に自動変換ツールに頼った移植では、こうした細部の差異が見過ごされたまま本番環境に投入されてしまうリスクがあります。

したがって、bashスクリプトをfishへ移植する際には、機械的な文法の置き換えにとどまらず、各コマンドの評価タイミングや戻り値の扱いまで含めて、一行ずつ丁寧に検証する姿勢が求められます。
次章以降では、この移植作業の中でも特に致命的な不具合につながりやすい、終了ステータスの扱いについて詳しく見ていきます。

終了ステータス$statusの扱いを誤るアンチパターン

シェルスクリプトにおいて、直前のコマンドが成功したか失敗したかを判定する処理は、エラーハンドリングの根幹を成すものです。
ところがfishでは、この終了ステータスの参照方法がPOSIX shと大きく異なるため、移植時に見落とされやすい致命的なアンチパターンの一つとなっています。

$?をそのまま使ってしまう典型的なミス

bashやPOSIX shに慣れた開発者が真っ先に書いてしまいがちなのが、$?を用いた終了ステータスの参照です。

• POSIX shでは、直前に実行したコマンドの終了ステータスは$?という特殊パラメータに格納されます
• 多くのシェルスクリプト入門書やチュートリアルでも、この$?を条件式に組み込む書き方が定番として紹介されています

しかし、fishには$?という特殊変数自体が存在しません。
bashのスクリプトをそのまま移植した際に$?を参照するコードを残してしまうと、変数が未定義のまま扱われ、期待した条件分岐が一切機能しなくなります。
しかもfishはエラーを明示的に出さずに空文字列として扱ってしまう場合があるため、不具合の発見が遅れやすいという点も見逃せません。
この種のミスは、テスト環境では偶然正常に動作しているように見えても、本番環境で想定外の分岐に入り込むという厄介な事態を招きます。

$statusを正しく参照する方法

fishにおいて直前のコマンドの終了ステータスを参照する場合は、$statusという専用の変数を用います。

some_command
if test $status -eq 0
    echo "成功しました"
else
    echo "失敗しました"
end

この$statusは、fishが標準で提供している変数であり、POSIX shの$?とほぼ同等の役割を果たします。
ただし、参照するタイミングには注意が必要です。
$statusは直前に実行されたコマンドの結果を保持するため、間に別のコマンドを挟んでしまうと、意図した値を取得できなくなります。

さらにfishでは、status is-successという専用のサブコマンドも用意されており、可読性を重視する場合はこちらを利用する選択肢もあります。
移植作業を行う際は、$?を含む箇所を機械的に置換するのではなく、参照タイミングのずれが発生していないかまで含めて、一つひとつ丁寧に確認する必要があります。

サブシェルとパイプラインの挙動を誤解したスクリプト設計

パイプラインは複数のコマンドを組み合わせて処理を行う際に欠かせない機能ですが、fishとPOSIX shではその内部的な挙動に見過ごせない違いがあります。
この差異を理解しないままスクリプトを設計すると、エラー検出の抜け漏れにつながりかねません。

パイプの終了ステータスがPOSIXと異なる点

POSIX shでは、パイプラインの終了ステータスは基本的に最後のコマンドの結果のみが採用されます。
そのため、パイプの途中にあるコマンドが失敗していても、最後のコマンドさえ成功していれば、パイプライン全体としては成功と判定されてしまいます。

一方fishでは、$pipestatusという変数が標準で提供されており、パイプラインを構成する各コマンドの終了ステータスを個別に配列として取得できます。

cat file.txt | grep "error" | wc -l
echo $pipestatus

このように、途中のコマンドの失敗を検知したい場合には、fish独自のこの仕組みを積極的に活用すべきです。
逆に言えば、bashのset -o pipefailに相当する挙動を暗黙的に期待したまま移植してしまうと、パイプの途中で失敗が起きても気づけないアンチパターンに陥ります。
パイプラインを多用するログ処理やデータ整形のスクリプトでは、この違いが特に重大な影響を及ぼす点に注意が必要です。

プロセス置換の書き方の違い

bashではプロセス置換として<(コマンド)という記法が使われますが、fishではこの記法自体がサポートされていません。
この違いに気づかず移植すると、構文エラーとして即座に処理が停止します。

fishでプロセス置換に相当する処理を行いたい場合は、以下のように一時的な名前付きパイプやリダイレクトを組み合わせる方法が一般的です。

• 中間結果をいったん変数やリストに格納してから後続処理に渡す
• psubコマンドを利用してプロセス置換に近い挙動を実現する
• 複雑な処理はいったん関数として切り出し、可読性を保ちながら段階的に処理する

特にpsubはfish独自のコマンドであり、bashのプロセス置換とは記法も評価タイミングも異なります。
安易に構文だけを対応付けて置き換えるのではなく、それぞれの処理が実行される順序やスコープの違いまで踏まえたうえで、パイプラインとサブシェルの設計を見直すことが、堅牢なスクリプト作成の鍵となります。

配列とリストの混同によるアンチパターン

fishには配列という概念が存在せず、代わりにリストという独自のデータ構造が用意されています。
名称の違いだけであれば些細な問題に思えるかもしれませんが、実際にはPOSIX shの配列とは根本的な設計が異なるため、この違いを軽視するとスクリプト全体の信頼性を損なう原因になります。

fishのリストはPOSIX配列と何が違うのか

POSIX shにおける配列は、bashやzshなど各シェルで拡張仕様として実装されており、宣言方法やインデックスの扱いに互換性がありません。
これに対してfishのリストは、言語仕様の一部として最初から統一的に設計されている点が大きな特徴です。

主な違いを整理すると、以下のようになります。

特に注意すべきなのが、インデックスが1から始まるという点です。
POSIX系シェルの感覚でインデックス0を参照してしまうと、期待した要素が取得できず、空の値が返されたことに気づかないまま処理が進んでしまう危険があります。

また、fishでは単一の値であってもリストの一種として扱われるため、代入した変数が単一値なのか複数要素を持つリストなのかを、コード上で明示的に意識する必要があります。

意図しない単語分割・展開を防ぐ書き方

POSIX shでは、クォートを付けずに変数を展開すると、空白を区切りとした単語分割やグロブ展開が自動的に発生します。
この挙動を前提としたスクリプトをfishにそのまま持ち込むと、意図しない結果を招くことがあります。

set files a.txt "b c.txt" d.txt
for f in $files
    echo $f
end

fishではリストの各要素がそのまま個別の単位として展開されるため、空白を含む要素であっても余計な分割は発生しません。
この挙動はPOSIX shと逆方向の安全性を提供するものですが、POSIX shの単語分割を前提に書かれたロジックをそのまま移植すると、想定していた分割が発生せず、条件判定がずれてしまう場合があります。
リストと文字列を明確に区別し、それぞれの展開結果を検証しながら移植を進める姿勢が欠かせません。

条件分岐とループ構文の誤用によるバグの温床

条件分岐とループは、あらゆるスクリプトの骨格を成す基本構文です。
しかしfishでは、これらの構文がPOSIX shとは異なる評価規則を持っているため、見た目が似ているだけに油断すると思わぬバグを埋め込みやすい領域でもあります。

if文とtest構文の落とし穴

POSIX shではif [ 条件 ]という角括弧を用いた記法が広く使われていますが、fishではtestコマンドをそのまま用いるか、あるいは組み込みの条件式を利用する形になります。
角括弧の記法自体はfishでもエイリアス的に動作することがありますが、スペースの有無や比較演算子の解釈がPOSIX shと微妙に異なる場面があり、これが移植時の見落としにつながります。

特に注意すべきなのが、文字列比較と数値比較の演算子の混同です。

• 文字列の等価比較には=を用いる
• 数値の等価比較には-eqを用いる
• 大小関係の比較には-ltや-gtなどを用いる

この点自体はPOSIX shと共通していますが、fishではtestの挙動が一部シェルビルトインとして最適化されているため、想定外の型でエラーが発生した際のメッセージがPOSIX shと異なります。
エラーメッセージの違いに戸惑い、原因の特定に時間を要するケースは少なくありません。
比較対象の型を常に意識し、変数の中身が数値なのか文字列なのかを明確にしたうえで、適切な演算子を選択することが重要です。

forループでのリスト展開の注意点

fishのforループは、リストの各要素を順に処理するというシンプルな構造を持っていますが、ループ対象がリストなのかコマンドの出力結果なのかを混同すると、意図しない挙動を招きます。

たとえばコマンドの出力を改行区切りで処理したい場合、POSIX shの感覚でそのまま変数展開すると、fishでは改行を含む出力が一つの要素としてまとめて扱われてしまうことがあります。
これは前章で解説した単語分割の挙動の違いに起因するものであり、コマンド置換の結果をどのようにリスト化するかを事前に設計しておく必要があります。

また、ループ内でbreakやcontinueを使用する際にも、ネストしたループの中でどの階層に作用するのかを明確に意識しておかないと、意図しない範囲まで処理が中断されてしまう場合があります。
条件分岐とループを組み合わせる箇所ほど、fish特有の評価規則を踏まえた慎重な設計が求められます。

fishスクリプトを堅牢にするためのエラーハンドリング設計

これまで見てきたように、fishでは終了ステータスの参照方法やパイプラインの挙動がPOSIX shと大きく異なります。
これらの違いを踏まえたうえで、実際に堅牢なスクリプトを設計するには、場当たり的な条件分岐ではなく、一貫したエラーハンドリングの方針を持つことが欠かせません。

まず前提として、fishにはPOSIX shのset -eに相当する、コマンド失敗時にスクリプト全体を即座に停止させる標準機能が存在しません。
この点を認識せずに移植すると、エラーが発生した後も後続処理がそのまま実行され続け、被害が拡大してしまう危険があります。
したがって、重要な処理の直後には明示的にステータスを確認し、失敗時には早期に処理を打ち切る設計を、開発者自身の手で組み込む必要があります。

status is-successを使った安全な分岐

前章で紹介した$status変数は数値としての比較が可能ですが、可読性の観点からはstatus is-successというサブコマンドを利用する方法も有効です。

if not status is-success
    echo "処理に失敗したため中断します" >&2
    exit 1
end

この書き方には、単に$status -eq 0と比較する場合と比べて、条件式の意図がコードを読んだだけで明確に伝わるという利点があります。
数値比較は一見単純に見えますが、比較演算子の書き間違いや、参照タイミングのずれによる事故が起きやすい箇所でもあるため、可読性の高い専用コマンドを使う意義は小さくありません。

さらに、複数のコマンドを連続して実行する処理では、以下のような方針を徹底することで、エラーの見落としを防ぐことができます。

• 重要なコマンドの直後には必ずstatus is-successによる確認を挟む
• パイプラインを使う場合は$pipestatusを併用し、途中の失敗も検知する
• エラー発生時のメッセージは標準エラー出力に明示的に出力する
• 致命的なエラーの場合はexitで速やかにスクリプトを終了させる

これらを関数として共通化しておけば、スクリプト全体で一貫したエラーハンドリングを実現でき、保守性も向上します。
次章では、こうしたエラーハンドリングの仕組みをさらに発展させ、関数化やモジュール設計によって保守性を高める方法について解説します。

保守性を高めるfish関数化とモジュール設計のベストプラクティス

エラーハンドリングの方針が固まったら、次に考えるべきは処理全体をどのように構造化し、保守性の高いスクリプトへと組み上げていくかという点です。
fishでは関数定義や変数のスコープの扱いがPOSIX shと異なるため、この違いを理解しないまま設計を進めると、後になって修正が困難な複雑な依存関係を生み出してしまいます。

関数の引数展開とスコープの注意点

fishの関数定義はfunctionキーワードを用いて明示的に行います。
POSIX shのような省略記法は存在しないため、既存スクリプトを移植する際には、すべての関数定義を書き換える必要があります。

function greet
    set name $argv[1]
    echo "こんにちは、$name さん"
end

ここで注目すべきは、引数を$argvというリストとして受け取る点です。
POSIX shの$1や$2といった位置パラメータとは異なり、fishでは$argv[1]のようにインデックスを用いてリストの要素として参照します。
前章で触れた通り、fishのインデックスは1始まりであるため、この点を見落とすと意図した引数を取得できません。

また、変数のスコープにも注意が必要です。
fishではsetコマンドに-l（ローカル）や-g（グローバル）といったスコープ指定オプションを付けない場合、関数内で定義した変数がデフォルトでも関数のスコープに閉じるとは限らない挙動が存在します。
意図せずグローバルスコープを汚染してしまうと、複数の関数を組み合わせた際に予期しない変数の上書きが発生し、原因の特定が困難なバグにつながります。
関数を設計する際には、スコープを明示的に指定する習慣を徹底することが重要です。

universal変数の乱用を避ける設計

fish独自の機能として、universal変数と呼ばれるスコープが用意されています。
これはシェルのセッションを超えて値が保持される変数であり、設定ファイルの管理などには便利な仕組みです。

しかし、この特性をスクリプト内の一時的な処理に安易に利用してしまうと、以下のような問題を引き起こします。

• スクリプトの実行が終了した後も変数が残り続け、別のセッションに影響を及ぼす
• 複数のスクリプトを並行実行した際に、意図しない値の競合が発生する
• デバッグ時に、どこで値が設定されたのかを追跡しづらくなる

universal変数は、あくまでユーザー設定やエイリアスの永続化といった用途に限定して使用し、スクリプト内部の一時的なデータの受け渡しには、ローカル変数や関数の引数を用いるべきです。
関数化とスコープ管理を適切に組み合わせることで、複数のスクリプトファイルにまたがる大規模なfish環境であっても、保守性を保ちながら開発を進めることができます。

まとめ:fishシェルでPOSIX非互換を乗りこなすための心構え

ここまで、fishシェルがPOSIX shと異なる設計思想を持つ理由から、終了ステータスの参照、パイプラインの挙動、配列とリストの違い、条件分岐やループの評価規則、そして関数化による保守性の向上まで、順を追って解説してきました。
改めて振り返ると、これらのアンチパターンに共通しているのは、POSIX shの知識や習慣を無意識のうちにfishへ持ち込んでしまうという点に尽きます。

fishは、既存のシェルとの互換性を犠牲にしてでも、一貫性のある予測可能な挙動を実現するという明確な思想のもとに設計されています。
この思想を理解せずに表面的な構文だけを置き換えようとすると、以下のような問題が繰り返し発生してしまいます。

• $?のような存在しない変数を参照し続けてしまう
• パイプラインの途中の失敗を検知できないまま処理を進めてしまう
• 配列とリストの違いを軽視し、インデックスや展開結果を誤解してしまう
• スコープを意識しない変数管理によって、意図しない副作用を生んでしまう

これらのアンチパターンに共通する対処法は、決して複雑なものではありません。
fish独自の機能である$status、$pipestatus、リストのインデックス規則、そしてsetコマンドによるスコープ管理という基本的な仕組みを、一つひとつ正確に理解し、実際のコードに落とし込んでいくことに尽きます。

移植作業においては、以下のような手順を踏むことをおすすめします。

1. スクリプト全体を俯瞰し、POSIX sh固有の構文や特殊変数を洗い出す
2. 洗い出した箇所を、fish独自の構文や変数へ一つずつ置き換える
3. 置き換えた箇所について、実際の挙動をテスト環境で個別に検証する
4. エラーハンドリングと関数化の方針を統一し、スクリプト全体の一貫性を保つ

こうした地道な作業を積み重ねることで、fishシェルの持つ対話的な使いやすさを損なうことなく、堅牢で保守性の高いスクリプトを構築できるようになります。
POSIX非互換という特性は、決して欠点として捉える必要はありません。
むしろ、曖昧さの少ない一貫した文法体系を提供してくれる利点として活用する視点を持つことが、fishシェルと長く付き合っていくうえでの重要な心構えになるはずです。

本記事で紹介したアンチパターンを一つの チェックリストとして手元に置きながら、日々のスクリプト記述に役立てていただければ幸いです。