開発効率爆上げ！僕が毎日使う自作シェルスクリプトの驚きの効果
引用元：https://news.ycombinator.com/item?id=45670052
memo(1) (https://github.com/aktau/dotfiles/blob/master/bin/memo) ってツールを知ってるかい？
これはコマンドの出力をメモ化して、シェルパイプラインの反復開発を爆速にしてくれるんだ。
一時ファイル使うよりずっと楽だし、冗長なRPCコールも防げるから、開発効率がマジで上がるぞ！
環境変数はハッシュ化されないから注意してね。
up (https://github.com/akavel/up) ってツールはきっと気に入るはず！
curlの出力をupにパイプすると、ライブなプレイグラウンドでパイプラインの残りの部分を微調整できるんだ。
これは本当にすごいぞ！
up(1)はめちゃくちゃクールだね、俺のツールボックスに追加しようと思うよ。
up(1)とmemo(1)は似たような使い方だけど、俺はmemo(1)を使い続けると思うな。
パイプラインの途中のコマンドを編集することが多いんだけど、memo(1)の方がやりやすいんだ。
それに、upは余分なファイルを作るみたいだけど、memo(1)はそれを避けるのが目標だからね。
memo(1)にはね、自動圧縮機能も組み込んであるんだ！
zstdとかlz4とかを使って、保存する内容を自動で圧縮・解凍してくれるんだよ。
これでディスク容量もIOPSもすごく節約できるんだ。冗長性が高いから、約10倍も圧縮できることもあるんだぜ！
これ最高じゃん！俺もいつもcurlの結果をファイルに保存して、それをパイプしてたんだ。
これはマジで助かるよ。
ところで、LLMにbash履歴を食わせて、ワークフローの改善を提案してくれるような時代になったんじゃないかな？
そのアイデア、面白いね！簡単に試せそうだし、結果が聞きたいな。
LLMが俺たちのPC操作を20分くらい見て、ワークフロー改善やツールの提案をしてくれるってとこまで来てないかな？
何かを知りたいと思って聞くと、すごく役立つ答えが返ってくるから、きっとできると思うよ。
memo(1)じゃなくて、sedとかmkfifoを使っても似たようなことできるぜ。
例えば、x=$(mktemp -u); test -p $x||mkfifo $x; zstd -19 ＜ $x ＞ tmpfile.zst & ＜long running command＞|sed w$x|＜rest of pipeline＞;みたいな感じで出力を保存できる。
grepの代わりにsedで結果をstderrに送ったり、複数のファイルに保存したりもできるよ。
そのコマンドは、(1)ちょっと分かりにくいし、(2)実際にはメモ化した結果（tmpfile.zst）を使ってその後の実行を高速化してないんじゃない？
パイプラインの開発を高速化するために、どうやって使うのか、もっと具体的な例を教えてくれないかな？
もしテキストの入力形式と、どんな出力形式が欲しいか教えてくれたら、テキスト処理の方法を具体的に教えてあげられるよ。
Linuxを15年も使ってるけど、いつも新しいことを学んでるよ…
だからまたここに戻ってきちゃうんだよね。これをどうやって覚えといて、tmpfilesに戻らないようにすればいいかな :)
Warp terminalを数年使ってるんだけど、最近AIが組み込まれたんだ。最初はイライラして無効にしたけど、AI Agentはオプションモード（Cmd-Iで切り替え）で、結局よく使うようになったよ。コマンドを覚えたりmanページを掘り下げたりする気力がないときに（「wifiインターフェースのIPアドレスを調べる」とか「ffmpegでこれあれする」とか）すごく便利。速いしエラーも自分で修正できるから、もう手放せないね。「コマンドを記憶するツール」が全く必要なくなったよ。
サブプロセスキャッシングにはbkt (https://github.com/dimo414/bkt) を使ってるよ。キャッシュの有効期限（TTL）を設定できるとか、いい機能があるんだ。記事のインパイプラインのmemoizationは良さそうだけど、bktがそれをサポートしてるかは分からないな。
bktは知らなかったよ。リンクありがとう！memoにすごく似てるけど、より機能が豊富だね。明示的なTTLとか、作業ディレクトリをキャッシュキーのコンテキストに含められるとか。でも僕の視点からすると欠点もあるみたい。Rust製だからコンパイルが必要だし（memoはbash/zshスクリプトでそのまま動く）、READMEやソースコードには透過的な圧縮については言及がないね。https://github.com/dimo414/bkt/issues/62でスワップ可能なバックエンドに触れてるけど、ファイルシステムじゃなくてデータベースを使うのは僕にはプラスじゃないな。僕は一般的なツールで状態を簡単に調査できる方が好きだから。ギガバイト級のデータを出力するコマンドをmemoにすることがよくあるんだけど、それは通常、非常に圧縮可能だし、透過的な圧縮があれば解決する。ZFSみたいなファイルシステムレベルの機能で避けられるという意見もあるけど、クロスFSでそれを検出する方法は分からないな。bktの作者も参加できるようにhttps://github.com/dimo414/bkt/discussions/63を開いたよ。
コストが高いからAPIコールをキャッシュして、何ヶ月も後にbashのサジェストでそのキャッシュデータを使っちゃったよ :(
memo(1)のデフォルトの保存場所は/tmp/memo/${USER}だよ。ほとんどのディストリビューションでは、自動で定期的にクリーンアップされるか、再起動時に削除される。それとは別に、呼び出しにはmemoって入ってるから、ユーザーはそれがmemoizeする可能性があるってわかるはず。memo(1)は一般的に遅いコマンドに使うものだよ。遅い部分があるコマンドを再実行して、予期せずミリ秒で返ってきたら、なんかおかしいって気づくべきだよね。実際、これで困ったことは一度もないし、このハックされたコマンドを何年も使ってるよ。
例を見てもmemoに名前を付ける方法がないみたいなんだけど、後でどうやって参照するの？あと、これってパイプでやり取りできるシェルスクリプトを自動で書く方法みたいだよね。だから、みんなを驚かせないシェルスクリプトを使うんじゃなくて、なぜこれを使うの？これは予期せぬ動作をするかもしれないのに。
memoの名前はその後ろに来るコマンドそのものだよ！
$ memo my-complex-command –some-flag my-positional-arg-1
この呼び出しでは、「my-complex-command –some-flag my-positional-arg-1」のハッシュ（sha512）が取られて、それが/tmp/memo/${USER}/{sha512hash}.zstに保存されるんだ（zstdがインストールされていればね。なければ他の圧縮拡張子だよ）。
マジこれ最高じゃん！シェアしてくれてありがとう！
＞curl ... | jq . | awk ’...’ってあるけどさ、jqってawkと同じくらい（それ以上）パワフルだよ。直接jqを使えばawkは飛ばせるって知ってた？まあ、昔からの習慣ってなかなか変えられないし、関数型プログラミング言語の学習も簡単じゃないのはわかるけどね。
うん、知ってる。違う例出すべきだったね。でも現実的でもあるんだ。単発の作業ではこんなショートカット使うこともあるし。awkはよく知ってるし、jq .でJSONが整形されるのは知ってる。ちゃんとしたjqの式も作れるけど、この組み合わせの方が早く終わるんだよね。同じくawk ’...’ | grep | ...ってやることも。awkの最初に条件追加しに戻るのが面倒だからさ。スクリプトに保存するなら整理するけど。正直、jqに関しては最近はLLMに聞いて、その答えを叩き台にするだろうな。jqの言語を覚えるほど使ってないんだ。
＞trash a.txt b.pngってやつ、ファイル順にゴミ箱に入れるから、ファイルごとに音が鳴るしFinderで⌘Zしても最後のしか戻せないよ。macOS標準のtrashコマンド使うといい。Finder使わないから音なし⌘Zなしだけど、速いし“元に戻す”はできる。＞jsonformatでjqじゃなくてnodeを優先する理由は何？jqの方がコード少ないしmacOSにはプリインストールされてるし。＞uuidでv4 UUID作るなら、macOSとかLinuxにあるuuidgenを使わないのはなぜ？
https://www.man7.org/linux/man-pages/man1/uuidgen.1.html
俺は著者じゃないけど、たぶん彼はその存在を知らなかったんじゃないかな。自分の設定とか知識を共有する最高の点は、誰かが必ず自分の盲点に光を当ててくれるってことだよね。
もっと抽象的に言えば、何かインターネットに投稿したら、人はいつも君がどう間違ってるかを詳しく説明するだろうね。時にはそれが役に立つこともあるけど。
それは特にHNで顕著だよね。他のフォーラムでもそういうのはあるけど、HNだとほぼ全てのコメント欄が、75%（適当な数字だけど）くらい投稿記事の欠点を指摘してるように見えるよ。
普段、理屈っぽい奴は嫌いなんだけど、HNの奴らはまだマシだと気づいたんだ。なぜなら、自分の主張を事実（できれば引用）で裏付ける必要があるってわかってるからね。HNの理屈っぽい会話からは、他のフォーラムやSNSより何かを学べる可能性が高いと感じるよ。他のプラットフォームではスルーしちゃうけど、HNではオタクの戦いの勝敗だけでなく、途中で何か一つでも学べるかもって好奇心が湧くんだ。コメント欄への関わり方に影響があったのが気に入ってる。
そして最悪なコメントはフラグが立てられたり、消されたりするから、ほとんどの人は少し経てばスキップするよね。最近もそうなると思ったよ。
https://news.ycombinator.com/item?id=45649771
trashの代わりに、rmを再実装（ある程度の時間が経つかリソース使用量に応じて初めて本当に削除するとか、本当に削除したいならシュレッドするとか）するか、zfsを使う方がずっと理にかなってるよ。
こんなことのためにrmを再実装したい状況なんて、ちょっと思いつかないな。
HNのフラグ機能って荒っぽいけど、投稿にはかなり役立つよ。俺が読む「dead」な投稿は、ほとんどガイドライン違反してるのばっかりだし。でも、いい記事が埋もれるからストーリーにフラグを立てるのは好きじゃないな。とはいえ、HNは平和で繊細な議論には向いてないし、結局炎上して埋もれるから、どっちでもいいか。全体的にはまあまあ良いと思うけど、繊細さに欠けるのは確かだね。
もっとコメントを表示（1）
自作スクリプトより、ネイティブ機能の方が良い例を挙げるね。vimで範囲選択してから:’＜,’＞!markdownquoteってやるより、ctrl-vで最初の列を選んで”i＞ ”、それからescape。選択後4キーだよ、20キーじゃなくて。u+ 2025でñが出るってあるけど、unicodeは広く使えて、良いデフォルト検索もオプションも多いんだ。
ちなみに、なんで”2025”が”ñ”にマッチしたんだろ？catbin fooってのは基本的にcat ”$(which foo)”だよね。作者がzshを使ってるなら、cat =fooの方が短くて強力だよ。長いコマンドでもzshが=の後に賢く補完してくれるから、エラーも少ないしね。俺もfile =firefoxとかvim =myscript.shみたいによく使うよ。
俺は、批評が愛おしいと思うよ。理由は2つ。
1. 批判が的を得てて、何か学べる。
2. コメントしてる人が何も分かってなくて、それが面白い。
その中間ってのは、ほとんどないね。
https://news.ycombinator.com/newsguidelines.html
優しくして、皮肉を言わないで。好奇心を持って話して、尋問しないで。攻撃的な言葉は編集で削除して。
無害な発言をした相手に失礼な態度をとる代わりに、優しく、君が主張する状況を説明するのに言葉を使えたはずだ。もしかしたら、彼らはChatGPTに聞いたけど、その答えに納得できなかったのかもしれないしね。ちなみに、君の攻撃がどう意味をなすのか、俺には理解できない。むしろ、ChatGPTが必要なことこそ想像力の欠如を示すものだよ。
俺はshowdeadをオンにしてるけど、俺が見たフラグ付きの投稿は、ほぼ全部がそれに値すると思うよ。”値しない”って時でも、その人は何の理由もなく過度に攻撃的なトーンだったしね。要するに、間違った意見を持ってるだけでフラグが立った人なんて見たことない。物議を醸す意見でさえ、よっぽど危険だったり常軌を逸してない限り、フラグは付かないものだよ。
うん、特に気にしてないけど、他のフォーラムと比べるとHNの面白いところだよね。
applescriptを実行して、Finderに一括でファイルを削除させることはできると思うよ。理論的には、applescriptをシェルスクリプト内で直接構築・実行することも可能だろうね。シェルから呼び出す際に、ファイルリストを引数として受け取って削除するapplescriptファイルを書く方が簡単（でもまだ楽じゃないけど）だろうな。
macOSでゴミ箱使うなら、https://github.com/ali-rantakari/trash がオススメだぜ。ちゃんと動くし、超使える！LinuxやBSDでも似たようなツールを長年使ってるんだけど、今FreeBSDデスクトップがないから確認できないんだよな。
trashってツール、知れてよかった、サンキュー！今までFinderアプリに”{%s}をゴミ箱へ移動”って命令してたんだよな。この%sは”POSIX file ＜path-to-file＞”のコンマ区切りリストだぜ。
＞unicodeは広く利用可能
俺のmacOSやUbuntuには、デフォルトでインストールされてないぜ。
想像してみてよ、お前のコメントがフラグ付けされたらさ。すごく価値あるもんだったとして、議論に何か重要なものが欠けるのか？まさかな！でもどう感じる？そこまで穏やかじゃない、”不快”じゃない意見持ってるからって、なんでフラグ付けするんだよ？みんなに低評価させればいいじゃんか！
Pythonもデフォルトでキレイに整形出力してくれるぜ:
$ echo ’{ ”hello”: ”world” }’ | python3 -m json.tool
{
”hello”: ”world”
}
その通り！macOSにJQやuuidgenツールが搭載されてるなんて知らなかったぜ。超クール！
これは偶然にもCunningham’s Lawとして成文化されてるぜ。https://meta.wikimedia.org/wiki/Cunningham%27s_Law
…そして直接的ではないけど（Wikipedia記事でも参照されてるが）…https://xkcd.com/386/
君は正しいけど、
$ unicode
Command ’unicode’ not found, but can be installed with:
sudo apt install unicode
って出て、実際インストールできたんだ。だから本当に利用可能だったんだよ。これはDebian 11の話ね。
rmやtrashの代替としてripを推しておくぜ:https://github.com/nivekuil/rip
jqじゃなくてnodeを優先する意味ある？PowerShellならecho ’{”foo”: ”bar”}’ | ConvertFrom-Json | ConvertTo-JsonってやればJSON処理できるのに。関数としてならもっと使えるよ。
あるあるだよね。DIYや「ハック」のショート動画を見てると、必ず「それは違う」「もっと良い方法がある」っていうコメントがいっぱいあるのが面白いんだ。動画と同じくらい楽しめるよ。
それはサンプリングバイアスだよ。記事を読んだ全員の意見じゃなくて、わざわざコメントした人の意見しか見てないからね。同意する人はだいたい高評価だけ押すし、褒めるためにコメントする人はほとんどいないから、批判的なコメントが多くなるんだ。
HNで他開発者の働き方を知りたいし、そこから自分の仕事を改善したいんだ。最初は不要だと思っても「珍しいタスクが安価になると、新しいワークフローの基礎になる」効果（誘発需要に似てるね）があるから、ほとんど試してみるよ！記事のスタイルもすごく良いね。著者が各スクリプトの使用頻度を書いてくれてるのが超助かる。これで、どのスクリプトが効果的か事前にわかるからね。ちなみに、俺はブラウザのdev toolsでJavaScriptを使って文字列を小文字にしたりしてるよ :)
著者のやり方と俺のやり方で、費用対効果の分析を見てみたいな。著者がスクリプトを作るのにかかった時間、使い方を覚えたり、構文を忘れた時に調べたりする時間、それにシステムを変えるたびに移行にかかる時間なんかも含めてさ。
なんでそんなことが気になるの？これ全部やる目的は、長い目で見ればもっと効率的になるためでしょ。もちろん初期設定のコストや学習曲線はあるけど、それが終われば開発環境にかなり効率的だと感じるはずだよ。学習に時間かかるからって、努力する価値がないみたいに言ってるように聞こえるけど？俺は学習にそんなに時間はかからないと思うんだ。もちろん人それぞれだけどね。君の意見は問題じゃないように思えるな。
自作スクリプトをいじるのに、結局、節約できる時間より多くの時間を無駄にする可能性が高いから面白いんだよ。
https://xkcd.com/1205/
例えば、ブログ記事にあった「月に一回やる5秒のタスク」のスクリプト。著者がそのスクリプトを書いたりメンテしたりするのに5分以上かけてないことを願うね。そうじゃなきゃ、長い目で見たら時間を無駄にしてるだけだからさ。
このbashショートカット、俺はすごく重宝してるよ。
https://raw.githubusercontent.com/fliptheweb/bash-shortcuts-…
＞ 構文を忘れた時に参照する
もしそうする必要があるなら、そのスクリプトは改善が必要だよ。常に--helpオプションを追加して、何をするスクリプトで、どんな引数を取るのか説明するべきだね。
Python使うならargparseがめっちゃ便利だから試してみて。コマンドライン処理を分離できるし、–helpページも自動で出してくれるんだぜ。https://docs.python.org/3/library/argparse.html
そのxkcdには同意できないな。時間って全部が平等じゃないだろ？緊急時には後で効率化するために今時間を使う価値があるんだよ。それに、どれくらい頻繁に使うかなんてわかんないじゃん。
xkcdはアジェンダを押し付けてるわけじゃなくて、時間と効率の関係をただ事実として提示してるだけだろ。
たとえ時間がかかっても、イライラが減るならそれもメリットだろ。それに、スクリプトを公開すれば他の人も使えるし、初期コストなしで時間を節約できる。共有することで、さらにみんなが自分のスクリプトを共有するきっかけにもなるんだぜ。
ハッカーカンファレンスでツールやスクリプト、裏技を共有するのって最高だったよな。トレーディングカード交換みたいで、今でもそれが一番恋しいんだ。
Pythonは好きじゃないけど、argparseは確かにすごく良いツールだよ。RubyのOptionParser¹はイマイチだと思ってた。SwiftにはApple公式のArgument Parser²っていうかなり高機能なやつがあるし。シェルスクリプトには、俺が長年使い回してるパターンがあるんだ。
¹ https://github.com/ruby/optparse
² https://github.com/apple/swift-argument-parser
もっとコメントを表示（2）
こういう議論でよく忘れられがちなのが、経験の獲得だよね。「無駄にした」と思った時間も、実は将来もっと複雑なタスクを速く書けるようになるための経験として蓄積されて、後々時間節約につながるんだよ。
俺もこの手の話は大好きなんだけど、これまで色んな環境で、こういう高レベルなニッチツール（自分のdot filesも含めて）が使えなかったり、ツール自体が廃れてしまったりして、結局基本的なコマンドやビルトインを思い出すのに苦労することが多かったんだ。だから、最近はそういうツールの採用にはかなり慎重になってるよ。
set editing-mode viとかinfo readlineについて教えてやるなよ。彼がせっかく頑張ってシェルスクリプト作ってるのに、既存機能でできるって言ったらやる気なくすだろ？ま、でも知ってた方が便利なのは間違いないけどね。
俺の経験だと、自作スクリプトは“多分”じゃなくて“ほぼ確実に”問題が起きるからやめたんだ。
新しいシステムへの設定、クロスプラットフォームじゃない、他人のPCじゃ使えない、突然壊れる、存在を忘れる…
これらのイライラがメリットを上回るんだよ。最初は良いんだけど、結局使わなくなるんだ。
XKCDの漫画“Is It Worth the Time?”の話だけどさ。
例えば、半年ごとに30分かかるタスクを5年間やると5時間分の“労働”時間になる。だから、自動化に5時間以上かかるならやらない方が良いって解釈されがちだよね。
でも、それがアプリのダウンタイム5時間だったら、もっと時間かけてでも自動化する価値はあるだろ？
アイデアを得るために色々試すことってあるじゃん。
今回みたいなちょっとした問題を解決する中で、別の状況でも役立つような技術を学べるんだよ。時間短縮だけが全てじゃないってこと。
“新しいシステムに毎回全部設定し直さないといけない”って言うけどさ。
それって、まさにスクリプトで自動化できることなんじゃね？（笑）
自分で言ってることとやってることが矛盾してない？
時間節約だけが自動化の唯一の要素じゃないんだよ。
俺は時間を大幅に節約するためじゃなくて、エラーが起きやすいプロセスをコード化して、ヒューマンエラーのリスクを減らすために自動化することもあるね。
その方が、節約できる時間以上に価値があるんだ。
最近はAIのおかげで、スクリプトをめっちゃ早く作れるようになったよね。
作成にかかる時間をかなり減らせるんだ。
プロンプトを考えたりテストしたりする時間はまだ必要だけど、それでも効率は全然違うよ。AIってすごい！
自動化って時間管理より、むしろ「正気を保つ」ためのものだったりするんだよね。
俺、会社のWebページからファイルダウンロードするsystemdサービス作ったことあるんだけど、手動でクリックするよりスクリプト書く方が時間かかったかも。
でも、クリック作業がマジでウザかったから、作った甲斐はあったよ。
自動化のメリットを本当に理解するには、新しいことを試すオープンな心が必要なんだよ。
でも、多くの人がそれに抵抗してるみたいだね。
まあ、俺にとっては、試すたびに脳の新しいつながりができるってことで、いいんだけどさ。
“お前らにはわかんねぇんだよ！
俺は常に自分のアップタイムを最適化しなきゃいけないんだ！
科学がそうしろと叫んでる！TIMEMAXXINGだ！
自由に探求したりブレインストーミングなんてできない。XKCD 1205に従わないとだめなんだ。俺は全ての活動を時間最適化ピボットテーブルで評価しなきゃいけないんだ！”
自作スクリプトを年に数回しか使わないなら、生涯で150回くらいしか使わないかもな。1回1分節約できても、作成に5時間、維持に5時間かかったら、それって本当に得なの？割に合わないこともあるんじゃない？
時間の質って色々なんだよね。後で忙しい時に集中力を途切れさせたくないから、スクリプトやvim configの調整には、かけた時間以上のリターンがなくても喜んで時間を使うよ。邪魔されないって大事じゃん？
他のargparseポートについてだけど、Typescriptで動くhttps://github.com/nodeca/argparseも良いよ。更新止まってるけど問題ないしね。Modern C++向けのhttps://github.com/p-ranav/argparseは分かりやすいけどデバッグがちょっと面倒かな。argparseのポートは、コマンドラインのUXが一貫するし、--helpページがちゃんと作れるのが良いところだね。
開発者のライフサイクルって変だよな。新人の頃は普通のシェル環境。数年経つとOPみたいにスクリプトやエイリアスをたくさん書いて.bashrcも長くなる。でも15年のベテランになると、今は普通のシェルで余計なものはいらないな。もっと複雑ならPythonかGoで書くよ。
これは悟りの境地ってより、怠惰から来てる可能性の方が高いと思うな（僕もそう、怠惰だから）。カスタマイズにハマる同僚を見てると、Atuinとかfzfとか、いつも面白いツールを教えてもらえるけどね。
僕も似たようなサイクルだった。シンプルに戻ったのは怠惰じゃなくて、いろんなシステムで作業するようになって、全部にカスタム設定をするのが面倒だったからだよ。一時的なコンテナとかね。だから、凝った設定とデフォルトを使い分けるより、デフォルトで効率的にやることに慣れたんだ。
SSH接続したサーバーにdotfilesは結構簡単に適用できるよ。どんなワークフローかわからないけど、zsh4humansみたいなフレームワークにはそれがあるし、sshrcみたいなツールも使える。SSH接続時に同期を自動化すればOK。コンテナにSSHする時も同じだよ。
他人の環境で働いたことないの？クライアントマシンやプロダクションサーバーに「dotfilesを適用する」なんてしたら、マジでやばいことになるよ。コンテナも同じ、変なdotfilesなんか入れるな。コンテナの肝は予測可能であることだろ。
