「すべてがファイルです」は少しglibです。「ファイルシステムのどこかに表示されるものはすべて」マークに近く、それでもシステム設計の法則よりも理想的です。
たとえば、Unixドメインソケットはファイルではありませんが、ファイルシステムには表示されます。あなたはできるls -lドメインソケットは、その属性を表示するにはcat、1から/へデータを介して、そのアクセス制御を変更するchmodなど
ただし、通常のTCP / IPネットワークソケットは、Unixドメインソケットと同じBSDソケットシステムコールで作成および操作されますが、TCP / IPソケットはファイルシステムに表示されません。¹本当だ。
ファイルシステムに表示される非ファイルオブジェクトの別の例は、Linuxの/procファイルシステムです。この機能は、カーネルの実行時操作に関する多くの詳細をユーザー空間に公開します。ほとんどは仮想プレーンテキストファイルです。多くの/procエントリは読み取り専用ですが、多くのエントリは/proc書き込み可能でもあるため、ファイルを変更できるプログラムを使用してシステムの実行方法を変更できます。残念なことに、ここでも非理想性があります。BSDタイプのUnixは一般になし/procで実行され、System V Unix /procはLinuxよりもはるかに少ないビアを公開します。
MS Windowsとは対照的ではありません
第一に、この点でUnixがファイルI / Oについてすべてであり、Windowsが「壊れている」ことについてのオンラインおよび書籍で見られる感情の多くは時代遅れです。Windows NTはこれの多くを修正しました。
Windowsの最新バージョンは、Unixと同様に統合I / Oシステムを備えているため、必要に応じReadFile()てWindows Sockets固有のAPIではなく、TCP / IPソケットからネットワークデータを読み取ることができますWSARecv()。これは、一般的なUnixシステムコールまたはソケット固有のコールを使用してネットワークソケットから読み取ることができるUnix Wayとまったく同じです。²read(2)recv(2)
それにも関わらず、Windowsはこの概念をUnixと同じレベルに引き継ぐことができません。ここでも2018年です。いくつかの例：
ドライバー。
Windowsのドライバーサブシステムは、Unixのように簡単にリッチで強力ですが、ドライバーを操作するプログラムを作成するには、通常、Windows Driver Kitを使用する必要があります。つまり、Cまたは.NETコードを作成します。
UnixタイプのOSでは、コマンドラインからドライバーに多くのことができます。不要な出力を/dev/null.³にリダイレクトする場合のみ、ほぼ確実にこれを既に実行しています。
プログラム間通信。
Windowsプログラムは互いに簡単に通信しません。
Unixコマンドラインプログラムは、テキストストリームとパイプを介して簡単に通信します。多くの場合、GUIプログラムはコマンドラインプログラムの上に構築されるか、テキストコマンドインターフェイスをエクスポートするため、同じ単純なテキストベースの通信メカニズムがGUIプログラムでも機能します。
レジストリ。
Unixには、Windowsレジストリに直接相当するものはありません。同じ情報がファイルシステム全体に散らばっています。そのほとんどは/etc、/procとにあり/sysます。
Windowsレジストリに対するドライバー、パイプ、およびUnixの回答が「すべてがファイルである」と関係があることがわからない場合は、読み進めてください。
「すべてがファイルである」という哲学は、ここでどのように違いをもたらしますか？
これについては、上記の3つのポイントを詳しく説明して説明します。
長い答え、パート1：ドライブとデバイスファイル
CFカードリーダーがE:Windowsおよび/dev/sdcLinuxのように表示されているとします。どのような実際的な違いがありますか？
単なる小さな構文の違いではありません。
Linuxでは、dd if=/dev/zero of=/dev/sdcの内容/dev/sdcをゼロで上書きすることができます。
それが何を意味するかを考えてください。ここに、通常のユーザー空間プログラム（dd(1)）があり、仮想デバイス（/dev/zero）からデータを読み取っ/dev/sdcて、統合Unixファイルシステムを介して実際の物理デバイス（）にデータを書き込むように要求しました。dd特殊なデバイスからの読み取りと書き込みを行っていることを知りません。以下に示すように、通常のファイルでも、デバイスとファイルが混在していても機能します。
E:Windowsはファイルとドライブを区別するため、Windowsでドライブをゼロにする簡単な方法はありません。同じコマンドを使用してそれらを操作することはできません。最も近い方法は、Quick Formatオプションなしでディスクフォーマットを実行することです。これにより、ドライブの内容のほとんどがゼロになりますが、その上に新しいファイルシステムが書き込まれます。私は何をしていない場合たく新しいファイルシステムを？ディスクをゼロ以外の何物でも満たしたくない場合はどうすればよいですか？
寛大になりましょう、私たちは本当に新鮮な新しいファイルシステムが欲しいと言っていますE:。Windowsのプログラムでこれを行うには、特別なフォーマットAPIを呼び出す必要があります。Linuxでは、OSの「フォーマットディスク」機能にアクセスするためのプログラムを作成する必要はありません。：あなたはちょうどあなたが作成したいファイルシステムタイプのために適切なユーザ空間のプログラムを実行しmkfs.ext4、mkfs.xfsまたは何を持っています。これらのプログラムは、/dev渡したファイルまたはノードにファイルシステムを書き込みます。
のでmkfsUnixyシステム上のタイプのプログラムは、デバイスと通常のファイルの間で人工の区別をせずにファイルで作業、それは私が作成できることを意味しますext4ファイルシステムを自分のLinuxボックス上の通常のファイル内：
$ dd if=/dev/zero of=myfs bs=1k count=1k
$ mkfs.ext4 -F myfs
文字通り、現在のディレクトリに1 MiBのディスクイメージが作成されmyfsます。次に、他の外部ファイルシステムであるかのようにマウントできます。
$ mkdir mountpoint
$ sudo mount -o loop myfs mountpoint
$ grep $USER /etc/passwd > mountpoint/my-passwd-entry
$ sudo umount mountpoint
これでmy-passwd-entry、ユーザーの/etc/passwdエントリを含むファイルが呼び出されたext4ディスクイメージができました。
必要に応じて、その画像をCFカードにブラストできます。
$ sudo dd if=myfs of=/dev/sdc1
または、そのディスクイメージをまとめて郵送し、USBメモリスティックなど、選択したメディアに書き込むことができます。
$ gzip myfs
$ echo "Here's the disk image I promised to send you." |
mutt -a myfs.gz -s "Password file disk image" you@example.com
Linux⁵では、ファイル、ファイルシステム、デバイスの間に人為的な区別がないため、これらすべてが可能です。Unixシステム上の多くのものは、ファイルであるか、ファイルシステムを介してアクセスされるため、ファイルのように見えます。
Windowsのファイルシステムの概念は寄せ集めです。ディレクトリ、ドライブ、ネットワークリソースを区別します。3つの異なる構文があり、すべてWindowsでブレンドされています：Unixのような..\FOO\BARパスシステム、などのドライブ文字C:、などのUNCパス\\SERVER\PATH\FILE.TXT。これは、単一の一貫した設計ではなく、Unix、CP / M、MS-DOS、およびLAN Managerからのアイデアの集積であるためです。Windowsファイル名に非常に多くの不正な文字が含まれているのはこのためです。
Unixには統一されたファイルシステムがあり、すべてが単一の共通スキームによってアクセスされます。Linuxのボックスで実行されているプログラムでは、、、およびの間/etc/passwdに機能的な違いはありません。ローカルファイル、外部メディア、ネットワーク共有はすべて同じように扱われます。⁶/media/CF_CARD/etc/passwd/mnt/server/etc/passwd
Windowsは上記のディスクイメージの例と同様の目的を達成できますが、非常に才能のあるプログラマーによって作成された特別なプログラムを使用する必要があります。これが、Windowsに非常に多くの「仮想DVD」タイプのプログラムがある理由です。コアOS機能の欠如により、ギャップを埋めるプログラムの人工市場が作成されました。つまり、最高の仮想DVDタイプのプログラムを作成するために競合する多くの人々がいることを意味します。ループデバイスを使用してISOディスクイメージをマウントするだけなので、* ixシステムではこのようなプログラムは必要ありません。
同じことは、ディスク消去プログラムのような他のツールにも当てはまります。これは、Unixシステムでは必要ありません。CFカードのコンテンツをゼロに戻すのではなく、回復不能にスクランブルしたいですか？さて、/dev/random代わりにデータソースとして使用して/dev/zeroください：
$ sudo dd if=/dev/random of=/dev/sdc
Linuxでは、コアOSの機能が十分に機能するだけでなく、広く使用されるほど機能するため、このような車輪の再発明を続けません。Linuxボックスをブートするための一般的なスキームには、上記のような手法を使用して作成された仮想ディスクイメージが含まれます。
私はそれはUnixが最初からファイルシステムにTCP / IP I / Oを統合した場合、我々は持っていないことを指摘するだけ公正だと感じnetcat対socat対Ncat対混乱の原因は同じデザインの弱点だったリードにあることをWindowsでのディスクイメージングとワイピングツールの普及：許容できるOS機能の欠如。nc
ロングアンサー、パート2：仮想ファイルとしてのパイプ
DOSにルーツがありますが、Windowsにはコマンドラインの伝統がありません。
これは、Windowsはしないと言っているわけではない必要があり、コマンドラインを、またはそれは、多くのコマンドラインプログラムを欠いていること。Windowsには、PowerShellと呼ばれる非常に強力なコマンドシェルさえあります。
それでも、このコマンドラインの伝統の欠如のノックオン効果があります。DISKPARTほとんどの人はコンピューターの管理MMCスナップインを使用してディスクのパーティション分割などを行うため、Windowsの世界ではほとんど知られていないツールを入手できます。次に、パーティションの作成をスクリプト化する必要がある場合、DISKPART別のプログラムによって駆動されるように実際に作成されていないことがわかります。はい、一連のコマンドをスクリプトファイルに書き込み、を介して実行できますDISKPART /S scriptfileが、それはすべてか無かです。あなたがそのような状況で本当に欲しいのはGNUのpartedようなものparted /dev/sdb mklabel gptです。これにより、スクリプトでエラー処理を段階的に行うことができます。
これはすべて「すべてがファイル」と関係がありますか？簡単：パイプはコマンドラインプログラムのI / Oを一種の「ファイル」に変換します。パイプは単方向ストリームであり、通常のディスクファイルのようなランダムアクセスではありませんが、多くの場合、違いは重要ではありません。重要なことは、独立して開発された2つのプログラムを添付して、簡単なテキストで通信できるようにすることです。その意味で、Unix Wayを念頭に置いて設計された2つのプログラムは通信できます。
ファイルが本当に必要な場合は、プログラムの出力をファイルに簡単に変換できます。
$ some-program --some --args > myfile
$ vi myfile
しかし、「すべてがファイルである」という哲学がより良い方法を提供するのに、なぜ出力を一時ファイルに書き込むのでしょうか？必要なのがそのコマンドの出力をviエディターバッファーに読み込むviことだけであれば、直接それを行うことができます。vi「ノーマル」モード、言います：
:r !some-program --some --args
これにより、そのプログラムの出力がアクティブなエディターバッファーの現在のカーソル位置に挿入されます。内部でviは、パイプを使用して、プログラムの出力を、ファイルからの読み取りに使用するのと同じOS呼び出しを使用するコードの一部に接続しています。の2つのケース（:rつまり、ありとなし）の!両方が、のすべての一般的な実装で同じ汎用データ読み取りループを使用したとしても、私は驚かないでしょうvi。しない理由は考えられません。
これもの最近の機能ではありませんvi。古代のed(1)テキストエディターに戻ります。⁸
この強力なアイデアは、Unixで何度も登場します。
この2番目の例については、mutt上記の私のメールコマンドを思い出してください。これを2つの別個のコマンドとして記述しなければならなかった唯一の理由は、一時ファイルに名前を付け*.gzて、電子メールの添付ファイルに正しい名前を付けることでした。ファイルの名前を気にしないのであれば、プロセス置換を使用して一時ファイルの作成を回避することもできます。
$ echo "Here's the disk image I promised to send you." |
mutt -a <(gzip -c myfs) -s "Password file disk image" you@example.com
これは、出力をgzip -cFIFO（ファイルのようなもの）または/dev/fdオブジェクト（ファイルのようなもの）に変えることにより、一時的な問題を回避します。（Bashは/dev/fdどこでも利用できないため、システムの機能に基づいて方法を選択します。）
この強力なアイデアがUnixに現れる第三の方法gdbとして、Linuxシステムを検討してください。これは、CおよびC ++で記述されたソフトウェアに使用されるデバッガーです。他のシステムからUnixに来たプログラマーはgdb、それについて見て、ほとんど常に不満を抱いています。「うん、それはとても原始的だ！」その後、GUIデバッガーを検索し、存在するいくつかのデバッガーの1つを見つけて、喜んで作業を続けます。GUIがちょうどgdbその下で実行され、その上にきれいなシェルを提供することに気付かないことがよくあります。ほとんどのUnixシステムには、そのレベルで競合するプログラムが必要ないため、競合する低レベルデバッガはありません。必要なのは、低レベルツールがパイプを介して簡単に通信する場合、高レベルツールのすべてをベースにすることができる1つの優れた低レベルツールだけです。
これはgdb、残念ながら、主要な競合他社gdb が低摩擦パスを採用しなかったもののドロップイン置換を可能にする、文書化されたデバッガーインターフェイスがあることを意味します。
それでも、少なくともコマンドラインインターフェイスのクローンを作成するだけで、将来の置き換えが透過的に行われる可能性が少なくともありgdbます。Windowsボックスで同じことを実現するには、交換可能なツールの作成者が何らかの形式のプラグインまたは自動化APIを定義する必要があります。これは、非常に人気のあるプログラムを除いては発生しないことを意味します。通常のコマンドラインユーザーインターフェイスと完全なプログラミングAPIの両方を構築するのは大変な作業です。
この魔法は、普及しているテキストベースのIPCの恵みを通して起こります。
WindowsのカーネルにはUnixスタイルの匿名パイプがありますが、通常のユーザープログラムがコマンドシェルの外部でIPCに使用することはまれです。それの上部は別に。これにより、GUIなしではできないことができます。これは、Linuxに比べてWindows用のリモートデスクトップシステムが非常に多い理由の1つです。WindowsはGUIなしで使用するのが非常に困難です。
対照的に、Unix、BSD、OS X、およびLinuxボックスをSSH経由でリモート管理することは一般的です。そして、それはどのように機能しますか？SSHは（ファイルのような）ネットワークソケットを（ファイルのような）疑似ttyに接続し/dev/pty*ます。これで、リモートシステムは、必要に応じてSSH接続でデータをパイプできる Unixの方法とシームレスに一致する接続を介してローカルシステムに接続されます。
この概念が今どれほど強力であるかについてのアイデアを得ていますか？
パイプテキストストリームは、プログラムの観点から見ればファイルと見分けがつきませんが、一方向であることを除きます。プログラムは、ファイルから読み取るのと同じ方法で、ファイル記述子を介してパイプから読み取ります。FDはUnixのコアです。ファイルとパイプの両方でI / Oに同じ抽象化を使用しているという事実から、何かがわかります。⁹
この単純なテキスト通信の伝統を欠くWindowsの世界は、COMまたは.NETを介したヘビーウェイトOOPインターフェースに対応しています。そのようなプログラムを自動化する必要がある場合は、COMまたは.NETプログラムも作成する必要があります。これは、Unixボックスにパイプを設定するよりもかなり難しいです。
これらの複雑なプログラミングAPIを欠くWindowsプログラムは、クリップボードやFile / Saveに続いてFile / Openなどの貧弱なインターフェースを介してのみ通信できます。
ロングアンサー、パート3：レジストリと構成ファイル
WindowsレジストリとUnixのシステム構成の実際の違いは、「すべてがファイルである」という哲学の利点も示しています。
Unixタイプのシステムでは、ファイルを調べるだけでコマンドラインからシステム構成情報を見ることができます。これらの同じファイルを変更することにより、システムの動作を変更できます。ほとんどの場合、これらの構成ファイルは単なるプレーンテキストファイルです。つまり、Unix上の任意のツールを使用して、プレーンテキストファイルで動作するツールを操作できます。
レジストリのスクリプト作成は、Windowsではそれほど簡単ではありません。
最も簡単な方法は、1台のマシンでレジストリエディターGUIを使用して変更を行い、その変更をregeditvia *.regfilesで他のマシンに盲目的に適用することです。条件付きで何もすることができないため、それは実際には「スクリプト」ではありません。それはすべてまたは何もありません。
レジストリの変更にある程度のロジックが必要な場合、次に簡単なオプションはPowerShellを学ぶことです。これは基本的に.NETシステムプログラミングを学ぶことに相当します。UnixにPerlしかなく、それを通してすべてのアドホックシステム管理を行わなければならなかった場合のようになります。今、私はPerlファンですが、誰もがそうではありません。Unixでは、プレーンテキストファイルを操作できる限り、好きなツールを使用できます。
脚注：
計画9では、この設計の誤りを修正し、/net仮想ファイルシステムを介してネットワークI / Oを公開しました。
Bashには、/dev/tcp通常のファイルシステム機能を介してネットワークI / Oを許可するという機能があります。これはBash機能であり、カーネル機能であるため、Bashの外部またはBashをまったく使用しないシステムでは表示されません。これは、反例として、ファイルシステムを通してすべてのデータリソースを見えるようにすることがなぜ良い考えであるかを示しています。
「最新のWindows」とは、Windows NTおよびその直接の子孫を意味します。これには、Windows 2000、Windows Serverのすべてのバージョン、およびXP以降のWindowsのすべてのデスクトップ指向バージョンが含まれます。この用語を使用して、Windows 95およびその直接の子孫であるWindows 98およびWindows MEに加えて、16ビットの前身であるWindowsのDOSベースバージョンを除外します。
後者のOSには統合I / Oシステムがないため、違いがわかります。ReadFile()Windows 95ではTCP / IPソケットを渡すことはできません。ソケットはWindows Sockets APIにのみ渡すことができます。Andrew Schulmanの重要な記事、Windows 95：What it's not not for this deep into the topicをご覧ください。
間違えないでください/dev/null。Unixタイプシステム上の実際のカーネルデバイスでありNUL、Windowsで表面的に同等の特殊なファイル名ではありません。
WindowsはNULファイルの作成を阻止しようとしますが、Windowsのファイル名解析ロジックをだまして、単なる策略でこの保護をバイパスすることは可能です。cmd.exeまたはエクスプローラでそのファイルにアクセスしようとすると、Windowsはそれを開くことを拒否しますが、サンプルプログラムと同様の方法を使用してファイルを開き、同様のトリックでファイルを削除できるため、Cygwinを介して書き込むことができます。
対照的に、Unixはrm /dev/null、に書き込み権限がある限り喜んであなたを許可し/dev、その場所に新しいファイルを再作成させます。そのdevノードは単なる別のファイルです。そのdevノードが欠落している間、カーネルのヌルデバイスはまだ存在しています。でdevノードを再作成するまでアクセスできませんmknod。
追加のヌルデバイスdevノードを別の場所に作成することもできます。それを呼び出すかどうかは問題ではありません。nullデバイスのdevノードである/home/grandma/Recycle Bin限り、まったく同じように機能し/dev/nullます。
Windowsには、実際には2つの高レベルの「フォーマットディスク」APIがSHFormatDrive()ありWin32_Volume.Format()ます。
非常に...まあ... Windowsのような理由で2つあります。1つ目は、エクスプローラーに通常の「ディスクのフォーマット」ダイアログボックスを表示するように要求します。つまり、最新バージョンのWindowsで動作しますが、ユーザーがインタラクティブにログインしている間のみです。しかし、Windows Server 2003まではWindowsに追加されませんでした。そうです、コアOSの動作は、UNIXがmkfs 1日目から出荷された2003年までGUIの背後に隠れていました。
私のUnixのV5のコピー 1974年からは、/etc/mkfs、4136バイト静的にリンクされたPDP-11実行ファイルを。（Unixは1980年代後半までダイナミックリンケージを取得しなかったため、他の場所に実際の作業をすべて行う大きなライブラリが存在するわけではありません。）そのソースコードは、V5システムイメージに含まれ/usr/source/s2/mkfs.c、完全に自己完結型ですラインCプログラム。#include声明さえありません！
つまり、40年前のKen Thompsonのmkfsように、Unixで作成されたのと同じツールセットを使用して、高レベルで何を行うかを調べるだけでなく、それを試すことができます。Windowsで試してみてください。今日最も近いものは、2014年に最初にリリースされたDOSソースコードをダウンロードすることです。これは、アセンブリソースの山にすぎません。おそらく手元にない時代遅れのツールでのみビルドされ、最終的には、ほぼ10年後にリリースされているにもかかわらず、1974年のUnix V5よりもはるかに強力でないOSであるDOS 2.0の独自のコピーを手に入れます。
それは最古の完全なUnixシステムがまだ使用可能であるので（なぜUnixのV5の話？。以前のバージョンでは、されて明らかに時間を失っていた。プロジェクトを一緒V1 / V2時代のUnixをつなぎことは、それが欠けているように見えるmkfs存在するにもかかわらず、上にリンクされたV1マニュアルページのどこかに、いつか存在したに違いないことを証明します。このプロジェクトをまとめる人mkfsは、インクルードする既存のコピーを見つけることができなかったか、またはfind(1)そのシステムに存在しない。:)）
今、あなたは「私はただ電話することはできませんformat.comか？WindowsでそれはmkfsUnixで電話することと同じではないですか？」残念ながら、多くの理由により、同じではありません。
まず、format.comスクリプト用に設計されていませんでした。「準備ができたらENTERを押してください」というプロンプトが表示されます。つまり、入力にEnterキーを送信する必要があるか、単にハングするだけです。
次に、成功/失敗のステータスコード以外のものが必要な場合は、その標準出力を読み取り用に開く必要があります。これは、Windowsでは必要以上に複雑です。（Unixでは、そのリンクされた記事のすべてが簡単なpopen(3)呼び出しで実行できます。）
このすべての複雑さを経てformat.com、の出力はmkfs、主に人間が消費することを意図したの出力よりも、コンピュータープログラムの解析が困難です。
あなたは何をトレースする場合はformat.comありません、あなたはそれが複雑呼び出しの束を行うことがわかりDeviceIoControl()、ufat.dll、およびなど。単にデバイスファイルを開いて、そのデバイスに新しいファイルシステムを書き込むだけではありません。これは、126000人の従業員を抱える会社から得られる一種の設計であり、それらを採用し続ける必要があります。
ループデバイスはUnixタイプのシステム間で移植できないため、ループデバイスについて話すときは、一般的にUnixではなくLinuxについてのみ説明します。OS X、BSDなどにも同様のメカニズムがありますが、構文は多少異なります。
ディスクドライブが洗濯機のサイズであり、部門長の高級車よりも高価だった時代には、大規模なコンピューターラボは、現代のコンピューティング環境と比較して、より多くのディスクスペースを共有していました。リモートディスクをローカルファイルシステムに透過的に移植する機能により、このような分散システムははるかに使いやすくなりました。これは、/usr/shareたとえば、取得する場所です。
通常、リモートディスクはドライブ文字にマッピングされるか、ローカルファイルシステムに透過的に統合されるのではなく、UNCパスを介してアクセスされる必要があるWindowsのコントラスト。ドライブ文字では、シンボリック表現の選択肢がほとんどありません。んP:BIGSERVERの「公共」のスペースに、またはソフトウェアミラーサーバー上の「パッケージ」ディレクトリを参照してください？UNCパスは、リモートファイルがどのサーバーにあるかを覚えておく必要があることを意味します。これは、数百または数千のファイルサーバーを持つ大規模な組織では困難になります。
Windowsは、NTFSシンボリックリンクを導入した2007年にリリースされたWindows Vistaまでシンボリックリンクを取得しませんでした。Windowsのシンボリックリンクは、1977年以来のUnixの機能であるUnixのシンボリックリンクよりも、ローカルパスだけでなくリモートファイル共有も指すことができるという点で、少し強力です。Unixは、1984年にNFSを介して異なる方法でそれを行いました。これは、Unixの既存のマウントポイント機能の上に構築されており、最初から搭載されています。
そのため、見方にもよりますが、WindowsはUnixを約20〜30年後押ししました。
それでも、いくつかの理由から、シンボリックリンクはWindowsユーザーエクスペリエンスの通常の部分ではありません。
まず、バックワードコマンドラインプログラムでのみ作成できますMKLINK。WindowsのエクスプローラにUNIXの等価物は、通常のに対し、あなたは、Windowsエクスプローラからそれらを作成することはできませんんあなたはシンボリックリンクを作成してみましょう。
第二に、デフォルトのWindows構成では、通常のユーザーがシンボリックリンクを作成できないため、管理者としてコマンドシェルを実行するか、平均的なユーザーが見たこともないツールのあいまいなパスを介してそれらを作成する権限をユーザーに付与する必要があります使い方。（また、Windowsのほとんどの管理者特権の問題とは異なり、この場合、UACは役に立ちません。）
Linuxボックスは、ブートシーケンスで常に仮想ディスクイメージを使用するとは限りません。あり、それを行うためのさまざまな方法の束が。
man ed
ちなみに、ネットワークソケット記述子もFDです。