「UNIXという考え方」再考

「UNIXという考え方」再考 Terminal Night #3 @ 2026-10-15

自己紹介 松木 雅幸 (@songmu) ● ● ● ● ● Senior Solutions Engineer @ GitHub 200+ OSS Developer / 3 Times ISUCON Winner 入門監視 付録C 執筆 「みんなのGo言語」共著者 Podcaster: ○ 趣味でOSSをやっている者だ

• https://www.google.com/url?q=https://x.com/songmu&sa=D&source=editors&ust=1791979410073579&usg=AOvVaw13hqbDMPra5iJvMD6HvJ2Z
• https://www.google.com/url?q=https://oss4.fun/&sa=D&source=editors&ust=1791979410074437&usg=AOvVaw1uQovIUbq44gOxIbyHHYJW

開発環境 ● ● ● ● ● ● ● ● キーボード: MD770 JIS (分割キーボード) OS: macOS ターミナル: Ghostty ターミナルマルチプレクサ: herdr シェル: zsh エディタ: vim AI Agent: GitHub Copilot ノートテイキング: Obsidian

Ghostty + herder + GitHub Copilot

代表的なOSS ● ghq (メンテナ) ○ ○ ● tagpr (オリジナル作者) ○ ○ ● ローカルリポジトリ管理を便利にするCLI https://github.com/x-motemen/ghq ■ 3.6k stars ■ Homebrew上で累計数万DL GitHub上でタグベースのリリース管理を便利にするカスタムGitHub Actions https://github.com/Songmu/tagpr ■ 1000を超えるOSSリポジトリでの利用 ■ さくらインターネット社を始め、多くの企業のプロダクションでも利用いただいています k1LoW/deck (共同メンテナ) ○ ○ MarkdownからGoogle Slideを生成するツール https://github.com/k1LoW/deck

• https://www.google.com/url?q=https://github.com/x-motemen/ghq&sa=D&source=editors&ust=1791979410577162&usg=AOvVaw055ZeO-KVASal3SDfds6E9
• https://www.google.com/url?q=https://github.com/Songmu/tagpr&sa=D&source=editors&ust=1791979410577658&usg=AOvVaw1QIDaZd71U-2wrkOUUHTRW
• https://www.google.com/url?q=https://github.com/k1LoW/deck&sa=D&source=editors&ust=1791979410578097&usg=AOvVaw0Ek04CGU8mebG36TY9ExkE

sagepipe (最近の新作OSS) https://github.com/Songmu/sagepipe ● Agentの入出力をJSONスキーマで指定したJSONに強制する ○ ○ ● 自動化に組み込みやすくする Claude Code, Codex, GitHub Copilot, ACP(Agent Client Protocol) 対応Agentをサポート 以下の例 ○ ○ ○ 入力は記事情報一覧 Agentの出力は記事要約 それを描画スクリプトに流し込んで出力を得る

• https://www.google.com/url?q=https://github.com/Songmu/sagepipe&sa=D&source=editors&ust=1791979410590753&usg=AOvVaw2PnQd0yweOmgszDIuAJBoq

設定の実例

Agenda ● ● ● ● ● ● UNIXという考え方 思想が強い本 拘束的ユーザーインターフェースを避ける 沈黙は金 man再評価 まとめ

UNIXという考え方: その設計思想と哲学

UNIXという考え方 ● ● ● ● ● ● Mike Gancarz 著 2001年 (原著: The UNIX Philosophy; 1994) 名著ではある 思想が強い本 原理としては参考になる 本資料では 平成23年 第1版第15刷を引用元とします

好きな言葉 ● 劣るほうが優れている (p. 119) ○ ● Worse is better 第三のシステム (p. 40)

思想が強い本 ls 批判

定理2 一つのプログラムには一つのことを うまくやらせる (p. 23) ● "creeping featurism" ソフトウェア開発者は、業界でいうところの「しのびよる多機能主義」の 犠牲になってしまう

百徳ナイフを作らない https://www.guinnessworldrecords.com/world-records/85961-most-tools-onone-penknife ● ギネスワールドレコード ○ ● 87ツール・141機能 Swiss Army Giant Knife 2007 ○ Wenger S.A. 製

