タグ付けされた質問 「history」

~（チルダ）がユーザーのホームディレクトリを表す理由をよく疑問に思います。この背後に理由がありますか、それともまれにしか使用されないキャラクターですか？

806 history  home 

実行ファイルへのパスを探したり、Unixシェルでコマンド名を入力する場合に何が起こるか確認する場合は、異なるユーティリティの茄多があります（which、type、command、whence、where、whereis、whatis、hash、など）。 which避けるべきだとよく耳にします。どうして？代わりに何を使うべきですか？

328 shell  history  which  portability 

私たちが知っているように、apt-getスーパーカウパワーをaptitude持っていますが、していません： $ apt-get --help | grep -i cow This APT has Super Cow Powers. $ aptitude --help | grep -i cow This aptitude does not have Super Cow Powers. そしてもちろん、APTにはイースターエッグがあります： $ apt-get moo (__) (oo) /------\/ / | || * /\---/\ ~~ ~~ ...."Have you mooed today?"... 私は興味があります、このイースターエッグの背後に物語がありますか？その歴史は何ですか？古いDebianリリースのaptソースの簡単なgrepから、それがDebian 2.2（potato; apt …

287 debian  apt  history 

万が一「リソース設定」ですか？

270 bash  bashrc  history 

wheel* nixのコンピュータ上のグループは、通常のルートのようなアクセスのいくつかの並べ替えを基を意味します。一部の* nixでは実行権限を持つユーザーのグループであると聞きましたsuが、Linuxでは誰でもあるようです（もちろん、rootパスワードが必要ですが）。私が使用したLinuxディストリビューションでは、デフォルトで使用する権利があるグループのようsudoです。sudoersそれらのためのエントリがあります： %wheel ALL=(ALL) ALL しかし、それはすべて接線です。私の実際の質問は次のとおりです。このグループはなぜ呼ばれwheelますか？以前にさまざまな説明を聞いたことがありますが、それらのいずれかが正しいかどうかはわかりません。誰が用語の実際の歴史を知っていますか？

220 sudo  history  group  su 

従来の圧縮ではなく、LZMA2に基づく形式をtar使用しxzて圧縮するアーカイブが増えていますbzip2(bz2)。実際、kernel.orgは2013年12月27日に「Good-bye bzip2」という最新の発表を行い、この時点からカーネルソースがtar.gzとtar.xzの両方の形式で、およびWebサイトのメインページでリリースされることを示しました直接提供されるのはですtar.xz。 これがなぜ起こっているのかgzip、この文脈での関連性を説明する特定の理由はありますか？

202 history  gzip  bzip2  xz 

そのため、HP-UX、AIX、BSDなど、UNIXにはさまざまなバージョンがあります。Linuxは、Unixの実装ではなく、Unixクローンと見なされます。すべての「本物の」ユニックスはオリジナルの実際の子孫ですか？そうでない場合、LinuxとUnixの違いは何ですか？

190 linux  unix  history 

実行するhashと、ハッシュが最後にリセットされてから実行されたすべてのコマンドのパスが表示されます（hash -r） [root@c04c ~]# hash hash: hash table empty [root@c04c ~]# whoami root [root@c04c ~]# hash hits command 1 /usr/bin/whoami [root@c04c ~]# whoami root [root@c04c ~]# hash hits command 2 /usr/bin/whoami マニュアルページによると、ハッシュの目的は次のとおりです。 / usr / bin / hashユーティリティは、現在のシェル環境が見つかったユーティリティの場所を記憶する方法に影響します。指定された引数に応じて、記憶されている場所のリストにユーティリティの場所を追加するか、リストの内容を削除します。引数が指定されていない場合、リストの内容について報告します。この-rオプションにより、シェルは記憶されているすべての場所を忘れます。 シェルにビルトインとして提供されるユーティリティは、ハッシュによって報告されません。 コマンドを何回入力したかを確認する以外に、のユーティリティが表示されませんhash。 thegeekstuff.comのトップ15の便利なコマンドにも取り上げられました どのような点でhash便利ですか？

118 bash  history 

