「」という理由はありますか？と「..」はls -aを実行した後に表示されますか？
ls -aを実行した場合
user@users-MacBook-Pro:~$ ls -a
. ..
.と..（現在のディレクトリと親ディレクトリ？）
ls -aの後に表示される理由はありますか何か面白いことをしていますか？
-aはすべてのファイルを表示することを意味するためです。 -lと組み合わせると便利です。 -lを使用しない場合にこれらの不要なファイルを表示する理由については、一貫性のため、およびUnixは何が良いかを二重に推測しようとしないためです。
これら2つ（-Aと..）を除外するオプション.（少なくともGNU ls）があります）があります。
興味深いことに、Unixでの隠しファイルのアイデアは、これら2つのファイルを隠そうとしたlsのバグによって生まれました。コードを単純にするために、元の実装では最初の文字のみをチェックしていました。人々はこれを使ってファイルを隠し、それが機能となり、隠しファイルを表示するために-aオプションが追加されました。後で誰かが、あなたと同じように、なぜ.と..が表示されるのか疑問に思っていました。 -Aオプションが生まれました。
注：Unixのファイルの意味は、あなたが持っているものよりもはるかに緩いです。
FILE⊇{通常のファイル、ディレクトリ、名前付きパイプ、unixソケット、シンボリックリンク、デバイス}。
そこに彼らが現れるポイントはあるのでしょうか？
所有権と権限が表示されます。これは多くの場合、2人のユーザーがいて、1人が期待していた相手のファイルを見ることができないと言っているときに確認する最も重要なことです。
https://ss64.com/bash/ls.html に示すように、-aパラメータをlsに追加すると.で始まるものも含め、すべてのエントリを取得します。それらは非表示のエントリと見なされ、単純なlsでは表示されません。
ls -aの後に表示される理由はありますか？
多くのことがそうであるように、それは単なる歴史的な事故だと思います。
Rob Pikeによる story によると、「隠された」ファイル（dotfiles）は何かの事故によって作成されました。
ずっと前に、Unixファイルシステムの設計が検討されていたときに、ナビゲーションを簡単にするために、エントリ
.および..が表示されました。確かではありませんが、バージョン2の書き換え中にファイルシステムが階層化された（初期の構造は非常に異なっていました）ときに..が使用されたと思います。ただし、lsと入力すると、これらのファイルが表示されたため、KenまたはDennisがプログラムに簡単なテストを追加しました。それは当時アセンブラでしたが、問題のコードは次のようなものと同等でした：if (name[0] == '.') continue;このステートメントは、本来あるべきものよりも少し短くなりました。
if (strcmp(name, ".") == 0 || strcmp(name, "..") == 0) continue;しかし、ちょっと、それは簡単でした。
2つのことが起こりました。
[...]2番目、さらに悪いことに、「非表示」または「ドット」ファイルのアイデアが作成されました。結果として、より遅延プログラマーは全員のホームディレクトリにファイルをドロップし始めました。
これに基づくと、ls -aが追加されて、これらの怠惰なプログラマーによって作成されたドットファイルを表示することを推測するのはそれほど難しくありません。そして、そのための単純な実装は、上記のテストを順番に無効にするだけで、再び.と..が表示されます。
履歴に関係なく、それらを表示するのは standard で指定された動作です。
-a
名前が<ピリオド>（ '。'）で始まるものを含め、すべてのディレクトリエントリを書き出します。
しかし、少し正気なことをするls -Aもあります。私はそれがどれだけ新しいかわかりません：
-A
名前が<ピリオド>（ '。'）で始まるものを含め、ドットとドットドット（存在する場合）を除くすべてのディレクトリエントリを書き出します。
彼らは何か面白いことをしますか？
単純なlsでそれらをリストすることはあまり面白くありません。
しかし、例えば.の/path/subdirは、/pathのsubdirを検索するのと同じiノードを提供します。ディレクトリの所有権とアクセス許可は、そこにあるファイルにアクセスできるユーザーを制御するため、.を介して情報を入手することもできます。ただし、ディレクトリ自体のプロパティが必要な場合は、いつでもls -ld .またはls -ld /path/subdirを実行できます。
このlsオプションでは、ls -a...ですべてのファイルを表示する必要があります.
しかし、ほとんどのファイルシステムでの.と..の物理的な存在は、コンピューターが非常に小さく、人々が小さなコードサイズのみを必要とする実装を見つけようとした1970年代の遺物です。これにより、現在のディレクトリと親ディレクトリへのハードリンクが作成されました。
30年以上もの間、これは間違いと見なされています。
実際、UNOS（1980年からの最初のUNIXクローン）には.と..がありませんでした。私のWOFS（書き込みファイルシステムの最初のコピー）とZFSにもありません。
POSIXで必要なのは、ファイル名を処理するsyscallsに渡されたときに、dir/.およびdir/..を期待どおりに処理することだけです。
残念ながら、今日のほとんどのソフトウェアは依然として不適切に記述されており、これらのエントリが欠落していると問題が発生します。これが、ZFSが存在をエミュレートする理由です...
その結果、ls -aが.および..の行を出力するかどうかは指定されていません。これはファイルシステムに依存します。 .と..の物理エントリが含まれておらず、それらを持っているように見せかけていないファイルシステム（ZFSなど）を使用している場合は、ls -ld . ..を呼び出す必要があります。
ところで、POSIXは最近、echo .*に.と..を含める必要はなくなりました。すべてのシェルがこのように動作すると、これは大きな勝利になります。
Unixでは（誤った言い方をすると、_._で始まるファイル/ディレクトリ名はlsで表示されませんでした（名前_._および_.._は、 「このディレクトリ」と「このディレクトリの親」であり、それらを表示することは役に立たないと考えられていました）。したがって、その奇妙なことに人々は「興味のない」ファイル（およびディレクトリ）に対して_.profile_または_.something-or-other-rc_（RCはRun Commandからの名前であり、もう1つの長い機能のないシステムのスタートアップファイル名）を使用し始めました。したがって、_ls -a_（show a ll）、そしてもちろん_._と_.._が表示されます
unixファイルシステムの設計が完成していたときに、エントリ。および..登場、ナビゲーションを容易にするため
そもそも、これらのエントリでの使用は、回答によって見られないようです。それらはどういうわけか階層的なリンクされたリストから生じます。 「簡単なナビゲーション」：lsではなく、readdir（3）などを使用するCプログラムで。
私は、ファイルシステムがバージョン2のリライト中に入ったと思います階層化になった
Ls -aの後に表示される理由はありますか、何か面白いことをしていますか？
A）はい（歴史的/技術的な理由）B）はい、cd ..に興味がないと思われる場合を除きます。 （または、グラフィカルファイルブラウザで（疑似）ファイル..をクリックします）
（OK、使用するために表示される必要はありません...それがオプションであり、-Aもある理由です）
Findでも空のディレクトリでそれを行います：
]# find
.
そのように私は知っています：findは何かを見つけました：何も。
]# stat . .. |grep Device
Device: 36h/54d Inode: 154051 Links: 6
Device: 803h/2051d Inode: 393219 Links: 26
]# cd /
]# stat . .. |grep Device
Device: 803h/2051d Inode: 2 Links: 18
Device: 803h/2051d Inode: 2 Links: 18
これは階層の上部を定義します。の家賃および..は、トップディレクトリ/で同一です。そして、あなたがそれに気づかない場合、cd ..はcd .と同じです。メッセージは表示されませんが、メッセージが表示されて機能するだけです。
POSIX.1では、フィールドd_nameおよび（XSI拡張として）d_inoのみが指定されています。 Linux以外のd_typeフィールドは、主にBSDシステムでのみ使用できます。
struct dirent {
ino_t d_ino; /* Inode number */
off_t d_off; /* Not an offset; see below */
unsigned short d_reclen; /* Length of this record */
unsigned char d_type; /* Type of file; not supported
by all filesystem types */
char d_name[256]; /* Null-terminated filename */
};
Readdir（）関数は、dirpが指すディレクトリストリーム内の次のディレクトリエントリを表すdirent構造体[へのポインタ]を返します。
タイプフィールドがないと、（ls）はファイル、ディレクトリ、またはパイプを通知する前に、iノードの内容を確認する必要があります。また、.と..がない場合、これらのiノードを変数に格納する必要があります。
これは、スクリプトとユーザーにとって、これらのエントリがナビゲーションを簡略化するとなる方法です。選択肢「1」は現在のディレクトリでそれを行い、.がdirとして含まれているふりをします。
]# select ans in $(ls -af); do ls -l $ans; done
1) .
2) ..
3) child3
4) child2
5) child1
#? 1
total 0
drwxr-xr-x 2 root root 40 Feb 21 07:36 child1
drwxr-xr-x 2 root root 60 Feb 21 07:40 child2
drwxr-xr-x 2 root root 60 Feb 21 07:40 child3
#? 2
total 0
drwxr-xr-x 5 root root 100 Feb 21 07:36 myself
drwxr-xr-x 2 root root 40 Feb 21 07:37 sibling1
drwxr-xr-x 2 root root 40 Feb 21 07:37 sibling2
#? 3
total 0
-rw-r--r-- 1 root root 0 Feb 21 07:40 f.b
#? 4
total 0
-rw-r--r-- 1 root root 0 Feb 21 07:40 f.a
#? 5
total 0
（それがcdsであり、新しいディレクトリを再度選択としてリストする場合、それ以上興味深いになります...）
Ls -aの後に表示される理由はありますか面白いことをしていますか？
まあ、それらはls -aの後に表示されます。これは-aがlsに切り替える機能だからです。 lsにドットで始まるファイルを表示するように要求しましたが、そうしました。申し訳ありませんが、これ以上の答えはありません。それが-aの目的です。
彼らが行う興味深いことは、相対パス指定を許可することです。ルートからの絶対パスとしてではなく、現在のデフォルトを基準にしてファイルの場所を指定できます。これは非常に便利であると同時に興味深いものです。
Unixライクなシステムの基本的な前提を明示的に述べた人はいません1：
これにはディレクトリも含まれます。
ls -aはすべてのファイルをリストし、ディレクトリはファイルです。つまり、.および..が含まれます。
「彼らは面白いことをしていますか？」
はい、彼らはやる。彼らはあなたに便利なリファレンスを提供します。 .は現在のディレクトリを表し、..は親ディレクトリを表します。これにより、mv /file/elsewhere .およびcd ..。もちろん、これは教訓であり、おそらくあなたはすでにこれを知っていました。 :)
1 @ ctrl-alt-delorの答えはそれを意味しますが。