わずか120ページで分かる！私が書いたモダンなコマンドライン入門書！
引用元：https://news.ycombinator.com/item?id=44126612
いいね！本！
ちょっと提案なんだけど、ランディングページで読者が何を学べるか、もっと具体的な例を載せた方がいいかも。今のだと、完全なコマンドライン初心者向けなのか、bashに慣れてる人にも役立つのか、分からないんだよね。サンプルページを探しまわって、やっと内容が掴めたよ。
あと、文章にいくつか指摘。「Fresh out of press」は「hot off the press」が一般的だよ。「Grok the Linux command line on only 120 pages」は「in only 120 pages」の方が自然かな。
確かに、ランディングページはもっと詳しくできるね。Gumroadのページの情報と重複させたくなかったんだけど、考え直すべきかも。
文章の指摘ありがとう。ネイティブじゃないんだ。
この本、楽しみにしてるし、あなたの仕事に感謝してるよ！
一つ気になったのは、スマホで縦表示にした時にタイトルが大きすぎて文字が切れちゃうこと。これが直れば、みんなもっと集中して読めると思うな。
あと、LLMとかGrammarlyみたいなツールで校正（編集じゃなくて）を手伝ってもらうのもありかもね。
これはすごくいいね！
ありがとう！
うん、他の人も指摘してたけど、ランディングページはモバイル表示と文章を改善する余地があるね。
英語について補足ね：「Fresh out of press」じゃなくて、「Fresh off the press」が探してる口語表現だよ。
間違いなくランディングページにはもっと情報追加すべきだよ。
Gumroadページに詳しい情報があるなんて全然知らなかったし。
いいね、いくつかコメント。
ウェブサイトがモバイルだとちょっと崩れてる（少なくとも僕のでは）文字が画面からはみ出しちゃうんだ。
それから、サンプルページか、せめて目次ページがあるといいね。この本がどのレベルを対象にしてるか分かるから。
無料で本を手に入れて後で支払うこともできるのは知ってるけど、それちょっと面倒だし、こういうのに０ドルを選ぶのは申し訳なく感じちゃうんだ。
フィードバックありがとう。
モバイルでも動くように頑張ってたんだけど、最後はちゃんとテストできてなかったかも。
サンプルについては、今から何か作ってみるよ。ありがとう。
追記：サンプルページはこちら: https://drive.google.com/file/d/1PkUcLv83Ib6nKYF88n3OBqeeVff…
細かい指摘なんだけど：^Dはカーソルが行頭にある時だけ終了するよ。
＜space＞^Dを入力してもセッションは残るんだ。
それ以外は、いいね！「env」を使ってるのと、適切なクォーティングはすごくいいサインだね！
説明ありがとう。次のアップデートでこれについてメモをこっそり入れられるか見てみるね。
page 112＞ if [[ ”${1-}” =~ ^-*h(elp)?$ ]]; then＜ …ハイフン一つ以上で始まるオプション…についてだけど、”one or multiple” は ＊ じゃなくて ＋ だよ。この正規表現だとハイフンなしの ”h” や ”help” にもマッチしちゃうね。
全部同意！ 俺も Firefox android、 pixel で見てるけど、画面の一部が見えなくなるよ。
目次があったら嬉しいな。
ゼロ円で手に入れて著者から何も奪いたくないんだ！
とにかく、素晴らしい本みたいだね。
完成して”shipping”したの、おめでとう！
＞全部同意！ 俺も Firefox android、 pixel で画面見切れてるよ。＜ あー、そうなんだ、全然知らなかったよ。報告ありがとうね。
俺も Android の Brave で画面外にテキストが出てるの見えてるよ。
君の言うとおりだね。間違ってるよ、これどうにかしなきゃ。
この2つの修正で改善されるはずだよ（小さい画面サイズで一番大きなテキストとか本の画像が画面外に溢れちゃうのを防げるよ）： diff –git a/index.html b/index.html
index a0f978c..040e50e 100644
— a/index.html
+++ b/index.html
@@ -21,3 +21,3 @@
h1 {
- font-size: 3.8em;
+ font-size: clamp(2.2em, 7vw, 3.8em);
margin-bottom: 0;
@@ -60,2 +60,3 @@
.hero-img {
+ max-width: 100%;
transform: rotate(2deg);
あと、本で見てる部分はすごく気に入ったよ。最初の数ページだけでもう学べることがある！ありがとう！
おー、それはすごい！ありがとう！
サンプルページはここだよ： https://drive.google.com/file/d/1PkUcLv83Ib6nKYF88n3OBqeeVff…
シェルにはかなり詳しいと思ってたんだけど、サンプルページだけで学べたことあったよ（process substitution）。購入したよ！
bashの¹マニュアルをプロセスの代替とかについて学ぶほどちゃんと読んでないのに、なんで本を読むと思うの？
1. ＜https://www.gnu.org/software/bash/manual/bash.html＞
だって、一般的にマニュアルって”ここにある全ての細かい情報”みたいな感じじゃん。でもこういう本は”ここにある特に役立つことの概要だよ”って感じなんだよ。
特定のことの仕組みとかやり方を知りたいときはマニュアルを見るけど、機能を見つけるのにはそんなに役立たないんだ。
人によって情報の学び方って違うんだよね。マニュアルを最初から最後まで読むのが好きな人もいれば、実践的なチュートリアルで同じ概念を見る方がよく学ぶ人もいる。
著者の本のサンプルを読んだけど、bashマニュアルよりずっと実践的で分かりやすいみたいだよ。だから、bashマニュアルを全部読む気がない人が著者の本を読むのは驚かないね。
サンプルpdfの12ページ目が”On
Linux, the PATH looks something like this：”で終わってるけど、その後にPATHの例が載ってないんだよ。
うん、リンクされてるサンプルページは本のPDFから適当に取っただけなんだ。Show HNのために急いでまとめたからね。ごめんね。ランディングページを修正するときにもっと良いサンプルを作るよ。
例のpdfには13ページ目はないよ。本全体の雰囲気を掴んでもらうために、ばらばらのページを集めたんだ。
うーん、サンプルページは納得できないな。例えば＞diffユーティリティはファイルを比較して違いを表示できる。lsコマンドの結果を渡せば、ディレクトリの中身を比較できる。
いや、lsコマンドの出力を渡すとエラーになるかもしれないよ。diffにたくさんのファイルを渡すことになるからね。
それに最後になるけど、ディレクトリをファイルごとに比較するには
diff -r directory-a directory-b
ってコマンドがあるよ。
それ、プロセスの代替を示すためのものだったと思うよ。diffにたくさんのファイルを渡すんじゃなくて、lsの出力をファイルとして渡すんだ。
実際、これを見られてすごいと思ったよ。コマンドの出力をdiffするときによく使うんだけど、知らない人が多いんだ。
置換機能を見せたかったんだ。ディレクトリをdiffする一番いい方法じゃなくてね。よくスペース節約のために、複数の概念とかツールを一度に見せる例を作ろうとしてたんだ。でも、君の言いたいことはわかるよ。
httpリンク付きの表紙ページをつければ、後でダウンロードした例とか読んだときに、元に戻りやすくなるよ。いいね！
各セクションのプロジェクトとか練習問題を見つけるのに、なんか情報源とか提案ある？コマンドラインなんて絶対使わないで、ExcelとかVSCodeに戻っちゃう人たちを訓練しなきゃいけなくてさ（誰が何を習得すべきか決める天才じゃないけどね…）。この本は素晴らしいんだけど、なんかプロジェクトとか問題がないと学習のモチベーションが足りないと思うんだ。自分で意味のないプロジェクトを考えるのが大変でさ。
もっとコメントを表示（1）
これに興味ある人たちは、これも気に入るかもね。The Shell Haters Handbook： https://shellhaters.org/deck/
あと、これも見逃さないでね。https://wizardzines.com/
著者の焦点は、ほとんどのマシンにあって古いシェルスクリプトで使われるような、昔ながらのツール（例えばfindとかgrep）なの？それとも開発者が自分のマシンに入れるような、新しいツール（fd、fzf、rg）なの？それとも両方？
昔ながらの標準ツールだよ。CIパイプラインに組み込みやすかったり、同僚とスクリプトとして共有しやすいからね。例えば、個人的にも仕事でもMakeをあちこちで使ってる。本では代替ツールも触れてるけど、例は昔からあるツールが元になってるよ。インストールがいらないもの（もし選択肢があればね）とか、職場で出会う可能性が高いものに焦点を当てたんだ。トレードオフだけど、逆のアプローチも魅力的だってのはわかるよ。
Makeって強力で自己文書化できるツールだよね。シンプルで普遍的なCLIの裏に、大量の複雑な依存関係の実装詳細を隠せるんだ。
Makeを使いたいならどうぞ、確かに便利なツールだよ。（Makeを批判してるんであって、あなたを批判してるわけじゃないからね。）とはいえ、俺はMakeが大嫌いなんだ。使いにくい点や変な癖、いつもハマる暗黙的な挙動が多すぎる。結局、俺が本当に欲しいのはJust（https://github.com/casey/just）みたいなコマンドランナーで、Makeファイルはビルドに必要な最低限だけあればいいんだよ。
ついでに言うと、CMakeもMakeと同じ問題を抱えたビルドツールだよ。パワフルだけど構文が醜いし、直感に反する意味合い、隠れた落とし穴、読むのが苦痛なマニュアルとかね。
俺も同意。Justとか（他のツールも）純粋なエントリーポイントとしては優れてる。でも、すでにMakefileがあるプロジェクトに出会ったり、コンテナに入れるものが1つでも少ない方がいいって分かってると…結局Makeを使うんだよ。
マイクロサービスや一時的なコンピューティングランタイムの時代では、ベースラインのデフォルト環境が不必要な複雑さから俺たちを救ってくれるだろうね。
例えば、CIパイプラインでは、自分の普通のMakefileを使って、シェルスクリプトからPythonスクリプト、npmスクリプトまで、様々な言語の異なるYAMLタスクを置き換えることができるんだ。
最近の人たちは、既存のツールが使いにくいと、最新のキラキラしたツールに飛びつく傾向があるよね。新しいツールをインストールするより、既存のツールを理解する方が手間がかかるからさ。
LLMを使えば、それらのツールの能力やより深いアイデアを探求するチャンスがあるかもしれないね。もしLLMの予算（時間とお金）が十分にあるなら、awkを使ってスーパーエージェントを構築するのにもっと時間を使うかも。GNUのマニュアルは、こういった使い方にぴ”ったりなコンテキストだよ。
魅力的なアイデアだけど、cmakeでendif（）を書いたり、find_package（）が「from package import ＊」と同じだったり、CXXが自動的にCMAKE_CXX_COMPILERに名前変更されたりするのは、ただのひどい設計だよ。深掘りするようなアイデアなんてない。システムがただ醜くて紛らわしいだけなんだ。
俺はCMakeのベストプラクティスを理解しようとhttps://cliutils.gitlab.io/modern-cmake/README.htmlを読んでるんだけど、この本はひたすら「古いやり方やお決まりのやり方でやるな、隠れた落とし穴のせいでうっかり間違ったことをする羽目になるからだ。」っていう行が続くだけなんだ。それはひどい設計＊だよ！
Linux CLI tools、coreutils、grep、sed、awkの演習付き対話型TUIアプリを書いたよ：https://github.com/learnbyexample/TUI-apps
これと一緒に使うといいリソースだよ： https：//linuxjourney.com。
そのサイトに影響を受けたオープンソース版もあるよ： https：//github.com/daquino94/linux-path
内容はすごくいいと思うんだけど、レイアウトがちょっと読みにくいかな。
＊説明の次のページにコードブロックがあったり（18／19p）
＊注釈もそう（26／27p）
＊単語がページで区切られちゃったり（51／52p）
＊フッターが複数ページにまたがったり（61／62p）
細かいこと言ってるみたいだけど、読んでて流れが途切れるし、理解するのにページを行ったり来たりしなきゃいけないのが大変なんだよね。
フィードバックありがとう。
そうだよね。できるだけきれいにしようとはしてるんだけど、本を更新したり内容が変わったりすると難しくなることもあるんだ。
でも、次のアップデートでは気をつけるようにするね。
いいね、Linux 20＋年以上使ってるけど、サンプルページからいくつか学べたよ。（追記：あれ、もう30年近かったわ、マジか）
これ素晴らしい！来年大学のクラスでコマンドラインを教えるんだけど完璧に見えるわ。
最近のリソースはスクリプトに偏りがちだけど、これは初心者に必要な「コマンド打ってエンター」とか「上矢印で履歴」みたいな基本からJob Control、AI活用まで網羅してる。
値段も手頃だし、来年おすすめするよ！
ちょっと気になったんだけどさ、CLIベテランの人たちが「もっと早く知りたかったー！」って思うような、ゲームチェンジャーになったコマンドとか概念ってある？「次の20％」に含まれるかもしれないやつ。
そういう「なるほど！」みたいな瞬間が知りたいな！
bat ＃シンタックスハイライト付きのcat
zoxide ＃ディレクトリを覚えてくれる
tig ＃cursesのgitビューア
atuin ＃複数マシンでシェル履歴を共有
choose ＃cutとか”awk ’{print $1}’”より簡単
direnv ＃ディレクトリに入ると環境変数をセット
fd ＃もっといいfind
fzf ＃なんでもファジー検索、マジでゲームチェンジャー
gh ＃GitHubクライアント
rg ＃めっちゃ速い再帰的grep
本で気に入ってるのは、”xdg-open”を”open”にエイリアスすることかな．コマンドをよく忘れるからさ．こうすれば必要に応じて”open X”って打つだけでファイルとかをGUIアプリで開けるんだ．小さいことだけど、よく使うよ．
本に入れなかったけど、最近知ったのは”notify-send”の使い方．コマンドラインやスクリプトから自分にシステム通知を送れるんだ（少なくともGnomeでは動いたよ）．例えばタスクが終わったらさ：
＞ echo ”when finished send notification” ＆＆ notify-send ”system notification”
なかなかいいと思わない？
俺のLinux（Debian 12／Bookworm）だと、／usr／bin／openは／usr／bin／xdg-openへのシンボリックリンクになってたわ．だから、知らず知らずのうちにxdg-open使ってたんだね．
もし俺が講座やるなら、最初の1時間で多分grep，sed，awk，そして正規表現を教えるかな．awkって言っても、超基本的なことだよ．例えば−F’，’ ’｛print ＄3” ”＄NF｝’みたいなね．これだけでもかなり役に立つんだ．あと、any command ｜ while read line； do something ＄line； doneみたいなパイプを使ったループとか、もちろんfindとviもね．
これらって基本的なことかもしれないけど、覚えたらめっちゃ変わったよ：
set −o vi
set −o xtrace
xargs， xargs −I
パラメータ展開（bashマニュアルのParameter Expansionの項を見てみて）
ctrl ＋ r
find −exec
lsof
findとgrepには本当に慣れた方がいいよ．信じられないくらい強力だから．perl −peはawkより断然簡単だしね．
それに賛成！それに加えて、findとxargsの組み合わせを知っておくのも大事だね．find自体のexecを使うよりうまくいくことが多いから．
もちろんこういうのもね：
find ．．． ｜ xargs perl −lne ”fancy stuff”
これで、見つけたファイルに対してちょっと凝った処理ができるんだよ 😉
俺は絶対こっちを使うべきだと思うよ：
find ．．． −exec ｛｝ ＋
これだとstdinを汚さないし、ファイル名にスペースや改行があっても問題ないんだ．一致するファイルがない場合に何もしないのも良い点．見た目もスッキリして短いしね．どうしても覚えられないなら、少なくとも−print0／xargs −0を使うべきだよ．
awkとperlの基本、最近だとjqも重要だね．
すごくいいね！俺もインタラクティブなチュートリアルを書いて教えてるんだけど、ここに置いてあるよ：https：／／github．com／JulianEducation／CommandLineBasics
役に立つかもしれないから見てみて．俺は教える時間が90分しかなくて、どこまで教えるか調整が大変なんだ．まだ改善したい点も多いけどね．こういうリソースがたくさんあるのは良いことだから、君の本を見るのが楽しみだよ．
いいね！少なくともリアルタイムでフィードバックもらえるし、みんながどこでつまずくかも分かるし。それめっちゃ役立つじゃん。
興味あるんだけど、ウェブサイト行ってもコマンドラインの本だってこと以外何も分かんなかった。
何ページか、章だけでもプレビューできると嬉しいな。
もっとコメントを表示（2）
分かったよ。今はコメント欄とGumroadページにサンプルページのリンク貼ってる。あとでホームページ変えなきゃね。意見ありがとう！
コマンドラインのシェルスクリプトで一番大事なのは「複雑なスクリプトには使うな。ifとかforがいっぱいなら、もっと高級な言語で書き直せ」ってこと。これはGoogleのシェルガイドにも書いてあるアドバイスね。DevOpsとかPlatform engineerを何年もやってきて思うけど、Bashはクソ。10～20行くらいのスクリプトには最高だけど、それ以上は全然ダメ。
クソとは言わないけど、大筋では同意するし、個人的にも長いスクリプトは書かないな。＞これはGoogleシェルガイドにも書いてあるアドバイスだね。この本にも同じアドバイス載せてるよ！でも実際、職場のリポジトリにはそういうスクリプトがいっぱいあるだろうし、ちょっとは理解しとくのは良いと思うけどね。
「職場で見かけるかも…」って？友達、全然分かってないね（笑）俺の憎しみはちゃんと理由があるんだよ！
なんで？（俺のスクリプト平均115行なんだけど）。
構文が分かりにくくて複雑。forとかifとか、他の言語の方がずっとやりやすい。パッケージマネージャーとかテストとかデバッガーもない。データ構造のサポートゼロだから操作最悪。メンテも大変なダメ言語。
Bashで「できない」んじゃなく、NodeとかPythonの方が「うまくできる」。PythonやNodeからシェル呼ぶのは簡単だし、Pythonは最近ほぼシステムに入ってる。もうシェルスクリプト書くのはPerlやCobolみたい。もっと良いツールあるし、世の中は進んでるよ。
AIでコマンド作るのも楽になったけどさ，コマンドラインをちゃんと理解するのってやっぱ大事だと思うんだよね．この本，友達にも絶対勧めるわ．一つ提案なんだけど，実際の仕事で使うような具体例をもっと載せたら，もっと分かりやすくて面白くなるんじゃないかな．
短くしたかったから，あんまり追記はしたくないんだけど，一部の章は書き換えたり改善したりするの考えてるよ．例はちゃんと実用的なんだけど，それぞれの概念が現実世界でどう役立つか，もうちょっと説明があってもいいかもね．シェアしてくれてありがとう！
この本読んでコマンドラインに詳しくなったとしてさ，DevOpsでちゃんとやってくには，あとどんだけ勉強したり覚えたりする必要があるの？
DevOpsって言葉が結構あいまいだからさ，具体的に何を学べばいいかリストするのは難しいんだ…．でも，シェルとかコマンドラインの知識だけじゃなくて，それよりずっとたくさん学ぶことがあるのは間違いないね．
買ったよー！この本でターミナル使いこなすためのアドバイスある？１日１ページ読むとか，１，２週間で全部終わらせちゃうとか，どうしたらいいかな？
進めながら自分で色々試すのが絶対お勧めだよ！書いてあることコピペして動かしてみてね．終わるまでの期間は人それぞれだから気にしなくて大丈夫．学習ってのは時間かかるし反復練習が必要だから，焦らずじっくり，練習に集中するのがいいと思うな．
うわー，これすごいね！色の使い方がおしゃれだし，脚注みたいな説明の仕方もめちゃくちゃ気に入ったよ．
ありがとう！
Gumroad以外で買う方法ないの？
今のところはないかな．でも，Gumroadにお金払いたくないって理由だったら，PDFをメールで送るから，代わりにPayPalで寄付してもらうのでもOKだよ．連絡はpetr@stribny.nameか，Xの@stribnyまでどうぞ．