• https://www.google.com/url?q=https://www.guinnessworldrecords.com/world-records/85961-most-tools-on-one-penknife&sa=D&source=editors&ust=1791979410925575&usg=AOvVaw0bGZfRpW3uU6m_Fp7-nbKs
• https://www.google.com/url?q=https://www.guinnessworldrecords.com/world-records/85961-most-tools-on-one-penknife&sa=D&source=editors&ust=1791979410926377&usg=AOvVaw2QvXrL4NVFQhySZ9JpsXmn

道を踏み外したls (p. 24) 思想が強いシリーズ ls は愚直に行指向で出力すれば良く、段組みは別のプログラムと分離されて いるべきだという主張。 道を踏み外したUNIXアプリケーションの例として、lsコマンドを挙げ よう。20以上ものオプションをもち、一画面に収まっていない。 (中略) ファイル名を複数の列に整理させて表示することは、一見、気の効い たやりかたに思える。しかし、この機能は、ディレクトリの内容を表 示するという本来の機能とはほとんど関係がない。

原理主義的なplan9

plan9のlc コマンド

(宣伝) 趣味でOSSをやっているものだ ep.83

近代的な(普通の) ls は出力先によってフォーマットを変える ● ● 出力先がターミナルであれば段組み 出力先がパイプやリダイレクトであれば行指向

シェルスクリプトでの簡単な分岐例 ● ● ターミナル出力であれば色付けなどの制御も ただ、そういう余計な分岐は無駄だという考え方も ○ ○ ○ ● パフォーマンスオーバーヘッド 似た処理を各コマンド毎に実装する無駄 複雑度の増大 「一つのことを上手くやっているか」

github.com/Songmu/prompter ● ● ターミナル上でプロンプトを出すためのGoライブラリ 標準入力がターミナルか否かを判定して、プロンプト表示を制御する ○ ○ ターミナルではなかったら、処理をブロックさせずデフォルト入力で進む github.com/mattn/go-isatty が便利

所感 ● ls が段組み機能を内包するくらいは良いのではないか ○ ● ls | mc とか小さいコマンドを組み合わせるのは綺麗だが逆に認知負荷 が高くなるとも ○ ● それが多数派だったから生き残ったという話もある 自由度の高さと組み合わせ爆発 逆にAIに対しては単機能なパーツをたくさん用意して自由に組み合わせて もらった方が良いかも ○ 彼らの認知能力は高い

UNIXプログラミング環境 ● UNIX作者 ブライアン・カーニハン氏、ロブ・パイク氏 著 ○ ● ● まさにバイブル 対話環境が実はプログラミング環境であるという、UNIXの革命的な設計思想 原著1984年、邦訳1985年 ○ 流石にちょっと古い記述も

拘束的ユーザーインターフェース を避ける TUI的なものに対する否定論

CUIとGUI, そしてCLI, TUI CUIとGUIは対比で理解して構わないが、CLIとTUIはやや複雑 ● CUI ○ ● GUI ○ ● Graphical User Interface CLI ○ ● Character User Interface Command Line Interface TUI ○ Terminal (Text-based) User Interface

関係 (私的解釈)

ターミナルルネサンス TUIの発展 近年のTUIはターミナル上でのGUI実装という側面も ● ターミナル上でグラフィカルな表現が可能に ○ ○ ○ ○ ● 各種エスケープシーケンスでの拡張 sixelなどのグラフィック拡張 AI Agent普及による再評価 モダンなターミナル 私はTUIを作ったことが無い ○ ○ 単純なCLIしか作ってこなかった 作ってみたい気持ちはある

第6章 対話的プログラムの危険性 (p. 87) TUI的なものに対する否定論 ● ● ● ● ● シェルを離れて独自プロンプトに入ることのネガ mail コマンドを例に上げている psql シェルなどの対話的インターフェース ターミナルエディタも TUI のAI Agentはまさしくそれ

定理8 過度の対話的インターフェースを避 ける (p. 90) 「拘束的ユーザーインターフェース」 ● ● ● ユーザーを人間と想定している 他のプログラムと結合するのが難しい スケーラビリティに欠ける → ソフトウェアの梃子の効果を利用できない 拘束的ユーザーインターフェースとは、システムに存在するあ るアプリケーションが、最上位のコマンドインタープリタの範 囲外にあって、ユーザーと対話するスタイルをいう。

