元々は /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. <..
POSIXシェルスクリプトではwhichではなくcommand -vを使うべき理由（＋シェルスクリプト版which） - Qiita
重要 2022-01-30 追記 この記事で解説していた警告の出力は 2022-01-21 に取り消されました（参照 Revert deprecation of which）。そのため Debian which が GNU which に変わることは（少なくとも近い未来では）ないと思います。しかしながら which を使うよりは POSIX で規定されている command と type を使う方を推奨します。 はじめに which コマンドはシステムにインストールされてるとは限りません。実際に最小構成でインストールされてない環境として CentOS があります。一方 command -v は POSIX 規定されているので POSIX に準拠したどのシェルでも問題なく使えます。シェル上では which コマンドを使っても良いと思いますが、シェルスクリプトでは command -v を使う
Linux シグナルの基本と仕組み (カーネル v5.5 時点) - Qiita
この記事は、Linux シグナルの基本と仕組み (カーネルでの実装) について調査したことのまとめです。 シグナルは普段から利用しているものの仕組みについては理解してなかったので、カーネル勉強の題材として調べてみました。想像以上に複雑でボリュームがあったため、書き切れていない部分 (調査しきれなかった部分) もありますが、一通りの流れ (仕組み) は理解できたと思います。 なお、この記事は主に「■ 基本編」と「■ カーネル編 (v5.5)」で構成されています。仕組みを理解するには基本も知る必要があると思い、このような構成となっています。書籍レベルの基本を理解されている方は 「■ カーネル編 (v5.5)」 から読み進めることを推奨します。 ■ 基本編 はじめにシグナルの基本について、ざっと整理します。 なお、例で登場するコマンドや API (C 言語) の細かい使い方やエラー処理などは省き
圧縮されたtarの展開方法の変遷 - Qiita
私がやっていた圧縮されたtarの展開の仕方を書いてみる。 ～1992年 gzipが出る前。圧縮に使っていたのはcompressで圧縮したtarの拡張子はtar.Z。ファイルを伸長して標準出力に出力するzcatがあり、tar.Zを展開するときは
GNU man のイースターエッグが削除される | スラド Linux
GNU manに6年前から組み込まれていたイースターエッグが削除された。 このイースターエッグはmanを夜中過ぎ(0時30分)に引数なしまたは「-w」を付けて起動すると、stderrに「gimme gimme gimme」と出力されるもの。ABBAの「Gimme! Gimme! Gimme! (A Man After Midnight) 」にかけたジョークだったが、自動テストが失敗したという質問がStack Exchangeに投稿されて騒ぎとなり、ソースコードから削除されてしまった。
実行中プログラムのイメージを得る - tmtms のメモ
Twitter見てたらこんなこと言ってる人がいました。 Unix で実行中の実行ファイルのパスを確実に得る方法はない、というのは FAQ だと思うけど、実際にやりたいことは自分自身を別プロセスで新たに立ち上げたいということなので、メモリにロード済の自分自身から別プロセスを作る手段はないんだろうか— Yusuke Endoh (@mametter) 2017年10月25日 昔自分もそんなこと考えたなーと思いつつ、Linuxなら /proc/<pid>/exe が実行ファイルへのリンクになってるんで、 環境によるような気もするけど、自分の実行ファイルのパスは /proc/pid/exe から取れないですかね。— とみたまさひろ (@tmtms) 2017年10月25日 と言ってみたら、 Linuxならその手が使えますが、現在実行中の実行ファイルでも削除できちゃいますから、パス名を得る完璧な方法
systemdで複数の不具合が確認される | スラド IT
多くのLinuxディストリビューションで採用されているシステム管理ソフトウェア「systemd」で、複数の不具合が確認されています。1つは、ユーザー名を指定する個所で数字で始まるユーザー名を指定すると、そのユーザーの代わりに「root」が指定されたことになってしまうというもの（MA.TTIAS.BE）。 多くのUNIX系OSでは、ユーザー名にはアルファベット小文字と数字、アンダースコアのみが利用でき、さらに先頭には数字は指定できないとされています。そのため、報告を受けたsystemd開発者のLennart Poettering氏は、「数字で始まるユーザー名が不正なのであってsystemdのバグではない」と主張している。しかし、そのようなユーザー名がuseraddでは問題なく作成できたり、adduserでも設定により作成できると指摘され、氏はこう返答しました。「（1）systemdは色々なシ
知っておくべきUnixユーティリティー : lsof | Yakst
ファイルがどのようなプロセスやユーザなどに使われているのかを表示する lsof コマンドの使い方を網羅的に書いた記事。基本的なものから複数条件を指定したちょっと複雑な使い方まで。 これは、知っておくべきUnixやLinuxのユーティリティーに関するシリーズの3番目の記事です。この記事では、便利な lsof ツールについてお伝えしようと思います。 netcat がネットワーク接続のスイスアーミーナイフ(訳注 : 何でもできる便利なツールの意味)なら、 lsof はUnixのデバッグのスイスアーミーナイフであると言いたいところです。 lsof はUnix哲学に忠実に従っています。ひとつのタスクだけを完璧にこなす、つまり、プロセスによって開かれているファイルの情報を一覧にするだけです。開かれているファイルとは、通常のファイル、ディレクトリー、NFSのファイル、ブロックファイル、キャラクタースペシ
sedでこういう時はどう書く? - Qiita
シェルでデータ加工するときSEDをよく使いますが、その利用例と覚え書きです、参考になれば sedコマンドはLinux/Unix/BSD/OSXに標準で入っているので、Macの人なら覚えておくと捗るかも(Linuxとは少し違うのでそこは調べてね?) 当方の利用環境がRedhat系Linuxメインですので、微妙に書式が異なることがありますが、大体の書式は同じはずですので、そこは、ご容赦願います (4/15 ちょっと追加…) Windowsでもsed使いたいという人がいたので、ちょっと追記、以下のサイトからWindows用のバイナリを取得すれば、Windowsでもsedが使えます。WSLなどLinux環境を追加したくない、sedのコマンドだけほしい、PowerShellやプロンプトで使えればいいだけという人にお勧めです。 sed for Windows Site 使用例をいろいろ上げてみる '#
UNIXの設定ファイル中の平文パスワードを暗号化してセキュアにする方法 - 余白の書きなぐり
UNIX系の設定ファイルの中にパスワードを書くのは、あまりにインセキュアで躊躇われる。 たとえばCUIメーラーの雄 mutt で Gmail を使う場合、~/.muttrc に # ~/.muttrc for Gmail set imap_user = "YOUR.EMAIL@gmail.com" set imap_pass = "パスワード" set smtp_url = "smtp://YOUR.EMAIL@smtp.gmail.com:587/" set smtp_pass = "パスワード" といった具合にパスワードを書く必要がある。 参考: brew - mutt + Gmailを使ってCUIでのメール環境を作る - Qiita いくらなんでもセキュリティ的にアレすぎるので、平文のパスワードを暗号化してセキュアにしよう。 大抵のUNIXの設定ファイルには、外部ファイルを読み込む
GitHub - jlevy/the-art-of-command-line: Master the command line, in one page
Scope: This guide is for both beginners and experienced users. The goals are breadth (everything important), specificity (give concrete examples of the most common case), and brevity (avoid things that aren't essential or digressions you can easily look up elsewhere). Every tip is essential in some situation or significantly saves time over alternatives. This is written for Linux, with the excepti
シェルのリダイレクトの補遺 - 檜山正幸のキマイラ飼育記 (はてなBlog)
昨日書いた「シェルのリダイレクトを『こわいものなし』というくらい完全に理解しよう」に、随分とブックマークやトラックバックをいただきました。それらのフィードバックを拝見して、僕の説明にいたらない所があったと思いますので、ここで補足します。 コマンド実行単位≒simple command パイプ記号「|」や逐次実行の記号「;」を含んだ長いコマンドラインも、１つのコマンドとその引数、それとリダイレクト指定からなる“成分”に分解できます。こういった成分をなんと呼ぶか僕は知らないので、仮に「コマンド実行単位」とでも呼びましょう。 シェルの構文（grammar）的概念としてsimple commandというものがあります。ここで言ったコマンド実行単位は、ほぼsimple commandだと言っていいでしょう。「ほぼ」と付けたのは次の理由からです； 「コマンド実行単位」は、1つのプロセスを起動することを
シェルのリダイレクトを「こわいものなし」というくらい完全に理解しよう - 檜山正幸のキマイラ飼育記 (はてなBlog)
「Java BlockingQueueで遊ぶ：パイプラインごっこ」でパイプラインの話をしたので、本来の、つまりUnixのパイプやリダイレクトを少し調べてみました。 たまに話題となる some-command >file 2>&1 と some-command 2>&1 >fileの挙動の違いについて、「シェルはコマンドラインリダイレクトの指定を右から左に解釈実行する」なんて説明が見つかりました。んなバカな！ パージングは左から右にするものですよ。パーズツリーを逆順にたどることはできるけど、そんなことする必然性はなんにもないよ。 次の記事を読むと、「右から左」なんて事情じゃないことが分かるでしょう。 UNIXの部屋 検索: リダイレクト シェルのリダイレクトにまつわる失敗 さてここでは、複雑なリダイレクト処理も完全に理解できる処方箋を示しましょう。例えば、次のコマンドラインが何をするか分かる
Unixデーモンの仕組み
Home Subscribe Unixデーモンの仕組み 12 March 2015 おはこんばんちは!! 尾藤 a.k.a. BTO です。 みなさん、Unixデーモンよく使ってますよね。 Webエンジニアなら、Webサーバ、メールサーバ、DBサーバ、cronなどがよく使われるのではないでしょうか。 24時間365日黙々と働き続けるUnixデーモン達。 身近な存在だと思いますが、実はどういう仕組みで動いているのかご存じない方も多いのではないでしょうか。 先日、オトバンクでUnixデーモンの仕組みについて勉強会をやったので、その内容をまとめます。 デーモンとは では、デーモンとはいったい何なのでしょうか。 Unixライクシステムにおいて、バックグランドで動作して様々な処理を実行してくれるプロセスがデーモンです。 デーモンには明確な定義はありませんが、だいたい次のような条件を満たすプロセスが
process-book
この文書はなんですか？ この文書は*nix系のシステムにおけるプロセスやシグナルなどについて説明することを目的に書かれました。「プロセスとかよくわかってないからちゃんと知りたいな」みたいなひとたちが想定読者です。 書いているあいだは gist で管理されていたのですが、ボリュームが大きくなったので github で管理するように変えました。 目次 導入 プロセスの生成 プロセスとファイル入出力 ファイルディスクリプタ preforkサーバーを作ってみよう ゾンビプロセスと孤児プロセス シグナルとkill プロセスグループとフォアグランドプロセス epub と pdf epub化したもの、pdf化したものが release ディレクトリに入っています。thanks to mitukiii & moznion！ ライセンス この 作品 は クリエイティブ・コモンズ 表示 - 継承 3.0 非移
パイプとフィルタ ~ソフトウェア工学における有用なアーキテクチャ~ | POSTD
パイプライン は、最近のソフトウェアエンジニアリングにおいて、非常に便利な（そして驚くほど活用されていない）アーキテクチャパターンです。ソフトウェアでデータの流れを制御するためにパイプとフィルタを用いる考え方は、最初のUNIXシェルが作られた1970年代からあります。もしターミナルエミュレータでパイプ” | ”を使ったことがあるなら、”パイプとフィルタ”を活用できていることになります。以下の例を見てみましょう。 cat /usr/share/dict/words | # Read in the system's dictionary. grep purple | # Find words containing 'purple' awk '{print length($1), $1}' | # Count the letters in each word sort -n | # Sort l
cpで大量のファイルをコピーした（4億3200万件、39TB）
GNUのcpを使って大量のファイルをコピーしたところ、cpの設計上の問題で、極めてコピーが遅かったというお話。 My experience with using cp to copy a lot of files (432 millions, 39 TB) よう。俺は最近、大量のファイルをコピーする必要があったんだが、UNIXは20年もやってきた俺の経験からも、cpの挙動には驚かされたし、俺の意見はコミュニティに共有されるべきだと思う。 環境：古いDellのサーバー（2コア、初期メモリ2GB、追加して10GB、Ubuntu Trusty）と、新しいDellのストレージ格納機(MD 1200)にある、12個の4TBディスクでRAID 6が設定してあって、全体で40TBの要領を持ち、二つのドライブが同時に失敗しても問題ない環境。サーバーは遠隔地バックアップに使われていて、ディスクへの書き込みし
UNIXドメインソケット通信の内容を見たい - Qiita
UNIX domain socket 通信は同一マシン上のプロセス間通信にしか使えないというデメリットがありますが，tcp 通信よりも圧倒的にパフォーマンスが良いので要求仕様的に使わなければならない局面は多いと思います 今回はフロントに Nginx で proxy して同一マシン上の別プロセスで動いているアプリケーションサーバーに対して UNIX domain socket 通信を行う構成で実際のアプリケーションサーバーに流れている通信を見たい時にどうするか書きます 実際にトラブルが起こった時に実際にどのような通信が流れているのかは tcp 通信なら tcpdump をすれば見れますが，UNIX domain socket 通信の場合は容易に見ることが出来ないので実際のアプリケーションサーバーにどのような通信が流れているのか分かりません しかしアプリケーションサーバーにどのような通信が流れ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
shutdownコマンドとrebootコマンドの違いについて
GitHub - minoca/swiss: Unix multitool for Windows and Minoca OS
