いい加減シェルスクリプトで [ $? -eq 0 ] や [ $? -ne 0 ] なんて エラー処理を書くのはやめよう！ShellScriptBashLinuxUNIXmacOS はじめに [ $? -eq 0 ] や [ $? -ne 0 ] は冗長でデメリットしかありません。非常に多く見かける書き方ですが、1979 年に Bourne シェルが広く公開された時からこのようなコードは必要ありませんでした。実際に当時はこのような書き方は使われておらず、このような書き方をしなければならなかった歴史的な経緯などはありません。これはなぜか広まってしまった良くない書き方です。 優れたコードとは無駄がないシンプルなコードです。丁寧なコードとは無駄な処理を書くことではありません。[ $? -eq 0 ] や [ $? -ne 0 ] は書かないほうが、簡単で読みやすくわかりやすくなります。優れた文法

Twitterとか見て「そうだったのかー」とか言うんじゃなくて、ちゃんと調べてみましょうよ。/usr は元々ユーザーのホームディレクトリをおいていた場所ですよ。/bin などを置いていたシステムディスクの容量が足りなくなったので別ディスクだった /usr 以下を使うようになっただけです。Unix System Resources とかそんな長い名前、後付けに決まってるでしょ？ 翻訳は面倒なので、DeepL（の少し手直し）です。 初期の Unix のドキュメントから URLと1972年という年から、おそらく Version 1 Unix (1971) のドキュメントだと思います。ここ 経由で見つけました。 12ページにこのようなものがあります。詳細はよくわかりませんがディレクトリ構造でしょう。 idata: / root 41. 140016 .byte 7,1 9f-.-2 41. <..

Unix 哲学的に考えれば、行を並び替える sort コマンドと重複行を取り除く uniq コマンドは別のコマンドであるべきなように思えます。しかし sort コマンドには -u オプションとして uniq コマンドに相当する機能が組み込まれています。なぜそうなっている（そうなってしまった）のかを「ソフトウェア作法（さくほう）」を参照しながらこの記事で明らかにしたいと思います。 関連記事 Unix哲学「一つのことをうまくやる」は単機能のコマンドを作ることではない 「誰」がuniq機能をsortコマンドに組み込んだ！？ 熱烈的な Unix 哲学の信者は「どうせ Unix 哲学を理解しない GNU が便利だと思ってオプションを追加したのだろう」と考えるかもしれません。しかし uniq 機能が組み込まれたのは Version 7 Unix、つまり Unix の開発者が組み込んだのです。これは 1

はじめに Windows NT は最初のバージョンから POSIX 準拠です。当時の POSIX で標準化されていた POSIX API を実装しており NIST が POSIX 準拠であると認めています。その資料も公開されています。 NIST（National Institute of Standards and Technology）とは、アメリカ合衆国の連邦政府機関の一つで、科学技術に関連する標準についての研究などを行う機関。主に度量衡や計測・計量についての標準を管理したり、関連する科学研究や技術開発を推進している。1988年に前身のNBS（National Bureau of Standards：国立標準局）から改組された。 いつの間にやら某所の Windows に関する POSIX の説明があまりにも酷いデタラメな内容に書き換えられていたので、ここに「1993年から Window

Windows は 1999年12月（ほぼ2000年なので上記では2000年としています）に発売された Windows 2000 まで POSIX サブシステムを搭載していました。2001年8月に発売した Windows XP では POSIX サブシステムを搭載するのをやめましたが、そのときにはもう米国政府の導入要件ではなくなっていました。POSIX が米国政府の導入要件ではないため POSIX サブシステムをやめたのかもしれません。だからといって Windows が POSIX システムとの互換性を諦めたわけではなく、Microsoft Windows Services for UNIX (SFU) という形で POSIX システムというより UNIX との互換性を実現していました。POSIX だけでは足りないからです。後に SFU は Subsystem for UNIX-based

はじめに 2023年、長い時を経て awk がとうとう Unicode (UTF-8) と CSV に対応しました 🎉🎉🎉 awk で日本語がうまく扱えない（場合がある）、Excel が出力する CSV ファイルが扱えない（場合がある）、といった問題が解決に向けて一歩に進みます。 去年、本家 awk (One True Awk, nawk) に Unicode サポートが Brian Kernighan の手によって追加されたと話題になった（参照）ことを覚えているでしょうか？ Brian Kernighan が誰だか知らない方がいるかもしれないので説明すると、オリジナルの awk の開発者の一人で awk の頭文字、Alfred Aho、Peter Weinberger、Brian Kernighan の一人です。通称「K＆R」の「プログラミング言語C」や「プログラミング言語AWK」