対話的インターフェースの問題点 ● 独自のプロンプトの中では、シェルのパワーを活かせない ○ ● パイプ等を使って他のコマンドとの連携が行えない 人間の入力待ちでブロックしてしまう ○ 自動化に不向き

(脇道) 入力待ちブロックを発生させないセオリー ● これはあくまで psuedo code ○ ● シェルに限らず、プロンプトを促すプログラムでは必須 値が未設定で、かつ標準入力がターミナルであれば、ユーザーに入力を促す ○ ターミナルに接続されていない場合は、入力待ちでブロックするのではなく、エラー終了する

定理9 全てのプログラムをフィルタにする (p. 100) 対話的インターフェースではなく、パイプで繋いで使えるフィルタとしてCLI を設計することが望ましい。 1. データ入力にはstdinを使用する 2. データ出力にはstdoutを使用する 第一等地としての標準入出力を汚さない

3. 帯域外情報にはstderrを使用する (p. 102) ● パイプ・フィルタとは関係ない情報はstderr(標準エラー出力)に出す ○ ○ ○ ● 迷ったら標準エラー出力に出す 人間が読むための途中経過などのinfoログも 標準「エラー」出力という名前はやや直感的ではない 常駐プロセスは構造化ログを標準出力に ○ 雑多なログは標準エラー出力に

JSONLを入出力に使う近年の発明 Structured Inputs/Outputs https://jsonlines.org/ ● ● CLIが標準出力1行に1つのJSONオブジェクトを出力する UNIXの行指向の思想とも親和性が高い ○ ○ ● JSONは必ず1行にシリアライズできる点が優れている ref. JSONにケツカンマを求めるのは間違っているだろうか - An Epicurean スキーマ情報も定義できる ○ ○ jq も多くの場所に入るようになった クエリもAgentに書いてもらえる

• https://www.google.com/url?q=https://jsonlines.org/&sa=D&source=editors&ust=1791979412276963&usg=AOvVaw1ApF13kp09jH9Vtr5P89qh
• https://www.google.com/url?q=https://blog.song.mu/entry/is-it-strange-to-want-a-trailing-comma-in-json&sa=D&source=editors&ust=1791979412277495&usg=AOvVaw1QNkd4Neazpb4jCachcooT

PowerShell: オブジェクトをパイプで渡す ● ● Windows発祥のシェル 時代を先取りしていたとも言える

沈黙は金 雄弁は銀

7.5 (5) 沈黙は金 (p. 112) ● 成功したら何も言わなくて良い ○ ○ ● 「頼りがないのは良い知らせ」 硬派なとっつきづらさ カラフルなアウトプットとか要らない (?) ユーザーに会話調で話しかけることがユーザーを助けることだ、と考えて いるプログラマが多すぎる。UNIXは一般に「ドライ」で、ただ「事実」だ けを伝える。

余計な情報は出力しない ● ● 補足情報などを出すにしても標準エラー出力に出す --verbose オプションで「冗舌」モードにする ○ ○ 短縮形を -v で提供する ■ -vv とか重ねてさらに冗舌に出来るツールも (ssh等) --version と短縮形が被って困ることも… ■ 個人的には -v は --verbose に取っておきたい ■ --version は -V

カラフルなアウトプットの是非 キラキラした最近のCLI ● 色や絵文字は自動化に不向き ○ ○ ● 標準出力に色を出したい場合 ○ ○ ○ ● noisyなエスケープシーケンス 環境依存・Windowsへの移植の難しさ ■ Goだと github.com/mattn/go-colorable が便利 パイプで繋いだ場合は色を消す --color=auto オプション等を設ける NO_COLOR 環境変数 → これらも分岐のために余計なコストを払うかどうか

NO_COLOR 環境変数 https://no-color.org/ ● ● ● ● 「このカラフルなトレンドを逆転させようとすることが無駄であることを受け入 れ、2017年に非公式の標準が提案された」 NO_COLOR=1 でプレーンな出力を得られるように実装するお約束 出力をカラフルにしたい人がいることは受け入れざるを得ないが、せめてプレー ンな出力のための共通手段が欲しいということ このページも思想が強めで面白い Accepting the futility of trying to reverse this trend, an informal standard was proposed in 2017:

• https://www.google.com/url?q=https://no-color.org/&sa=D&source=editors&ust=1791979412376427&usg=AOvVaw0-Xe4Sqzkik708MGiKHQwN