POSIX仕様の全体にわたって、規定（があります1、2、3の実装は、2から始まるパスを治療することを可能にする...）/特別。 POSIXアプリケーション（すべてのPOSIX準拠システムに移植できるようにPOSIX仕様に記述されたアプリケーション）//foo/barは、それが同じであると想定することはできません/foo/bar（ただし///foo/bar、同じであると想定できます/foo/bar）。 今、//foo特別に扱うそれらのPOSIXシステム（歴史的で、まだ維持されている）は何ですか？私はPOSIXの提供がMicrosoftによってUnixバリアント（XENIX）とWindows POSIXレイヤー（おそらく誰でも確認できますか？）のためにプッシュされたと信じました（今では間違っていることが証明されました）。 これは、Microsoft WindowsのPOSIXのようなレイヤーでもあるCygwinによって使用されます。Microsoft Windows以外のシステムはありますか？OpenVMS？ //foo/bar特別なシステムでは、何に使用されますか？//host/pathネットワークファイルシステムにアクセスするには？仮想ファイルシステム？ Unixライクで実行される一部のアプリケーションは（システムのAPI //foo/barではない場合）、パスを特別に処理しますか（そうでなければ/foo/bar、ファイルシステム上のパスとして処理するコンテキストで）。 編集、それから私は//foo/bar仕様の取り扱いの起源についてオースティングループのメーリングリストで質問しました、そして議論は興味深い読み物です（少なくとも考古学の観点から）。

114 filenames  history  portability  slash 

Linuxは単なるカーネルであり、ユーザーがそれを使用する場合は、完全なディストリビューションが必要です。そうは言っても、Linuxディストリビューションがなかったとき、Linuxの最初のバージョンはどのように使用されましたか？

112 linux  kernel  linux-kernel  history 

Googleでこれについていくつか調査しましたが、結果は曇っていました。/ルートディレクトリを示すために記号が使用されるのはなぜですか。その背後にある確かな理由はありますか？

95 linux  directory-structure  history 

私の知る限り、すべてのオペレーティングシステムには、行末（EOL）文字をマークする異なる方法があります。商用オペレーティングシステムでは、EOLにキャリッジリターンを使用します（Windowsではキャリッジリターンとラインフィード、Macではキャリッジリターンのみ）。一方、LinuxはEOLにラインフィードを使用します。 LinuxがEOLにキャリッジリターンを使用しないのはなぜですか（代わりにラインフィードのみ）。

87 files  history  newlines 

読み取り/dev/randomはブロックされる場合がありますが、読み取り/dev/urandomはブロックされないことが保証されています。 手紙はどこにu来ますか？それは何を意味しますか？ ユーザースペース？ブロックを解除しますか？マイクロ？ 更新： 質問の最初の文言に基づいて、/dev/randomvs の有用性についていくつかの議論がありました/dev/urandom。/ dev / urandomについてのリンクMythsが以下に3回投稿されており、/ dev / random vs / dev / urandomを使用する場合の質問に対するこの回答にまとめられています。

87 linux  devices  history  random 

技術的な理由はありますか？これは初期のLinuxまたはUnixのアーティファクトですか？もしそうなら、それが持続する理由はありますか？

84 linux  users  history 

さまざまな場所で、今日の機能はディレクトリへの書き込み許可に影響を与え、制限付き削除フラグとして機能するため、今日の「スティッキービット」は完全に誤った呼び名であると非難されています。 AskUbuntuの回答で、回答者は「スティッキービットは通常ディレクトリに適用される」と書いています。実際、現代のシステムは実際にはファイルに適用しないように見えますが、昔は通常の場合、ディレクトリではなく（実行可能なプログラムイメージ）ファイルに適用されていました。（ファイルの現代的な使用の不足に関しては、「スティッキービットは現在のファイルシステムでは使用されていませんか？」に関連する質問があります。） これは質問を促しました： 実行可能ファイルに適用されたスティッキービットは何をしましたか？それはsetuidのようなものでしたか？ 過去形に注意してください。これはスティッキービットの仕組みではありませんか？今。それが当時の動作方法です。

65 permissions  history  sticky-bit