私は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] これは知っておく価値があるから、両方の機能を避けるためにね。

Denoにはnpmスクリプトに似た「タスク」というツールがdeno.jsonにあるんだ。これには、設定されたタスクのリストやさまざまなIDE統合に表示される1行の説明を含めることを促すという小さな利点もある。だけど、俺の経験では、ほとんどのDenoタスクは、npmスクリプトよりもむしろdeno run …コマンド（記事のシェバン行）として、_scripts/みたいなディレクトリ内のスクリプトに対して書かれていることが多いんだ。

俺はしばらくの間Justを楽しんでたけど、miseを試してからは変わった。MiseはJustと同じことを全部やってくれるけど、ビルドジョブを再実行しないようにソース/出力トラッキングもしてくれるし、asdfみたいなランタイムもまとめてくれる。今では俺のお気に入りのオールインワンタスクランナーになったよ。

タイトルの「make」はちょっと誤解を招くと思う。著者は実際には、アドホックなスクリプトやテストに使うための一貫したファイルを持つことを提唱してるだけだから。この記事の要点は、シェルに複数のコマンドを入力するなら、スクリプトを作れってことだね。

この部分もよくわからないな、「ちゃんとした」がBashを意味するなら。どんな状況でもBashを書くべきじゃないと思うよ。

何が違うの？バージョン管理しないの？だって、ディレクトリパスをハードコーディングしてるから。特定の設定がされてる前提でやってるし、私のマシンのやり方に合わせてるから。今使ってるワークフローに特化してハードコーディングしてるだけで、それ以上でもそれ以下でもない。もう必要なくなった後は責任を持ちたくないし、正当化するのも面倒。チェックインすべきじゃないものをハードコーディングしてるから、これに基づいてやり方を決める責任も負いたくないんだよね。

fdとzoxideのことをずっと知らなかったなんて信じられない。zoxideは今や俺のトップコマンドの一つだし、fdはripgrepに切り替えたときの感覚に似てる。めちゃくちゃ速くて簡単だから、使わない理由がないよ。

zshのvimモードでは、現在のコマンドをエディタで開くショートカットはvだよ。