なんだろう、嘘つくのやめてもらっていいですか？ 大学も技術者認定機関も、いつまで古いまたは間違ったシェルとカーネルの概念を説明し続けるのでしょうか？ シェルはカーネルの言葉をユーザーの言葉に翻訳したり、出力結果をユーザーに中継したり、カーネルを防御したりする層ではありません。指定したコマンドを実行するだけのプログラムです。勉強中の学生か代理執筆業者が適当な文献を調べて書いたとしか思えません。そして他人の説明を自分の言葉に置き換えるのが上手い人がおかしな説明をさらに広めています。個人サイトやオンライン学習サイト程度であれば適当なことを書いていても気にも留めませんが、大学や技術者認定機関のような正しいことを書いているに違いないと思えるような所までもが間違ったことを書いているから困ったものです。 みなさんは大学や技術者認定機関が言っていることなら正しいと思いこんでいないでしょうか？ そんなことあ

はじめに 1992 年に POSIX でシェルが標準化されて以来、シェルスクリプトの数値計算に expr コマンドは使いません。expr コマンドを使って計算していたのは Bourne シェル（古い UNIX の sh）時代の話で、現在の POSIX sh （dash、bash、ksh 等）時代では数値計算に expr コマンドは不要です。今どきはシェルの機能だけで整数の計算を行うことができます。「今どき」って一体いつからだって話なわけですが……。 注意 シェルスクリプトでパフォーマンスの話をするとすぐに「他の言語で〜」という方がいますが、私はどんなことにでもシェルスクリプトを使えなんて一言も言っていません。パフォーマンスを気にしている理由は、そこが実際にシェルスクリプトのボトルネックになるポイントだからです。そもそもシェルスクリプトと一般的な言語は言語設計レベルで得意なことが違います。ユ

はじめに シェルスクリプトで二重起動防止やロックをする方法を検索すると、いろいろな方法や書き方が見つかりますが、どれを使えばよいのか、本当に正しく動くのか、不安になりますよね？ ディレクトリ (mkdir) やシンボリックリンク (ln) を使った独自実装の例も見かけますが、エラー発生時や予期せぬ電源断、CTRL+C で止めたときなどでも問題は発生しないのでしょうか？ まず、ディレクトリやシンボリックリンクを使った独自実装はしない。これを肝に銘じてください。シェルスクリプトでのロック管理はとても難しく、一般的な排他制御の知識に加えて、シェルスクリプト特有の問題、シグナルやトラップ、サブシェルや子プロセスの問題、さらには特定のシェル固有の仕様やバグなどさまざまな問題に対処する必要があり大変です。独自実装の例では古いロックファイルが残ってしまい、それをいつどのタイミングで片付ければ安全なのか？

補足 1975: トンプソンはベル研を一時休職し、母校のカリフォルニア大学バークレー校に Version 6 Unix をインストールする作業を手伝う。これは後に BSD Unix として配布される。 1984-1998: ガンカーズが DEC でプリンシパル・ソフトウェア・エンジニアを務めた時期 ガンカーズは DEC の Unix Engineering Group (UEG) に所属 いつから DEC に勤めていたのかは不明 P63 より「小さな会社で Version 7 Unix を使っていた」ので 1979 年よりも後 V7M の開発には関わってなさそう おそらく 1980-1984 の間に DEC に入社したと思われる ガンカーズが「UNIX の考え方」についての本はないだろうか？と考えたのは 1991 年 1988: POSIX.1 標準化（POSIX.2 は 1992 年）

なぜシェルスクリプトで高度なデータ管理にSQLiteを使うべきなのか？ ～ UNIX/POSIXコマンドの欠点をSQLで解決するShellScriptUNIXSQLitePOSIXQiitadelika 「利用者は数十億人！？ SQLiteはどこが凄いデータベース管理システムなのか調べてみた」の続きです。 はじめに 複雑な構造のデータを扱うのであればシェルスクリプトや Unix (POSIX) コマンドでデータ管理を行うのは避けるべきだと思います。解決不可能な問題が多いからです。しかしそれでも何かしらの理由でやろうと考える（やらなければいけない）のであれば SQLite を使うのをおすすめします。シェルスクリプトや Unix コマンドは行単位の単純なテキストデータをシーケンシャルにデータ処理するのが前提となっており、改行や空白が含まれるデータや複雑な構造のデータ扱うのは苦手です。またシェル