(余談) 環境変数文字列のtruthy/falsy ● 環境変数は文字列しか入れられないため、真偽値の表現が曖昧になりがち ○ ○ ○ ○ ○ ○ ● "true" / "false" "1" / "0" "yes" / "no" "on" / "off" "enabled" / "disabled" "enable" / "disable" NO_COLOR は空文字列以外は全部 truthy として扱うと明記されている ○ ○ "0" も "false" も true これは明確で良いと思う a NO_COLOR environment variable that, when present and not an empty string (regardless of its value)

man (マニュアル表示コマンド) 再評価 有用でありながら余り使われなくなってしまった

$ man ascii, $ man 7 ascii を打ってみよう

「manを読め」は遠くになりにけり ● 昔はマニュアルを読むことが必須だった ○ ○ ● インターネットが無い時代 インターネットにろくな情報がなかった時代 最近はCLIを開発してもmanページを作る人は少ない ○ ○ 私も書いたことはない… github.com/spf13/cobra はmanページを作ってくれる機能がある

man は本来は積極的に使うべき ● man はマニュアルを読むためのコマンド ○ ● 「一つのことをうまくやっている」 mycmd --help の問題点 ○ ○ --help が実装されているとは限らない 出処不明な実行ファイルを実行する危険性

man は何故下火になったか ● roff記法のとっつきづさ ○ ● 配置ルールの複雑さ ○ ● pandoc などでMarkdown等から変換する手もあるが /usr/share/man/man1/hoge.1 OS, distribution提供者は今でもmanページをメンテナンスしてくれている

まとめ

書籍「UNIXという考え方」とは何なのか ● ● ● ● 変化を受け入れながらも、原理主義的なところに立ち返る価値はある 「一つのことを上手くやる」無数の決定的なツールを組み合わせる考え方 はAgent時代にも即しているように感じる 「テキストかバイナリか」みたいな話もあって、これも時代によって揺り 戻しがあるのが面白い 著者のMike GancarzはイチUNIX思想家である点は留意 ○ DEC社にいて、初期X Window Systemの開発に関わるなどしていた

カーニハンのUNIX回顧録 本物のレジェンドによる最新書籍 ● ● ブライアン・カーニハン著 2025年出版 ○ ● 原著: Unix: A History and a Memoir (2019) パイプを発明した際のメモ書きの記載がアツい (p. 73)

(宣伝)このスライドは k1LoW/deckで作られました ● k1LoW/deck ○ ○ ○ MarkdownからGoogle Slideを生成するツール 私もメンテナとして開発に関わっています ぜひご利用ください！

• https://www.google.com/url?q=https://github.com/k1LoW/deck&sa=D&source=editors&ust=1791979412879294&usg=AOvVaw04yrkl2Q0Z7-SH0VFZzYK_

(宣伝) Slidownもよろしく ● Songmu/slidown ○ ○ ● MarkdownからPowerPointを生成するツール k1LoW/deck のフォークで兄弟プロジェクト pptxは実はzipで包まれたxmlの塊なのでAIに調整させやすい ○ Slidown自体はAIを使わずにMarkdownからpptxを生成するツール

• https://www.google.com/url?q=https://github.com/Songmu/slidown/&sa=D&source=editors&ust=1791979412917524&usg=AOvVaw0bIDUnFrB59JFsZhaaqHnh

参考 ● ● ● UNIXという考え方: その設計思想と哲学 : Mike Gancarz, 桂, 芳尾 UNIXプログラミング環境 : Brian W. Kernighan, Rob Pike, 石田 晴久, 野中 浩一 カーニハンのUNIX回顧録 eBook : ブライアン・カーニハン, 井上尚司

• https://www.google.com/url?q=https://link.amazon/B03VEDAaQ&sa=D&source=editors&ust=1791979412924192&usg=AOvVaw1jqzGqPaAgaaSr4vxryls-
• https://www.google.com/url?q=https://link.amazon/B0eWBfw80&sa=D&source=editors&ust=1791979412924353&usg=AOvVaw0Idpw5GwUP48EUnzXovK0B
• https://www.google.com/url?q=https://link.amazon/B02RknBOK&sa=D&source=editors&ust=1791979412924459&usg=AOvVaw2psr0gjPFFPNYYx4iav2cT