サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
買ってよかったもの
qiita.com/ko1nksm
はじめに もう文字列の置換で sed コマンド使うの禁止して良いんじゃないですかね? 言いすぎだとわかってあえて言っていますが。 悪い書き方(外部コマンドに頼る方法) # 変数 line に入ってる文字列を echo コマンドで出力して sed コマンドに渡し、 # sed の s コマンドで "from" を "to" に置換して出力したものを ret 変数で受け取る ret=$(echo "$line" | sed "s/from/to/")
はじめに シェルスクリプトの if コマンドの使い方は覚えるのがとても簡単です。 if の一番単純な構文 if の一番単純な書き方(elif や else がない場合)は次のとおりです。 fi は if を逆に並べたものです。この文法の発想は歴史をたどると C 言語を含む多くの言語に影響を与えた ALGOL から来ており、Bourne シェルの開発者が ALGOL 68 コンパイラの開発に関わっていた影響です。Bourne シェルとは ash や bash や zsh の祖先のシェルで、今はほとんど使われることのない古いシェルの名前です(2025年1月1日でサポート終了する Solaris 10 を除く)。昔は sh = Bourne シェルという時代がありましたが、今は sh = さまざまな POSIX シェルのどれかです。POSIX シェルとは POSIX で標準化されているシェルの仕
$ awk 'BEGIN{print srand() + srand()}'; date +%s 1686750469 ← awk コマンドによる出力(1秒ズレている) 1686750468 ← date コマンドによる出力(date コマンドを使った Unix 時間の取得) $ readlink -f $(which awk) # awk の実体は GAWK /usr/bin/gawk このコードは書籍『「シェル芸」に効くAWK処方箋』で紹介されているコードで、「これは強力! AWKとパイプの新しい関係 ~ 時刻を取得する関数、Socket通信、双方向パイプ」や「第2回 月刊『シェルスクリプトマガジン 2014 November (Vol.19)」にも掲載されているようです。一応 Solaris 10.3 / 11.4 の POSIX awk (/usr/xpg4/bin/awk) に限
【初学者向け】内部コマンドと外部コマンドの違い ~ LinuxとWindowsの話を混ぜて解説するな!WindowsLinuxUNIX外部コマンド内部コマンド はじめに Linux では内部コマンドはシェルビルトインコマンドに相当します。bash などのシェルに組み込まれ個別の実行ファイルは存在しません。略してシェルビルトインやビルトインコマンド、日本語で組み込みコマンドなどと呼ばれることもありますが Linux では内部コマンドという用語はあまり使いません。内部コマンドとは主に Windows の世界で使われる用語で、コマンドプロンプトを起動した時に実行されるcmd.exe (Windows コマンド プロセッサ、コマンドラインインタプリタ)に組み込まれているコマンドのことです。例えばコマンドプロンプトから、存在しないコマンドを実行すると以下のように「内部コマンド」という用語が出力されま
はじめに フェアフィールドの公式とは西暦1年1月1日から何日目かを計算する日本でしか知られていない謎の公式です。発表は1949年(?)でツェラーの公式の1882年よりも後です。 365 y + \left\lfloor \frac{y}{4} \right\rfloor - \left\lfloor \frac{y}{100} \right\rfloor + \left\lfloor \frac{y}{400} \right\rfloor + \left\lfloor \frac{306 ( m + 1 )}{10} \right\rfloor + d - 428 ことの始まりは気まぐれに ChatGPT にフェアフィールドの公式を実装させてみようと思い立ったことです。たいして難しい式でもないので実装できるだろうと思っていたのですが、ChatGPT はフェアフィールドの公式を知らないと答え
この中で私が特に気に入ったコマンドは dateround です。次点は dategrep です。この二つは特に強力で、awk やその他のコマンドを使って日時をこねくり回すような「無駄に難解なコード」を書かずに Dateutils のコマンド群だけで大抵のことはなんでもできてしまいます。専用のことをするには専用のコマンドを作ることが重要であることを思い出させてくれるでしょう。 Dateutils の重要な特徴と使用例 大抵のコマンドは機能の説明から想像できると思いますし、公式サイトにも例があるので詳細を一つ一つ説明することはしません。その代わりに「Dateutils の使いこなしに必要な考え方」が分かるような例をいくつか紹介します。 重要な注意点ですが Dateutils はロケールをサポートしていますが、原則としてシステムのロケール情報やユーザーの環境変数には依存していません。内部にロケー
はじめに この記事は type, command, which 等を用途で使い分けたい人のための記事です。関連がある hash、whence、where や紛らわしい whereis、whatis、what についても解説しています。これらのコマンドは、コマンドの存在チェックでよく使われますが、本来の用途というものがあるわけでその違いと実際のシェルでの実装の注意点を解説しています。速度に関しては「Bashでコマンドの存在チェックはwhichよりhashの方が良いかも→いやtypeが最強→command -vも」ですでに記事があるので特に調べませんが、個人的には「シェルビルトインコマンドの方が速い」という考え方だけで十分だと思っています。 補足 この記事の Bourne シェル とは Solaris 10 の /bin/sh のことです。その他の(商用)UNIX の Bourne シェルでは
シェルスクリプト用の国際化ライブラリの決定版! sh-i18n を作りました ~ gettext.sh 代替・すべてのPOSIXシェルと環境に対応ShellScriptBash国際化GettextPOSIX はじめに POSIX 準拠でどの環境でも動くシェルスクリプト用の国際化ライブラリ sh-i18n を作りました。同様のライブラリとしては GNU gettext に含まれている gettext.sh が有名です。すでにライブラリがあるのになぜ作ったのかと言えば、gettext.sh は基本的に GNU gettext 専用で、書きづらく単一の書き方でどのシェルどの環境でも動くわけではなかったからです。一言で言えばすべての環境で動く完璧なシェルスクリプト用の国際化ライブラリを作りたかったのです。 ちなみにすべての環境で動くというのはおそらく嘘です。動かない環境は今のところ認知していません
はじめに envsubst コマンドはシェルスクリプトから使える簡易的なテンプレートエンジンとしてしばしば紹介されていますが、なぜこのような仕様になっているんだ?と疑問になるような仕様の機能を持っています。その理由は envsubst コマンドが本来 gettext.sh による国際化機能(翻訳処理)に伴う変数展開を安全に行うために作られたコマンドだからです。それを知らずに envsubst だけを見ていても使い方や仕様の意味はよくわからないでしょう。この記事では envsubst コマンドの奇妙な仕様はどのように使うもので、なぜこのような仕様になったのかについて説明します。 envsubt コマンドの使い方 基本機能(変数の展開) envsubt コマンドは簡易的なテンプレートエンジンのような機能を持っており、指定されたテンプレートに対して環境変数の値を埋め込むという処理を行います。よく
echoコマンドの移植性が低い歴史的理由とPOSIXの改定方針 ~ 次期POSIXでbashのechoはPOSIX準拠になる! はじめに 実は bash に組み込まれた echo コマンドは POSIX に準拠していません。しかし 2023 年に予定されている次期 POSIX (Issue 8) の改定で、POSIX 準拠の動作になります。🎉🎉🎉 私のこの言い方には違和感を感じるかもしれません。「POSIX に違反している bash が問題点を修正して、POSIX に準拠させるのではないのか?」と。いいえ違います。POSIX 側が仕様を修正することで、bash は何も変更せずに過去のバージョンも含めて POSIX に準拠するようになります。面白いですね。 この記事は echo コマンドの移植性の問題の歴史を振り返りながら、それを例に POSIX 標準化団体がどのような方針で標準規格を
はじめに Linux / Unix を使っていて ls コマンドを使ったことがない人はいないと思います。では ls コマンドの出力の「ファイル名」の部分はどのような形式で表示されているか、ご存知でしょうか? 普通のファイル名であれば単純にその名前が表示されます。しかしファイル名に空白や特殊な文字が含まれている場合はそうではありません。この記事では ls コマンドのファイル名がどのような形式で表示されているのかを解説したいと思います。 基礎知識 コマンドの出力形式は出力先で変化する ls コマンドに限りませんが、多くのコマンドは出力先が端末(画面)の場合とそれ以外の場合で出力形式を変えています。端末に出力する時は人間が見やすいようにし、それ以外への出力はデータとしてプログラムから扱いやすいようにするためです。例えば端末に出力するときには色がついていたり、画面幅に応じて自動的に出力を整形したり
シェルスクリプトでlsをパイプでつなぐのはなぜ悪いのか ~ ShellCheck: SC2010, SC2011, SC2012 とファイル名改行問題ShellScriptUNIXshellシェル芸POSIX はじめに シェルスクリプトで ls コマンドの出力結果(ファイル名一覧)をパイプで他のコマンドに渡して処理するのは推奨されません。ls コマンドを使ったコードを ShellCheck で検査するとおそらく問題があると警告が表示されるでしょう。ls を使うなという指摘自体には賛成なのですが SC2010、SC2011、SC2012 に書いてある理由については正しい説明がされていないと思っています。この記事ではなぜ ls の出力結果を他のコマンドにパイプで渡すのが悪いのか、ls を使わずに実現するにはどうしたら良いのかを解説したいと思います。一つ補足をしておくと、この問題は CLI コマ
まず位置パラメータを含め変数を参照する時にダブルクォートしないのは無しです。理由は予期せぬ変数展開やパス名展開が行われるからです。詳細は「シェルスクリプトの変数はダブルクォートしなければいけない!という話」を参照してください。この理由により上半分は「使いません」で終わりです。 ダブルクォートはほぼ必須ですが { } は必要な時だけ書けば十分です。常に ${var} のように { } を書く人がいるようですが、そういう人に限って面倒なのかダブルクォートをしてないことをよく見かけます。逆です。省略可能なのは { } であり、ダブルクォートは(本当に不要な場合を除き)省略できません。常に { } を使ってもかまわないと思いますがダブルクォートも書きましょう。 ❌ ${var} ・・・ ダブルクォートが抜けている! ⭕ "$var" ・・・ このように書け! ⭕ "${var}" ・・・ 問題ない
シェルスクリプトの正しい実行方法は一つだけ! ~ sh や source で実行するのが良くない理由とシバンの話ShellScriptBashLinuxUNIXshell はじめに なぜ「シェルスクリプトの実行方法は○つある」とか、ややこしい説明をするのだろうと不思議です。複数の手段を提示するのは初学者を混乱させるだけです。シェルスクリプトの推奨の実行方法はたった一つです。その他の方法には問題があるのだから(最初に)いくつも教える必要はないでしょう? 特に source を使って一般的なシェルスクリプトを実行してはいけません。全く使わないわけではありませんが同列に並べるようなものではありません。 推奨されるシェルスクリプトの実行方法は一つだけ シェルスクリプトは・・・というか、これはシェルスクリプトだけに限りません。どの言語で作ったプログラムでも同じですが、Unix / Linux でプロ
なんだろう、嘘つくのやめてもらっていいですか? 大学も技術者認定機関も、いつまで古いまたは間違ったシェルとカーネルの概念を説明し続けるのでしょうか? シェルはカーネルの言葉をユーザーの言葉に翻訳したり、出力結果をユーザーに中継したり、カーネルを防御したりする層ではありません。指定したコマンドを実行するだけのプログラムです。勉強中の学生か代理執筆業者が適当な文献を調べて書いたとしか思えません。そして他人の説明を自分の言葉に置き換えるのが上手い人がおかしな説明をさらに広めています。個人サイトやオンライン学習サイト程度であれば適当なことを書いていても気にも留めませんが、大学や技術者認定機関のような正しいことを書いているに違いないと思えるような所までもが間違ったことを書いているから困ったものです。 みなさんは大学や技術者認定機関が言っていることなら正しいと思いこんでいないでしょうか? そんなことあ
はじめに bash などのシェルには [ ... ] と [[ ... ]] の二種類の比較方法があります。一つはコマンド、もう一つはシェルの文法なのですが、具体的にはこの二つは一体何が違うのでしょうか? そもそもなぜ似ている機能が二つもあるのでしょうか? この記事は言語設計者の気持ちになって考えることで、その理由を解き明かそうという記事です。 なお、違いについての簡単な説明については「test と [ と [[ コマンドの違い - 拡張 POSIX シェルスクリプト Advent Calendar 2013 - ダメ出し Blog 」の記事がよくまとめられていますので紹介します。一通りの違いを素早く知りたい方はこちらを参照してください。 参考 シェルの歴史や種類については「シェルの歴史 総まとめ(種類と系統図)と POSIX の役割」に詳しくまとめています(系統図とか頑張って書いたので見
はじめに どこからでもシェルスクリプトを実行できるようにと、冒頭でカレントディレクトリを移動するコードをベストプラクティスかのように書いてある記事がいくつかありますが、それは違います。例えば以下のようなコードは良くないコードです。 # スクリプトのある場所にカレントディレクトリを移動してはいけない cd "$(dirname "$0")" # 上記のやたらと面倒な書き方 WORKDIR=$(cd "$(dirname "$0")" && pwd) cd "$WORKDIR" 絶対に書いたらだめなのか?と聞かれるなら、理由をわかった上で「手抜きとして」なら書いても良いと思いますが、ベストプラクティスではありません。 補足 上記のコードは問題点を示すサンプルコードです。他にも cd が失敗した場合などの別の問題がありますが、この記事の内容とは無関係なので意図的に省略しています。私は set -
シェルの歴史 総まとめ(種類と系統図)と POSIX の役割 〜 シェルスクリプトの現在・過去・未来【POSIX改訂間近】ShellScriptBashUNIXPOSIXksh はじめに Linux / Unix をターミナルから使う時に使用するソフトウェアがシェルです。シェルの役目は CLI ベースのユーザーインターフェースとしてユーザーからの操作でプログラム(主に CLI コマンド)の実行を仲介したり、その操作を自動化するためのシェルスクリプトを実行する機能を持っています。現在最も使用されているシェルは GNU プロジェクトが開発している bash ですが、OS によって異なるさまざまなシェルが使われています。 シェルの最低限の仕様は POSIX で標準化されています。この標準規格に準拠しているシェルは「POSIX(準拠)シェル」と一般的に呼ばれています。シェルは大別すると「POSIX
はじめに シェルスクリプトを遅くする原因は「外部コマンドの呼び出し」と「サブシェルの生成」です。 シェル自身が持っている機能、if や case と言った条件分岐、for や while や until などのループ、関数呼び出し、変数展開 (${var...})、算術式展開($((...)))、 [ ... ] や read や echo や eval などのシェルビルトインコマンド、そのような部分がシェルスクリプトの遅い原因となることはほとんどありません。 シェルスクリプトはインタプリタ言語だから遅いという指摘がありますが、それは正しい認識ではありません。確かにコンパイラ言語より遅いのは事実ですが、それでもシェル自身が持っている機能だけを使っていれば、シェルスクリプトが実用にならないレベルで遅くなるようなことはありません。「外部コマンドの呼び出し」と「サブシェルの生成」を減らせば、シェ
詳細解説 jqコマンドとシェルスクリプトの正しい使い方と考え方 〜 データの流れを制するUNIX哲学流シェルプログラミングShellScriptUNIXシェル芸jqUnix哲学 はじめに シェルスクリプトから JSON データを処理する時に良く使われるのが jq コマンドです。しかしほとんどの人は jq コマンドとシェルスクリプトのつなぎ方を間違えています。jq コマンドの使い方が間違っているというより、シェルスクリプトの設計思想や考え方を正しく理解していないために、間違ったつなぎ方をしていると言った方がより正確でしょう。「シェルスクリプトは正しい書き方をすれば簡単になる」このことをこの記事では明らかにしています。 追記 「jqコマンドとシェルスクリプトの上手い速い使い方」に要約版を書きました。この記事は長すぎた…。 タイトルの「UNIX 哲学流」とは jq コマンドをフィルタして使い、J
はじめに 1992 年に POSIX でシェルが標準化されて以来、シェルスクリプトの数値計算に expr コマンドは使いません。expr コマンドを使って計算していたのは Bourne シェル(古い UNIX の sh)時代の話で、現在の POSIX sh (dash、bash、ksh 等)時代では数値計算に expr コマンドは不要です。今どきはシェルの機能だけで整数の計算を行うことができます。「今どき」って一体いつからだって話なわけですが……。 注意 シェルスクリプトでパフォーマンスの話をするとすぐに「他の言語で〜」という方がいますが、私はどんなことにでもシェルスクリプトを使えなんて一言も言っていません。パフォーマンスを気にしている理由は、そこが実際にシェルスクリプトのボトルネックになるポイントだからです。そもそもシェルスクリプトと一般的な言語は言語設計レベルで得意なことが違います。ユ
はじめに 一部の POSIX シェルには、シェル自体に正規表現対応の機能が含まれており、外部コマンドに依存せずに正規表現による比較を行えます。すべての POSIX シェルで使えるわけではありませんが、シェルに含まれている機能であるため環境の違いを気にする必要はなくパフォーマンスも良いというメリットがあります。しかし正規表現に対応している bash、ksh、yash、zsh で、実装にそれぞれ違いがあります。この記事ではその違いをまとめました。現時点でのそれぞれの最新版である bash 5.2、ksh 93u+m/1.0.3、yash 2.53、zsh 5.9 で動作確認しています。 なお POSIX 正規表現の話や、コマンド(POSIX コマンド・UNIX コマンド)で正規表現を使用する場合の注意点などは「シェルスクリプトの正規表現の詳細解説(令和最新版)〜 基本正規表現(BRE)と拡張正
はじめに シェルスクリプトで二重起動防止やロックをする方法を検索すると、いろいろな方法や書き方が見つかりますが、どれを使えばよいのか、本当に正しく動くのか、不安になりますよね? ディレクトリ (mkdir) やシンボリックリンク (ln) を使った独自実装の例も見かけますが、エラー発生時や予期せぬ電源断、CTRL+C で止めたときなどでも問題は発生しないのでしょうか? まず、ディレクトリやシンボリックリンクを使った独自実装はしない。これを肝に銘じてください。シェルスクリプトでのロック管理はとても難しく、一般的な排他制御の知識に加えて、シェルスクリプト特有の問題、シグナルやトラップ、サブシェルや子プロセスの問題、さらには特定のシェル固有の仕様やバグなどさまざまな問題に対処する必要があり大変です。独自実装の例では古いロックファイルが残ってしまい、それをいつどのタイミングで片付ければ安全なのか?
BusyBox for Windows BusyBox for Windows (BusyBox-w32) は Busybox の Windows 移植版です。トップページを見ると、どうやら 2021 年の 10 月頃に BusyBox-w32 から BusyBox for Windows に名前が変わっているような気がします。確かにもう 32 ビットの時代ではないですからね……。でも GitHub は busybox-w32 のようですが。ちなみに 64ビット版バイナリもあります。 これの何がすごいのか? インストールは実行ファイル一つをコピーするだけ。環境を汚しません。 ash 系のシェルを改良していくつかの bash の機能が追加されたシェルが含まれています。 シェルスクリプトでよく使うコマンド(sed や awk 等)の多くが含まれています。 最新のプレリリース版(busybox-
はじめに mkfifo コマンドはシェルスクリプトの初心者にとって何に使うのか分かりづらいコマンドの一つだと思います。mkfifo コマンドの説明として「名前付きパイプ (FIFO) を作成する」と言われても、名前付きパイプとはなにか?それで何が出来るのか?どのように使うのか?が詳しく説明されていないのがその原因の一つではないかと思います。シェルスクリプトにおける mkfifo や名前付きパイプに関する解説記事も検索するといくつか見つかるのですが、解説や検証が中途半端だったり間違いや奇妙なシェルスクリプトがあったりします。 mkfifo コマンドがあまり知られていないもう一つの原因は使う必要があまりないからです。名前付きパイプを使う例の一つは、厳密に POSIX に準拠したシェルスクリプトを書く場合です。bash などの拡張機能を持つシェルに備わっている「プロセス置換」相当のことを das
最強uconvコマンドで全角⇔半角, ひらがな⇔カタカナ, 大文字⇔小文字の変換をシェルスクリプトで行うShellScriptBashnkfシェル芸uconv はじめに uconv は ICU が開発した文字変換のコマンドです。文字コードを変換したり、全角を半角に変換したり、大文字を小文字に変換したり、ひらがなをカタカナに変換したりする場合、tr コマンドや nkf コマンドを使って変換するという例を多く見かけます。しかし tr コマンドは Unicode に対応していなかったり POSIX ロケール以外の対応に問題があったりします。また nkf コマンドは Network Kanji Filter の略であることからもわかるように基本的に日本語にしか対応していません。そういった時に使えるのが uconv コマンドです。uconv コマンドはあらゆる国の文字種や文字コード変換に対応しており
はじめに この記事は UNIX コマンド(POSIX コマンド)で使える正規表現(基本正規表現 BRE と拡張正規表現 ERE)を正しく理解したい人のための記事です。正規表現とはなにか?みたいな基本的な話はしません。他のプログラミング言語で使ってるから正規表現自体は知ってるつもりだけど、シェルスクリプトだといつもの正規表現が使えず苦手だという人のために、シェルスクリプトにおける正規表現を深く理解できるような内容にしています。 基本的に POSIX に準拠した内容を中心に解説しており、どの環境にも対応した内容にしています。さらに Linux (GNU) や BSD や macOS の環境固有の拡張された正規表現、歴史的な UNIX コマンドの話や各コマンド毎の細かい違いなど、実際に使う上で必要な知識も解説しています。 注意 bash 等のシェルの正規表現についてはこの記事では詳しく扱っていま
はじめに 「UNIX 哲学 (Unix philosophy)」とは、一つの大きなシステムを、独立した小さなソフトウェアの集まりとして作るという考え方です。UNIX のように大きく複雑なものをシンプルに作るための考え方で、技術的な用語で説明するならば、大きなシステムをモジュール化された構成可能なプログラム設計で開発するということです。 UNIX 哲学に公式の定義は存在しません。ケン・トンプソンを始めとする UNIX の創始者が UNIX の開発を通して示したソフトウェア開発の考え方が UNIX 哲学と言われるようになり、それを他の人が独自に解釈して解説したものが UNIX 哲学として知られています。UNIX 哲学と呼ばれているものが複数あって、それぞれで異なっているのはそのためです。UNIX 哲学の本質的な考え方は今も通じるものですが、これまでの UNIX 哲学の解説の多くは古い技術を元に
補足 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 年)
次のページ
このページを最初にブックマークしてみませんか?
『@ko1nksmのマイページ - Qiita』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く