はてなブックマーク

プロファイルでできることは環境の設定だけです。シェルの設定は実際にはできないことはないのですが、やっても無意味なことになるのでできないとします。無意味なことになるというのは新しく起動したシェルにはプロファイルで行うシェルの設定は反映されないということです。環境の設定とは、特定のシェルに依存しない初期化処理のことで、その一つが環境変数の設定です。環境変数は OS の機能であってシェルの機能ではありません。環境の設定には、他に stty コマンドによる端末の設定や umask コマンドによる umask の設定などがありますが、プロファイルで設定することはあまりありません。 rc ファイルでは環境の設定とシェルの設定の両方ができます。シェルの設定、例えばプロンプト文字列の設定やシェルの機能を有効にしたり補完スクリプトの読み込みなどは rc ファイルに書きます。つまり、ほとんどのことは rc フ

はじめに シェルにはサブシェルという重要で独特な概念があります。どの言語でも独特の概念はあるものですが、シェルにとってはそれがサブシェルです。豆知識やうんちくとかいうレベルではなくサブシェルは基礎知識なので、シェルスクリプトをちゃんと書こうという人は知らなければヤバいと言っても過言ではありません。「難しい概念だから知らなくてもいいよ」などではなく、サブシェルを理解しなければまともに動くシェルスクリプトを書くことはできないと思ってください。独特なだけで難しいわけではないのですが、ちゃんと正しく説明できているものは市販の技術書を含めてもあまりありません。 サブシェルを一言で言うと、

ちなみに Space Travel にスコア機能やゲームのなにかを記録する機能はありません。描画は点と線だけで画像ファイルの読み込みなどは行いません。オリジナルの Space Travel は紙テープから起動してオンメモリで動くはずです。何が言いたいかというと Space Travel を動かすためにファイルシステムを作る理由はないということです。紙テープからの起動なんて時間がかかるのでは？ と思ったあなたは鋭い。1980 年頃の音楽用のカセットテープをコンピュータの記憶媒体として使っていた時代では、実際にゲームを始める前のロード時間に何分も待っていました。 初期の Unix 開発の技術は Space Travel から学んだ さて、この記事は Space Travel を通して Unix 開発の初期の歴史や、なぜケン・トンプソンは Unix を開発するに至ったのかを知ろうというのが趣旨の

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

