私はSwiftを使ってるよ！外部モジュールをスクリプトにインポートできるように、swift-sh[0]を（再）作ったんだ（uv風にね）。 [0] https://github.com/xcode-actions/swift-sh

まあ、少なくとも5年後には自分のBashスクリプトを実行できるようになるだろうね。

同意するよ。シェルはプレーンテキストの原子的な操作をつなげるのには最高だよね。つまり、そういう一行スクリプトには向いてる。多分、プレーンテキストでどう動くかよりも、プロセスを始めたり、プロセス置換やリダイレクションを簡単にできることが主な理由だと思う。どこかに状態が蓄積されると、分岐やループが出てきた時にすぐに混乱しちゃうんだよね。

一般的にはAWKをスクリプト言語として使ってるか、全体をAWKで直接書くことが多いかな。変わらないし、すべてのPOSIXプラットフォームに常にインストールされてるし、コマンドラインとも簡単に連携できるし、学びやすい小さな言語だからね。

これが正解。シェルはひどいスクリプト言語で、最初のifを「シンプル」なスクリプトに入れなきゃいけなくなると、選んだことを後悔し始める。もうちょっと複雑な文字列操作をしなきゃならないときも同様。JS環境にいるならいいかもしれないけど、著者のニーズはシェルコマンドを.shファイルに入れるだけで満たされるんじゃない？このやり方はちょっとオーバーエンジニアリングすぎて、その分のメリットが少ない。著者がMake.tsファイルを作る理由は、コマンドを.shファイルに入れるだけで十分に満たされるし、プロジェクトをチェックアウトするときにビルドシステムに何をインストールする必要があるか気にしなくて済むっていう利点もある。メリットが見えないんだよね。

これがまさに私がRad [0]を書くきっかけになったフラストレーション。READMEには例が載ってるよ。もう1年以上取り組んでて、目標はCLIを書くためのプログラミング言語を提供すること。宣言的な引数（毎回Bashの操作を解析しない）、自動的な--help生成、親しみやすい（Pythonっぽい）構文を目指してるし、開発用ビルドスクリプトにぴったり。こんな感じのスクリプトになることが多いかな：#!/usr/bin/env rad --- 開発自動化スクリプト。--- args: build b bool # プロジェクトをビルド test t bool # テストを実行 lint l bool # リンターを実行 run r bool # 開発サーバーを起動 release R bool # リリースモード filter f str? # テストフィルターパターン filter requires test if build: mode = release ? "--release" : "" print("Building ({release ? 'release' : 'debug'})...") $cargo build {mode} if lint: print("Linting...") $cargo clippy -- -D warnings if test: f = filter ? "-- {filter}" : "" print("Running tests{filter ? ' (filter: {filter})' : ''}...") $cargo test {f} if run: bin = release ? "target/release/server" : "target/debug/server" $./{bin} 使用方法: ./dev -b (ビルド), ./dev -blt -f "test_auth" (ビルド、リンティング、テスト), ./dev -r (ただ実行)。現在も開発中！[0] https://github.com/amterp/rad

最近、かなり複雑なシェルスクリプトをたくさん書いてる（とはいえ、1000行を少し超える程度だけど）。その中にはローカルで動く小さなプログラムもあれば、Terraformのためのコンポーザブルなcloud-initモジュールを駆動するものもある。これを使えば、ユーザーは自分でシェルスクリプトを書くことなく、複数のLinuxディストリビューションでEC2ホストのさまざまな機能を設定できる。適切なツールがあれば、思っているほど悪くはないよ。どちらのスクリプトも、面白いものはすべてNixを通じてインストールされるから、特定のディストロのパッケージマネージャに依存することは少ない。どちらの場合も、すべてのスクリプトはShellCheckを通過しないと「ビルド」できない。明らかなパースエラーや引用符の曖昧さ、変数名のタイプミスがある状態ではデプロイやコミットできない。開発者向けのツールとしてのスクリプトの場合、Bashインタープリタ、coreutils、すべての外部コマンドはNixによって提供され、スクリプト内にそのフルパスがハードコーディングされてる。スクリプトはLinuxでもmacOSでも関係なく動くし、PATHに何があるか（空でも）気にしない。彼らは「モダン」なBash機能を取り入れて、最も読みやすいインターフェースを提供するCLIツールを使ってる。私のお気に入りの言語？いいえ。でも、しばしば最も良いROIを持ってるし、ポータビリティや多くの問題も、使うべきツールを知っていればかなりうまく解決できる。特にスクリプトがシンプルならね。

私のモノレポは年々多言語化してきてて、依存関係のせいで、makeファイルやcargo.toml、package.json、deno.json、venv + requirements.jsonなんかが同じルートにあるのは珍しくないよ。ウェブのバックグラウンドから来たから、通常はpackage.jsonにスクリプトを全部入れるようにしてる。全部にmakeを使いたいけど、いろんなことに対してはオーバーキルだし、私が働いてる分野では標準的じゃないことも多いからね。

package.json（またはNXのproject.json）にスクリプトを入れる主な欠点は、JSONでラップしなきゃいけないことだね。シンプルなコマンドには問題ないけど、引用符や複数コマンドを追加し始めると、ちょっとごちゃごちゃしてくる。makeやタスクランナーとして使うのが好きなんだけど、構文やインデントのオーバーヘッドがかなり少ないからね。ただ、まだJSベースのプロジェクトに導入したことはないんだ。新しいツールを追加することになるからね。

Makeはプロジェクトの一般的なメンテナンスコマンドを保存するのにとても良い選択だよ。仕事でもこれを使ってる。10年以上前にDockerに移行したときに始まったんだ - docker-composeが存在する前に、コンテナのセットをビルドして実行するにはかなりのシェルスクリプトが必要だったから、Makeを使うことにしたんだ。Makeはどこにでもあって、クロスプラットフォームで、ターゲットは基本的にシェルのスニペットに追加機能や構文が加わったものだし、依存関係のシステムもある（「Xを実行したいなら、まずZとYをビルドしてからXを実行する必要がある」みたいなことを自然に表現できる）。パラメータ化も簡単だし（make ARG=val）、実際にはチューリング完全な言語で、ファーストクラスのラムダや自己修正コードの能力もあるんだ[1]。ルールが複雑になりすぎたら、scripts/something.shにダンプしてMakeに呼び出させるのも簡単だし、別の言語でスクリプトを書き直すのも可能だよ。Makeはターゲット間の依存関係も提供してくれる。要するに、Makeはプロジェクトに必要な「補助的」スクリプトを言語に依存しない形で集めるのにとても良いツールなんだ。setup.pyやpackage.jsonよりも優れているのは、両方の種類のプロジェクトに対して単一のインターフェースを提供しているからだよ。[1] これは知っておく価値があるから、両方の機能を避けるためにね。