はじめに POSIX コマンドはどの環境にもある（追加インストールの必要がない）コマンドだと思われがちですがこれは間違いです。POSIX コマンドにどの環境にもあるという性質は有りません。POSIX コマンドの中でどの環境にもあるコマンドは実際には半分程度しかありません。 関連記事 POSIX準拠 とは本当はどういうことなのか？「POSIXで規定されたものだけを使う」ではありません 補足 Linux は POSIX に準拠してないからだという意見もあるかとは思いますが、現実に使われている環境を無視して「どの環境にもある」と主張しても意味はありません。 本当にどの環境にもあるコマンドとは？ 全 POSIX コマンドは 160 個 POSIX コマンドは全部で 160 個あります。そのうち 22 個はシェルにビルトインされているコマンドなのでどの環境にもあると言えます。残りは 138 個のコマ

はじめに SQLite は世界で一番使われている　だから世界で一番凄いものに決まってるだろ SQLite は世界で最も使われている RDBMS です。名前に反して（？）おもちゃの RDBMS ではありません。元ネタと同じで 一番普及しているからと言って必ずしも一番凄いものであるとは限りませんが、普及しているのであればそこには何かしらの理由があるはずです。その理由を調べないことには、凄いか凄くないかの結論は出せないので SQLite のなにがそんなに凄いのかを調査しました。 2022/04/01 続編記事↓を書きました。 注意 この記事は「なぜシェルスクリプトで高度なデータ管理にSQLiteを使うべきなのか？ ～ UNIX/POSIXコマンドの欠点をSQLで解決する」の補足記事して書いたものです。ところどころ不自然にシェルスクリプトや Unix コマンドの話が登場するのはそのためです。基本的

POSIX 準拠のシェルスクリプトでは find | xargs よりも find -exec {} + を使うべき！ShellScriptBashshellPOSIX はじめに find の出力を xargs にパイプで渡すというのはよく見かける使い方ですが、find -print0 | xargs -0 が使えない POSIX 準拠のシェルスクリプトでは find -exec {} + を使った方が良いです。安全かつ十分に速いからです。よく見かける -exec {} ; ではなく -exec {} + ですので間違えないようにしてください。多くのケースでは + の方が優れているのですが ; ばっかり使われているのを見ると、意外と知られてない気がします。 少しだけ予備知識として、-exec {} ; は -exec {} \; と ; をバックスラッシュでエスケープするのがよく見る使い方

はじめに ことの始まりは「シェルスクリプトでツールを作ったけど速度が遅くて使い物にならなかったので供養」というツイートを見たからです。コードを見てみると、実例をあまり見ないシェルスクリプトのリファクタリング例として丁度良い内容と分量だったため記事にいたしました。記事を書くにあたりコードの利用を快く承諾していただいた @Hayao0819 様にはこの場を借りて御礼を申し上げます。 内容は章立てで構成しており、序章で事前調査をし、第一章で一般的なリファクタリング、第二章でパフォーマンスを重視したリファクタリング、終章で少し余談をして締めくくっています。最初はパイプは並列処理されるから速くなるというのは神話（そうとは限らない）についても書いていたのですが流石に長いので分けました。それでも書きたいことを色々書いていたらめちゃくちゃ長くなってしまいましたので読み物として私がどんなことを考えながらリフ

実は最大並列数の制限がなければジョブ（標準入力からの一行単位のデータ）の数だけバックグラウンドプロセスを起動すればいいのでかなり簡単に実装できます。ですが普通は嫌ですよね？ということで最大並列数を制限する処理を入れています。また通常の利用で必要になりそうな CTRL-C と TERM シグナルへの対応もしています。 #!/bin/sh set -eu [ "${ZSH_VERSION:-}" ] && setopt shwordsplit MAX_PROC=4 # 最大並列数 # INT(CTRL-C)、TERM による終了処理 terminate() { trap '' TERM kill -TERM 0 exit "$1" } trap "terminate 130" INT trap "terminate 143" TERM # trap : CONT # 並列で実行される処理 fu