補足1: 上記以降のその他のシェルの歴史 ksh88: 1980年頃に開発開始。一般的に公開されていないが ksh83 や ksh86 もある pdksh: ksh88 クローンで 1987年から1989年頃に開発。その派生版を OpenBSD が採用 bash: 1988年1月に開発開始し、1989年6月に 0.99 がリリース ash: 1989年5月にリリース、その派生版をFreeBSD、NetBSD、Debian系Linux などが採用 zsh: 1990年頃に1.0がリリース ksh93: 1993 年頃に開発開始。ksh88 の大幅強化版だが完全な上位互換ではない 参考: シェルの歴史 総まとめ（種類と系統図）と POSIX の役割 〜 シェルスクリプトの現在・過去・未来 補足2: POSIX 標準化以降 1992 年に POSIX によってシェルの仕様が標準化されました。しか

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに $\color{#e02020}{\huge{\bf{それは単なる「POSIX標準規格書の用語集」じゃい！}}}$ ということで、まことしやかに POSIX がテキストファイルの仕様を決めているかのような噂が流れていますが（私も言ったことがあるかも？）、POSIX に「テキストファイルは末尾に改行を書かなければならない」なんて仕様はありません。また POSIX は「テキストファイルの末尾を改行にすべし」などとも言っていません。POSIX は「3. Definitions（定義）」で 「POSIX 標準規格書の中で使用している『

はじめに grep コマンドや sed コマンドの -e オプションや -E オプションの意味を勘違いしている例を見かけるので訂正です。 -e オプションは正規表現またはスクリプトを追加指定するためのオプションです -E オプションは拡張正規表現モードを有効にするためのオプションです -e と -E は反対の意味を持つオプションではありません。まったく異なる機能を提供しているオプションです。-e オプションは拡張正規表現でも使うことができます。 -e オプションは正規表現またはスクリプトの追加指定 まず、なぜ -e オプションというものが作られたのか？ それはハイフンで始まる正規表現を指定したり、sed スクリプトを組み立てたりするためです。 grep コマンドの話 例えば grep コマンドで -a という文字列を検索したい場合はどうするでしょうか？

はじめに CUI は英語圏では通用しないようです。CLI という正しい用語を使いましょう。というか CUI のことしか書いていない初心者向け記事、量産させすぎ😡 ❌ CUI （キャラクターユーザーインターフェース）なんて言葉は英語にはありません 🟢 CLI （コマンドラインインターフェース）が正しい用語です 🟢 GUI （グラフィカルユーザーインターフェース）も正しい用語です なんども繰り返されている話題ですが、ふと書きたくなったので書きます。 CLI (コマンドラインインターフェース)ってなに？ CLI とはその名の通り、コマンドラインを使ったインターフェースのことです。つまり一般的にはシェルを使うユーザーインターフェースです。よく見るコレ↓です。 コマンドラインインターフェースとは、コマンドラインにコマンドを入力することでコンピュータを使うインターフェースです。ちなみにコマンドと

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. <..

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

FreeBSD では 2024-05-31 に 200112 から 200809 への変更がようやく行われました（一度間違えて 200808 と書いてしまっていますが）。 https://cgit.freebsd.org/src/commit/?id=2e30926a68 https://cgit.freebsd.org/src/commit/?id=6e0278408e macOS は FreeBSD のユーザーランドのコマンドを使用しているため、そのせいで 200112 のままだった可能性も考えられますが、シェルやカーネルは FreeBSD のものではないため、FreeBSD が変更になったからと言って macOS が更新されるとは限らないでしょう。Solaris 10 と 11 ではディレクトリごとに準拠バージョンが異なるバイナリが配置されており以下のようになります。Solaris

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Unix 哲学には DOTADIW: Do One Thing and Do It Well という言葉があります。日本語に訳すと「一つのことをうまくやる」となりますが、しばしば単機能のコマンドを作ることだと勘違いされています。もし勘違いしている人がいるのであれば、ぜひその人に聞いてみてください。なぜ grep コマンドはマッチした行数をカウントする機能を昔から持っているのですかと。昔からある wc コマンドがあれば grep コマンドに行数をカウントする機能をもたせる必要はないのではないかと。 -c Only a count

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

はじめに 多分これはガセネタです。おそらく日本だけで出回っているガセネタです。インタプリタにはそのような定義はありません。インタプリタは「ソースコードを読み込んで意味を解釈して実行するプログラム」 です。「1行ずつ」は些細な間違いとして「機械語に変換する」は完全に間違いです。ある程度詳しい人にとっては常識だと思うのですが。 おそらくコンピュータは機械語しか動かせないから、インタプリタも最終的に機械語に変換しているはずだという間違った思い込みからこのガセネタは広まってしまっているのでしょう。機械語に変換するのは面倒な処理です。速くなるかもしれませんが変換処理しなくて良いのだから普通はしませんよ。 コンパイラとインタプリタの定義 コンパイラとは コンパイラとは、ソースコードを元に実行可能なプログラムを生成するためのプログラムです。ユーザーは（ソースコードではなく）別に生成されたプログラムを実行

「POSIX」という用語が何を指すかですが、昔は POSIX.1 しかなかったので、POSIX.1 のことです。後に POSIX.2 が誕生しました。上記のリストに POSIX.1-2001 の前に空行を入れていますが、これは 1998 年に POSIX を策定していた団体が IEEE から現在の Austin Group （IEEE PASC と The Open Group と ISO/IEC JTC 1/SC 22 のジョイントワーキンググループ）に切り替わる重要なラインです。この後に POSIX.1 シリーズのさまざまな規格と POSIX.2、そしてSUS が統合されました。現在では POSIX.2 は POSIX.1 に統合されています。今は単に POSIX といえば、POSIX.1 しかありません。 Microsoft も Linux も Apple も POSIX API・コ

はじめに シェルスクリプトを遅くする大きな原因は fork と exec です。この二つは OS のインターフェースである fork() 関数と exec() 関数のことで、シェルスクリプトからは、外部コマンドやバックグラウンドプロセスの実行、明示的なサブシェル (...)やコマンド置換 ret=$(...)、パイプの使用などで呼び出されます。 シェル関数はシェルの中で実行される関数であるため、単純にシェル関数を呼び出す場合には fork も exec も行われません。しかしシェル関数の出力を変数に代入しようとコマンド置換（var=$(func)）を使うと、exec は行われませんが fork は行われてしまいます。その事に気づかず例えば回数の多いループの中でにコマンド置換を使うことがシェルスクリプトを遅くする原因の一つとなっていました。新しいコマンド置換である「関数置換（仮）」と「値置換

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

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

はじめに 30年以上もの長い間 UNIX を支えてきた Bourne シェルも UNIX のサポート終了とともに消え去ろうとしています。みなさん、他のシェルへの移行はお済みでしょうか？ 残り一年、まだ移行が済んでいないという人のために、移行のための簡単なガイドラインと各シェルの特徴をまとめました。 関連記事 シェルとUNIXコマンドの未来 ～ これからの10年で起きるシェルスクリプトの変化 残り1年というのはどういうこと？ Bourne シェルは POSIX に準拠していない古いシェルです。最初の Bourne シェルは 1979 年に登場し、最終バージョンは 1992 年のものです。ちゃんとしたデータを持っているわけではありませんが、現在 Bourne シェルを使っている最もシェアが高いと思われる UNIX は Solaris 10 です。ただし Solaris 10 では 1989 年

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに シェルスクリプトの世界は今後 10 年で大きく変化します。10 年という数字は切りが良い数字を持ってきただけで根拠はありません。これより長い時間がかかるかもしれませんし、もしかしたら短くなるかもしれません。しかし確実によりよい方向に変わっていくでしょう。Unix/Linux の標準コマンドはさまざまな問題を抱えています。Unix/Linux の標準コマンドに依存している限りシェルスクリプトに大きな改善はありません。これからのシェルスクリプトの世界は Unix/Linux の標準コマンドに依存しない世界です。それがどういうものに

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

はじめに xargs コマンドは「なにか凄そうだけどよく分からないコマンド」としてよく知られています。使う人は使うけど何をやっているのか全くわからないコマンドです。また、やっていることがわかっても実際に使ってみると、空白やクォーテーション文字でエラーになってしまう使い方がとても難しいコマンドです。この記事はそういうよくわからない xargs はどういうコマンドなのか解説します。この記事を読むと xargs を「完全に理解した」と言えるようになるでしょう。 xargs コマンドが難しい理由は、xargs 自体の設計や実装の問題で古い時代の制限が多いからです。仕様が意味不明で一貫性がなくで他のコマンドと正しく連携するのが困難です。そして本来の目的と違う用途に流用されてばかりです。最初にこの記事の結論を書いておきます。 xargs は難しすぎるコマンド、可能な限り使うな 昔と違い今はそんなに重要

はじめに readlink コマンドと realpath コマンドは、どちらもシンボリックリンクのリンク先を調べるコマンドです。readlink -f は realpath とほぼ同等です。 readlink はシンボリックリンクファイルのリンク先を調べるコマンド realpath はシンボリックを再帰的に解決し実際のパスを調べるコマンド readlink コマンドと realpath コマンドは多くの環境で使えるようになり、POSIX.1-2024 (Issue 8) で標準化されました。標準化は一般的に実装された後に行われます。ほとんどの環境ですでに実装ずみであるため、使ったことがある人は多いでしょう。もし古い使えない環境にも対応したい場合には、readlink -f と互換性がある readlinkf 関数を作っているので環境が対応するまでそれを使用して時間稼ぎができます。 read

はじめに kill コマンドと trap コマンドはシェルでシグナルの送信と受信を行うためのコマンドです。このコマンドは意外と適切ではない使われ方をよく見かけます。この記事では kill と trap の基礎知識を解説します。 関連記事: こちらに trap を利用した終了処理のコードを書きました。 trapを使ったシェルスクリプトの終了処理のテンプレ（POSIX準拠） POSIX準拠のkillコマンドの構文 POSIX で標準化されている kill コマンドの使い方は次のとおりです。POSIX で標準化されているというのは移植性が高い書き方ということを意味しています。シグナル名の指定には -s オプションが必要です。そして signal_name であって signal_number でないことに注意してください。POSIX シェルの世界にシグナル番号という概念はありません。シグナル番号

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

ファイルの末尾に改行が必要なのは「POSIXの仕様」だとする説がありますが、これは間違いで POSIX は標準規格で使用している「テキストファイル」の用語を定義しているだけです。 POSIX では「テキストファイル」という用語を、0行以上の行で構成されたファイルと定義しており、行とはヌル文字がを含まず末尾に改行がある LINE_MAX バイト（一般的に2048バイト）以内の文字列のことです。 詳細は以下を参照してください。 「POSIXがファイルの末尾に改行が必要と決めた」はガセネタ 1. read コマンドで改行がないデータを扱う この read コマンドを使った方法は POSIX で標準化された範囲のシェルの機能とコマンドの中では 最終行の末尾に改行がある場合とない場合を正しく区別できるという点で （おそらく）最も自然な形でシェルスクリプトで最終行に改行がないデータを扱う方法です。 改