元々は /usr は user の略に決まってるじゃん？ホームディレクトリを置く場所だったんだから - Qiita
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. <..
なぜsortコマンドはuniq機能を含んでいるのか？（Unix哲学はどこ行った！？） - Qiita
Unix 哲学的に考えれば、行を並び替える sort コマンドと重複行を取り除く uniq コマンドは別のコマンドであるべきなように思えます。しかし sort コマンドには -u オプションとして uniq コマンドに相当する機能が組み込まれています。なぜそうなっている（そうなってしまった）のかを「ソフトウェア作法（さくほう）」を参照しながらこの記事で明らかにしたいと思います。 関連記事 Unix哲学「一つのことをうまくやる」は単機能のコマンドを作ることではない 「誰」がuniq機能をsortコマンドに組み込んだ！？ 熱烈的な Unix 哲学の信者は「どうせ Unix 哲学を理解しない GNU が便利だと思ってオプションを追加したのだろう」と考えるかもしれません。しかし uniq 機能が組み込まれたのは Version 7 Unix、つまり Unix の開発者が組み込んだのです。これは 1
【POSIX準拠】set -o pipefailを使おう！ただしdash、テメーはダメだ - Qiita
はじめに set -o pipefail は POSIX で標準化されているシェルオプションです。パイプラインにおけるエラーを確実に検出するために、シェルスクリプトでは基本的に使うようにしましょう。 某コメントより “set -o pipefail は標準化されました” っていってここ何年かの標準化を無邪気に正当化できるのいいなと思う(目の前のターミナルを見ながら) どのシェルを今使っているのか聞きたいですね。商用 Unix を含む主流の環境で、すでに何年（十数年、数十年）も前から set -o pipefail は実装済みなんですが？ おそらくシェルの事をよく知らないで言ってるのでしょう。私は標準化の有無は関係なく実際のシェルのことを調べ尽くして言ってるわけで無邪気に正当化とか失礼な話です。標準化とか気にしてるから何年（十数年、数十年）も前に実装された便利な機能が使えないんですよ。自業自
findコマンドの使い方を簡単に理解するための7つのルール＋実践的な知識 - Qiita
はじめに find コマンドの使い方は、ざっくり調べただけではよくわからんとなりますが、見逃しがちなルールを知れば簡単に理解できます。find コマンドに限りませんが使い方を調べるのが面倒だからと曖昧な理解で使うと逆にもっと分からなくなって時間がかかります。急がば回れ、理解して正しく使ったほうがシンプルで楽で簡単です。この記事では find コマンドの使い方を理解するために必要なルールと使い方の実践的な知識をまとめました。 Q&A（？）: -type や -perm の説明はしないの？ ⇒ それらはドキュメントを読むか検索すればすぐにわかることで難しいポイントではありません。重要なのは基本のルールを理解することです。 関連記事 POSIX 準拠のシェルスクリプトでは find | xargs よりも find -exec {} + を使うべき！ 移植性の話はこちら ⇒ findコマンドのオ
シェルスクリプトでlsをパイプでつなぐのはなぜ悪いのか ～ ShellCheck: SC2010, SC2011, SC2012 とファイル名改行問題 - Qiita
シェルスクリプトでlsをパイプでつなぐのはなぜ悪いのか ～ ShellCheck: SC2010, SC2011, SC2012 とファイル名改行問題ShellScriptUNIXshellシェル芸POSIX はじめに シェルスクリプトで ls コマンドの出力結果（ファイル名一覧）をパイプで他のコマンドに渡して処理するのは推奨されません。ls コマンドを使ったコードを ShellCheck で検査するとおそらく問題があると警告が表示されるでしょう。ls を使うなという指摘自体には賛成なのですが SC2010、SC2011、SC2012 に書いてある理由については正しい説明がされていないと思っています。この記事ではなぜ ls の出力結果を他のコマンドにパイプで渡すのが悪いのか、ls を使わずに実現するにはどうしたら良いのかを解説したいと思います。一つ補足をしておくと、この問題は CLI コマ
初学者のための正しいシェルとカーネルの概念 ～ 大学も技術者認定機関も間違いだらけ - Qiita
なんだろう、嘘つくのやめてもらっていいですか？ 大学も技術者認定機関も、いつまで古いまたは間違ったシェルとカーネルの概念を説明し続けるのでしょうか？ シェルはカーネルの言葉をユーザーの言葉に翻訳したり、出力結果をユーザーに中継したり、カーネルを防御したりする層ではありません。指定したコマンドを実行するだけのプログラムです。勉強中の学生か代理執筆業者が適当な文献を調べて書いたとしか思えません。そして他人の説明を自分の言葉に置き換えるのが上手い人がおかしな説明をさらに広めています。個人サイトやオンライン学習サイト程度であれば適当なことを書いていても気にも留めませんが、大学や技術者認定機関のような正しいことを書いているに違いないと思えるような所までもが間違ったことを書いているから困ったものです。 みなさんは大学や技術者認定機関が言っていることなら正しいと思いこんでいないでしょうか？ そんなことあ
シェルスクリプトの [ ] と [[ ]] の違いを歴史的に解説 〜 言語設計者の気持ちになって理解しよう - Qiita
はじめに bash などのシェルには [ ... ] と [[ ... ]] の二種類の比較方法があります。一つはコマンド、もう一つはシェルの文法なのですが、具体的にはこの二つは一体何が違うのでしょうか？ そもそもなぜ似ている機能が二つもあるのでしょうか？ この記事は言語設計者の気持ちになって考えることで、その理由を解き明かそうという記事です。 なお、違いについての簡単な説明については「test と [ と [[ コマンドの違い - 拡張 POSIX シェルスクリプト Advent Calendar 2013 - ダメ出し Blog 」の記事がよくまとめられていますので紹介します。一通りの違いを素早く知りたい方はこちらを参照してください。 参考 シェルの歴史や種類については「シェルの歴史 総まとめ（種類と系統図）と POSIX の役割」に詳しくまとめています（系統図とか頑張って書いたので見
![シェルスクリプトの [ ] と [[ ]] の違いを歴史的に解説 〜 言語設計者の気持ちになって理解しよう - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/647514abcaea7b5f8e1a1cdb8e496644eb63f609/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JUUzJTgyJUI3JUUzJTgyJUE3JUUzJTgzJUFCJUUzJTgyJUI5JUUzJTgyJUFGJUUzJTgzJUFBJUUzJTgzJTk3JUUzJTgzJTg4JUUzJTgxJUFFJTIwJTVCJTIwJTVEJTIwJUUzJTgxJUE4JTIwJTVCJTVCJTIwJTVEJTVEJTIwJUUzJTgxJUFFJUU5JTgxJTk1JUUzJTgxJTg0JUUzJTgyJTkyJUU2JUFEJUI0JUU1JThGJUIyJUU3JTlBJTg0JUUzJTgxJUFCJUU4JUE3JUEzJUU4JUFBJUFDJTIwJUUzJTgwJTlDJTIwJUU4JUE4JTgwJUU4JUFBJTlFJUU4JUE4JUFEJUU4JUE4JTg4JUU4JTgwJTg1JUUzJTgxJUFFJUU2JUIwJTk3JUU2JThDJTgxJUUzJTgxJUExJUUzJTgxJUFCJUUzJTgxJUFBJUUzJTgxJUEzJUUzJTgxJUE2JUU3JTkwJTg2JUU4JUE3JUEzJUUzJTgxJTk3JUUzJTgyJTg4JUUzJTgxJTg2JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz01MjNkMGI4OGJlMzhhMTc4N2JhMjc1NDk1ZjhkNjdmNA%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTcxNiZ0eHQ9JTQwa28xbmtzbSZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTMyJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9YzU4ZjdmNmRhMDNjMTE2MGZlNWU3ZTc5Y2Y2OTljYTk%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D93ef0dfa5f01edb32750f9b33392ebfc)
詳細解説 jqコマンドとシェルスクリプトの正しい使い方と考え方 〜 データの流れを制するUNIX哲学流シェルプログラミング - Qiita
詳細解説 jqコマンドとシェルスクリプトの正しい使い方と考え方 〜 データの流れを制するUNIX哲学流シェルプログラミングShellScriptUNIXシェル芸jqUnix哲学 はじめに シェルスクリプトから JSON データを処理する時に良く使われるのが jq コマンドです。しかしほとんどの人は jq コマンドとシェルスクリプトのつなぎ方を間違えています。jq コマンドの使い方が間違っているというより、シェルスクリプトの設計思想や考え方を正しく理解していないために、間違ったつなぎ方をしていると言った方がより正確でしょう。「シェルスクリプトは正しい書き方をすれば簡単になる」このことをこの記事では明らかにしています。 追記 「jqコマンドとシェルスクリプトの上手い速い使い方」に要約版を書きました。この記事は長すぎた…。 タイトルの「UNIX 哲学流」とは jq コマンドをフィルタして使い、J
シェルスクリプトで安全簡単な二重起動防止・排他/共有ロックの徹底解説 - Qiita
はじめに シェルスクリプトで二重起動防止やロックをする方法を検索すると、いろいろな方法や書き方が見つかりますが、どれを使えばよいのか、本当に正しく動くのか、不安になりますよね？ ディレクトリ (mkdir) やシンボリックリンク (ln) を使った独自実装の例も見かけますが、エラー発生時や予期せぬ電源断、CTRL+C で止めたときなどでも問題は発生しないのでしょうか？ まず、ディレクトリやシンボリックリンクを使った独自実装はしない。これを肝に銘じてください。シェルスクリプトでのロック管理はとても難しく、一般的な排他制御の知識に加えて、シェルスクリプト特有の問題、シグナルやトラップ、サブシェルや子プロセスの問題、さらには特定のシェル固有の仕様やバグなどさまざまな問題に対処する必要があり大変です。独自実装の例では古いロックファイルが残ってしまい、それをいつどのタイミングで片付ければ安全なのか？
シェルスクリプトを学ぶ人のための「新しいUNIX哲学」 〜 ソフトウェアツールという考え方 - Qiita
はじめに 「UNIX 哲学 (Unix philosophy)」とは、一つの大きなシステムを、独立した小さなソフトウェアの集まりとして作るという考え方です。UNIX のように大きく複雑なものをシンプルに作るための考え方で、技術的な用語で説明するならば、大きなシステムをモジュール化された構成可能なプログラム設計で開発するということです。 UNIX 哲学に公式の定義は存在しません。ケン・トンプソンを始めとする UNIX の創始者が UNIX の開発を通して示したソフトウェア開発の考え方が UNIX 哲学と言われるようになり、それを他の人が独自に解釈して解説したものが UNIX 哲学として知られています。UNIX 哲学と呼ばれているものが複数あって、それぞれで異なっているのはそのためです。UNIX 哲学の本質的な考え方は今も通じるものですが、これまでの UNIX 哲学の解説の多くは古い技術を元に
名著「UNIXという考え方 - UNIX哲学」は本当に名著なのか？ 〜 著者のガンカーズは何者なのかとことん調べてみた - Qiita
補足 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 年）
シェルスクリプトは変数代入で = の前後にスペースを置けない！･･･の本当の理由を知ると優れた文法が見えてくる - Qiita
シェルスクリプトは変数代入で = の前後にスペースを置けない！･･･の本当の理由を知ると優れた文法が見えてくるShellScriptBashUNIXshellPOSIX はじめに シェルスクリプトの変数代入で = の前後にスペースを置くことができない理由は、検索すれば「プログラマーの君！ 勘違いするな！ シェルスクリプトでは読みやすさのためにスペースを置くな！！ という話」のような記事がすぐに見つかります。記事に書いてあるとおり変数代入とコマンド呼び出しと区別がつかないからです。それは間違いではないんですが、私はもう少し説明が足りないと感じています。そこで今回は = の前後にスペースを置けない本当の理由を解説したいと思います。 の前に皆さんにはこの話を読みながら、自分がシェルスクリプトの言語設計者だったとしたら、どういう言語仕様にするかを考えて欲しいです。なぜかと言うとシェルスクリプトの文
POSIX 準拠のシェルスクリプトでは find | xargs よりも find -exec {} + を使うべき！ - Qiita
POSIX 準拠のシェルスクリプトでは find | xargs よりも find -exec {} + を使うべき！ShellScriptBashshellPOSIX はじめに find の出力を xargs にパイプで渡すというのはよく見かける使い方ですが、find -print0 | xargs -0 が使えない POSIX 準拠のシェルスクリプトでは find -exec {} + を使った方が良いです。安全かつ十分に速いからです。よく見かける -exec {} ; ではなく -exec {} + ですので間違えないようにしてください。多くのケースでは + の方が優れているのですが ; ばっかり使われているのを見ると、意外と知られてない気がします。 少しだけ予備知識として、-exec {} ; は -exec {} \; と ; をバックスラッシュでエスケープするのがよく見る使い方
なぜシェルスクリプトはPOSIX準拠でも環境依存が激しいのか？ 〜POSIXの問題点とその解決策の案〜 - Qiita
なぜシェルスクリプトはPOSIX準拠でも環境依存が激しいのか？ 〜POSIXの問題点とその解決策の案〜ShellScriptBashshellPOSIX まえがき この記事は「シェルスクリプトで高い移植性と生産性を両立させるシリーズ」の第一弾です。移植性と生産性を両立させるための前提知識として POSIX コマンドの問題点について解説します。第二弾では高い移植性と互換性を実現させるための考え方、そして第三弾、第四弾ではそれを実現するシェルスクリプトの具体的な実装テクニックを紹介します。第五弾では現実的な問題と回避方法について解説する予定ですがまだ具体的な内容は決まっていません。第五弾はその前に「シェルスクリプト入門（仮）」の記事を書こうと思ってるので少し遅くなると思います。もし興味がある方は記事をストックしていると更新時に通知されると思います。 2021-07-11 追記 記事が長くなった
POSIX準拠シェルスクリプトでマルチコアの能力を活用する並列処理の実装（最大並列数あり、GNU Parallel, xargsなし） - Qiita
実は最大並列数の制限がなければジョブ（標準入力からの一行単位のデータ）の数だけバックグラウンドプロセスを起動すればいいのでかなり簡単に実装できます。ですが普通は嫌ですよね？ということで最大並列数を制限する処理を入れています。また通常の利用で必要になりそうな 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
スクリプト言語としてみた各POSIXシェルの特徴と互換性上の注意点まとめ - Qiita
はじめに この記事は私の主観かつ知っていることをまとめたものです。古くからのシェルの専門家とかではなくここ数年の間に必要になった時にその都度調べたものなので間違いとかもあると思います。またタイトルの通りスクリプト言語としての比較です。つまりインタラクティブシェルの機能についての比較はしていません。（そもそも使い込んでるわけじゃないので知らないです。）POSIX シェルに限定しているのも私が他のシェルを詳しく知らないからです。もし今も使われていて（もしくは開発中で）ここに書かれていない POSIX シェルがありましたらコメントで教えて下さい。（※ csh, tcsh, fish は POSIX シェルではありません。） シェルの系統は少し古いですが「What does it mean to be “sh compatible”?」に投稿されている図が詳しくてわかりやすいです。またこちら「~s
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【脱sed】いい加減シェルスクリプトで文字列をsedで置換するなんてやめよう - Qiita