これはbash 4.3.42とtcsh 6.19を使用するUbuntu 16.04にあります。
Xで未使用の仮想コンソールを開いてbashを実行すると、stdin、stdout、stderr、およびtty（明らかに）の専用ファイル記述子が表示されます。
$ cd /dev/fd
$ ls
0 1 2 255
$ ls -al .
... .
... ..
... 0 -> /dev/tty3
... 1 -> /dev/tty3
... 2 -> /dev/tty3
... 255 -> /dev/tty3
tcshを使用すると、ttyを指す5つの非std {in、out、err}ファイル記述子が表示され、std {in、out、err}はすべて/dev/null。
% cd /dev/fd
% ls -al
... .
... ..
... 0 -> /dev/null
... 1 -> /dev/null
... 15 -> /dev/tty3
... 16 -> /dev/tty3
... 17 -> /dev/tty3
... 18 -> /dev/tty3
... 19 -> /dev/tty3
... 2 -> /dev/null
ttyを指すにはなぜtcshそんなに多くのファイル記述子が必要なのですか？ 0、1、2をマッピングするとどのような利点がありますか/dev/null？これはtcsh、プロセスがコンソールに書き込んだり、コンソールから読み取ったりできるようにプロセスを分岐するときに、より多くの記録が必要であるという意味ではありませんか？
答え1
tcsh（驚くことではない）他の方法で構成されていますbash。どちらも古いものであり、細心の読者のための興味深い特徴でいっぱいです。
tcshこの違いは、ファイル記述子が管理される方法によって発生します。とは異なり、bashスクリプト作成者は番号付きファイル記述子を操作する方法を提供しません。開発者は、ファイル記述子を次のように構成するのが便利だと思います。移動する標準ストリームは「保存」領域（実際のスクリプトでは使用されません）に移動し、コマンドを実行すると重複対応するコマンド（つまり、子プロセス）閉鎖コマンドが完了すると表示されます。
ソースコードではsh.hこのようなブロックがあります。以下では、これらのファイル記述子の使用法について説明します。
/*
* The shell moves std in/out/diag and the old std input away from units
* 0, 1, and 2 so that it is easy to set up these standards for invoked
* commands.
*/
#define FSAFE 5 /* We keep the first 5 descriptors untouched */
#define FSHTTY 15 /* /dev/tty when manip pgrps */
#define FSHIN 16 /* Preferred desc for shell input */
#define FSHOUT 17 /* ... shell output */
#define FSHDIAG 18 /* ... shell diagnostics */
#define FOLDSTD 19 /* ... old std input */
両方のシェルには（少なくともLinuxの場合）、同じ「実際の」デバイスへの複数のリンクがあります/dev/fd。これは疑似ターミナルドライバの構成方法だからです。
tcshちなみに、別のシェルで実行すると、別の結果が表示されます。ただし、デフォルトのシェルがある場合は、tcsh質問で説明されているファイル記述子を表示できます。
答え2
これは設定（たとえば）tcshにあることがほぼ確実です。 stdin、stdout、stderrをリダイレクトするエントリを見つけます。~/.login~/.cshrc /etc/csh.*
私のシステムでこれを実行すると、次tcshのような結果が得られます。
$ tcsh
> ls -lF /dev/fd/
total 0
lrwx------ 1 cas cas 64 Jun 26 13:28 0 -> /dev/pts/29
lrwx------ 1 cas cas 64 Jun 26 13:28 1 -> /dev/pts/29
lrwx------ 1 cas cas 64 Jun 26 13:28 2 -> /dev/pts/29
lr-x------ 1 cas cas 64 Jun 26 13:28 3 -> /proc/16570/fd/