"모든 것이 파일이다"에 대한 일반인의 설명 - Windows와 어떻게 다른가요?

Question 1

"모든 것이 문서이다"라는 말은 약간 횡설수설합니다. "모든 일은 어딘가에서 일어난다.파일 시스템”가 목표에 더 가깝고, 심지어 시스템 설계 법칙보다 이상에 가깝습니다.

예를 들어,유닉스 도메인 소켓파일은 아니지만 파일 시스템에는 나타납니다. ls -l도메인 소켓을 사용하여 액세스 제어를 수정하여 해당 속성을 노출할 수 chmod있으며 일부 Unix 유형 시스템(Linux가 아닌 macOS와 같은)에서는 cat데이터를 주고받을 수도 있습니다.

그러나 비록 자주TCP/IP 네트워크 소켓동일한 방법으로 생성하고 운영BSD 소켓Unix 도메인 소켓, TCP/IP 소켓과 같은 시스템 호출아니요파일 시스템에 나타나는데, 이것이 사실인 특별한 이유는 없습니다.

파일 시스템에 존재하는 파일이 아닌 객체의 또 다른 예는 다음과 같습니다.리눅스 /proc파일 시스템. 이 기능은 커널의 런타임 작업에 대한 풍부한 세부 정보를 사용자에게 노출합니다.사용자 공간, 주로 가상 일반 텍스트 파일로 사용됩니다. 많은 /proc항목은 읽기 전용이지만 대부분은 /proc쓰기 가능하므로 파일을 수정할 수 있는 모든 프로그램을 사용하여 시스템 실행 방식을 변경할 수 있습니다. 아쉽게도 또 다른 비이상적인 상황이 있습니다: BSD Unix/proc기본적으로 실행되지 않음System V Unix는 Linux보다 훨씬 적은 수의 via를 노출합니다 /proc.

MS윈도우랑 비교가 안되네

첫째, Unix는 파일 I/O에 관한 것이고 Windows는 이 점에서 "깨졌다"는 오래된 개념을 온라인과 책에서 찾을 수 있습니다.윈도우 시스템이 문제가 많이 해결되었습니다.

최신 버전의 Windows에는 Unix와 마찬가지로 통합 I/O 시스템이 있으므로 TCP/IP 소켓에서 네트워크 데이터를 읽을 수 있습니다.ReadFile()Windows 소켓 특정 API가 아닌WSARecv(), 네가 원한다면. 이는 정확히 평행하다.유닉스 방식, 일반 네트워크 소켓을 사용하여 읽을 수 있습니다.read(2)Unix 시스템 호출 또는 소켓별recv(2)통화.²

그럼에도 불구하고 2021년에도 Windows는 여전히 이 개념을 Unix와 같은 수준으로 끌어올리지 못했습니다. Windows 아키텍처의 많은 영역은 파일 시스템을 통해 액세스할 수 없거나 클래스 파일로 처리할 수 없습니다. 몇 가지 예:

운전사.

Windows의 드라이버 하위 시스템은 Unix만큼 풍부하고 강력하지만 드라이버를 조작하는 프로그램을 작성하려면 일반적으로 다음을 사용해야 합니다.Windows 드라이버 제품군, 이는 C 또는 .NET 코드 작성을 의미합니다.

Unix 유형 운영 체제에서는 명령줄을 통해 드라이버에 대한 다양한 작업을 수행할 수 있습니다. 원치 않는 출력을 /dev/null거의 확실히 이미 수행한 .³ 로 리디렉션하기만 하면 됩니다.
프로그램 간 통신.

Windows 프로그램은 Unix 명령줄 프로그램만큼 쉽게 텍스트 스트림과 파이프를 통해 서로 통신하지 않습니다. Unix GUI는 일반적으로 명령줄 프로그램 위에 구축되거나 텍스트 명령 인터페이스를 내보내므로 GUI 프로그램에도 동일한 간단한 텍스트 기반 통신 메커니즘이 적용됩니다.
기재.

Unix에는 Windows 레지스트리와 직접적으로 동등한 것이 없습니다. 동일한 정보는 주로 /etc, /proc및 에 있는 파일 시스템 전체에 분산되어 있습니다 /sys.

Windows 레지스트리에 대한 드라이버, 파이프 및 Unix 응답이 "모든 것이 파일입니다"와 관련이 있다는 것을 알지 못한다면 계속 읽으십시오.

"모든 것이 파일이다"라는 생각이 여기에 어떻게 작용합니까?

위의 세 가지 사항을 확장하여 자세히 설명하겠습니다.

긴 답변, 1부: 드라이브 및 장치 파일

E:CF 카드 리더가 Windows 및 /dev/sdcLinux 에 표시된다고 가정합니다 . 어떤 실질적인 차이가 있습니까?

이는 단지 사소한 구문 차이가 아닙니다.

dd if=/dev/zero of=/dev/sdcLinux에서는 콘텐츠를 0으로 덮어쓴다고 말할 수 있습니다 /dev/sdc.

이것이 무엇을 의미하는지 생각해 보십시오. 여기에는 일반적인 사용자 공간 프로그램이 있습니다(dd(1)), 통합 Unix 파일 시스템을 통해 가상 장치( )에서 데이터를 읽고 /dev/zero읽은 데이터를 실제 물리적 장치( )에 써야 합니다. 특수 장치를 읽고 쓰는지 몰랐습니다. 또한 아래와 같이 일반 파일이나 혼합 장치 및 파일에서도 작동합니다./dev/sdcdd

E:Windows는 파일과 드라이브를 구별하므로 동일한 명령을 사용하여 작동할 수 없기 때문에 Windows에서 드라이브를 0으로 만드는 쉬운 방법은 없습니다 . 가장 가까운 방법은 빠른 포맷 옵션 없이 디스크를 포맷하는 것입니다.최대내용을 드라이브에 저장한 다음 그 위에 새 파일 시스템을 씁니다. 내가 그러지 않으면 어떡하지?생각하다새로운 파일 시스템? 디스크를 0으로만 채우려면 어떻게 해야 합니까?

Windows의 프로그램에서 이 작업 E:을 수행하려면 특수 형식 지정 API를 호출해야 합니다. ⁴ Linux에서는 운영 체제의 "디스크 포맷" 기능에 액세스하기 위해 프로그램을 작성할 필요가 없습니다.mkfs.ext4,mkfs.xfs, 또는 당신은 무엇을 가지고 있습니까? 이러한 프로그램은 /dev전달한 모든 파일이나 노드의 파일 시스템에 기록합니다 .

mkfsUnixy 시스템의 유형 프로그램은 장치와 일반 파일을 인위적으로 구별하지 않기 때문에ext4 파일 시스템내 Linux 컴퓨터의 일반 파일에서:

$ dd if=/dev/zero of=myfs bs=1k count=1k
$ mkfs.ext4 -F myfs

myfs그러면 현재 디렉터리에 호출되는 1MiB 디스크 이미지가 생성됩니다. 그런 다음 다른 외부 파일 시스템처럼 마운트할 수 있습니다.

$ mkdir mountpoint
$ sudo mount -o loop myfs mountpoint
$ grep $USER /etc/passwd > mountpoint/my-passwd-entry
$ sudo umount mountpoint

my-passwd-entry이제 내 사용자 항목이 포함된 파일이 포함된 ext4 디스크 이미지가 생겼습니다 /etc/passwd.

원한다면 이 이미지를 내 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" \
      [email protected]

파일, 파일 시스템, 장치 간에 인위적인 구분이 없기 때문에 이 모든 것이 Linux⁵에서 가능합니다. 유닉스 시스템에는 많은 것들이 있다예파일을 사용하거나 파일 시스템을 통해 액세스하여처럼 보인다파일이거나 파일로 간주될 수 있을 정도로 파일과 충분히 유사해 보입니다.

Windows의 파일 시스템 개념은 뒤죽박죽입니다. 디렉터리, 드라이브 및 네트워크 리소스를 구별합니다. Windows에는 Unix와 같은 ..\FOO\BAR경로 시스템, 드라이브 문자(예: C:) 및 UNC 경로(예: )라는 세 가지 구문이 모두 함께 혼합되어 있습니다. \\SERVER\PATH\FILE.TXT이는 Unix 아이디어의 축적이기 때문입니다.CP/M,운영 체제, 그리고LAN 관리자하나의 일관된 디자인보다는. 그렇기 때문에Windows 파일 이름에 불법 문자가 너무 많습니다..

Unix는 통합된 파일 시스템을 갖추고 있으며 공통 체계를 통해 모든 것에 액세스할 수 있습니다. Linux 시스템에서 실행되는 프로그램의 경우 /etc/passwd, , 및 /media/CF_CARD/etc/passwd사이에 기능적 차이가 없습니다 /mnt/server/etc/passwd. 로컬 파일, 외부 미디어 및 네트워크 공유는 모두 동일한 방식으로 처리됩니다. ⁶

Windows는 위의 디스크 이미지 예와 유사한 목표를 달성할 수 있지만 매우 재능 있는 프로그래머가 작성한 특수 프로그램을 사용해야 합니다. 그렇기 때문에Windows용 "가상 DVD" 유형의 프로그램이 많이 있습니다.. 핵심 운영 체제 기능의 부족으로 인해 이러한 격차를 메우는 프로그램에 대한 인위적인 시장이 만들어졌습니다. 이는 최고의 가상 DVD 유형 프로그램을 만들기 위한 경쟁이 있음을 의미합니다. *ix 시스템에서는 그런 프로그램이 필요하지 않습니다.순환 장치.

다음과 같은 다른 도구도 마찬가지입니다.디스크 지우기프로그램, Unix 시스템에서도 이러한 프로그램이 필요하지 않습니다. CF 카드의 내용을 0으로 재설정하는 대신 복구 불가능하게 뒤섞기를 원하십니까? 알겠습니다. 사용하세요/dev/random다음 대신 데이터 소스로 사용 /dev/zero:

$ sudo dd if=/dev/random of=/dev/sdc

Linux에서는 핵심 운영 체제 기능이 충분히 잘 작동할 뿐만 아니라 너무 잘 작동하여 널리 사용되기 때문에 이와 같이 끊임없이 바퀴를 재발명하지 않습니다.여러 가지 방법 중 하나Linux 머신을 부팅하려면 위에서 보여준 기술을 사용하여 가상 디스크 이미지를 생성해야 합니다.

Unix가 처음부터 TCP/IP I/O를 파일 시스템에 통합했다면 대 대 대 대 상황이 발생하지 않았을 것이라는 점을 지적하는 것이 타당하다고 netcat생각 socat합니다 ncat.nc 착란그 이유는 Windows에서 디스크 이미징 및 삭제 도구의 확산을 초래한 것과 동일한 설계 결함, 즉 허용 가능한 운영 체제 기능이 부족하기 때문입니다.

긴 답변, 2부: 가상 파일로서의 파이프

Windows는 MS-DOS에서 시작되었지만 풍부한 명령줄 전통을 가져본 적이 없습니다.

이것은 Windows가 그렇지 않다는 것을 의미하지 않습니다.가지다명령줄 또는 많은 명령줄 프로그램이 부족합니다. 오늘날 Windows에는 매우 강력한 명령 셸도 있습니다.전원 공급 장치 하우징.

그러나 명령줄 전통이 부족하면 연쇄 효과가 발생합니다. 이런 도구를 얻게 됩니다.DISKPART대부분의 사람들이 컴퓨터 관리 MMC 스냅인을 통해 디스크 파티셔닝과 같은 작업을 수행하기 때문에 이는 Windows 세계에서는 거의 알려지지 않았습니다. 그런 다음 파티션 생성을 스크립트로 작성해야 할 때 DISKPART실제로는 다른 프로그램에 의해 구동되지 않는다는 것을 알게 됩니다. 예, 일련의 명령을 스크립트 파일에 작성하고 를 통해 실행할 수 있지만 DISKPART /S scriptfile전부 아니면 전무입니다. 너 뭐야진짜이 경우 원하는 것은 다음과 같습니다.암소 비슷한 일종의 영양parted, 이는 단일 명령을 허용합니다. 예를 들어 parted /dev/sdb mklabel gpt이를 통해 스크립트가 오류 처리를 단계별로 수행할 수 있습니다.

이 모든 것이 "모든 것이 파일이다"와 무슨 관련이 있습니까? 단순한:관로명령줄 프로그램 I/O를 일종의 "파일"에 넣습니다. 파이프는 단방향입니다.개울, 아니요무작위 액세스일반 디스크 파일과 비슷하지만 대부분의 경우 차이점은 중요하지 않습니다. 중요한 점은 독립적으로 개발된 두 개의 프로그램을 연결하여 간단한 텍스트로 통신할 수 있다는 것입니다. 이런 의미에서 어떤 두유닉스 방식정신적으로 소통할 수 있습니다.

파일이 꼭 필요한 경우 프로그램 출력을 파일로 쉽게 변환할 수 있습니다.

$ some-program --some --args > myfile
$ vi myfile

하지만 "모든 것이 파일이다"라는 철학이 더 나은 방법을 제공하는데 왜 임시 파일에 출력을 작성합니까? 명령의 출력을 vi편집기 버퍼 로 읽으려면 vi"일반" 모드에서 직접 수행할 수 있습니다.

:r !some-program --some --args

프로그램의 출력을 현재 커서 위치의 활성 편집기 버퍼에 삽입합니다. 그 뒤에서 vi파이프는 프로그램의 출력을 파일에서 읽는 데 사용되는 것과 동일한 운영 체제 호출을 사용하는 일부 코드에 연결하는 데 사용됩니다. 두 가지 경우 :r(예: yes 및 no !)가 모두 포함된 경우 vi이 작업을 수행하지 않을 이유가 없습니다.

이것은 최신 기능도 아닙니다 vi.고대의 ed(1)텍스트 에디터.

이 강력한 아이디어는 Unix에서 계속해서 등장합니다.

두 번째 예에서는 mutt위의 email 명령을 기억해 보십시오. 내가 이것을 두 개의 별도 명령으로 작성해야 했던 유일한 이유 *.gz는 이메일 첨부 파일의 이름이 올바르게 지정되도록 임시 파일의 이름을 지정하기를 원했기 때문입니다 . 파일 이름에 신경 쓰지 않으면 다음을 사용할 수 있습니다.프로세스 교체임시 파일 생성을 피하세요.

$ echo "Here's the disk image I promised to send you." | 
  mutt -a <(gzip -c myfs) -s "Password file disk image" \
      [email protected]

이는 출력을 gzip -cFIFO(파일과 같은) 또는 /dev/fd객체(파일과 같은)로 변환합니다. 7

이 강력한 아이디어가 Unix에 나타나는 세 번째 방법으로 다음을 고려하십시오.gdb리눅스 시스템에서. 이것은 C 및 C++로 작성된 모든 소프트웨어에 대한 디버거입니다. 다른 시스템에서 Unix로 전환하는 프로그래머는 gdb거의 항상 "아, 너무 원시적이야!"라고 불평할 것입니다. 그런 다음 그들은 GUI 디버거를 찾고 존재하는 몇 안 되는 디버거 중 하나를 찾아 행복하게 작업을 계속합니다... ...종종 전혀 그렇지 않습니다. GUI가 바로 gdb아래에서 실행되고 그 위에 멋진 쉘을 제공한다는 것을 깨닫습니다. 프로그램이 해당 수준에서 경쟁할 필요가 없기 때문에 경쟁하는 저수준 디버거는 대부분의 Unix 시스템에 존재하지 않습니다. 우리에게 필요한 것은 좋은 하위 수준 도구뿐입니다. 해당 하위 수준 도구가 파이프를 통해 쉽게 통신할 수 있다면 우리 모두는 해당 하위 수준 도구 위에 상위 수준 도구를 구축할 수 있습니다.

이는 이제 우리가 직접 대체할 수 있는 문서화된 디버거 인터페이스를 갖게 되었음을 의미합니다 gdb. 불행하게도 주요 경쟁사입니다.gdb 마찰이 적은 경로를 택하지 않음, 그러나 그 주장을 제외하면 lldb와 마찬가지로 스크립트가 가능합니다 gdb.

Windows 시스템에서 동일한 기능을 달성하려면 대체 도구 작성자가 일종의 공식 플러그인 또는 자동화 API를 정의해야 합니다. 이는 일반적인 명령줄 사용자 인터페이스와 전체 프로그래밍 API를 구축하려면 많은 작업이 필요하기 때문에 가장 널리 사용되는 프로그램을 제외한 모든 프로그램에서는 이런 일이 발생하지 않는다는 것을 의미합니다.

이 마법은 유비쿼터스 텍스트 기반 은혜를 통해 일어납니다.산업용 컴퓨터.

비록 Windows 커널Unix 스타일 익명 파이프, 일반 사용자 프로그램에서 이를 사용하는 경우는 거의 없습니다.산업용 컴퓨터명령 셸 외부에서는 Windows에는 먼저 명령줄 버전에서 모든 핵심 서비스를 생성한 다음 그 위에 별도로 GUI를 구축하는 전통이 부족하기 때문입니다. 이로 인해 GUI 없이는 불가능한 일이 발생하는데, 이는 GUI가 너무 많은 이유 중 하나입니다.원격 데스크톱 시스템Windows의 경우 Linux와 비교됩니다. 이것이 바로 Linux가 모든 것을 원격으로 관리하는 클라우드 운영 체제가 된 이유 중 하나입니다. 명령줄 인터페이스는 "모든 것이 파일"이기 때문에 GUI보다 자동화하기가 더 쉽습니다.

SSH를 고려해보세요. 어떻게 작동하는지 물어볼 수 있습니까? SSH는 네트워크 소켓(파일과 유사)을 다음에 연결합니다.의사 터미널at /dev/pty*(파일과 유사). 이제 원격 시스템은 Unix 방식과 완벽하게 일치하는 연결을 통해 로컬 시스템에 연결됩니다.SSH 연결을 통해 데이터를 전송할 수 있습니다, 필요한 경우.

이제 이 개념이 얼마나 강력한지 아시겠습니까?

프로그램의 관점에서 파이프로 연결된 텍스트 스트림은 단방향이라는 점을 제외하면 파일과 다르지 않습니다. 프로그램은 파일에서 데이터를 읽는 것과 같은 방식으로 파이프에서 데이터를 읽습니다.파일 설명자. FD는 확실히 Unix의 핵심입니다. 파일, 파이프 및 네트워크 소켓이 모두 동일한 I/O 추상화를 사용한다는 사실이 여러분에게 시사하는 바가 있습니다.

Windows 세계에는 이러한 단순한 텍스트 통신의 전통이 부족하며 무거운 통신을 사용해야 합니다.객체 지향 프로그래밍인터페이스를 통해직렬 통신또는. 그물. 이러한 프로그램을 자동화해야 하는 경우 COM 또는 .NET 프로그램도 작성해야 합니다. 이는 Unix 시스템에서 파이프를 설정하는 것보다 조금 더 어렵습니다.

이러한 정교한 프로그래밍 API가 없는 Windows 프로그램은 클립보드나 파일/저장, 파일/열기와 같은 기본적인 인터페이스를 통해서만 통신할 수 있습니다.

긴 답변, 3부: 레지스트리와 구성 파일

Windows 레지스트리와 Unix 시스템 구성 방식 간의 실질적인 차이점은 "모든 것이 파일이다"라는 철학의 이점을 보여줍니다.

Unix 유형 시스템에서는 간단히 파일을 검사하여 명령줄에서 시스템 구성 정보를 볼 수 있습니다. 동일한 파일을 수정하여 시스템 동작을 변경할 수 있습니다. 대부분의 경우 이러한 구성 파일은 일반 텍스트 파일이므로 일반 텍스트 파일을 처리할 수 있는 Unix의 모든 도구를 사용하여 구성 파일을 조작할 수 있습니다.

스크립팅Windows의 레지스트리는 그렇게 쉽지 않습니다.

가장 쉬운 방법은 한 컴퓨터에서 레지스트리 편집기 GUI를 통해 변경한 다음regedit파일을 통해 *.reg이러한 변경 사항을 다른 컴퓨터에 맹목적으로 적용. 이것은 조건에 따라 아무것도 할 수 없도록 허용하는 "스크립트"가 아닙니다. 전부 아니면 전무입니다.

레지스트리 변경에 어느 정도의 논리가 필요한 경우 다음으로 가장 쉬운 옵션은 다음을 배우는 것입니다.전원 공급 장치 하우징.NET 시스템 프로그래밍을 배우는 것과 같습니다. Unix에는 Perl만 있고 모든 작업을 수행해야 하는 것과 같습니다.애드 혹이를 통해 시스템 관리가 이루어집니다. 저는 Perl 팬이지만 모든 사람이 그런 것은 아닙니다. Unix에서는 일반 텍스트 파일에서 작동할 수 있는 도구라면 무엇이든 사용할 수 있습니다.

각주:

계획 9네트워크 I/O를 노출하여 이 설계 오류를 수정했습니다.가상 /net파일 시스템.

배쉬는/dev/tcp일반 파일 시스템 기능을 통해 네트워크 I/O를 허용합니다. 커널 기능이 아닌 Bash 기능이므로 Bash 외부나 시스템에서는 표시되지 않습니다.Bash를 전혀 사용하지 않는 시스템. 반례를 통해 이는 파일 시스템을 통해 모든 데이터 리소스를 표시하는 것이 좋은 이유를 보여줍니다.
"최신 Windows"란 Windows NT와 Windows 2000, 모든 버전의 Windows Server 및 XP로 시작하는 모든 데스크톱 지향 Windows 버전을 포함하여 모든 직계 자손을 의미합니다. 나는 이 용어를 사용하여 Windows의 MS-DOS 기반 버전, 즉 Windows 95와 그 직계 자손, Windows 98과 Windows ME 및 16비트 이전 버전을 제외했습니다.

후자의 운영 체제에서는 통합 I/O 시스템이 없다는 점에서 차이점을 확인할 수 있습니다. ReadFile()Windows 95에서는 TCP/IP 소켓을 전달할 수 없으며 Windows 소켓 API에만 소켓을 전달할 수 있습니다. Andrew Schulman의 주요 기사를 참조하세요.Windows 95: 그렇지 않은 것이 주제를 더 자세히 살펴보세요.
/dev/null이것이 단지 특수한 경우의 표면적으로 동등한 파일 이름이 아니라 Unix 유형 시스템의 실제 커널 장치라는 점에는 의심의 여지가 없습니다 .NULWindows에서.

Windows에서는 파일 생성을 차단하려고 시도하지만 NUL이 보호 기능을 우회할 수 있습니다.그냥 트릭으로, Windows의 파일 이름 구문 분석 논리를 속이기 위해. Cygwin이나 Explorer를 사용하여 파일에 접근하려고 하면 cmd.exeWindows에서는 파일 열기를 거부하지만, 예제 프로그램과 비슷한 방법으로 파일을 열고 삭제할 수 있으므로 Cygwin을 통해 쓸 수 있습니다.비슷한 계략으로.

대조적으로, 유닉스는 rm /dev/null당신이 쓰기 권한을 갖고 있는 한 /dev그 자리에 새 파일을 다시 생성할 수 있도록 허용합니다.개발 노드또 다른 파일입니다. 개발 노드가 손실되더라도 커널의 빈 장치는 여전히 존재하며 다음을 통해 개발 노드를 다시 생성할 때까지 액세스할 수 없습니다.mknod.

다른 곳에서 빈 장치 개발 노드를 추가로 생성할 수도 있습니다. 호출 여부에 관계없이 /home/grandma/Recycle Bin빈 장치의 개발 노드인 것처럼 작동합니다 /dev/null.
실제로는 있습니다둘Windows의 고급 "디스크 포맷" API:SHFormatDrive()그리고Win32_Volume.Format().

두 개가 있는데 아주...글쎄...윈도우몇몇 이유. 첫 번째 방법은 Windows 탐색기에서 일반적인 "디스크 포맷" 대화 상자를 표시해야 합니다. 즉, 모든 최신 버전의 Windows에서 작동하지만 사용자가 대화형으로 로그인한 경우에만 작동합니다. 다른 하나는 사용자 입력 없이 백그라운드에서 호출할 수 있지만 Windows Server 2003까지는 Windows에 추가되지 않았습니다. 맞습니다. 2003년까지 Unix 릴리스 세계에서는 핵심 운영 체제 동작이 GUI 뒤에 숨겨져 있었습니다.mkfs 첫날부터.

내/etc/mkfs유닉스 V5 사본1974년부터 4136바이트의 정적 링크가 시작되었습니다.플라즈마 11실행 가능. (Unix는 동적 연결을 얻지 못합니다.1980년대 후반까지, 따라서 하나의 큰 도서관이 모든 실제 작업을 수행하는 다른 장소와는 다릅니다. ) 해당 소스 코드 - 아래와 같이 V5 시스템 이미지에 포함되어 있습니다./usr/source/s2/mkfs.c— 완전히 독립적인 457라인 C 프로그램입니다. 어떤 진술도 없습니다 #include!

mkfs이는 높은 수준의 기능을 확인할 수 있을 뿐만 아니라 Unix를 만드는 데 사용된 것과 동일한 도구 세트를 실험할 수도 있음을 의미합니다 .켄 톰슨, 40년 전. Windows에서 사용해 보세요. 오늘 얻을 수 있는 가장 가까운 것은 다운로드하는 것입니다.MS-DOS 소스 코드, 에 처음 게시됨2014년, 당신은 그것이 단지 무리라는 것을 알게 될 것입니다집회원천. 아마도 여러분이 가지고 있지 않은 구식 도구로 구축될 것이며, 결국 1974년의 것보다 훨씬 덜 강력한 운영 체제인 MS-DOS 2.0의 복사본을 갖게 될 것입니다.유닉스 V5, 거의 10년 후에 출시되었지만.

(Unix V5에 대해 이야기하는 이유는 존재하는 최초의 완전한 Unix 시스템이기 때문입니다. 이전 버전은분명 시간에 쫓겨났지. 가지다프로젝트이것은 Unix의 V1/V2 시대를 하나로 묶었지만 사라진 것 같습니다. mkfs위에 링크된 V1 매뉴얼 페이지의 존재는 그것이 언젠가 어딘가에 존재했음이 틀림없다는 것을 증명합니다. 이 프로젝트를 함께 진행한 사람들이 포함할 기존 복사본을 찾을 수 없거나 mkfs, 나에게 없고 find(1)이 시스템에 존재하지 않는 파일을 찾는 데 어려움을 겪고 있습니다. :))

이제 "그냥 직접 호출하면 안 될까 format.com? Windows에서 호출하는 것이 Unix에서 호출하는 것과 같지 않을까 mkfs?"라고 생각할 수도 있습니다. 아뇨, 여러 가지 이유로 동일하지 않습니다.
- 첫째, format.com스크립트를 작성하도록 설계되지 않았습니다. "준비되면 Enter 키를 누르십시오"라는 메시지가 표시됩니다. 이는 Enter 키를 입력으로 보내야 함을 의미합니다. 그렇지 않으면 작동이 중단됩니다.
- 그런 다음 성공/실패 상태 코드 이상의 것을 원한다면 읽기 위해 표준 출력을 열어야 합니다.Windows의 상황은 실제보다 훨씬 더 복잡합니다.. (Unix에서는 이 링크된 기사의 모든 내용에 간단한 명령을 통해 액세스할 수 있습니다.popen(3)부르다. )
- 이 모든 복잡성 때문에 format.com의 출력은 의 출력보다 구문 분석하기가 훨씬 더 어렵고 mkfs주로 사람이 사용하도록 의도되었습니다.
- 내용을 추적해 보면 format.com복잡한 일련의 호출을 수행한다는 것을 알 수 있습니다.DeviceIoControl(), ufat.dll, 등. 단순히 장치 파일을 열고 해당 장치에 새 파일 시스템을 쓰는 것이 아닙니다. 이것이 당신이 얻는 디자인입니다전 세계적으로 221,000명의 직원을 보유한 회사그리고 필요하다유지하다그들을 고용하세요.
  
  핵심 운영 체제 도구가 자원 봉사자들에 의해 여가 시간에 작성될 때 일어나는 일과 대조해 보십시오. 그들은 자신의 문제에 대한 임시방편, 최소한의 해결책을 제시하고 나머지 사람들에게 단순성 배당금을 제공합니다.
루프 장치에 대해 이야기할 때 일반적으로 Unix가 아닌 Linux에 대해서만 이야기하는 것입니다. 왜냐하면 루프 장치는 Unix 유형 시스템 간에 이식 가능하지 않기 때문입니다. macOS, BSD 등은 메커니즘이 비슷하지만 구문이 다릅니다.약간 다른.
디스크 드라이브가 세탁기 크기이고 부서 임원의 고급 자동차보다 가격이 더 비쌌던 시대에 대형 컴퓨터실은 현대 컴퓨팅 환경보다 더 큰 전체 디스크 공간을 공유했습니다. 원격 디스크를 로컬 파일 시스템으로 투명하게 마이그레이션하는 기능을 통해 이 분산 시스템을 더 쉽게 사용할 수 있습니다. /usr/share예를 들어, 이것이 우리가 얻는 곳입니다.

드라이브 문자가 기호 표현을 위한 선택 사항을 거의 제공하지 않는 Windows의 경우 이는 P:BigServer의 "공용" 공간을 의미합니까, 아니면 소프트웨어 미러 서버의 "패키지" 디렉터리를 의미합니까? UNC 대안을 사용하려면 원격 파일이 있는 서버를 기억해야 합니다. 이는 수백 또는 수천 개의 파일 서버가 있는 대규모 조직에서는 어렵습니다.

Windows는 2007년 Vista가 출시될 때까지 심볼릭 링크를 얻지 못했습니다.NTFS 심볼릭 링크이며, 제조되지 않았습니다.쓸 수 있는 10년 후까지. Windows 심볼릭 링크는 Unix 심볼릭 링크보다 더 강력합니다. 이는 Unix 기능입니다.1977년부터- 로컬 경로뿐만 아니라 원격 파일 공유도 가리킬 수 있기 때문입니다. 유닉스에서는 다음과 같이 다르게 수행합니다.1984년 NFS, 이는 Unix의 기존을 기반으로 구축되었습니다.마운트 포인트기능, 이것은 처음부터 있었던 것입니다.

따라서 Windows는 보는 관점에 따라 Unix보다 약 20, 30, 40년 뒤쳐져 있습니다. 당신은 "그러나 그것은 Unix 스타일의 심볼릭 링크를 가지고 있습니다"라고 반대할 수도 있습니다.지금!“그러나 이는 수십 년 된 전통이 없다는 의미이기 때문에 요점을 놓치고 있습니다.사용Windows에서 실행되므로 Unix 시스템이 일반적으로 사용하는 세계에서는 사람들이 이를 인식하지 못합니다. 심볼릭 링크를 이해하지 못하면 오랫동안 Unix 시스템을 사용할 수 없습니다.

윈도우는 도움이 안 돼요MKLINK프로그램예뒤로, 여전히 Windows 탐색기에서는 만들 수 없으며 Windows 탐색기에 해당하는 Unix는 일반적으로하다심볼릭 링크를 생성할 수 있습니다.
/dev/fdBash는 모든 곳에서 사용할 수 없는 시스템 기능을 기반으로 방법을 선택합니다 .

Answer

"모든 것이 문서이다"라는 말은 약간 횡설수설합니다. "모든 일은 어딘가에서 일어난다.파일 시스템”가 목표에 더 가깝고, 심지어 시스템 설계 법칙보다 이상에 가깝습니다.

예를 들어,유닉스 도메인 소켓파일은 아니지만 파일 시스템에는 나타납니다. ls -l도메인 소켓을 사용하여 액세스 제어를 수정하여 해당 속성을 노출할 수 chmod있으며 일부 Unix 유형 시스템(Linux가 아닌 macOS와 같은)에서는 cat데이터를 주고받을 수도 있습니다.

그러나 비록 자주TCP/IP 네트워크 소켓동일한 방법으로 생성하고 운영BSD 소켓Unix 도메인 소켓, TCP/IP 소켓과 같은 시스템 호출아니요파일 시스템에 나타나는데, 이것이 사실인 특별한 이유는 없습니다.

파일 시스템에 존재하는 파일이 아닌 객체의 또 다른 예는 다음과 같습니다.리눅스 /proc파일 시스템. 이 기능은 커널의 런타임 작업에 대한 풍부한 세부 정보를 사용자에게 노출합니다.사용자 공간, 주로 가상 일반 텍스트 파일로 사용됩니다. 많은 /proc항목은 읽기 전용이지만 대부분은 /proc쓰기 가능하므로 파일을 수정할 수 있는 모든 프로그램을 사용하여 시스템 실행 방식을 변경할 수 있습니다. 아쉽게도 또 다른 비이상적인 상황이 있습니다: BSD Unix/proc기본적으로 실행되지 않음System V Unix는 Linux보다 훨씬 적은 수의 via를 노출합니다 /proc.

MS윈도우랑 비교가 안되네

첫째, Unix는 파일 I/O에 관한 것이고 Windows는 이 점에서 "깨졌다"는 오래된 개념을 온라인과 책에서 찾을 수 있습니다.윈도우 시스템이 문제가 많이 해결되었습니다.

최신 버전의 Windows에는 Unix와 마찬가지로 통합 I/O 시스템이 있으므로 TCP/IP 소켓에서 네트워크 데이터를 읽을 수 있습니다.ReadFile()Windows 소켓 특정 API가 아닌WSARecv(), 네가 원한다면. 이는 정확히 평행하다.유닉스 방식, 일반 네트워크 소켓을 사용하여 읽을 수 있습니다.read(2)Unix 시스템 호출 또는 소켓별recv(2)통화.²

그럼에도 불구하고 2021년에도 Windows는 여전히 이 개념을 Unix와 같은 수준으로 끌어올리지 못했습니다. Windows 아키텍처의 많은 영역은 파일 시스템을 통해 액세스할 수 없거나 클래스 파일로 처리할 수 없습니다. 몇 가지 예:

운전사.

Windows의 드라이버 하위 시스템은 Unix만큼 풍부하고 강력하지만 드라이버를 조작하는 프로그램을 작성하려면 일반적으로 다음을 사용해야 합니다.Windows 드라이버 제품군, 이는 C 또는 .NET 코드 작성을 의미합니다.

Unix 유형 운영 체제에서는 명령줄을 통해 드라이버에 대한 다양한 작업을 수행할 수 있습니다. 원치 않는 출력을 /dev/null거의 확실히 이미 수행한 .³ 로 리디렉션하기만 하면 됩니다.
프로그램 간 통신.

Windows 프로그램은 Unix 명령줄 프로그램만큼 쉽게 텍스트 스트림과 파이프를 통해 서로 통신하지 않습니다. Unix GUI는 일반적으로 명령줄 프로그램 위에 구축되거나 텍스트 명령 인터페이스를 내보내므로 GUI 프로그램에도 동일한 간단한 텍스트 기반 통신 메커니즘이 적용됩니다.
기재.

Unix에는 Windows 레지스트리와 직접적으로 동등한 것이 없습니다. 동일한 정보는 주로 /etc, /proc및 에 있는 파일 시스템 전체에 분산되어 있습니다 /sys.

Windows 레지스트리에 대한 드라이버, 파이프 및 Unix 응답이 "모든 것이 파일입니다"와 관련이 있다는 것을 알지 못한다면 계속 읽으십시오.

"모든 것이 파일이다"라는 생각이 여기에 어떻게 작용합니까?

위의 세 가지 사항을 확장하여 자세히 설명하겠습니다.

긴 답변, 1부: 드라이브 및 장치 파일

E:CF 카드 리더가 Windows 및 /dev/sdcLinux 에 표시된다고 가정합니다 . 어떤 실질적인 차이가 있습니까?

이는 단지 사소한 구문 차이가 아닙니다.

dd if=/dev/zero of=/dev/sdcLinux에서는 콘텐츠를 0으로 덮어쓴다고 말할 수 있습니다 /dev/sdc.

이것이 무엇을 의미하는지 생각해 보십시오. 여기에는 일반적인 사용자 공간 프로그램이 있습니다(dd(1)), 통합 Unix 파일 시스템을 통해 가상 장치( )에서 데이터를 읽고 /dev/zero읽은 데이터를 실제 물리적 장치( )에 써야 합니다. 특수 장치를 읽고 쓰는지 몰랐습니다. 또한 아래와 같이 일반 파일이나 혼합 장치 및 파일에서도 작동합니다./dev/sdcdd

E:Windows는 파일과 드라이브를 구별하므로 동일한 명령을 사용하여 작동할 수 없기 때문에 Windows에서 드라이브를 0으로 만드는 쉬운 방법은 없습니다 . 가장 가까운 방법은 빠른 포맷 옵션 없이 디스크를 포맷하는 것입니다.최대내용을 드라이브에 저장한 다음 그 위에 새 파일 시스템을 씁니다. 내가 그러지 않으면 어떡하지?생각하다새로운 파일 시스템? 디스크를 0으로만 채우려면 어떻게 해야 합니까?

Windows의 프로그램에서 이 작업 E:을 수행하려면 특수 형식 지정 API를 호출해야 합니다. ⁴ Linux에서는 운영 체제의 "디스크 포맷" 기능에 액세스하기 위해 프로그램을 작성할 필요가 없습니다.mkfs.ext4,mkfs.xfs, 또는 당신은 무엇을 가지고 있습니까? 이러한 프로그램은 /dev전달한 모든 파일이나 노드의 파일 시스템에 기록합니다 .

mkfsUnixy 시스템의 유형 프로그램은 장치와 일반 파일을 인위적으로 구별하지 않기 때문에ext4 파일 시스템내 Linux 컴퓨터의 일반 파일에서:

$ dd if=/dev/zero of=myfs bs=1k count=1k
$ mkfs.ext4 -F myfs

myfs그러면 현재 디렉터리에 호출되는 1MiB 디스크 이미지가 생성됩니다. 그런 다음 다른 외부 파일 시스템처럼 마운트할 수 있습니다.

$ mkdir mountpoint
$ sudo mount -o loop myfs mountpoint
$ grep $USER /etc/passwd > mountpoint/my-passwd-entry
$ sudo umount mountpoint

my-passwd-entry이제 내 사용자 항목이 포함된 파일이 포함된 ext4 디스크 이미지가 생겼습니다 /etc/passwd.

원한다면 이 이미지를 내 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" \
      [email protected]

파일, 파일 시스템, 장치 간에 인위적인 구분이 없기 때문에 이 모든 것이 Linux⁵에서 가능합니다. 유닉스 시스템에는 많은 것들이 있다예파일을 사용하거나 파일 시스템을 통해 액세스하여처럼 보인다파일이거나 파일로 간주될 수 있을 정도로 파일과 충분히 유사해 보입니다.

Windows의 파일 시스템 개념은 뒤죽박죽입니다. 디렉터리, 드라이브 및 네트워크 리소스를 구별합니다. Windows에는 Unix와 같은 ..\FOO\BAR경로 시스템, 드라이브 문자(예: C:) 및 UNC 경로(예: )라는 세 가지 구문이 모두 함께 혼합되어 있습니다. \\SERVER\PATH\FILE.TXT이는 Unix 아이디어의 축적이기 때문입니다.CP/M,운영 체제, 그리고LAN 관리자하나의 일관된 디자인보다는. 그렇기 때문에Windows 파일 이름에 불법 문자가 너무 많습니다..

Unix는 통합된 파일 시스템을 갖추고 있으며 공통 체계를 통해 모든 것에 액세스할 수 있습니다. Linux 시스템에서 실행되는 프로그램의 경우 /etc/passwd, , 및 /media/CF_CARD/etc/passwd사이에 기능적 차이가 없습니다 /mnt/server/etc/passwd. 로컬 파일, 외부 미디어 및 네트워크 공유는 모두 동일한 방식으로 처리됩니다. ⁶

Windows는 위의 디스크 이미지 예와 유사한 목표를 달성할 수 있지만 매우 재능 있는 프로그래머가 작성한 특수 프로그램을 사용해야 합니다. 그렇기 때문에Windows용 "가상 DVD" 유형의 프로그램이 많이 있습니다.. 핵심 운영 체제 기능의 부족으로 인해 이러한 격차를 메우는 프로그램에 대한 인위적인 시장이 만들어졌습니다. 이는 최고의 가상 DVD 유형 프로그램을 만들기 위한 경쟁이 있음을 의미합니다. *ix 시스템에서는 그런 프로그램이 필요하지 않습니다.순환 장치.

다음과 같은 다른 도구도 마찬가지입니다.디스크 지우기프로그램, Unix 시스템에서도 이러한 프로그램이 필요하지 않습니다. CF 카드의 내용을 0으로 재설정하는 대신 복구 불가능하게 뒤섞기를 원하십니까? 알겠습니다. 사용하세요/dev/random다음 대신 데이터 소스로 사용 /dev/zero:

$ sudo dd if=/dev/random of=/dev/sdc

Linux에서는 핵심 운영 체제 기능이 충분히 잘 작동할 뿐만 아니라 너무 잘 작동하여 널리 사용되기 때문에 이와 같이 끊임없이 바퀴를 재발명하지 않습니다.여러 가지 방법 중 하나Linux 머신을 부팅하려면 위에서 보여준 기술을 사용하여 가상 디스크 이미지를 생성해야 합니다.

Unix가 처음부터 TCP/IP I/O를 파일 시스템에 통합했다면 대 대 대 대 상황이 발생하지 않았을 것이라는 점을 지적하는 것이 타당하다고 netcat생각 socat합니다 ncat.nc 착란그 이유는 Windows에서 디스크 이미징 및 삭제 도구의 확산을 초래한 것과 동일한 설계 결함, 즉 허용 가능한 운영 체제 기능이 부족하기 때문입니다.

긴 답변, 2부: 가상 파일로서의 파이프

Windows는 MS-DOS에서 시작되었지만 풍부한 명령줄 전통을 가져본 적이 없습니다.

이것은 Windows가 그렇지 않다는 것을 의미하지 않습니다.가지다명령줄 또는 많은 명령줄 프로그램이 부족합니다. 오늘날 Windows에는 매우 강력한 명령 셸도 있습니다.전원 공급 장치 하우징.

그러나 명령줄 전통이 부족하면 연쇄 효과가 발생합니다. 이런 도구를 얻게 됩니다.DISKPART대부분의 사람들이 컴퓨터 관리 MMC 스냅인을 통해 디스크 파티셔닝과 같은 작업을 수행하기 때문에 이는 Windows 세계에서는 거의 알려지지 않았습니다. 그런 다음 파티션 생성을 스크립트로 작성해야 할 때 DISKPART실제로는 다른 프로그램에 의해 구동되지 않는다는 것을 알게 됩니다. 예, 일련의 명령을 스크립트 파일에 작성하고 를 통해 실행할 수 있지만 DISKPART /S scriptfile전부 아니면 전무입니다. 너 뭐야진짜이 경우 원하는 것은 다음과 같습니다.암소 비슷한 일종의 영양parted, 이는 단일 명령을 허용합니다. 예를 들어 parted /dev/sdb mklabel gpt이를 통해 스크립트가 오류 처리를 단계별로 수행할 수 있습니다.

이 모든 것이 "모든 것이 파일이다"와 무슨 관련이 있습니까? 단순한:관로명령줄 프로그램 I/O를 일종의 "파일"에 넣습니다. 파이프는 단방향입니다.개울, 아니요무작위 액세스일반 디스크 파일과 비슷하지만 대부분의 경우 차이점은 중요하지 않습니다. 중요한 점은 독립적으로 개발된 두 개의 프로그램을 연결하여 간단한 텍스트로 통신할 수 있다는 것입니다. 이런 의미에서 어떤 두유닉스 방식정신적으로 소통할 수 있습니다.

파일이 꼭 필요한 경우 프로그램 출력을 파일로 쉽게 변환할 수 있습니다.

$ some-program --some --args > myfile
$ vi myfile

하지만 "모든 것이 파일이다"라는 철학이 더 나은 방법을 제공하는데 왜 임시 파일에 출력을 작성합니까? 명령의 출력을 vi편집기 버퍼 로 읽으려면 vi"일반" 모드에서 직접 수행할 수 있습니다.

:r !some-program --some --args

프로그램의 출력을 현재 커서 위치의 활성 편집기 버퍼에 삽입합니다. 그 뒤에서 vi파이프는 프로그램의 출력을 파일에서 읽는 데 사용되는 것과 동일한 운영 체제 호출을 사용하는 일부 코드에 연결하는 데 사용됩니다. 두 가지 경우 :r(예: yes 및 no !)가 모두 포함된 경우 vi이 작업을 수행하지 않을 이유가 없습니다.

이것은 최신 기능도 아닙니다 vi.고대의 ed(1)텍스트 에디터.

이 강력한 아이디어는 Unix에서 계속해서 등장합니다.

두 번째 예에서는 mutt위의 email 명령을 기억해 보십시오. 내가 이것을 두 개의 별도 명령으로 작성해야 했던 유일한 이유 *.gz는 이메일 첨부 파일의 이름이 올바르게 지정되도록 임시 파일의 이름을 지정하기를 원했기 때문입니다 . 파일 이름에 신경 쓰지 않으면 다음을 사용할 수 있습니다.프로세스 교체임시 파일 생성을 피하세요.

$ echo "Here's the disk image I promised to send you." | 
  mutt -a <(gzip -c myfs) -s "Password file disk image" \
      [email protected]

이는 출력을 gzip -cFIFO(파일과 같은) 또는 /dev/fd객체(파일과 같은)로 변환합니다. 7

이 강력한 아이디어가 Unix에 나타나는 세 번째 방법으로 다음을 고려하십시오.gdb리눅스 시스템에서. 이것은 C 및 C++로 작성된 모든 소프트웨어에 대한 디버거입니다. 다른 시스템에서 Unix로 전환하는 프로그래머는 gdb거의 항상 "아, 너무 원시적이야!"라고 불평할 것입니다. 그런 다음 그들은 GUI 디버거를 찾고 존재하는 몇 안 되는 디버거 중 하나를 찾아 행복하게 작업을 계속합니다... ...종종 전혀 그렇지 않습니다. GUI가 바로 gdb아래에서 실행되고 그 위에 멋진 쉘을 제공한다는 것을 깨닫습니다. 프로그램이 해당 수준에서 경쟁할 필요가 없기 때문에 경쟁하는 저수준 디버거는 대부분의 Unix 시스템에 존재하지 않습니다. 우리에게 필요한 것은 좋은 하위 수준 도구뿐입니다. 해당 하위 수준 도구가 파이프를 통해 쉽게 통신할 수 있다면 우리 모두는 해당 하위 수준 도구 위에 상위 수준 도구를 구축할 수 있습니다.

이는 이제 우리가 직접 대체할 수 있는 문서화된 디버거 인터페이스를 갖게 되었음을 의미합니다 gdb. 불행하게도 주요 경쟁사입니다.gdb 마찰이 적은 경로를 택하지 않음, 그러나 그 주장을 제외하면 lldb와 마찬가지로 스크립트가 가능합니다 gdb.

Windows 시스템에서 동일한 기능을 달성하려면 대체 도구 작성자가 일종의 공식 플러그인 또는 자동화 API를 정의해야 합니다. 이는 일반적인 명령줄 사용자 인터페이스와 전체 프로그래밍 API를 구축하려면 많은 작업이 필요하기 때문에 가장 널리 사용되는 프로그램을 제외한 모든 프로그램에서는 이런 일이 발생하지 않는다는 것을 의미합니다.

이 마법은 유비쿼터스 텍스트 기반 은혜를 통해 일어납니다.산업용 컴퓨터.

비록 Windows 커널Unix 스타일 익명 파이프, 일반 사용자 프로그램에서 이를 사용하는 경우는 거의 없습니다.산업용 컴퓨터명령 셸 외부에서는 Windows에는 먼저 명령줄 버전에서 모든 핵심 서비스를 생성한 다음 그 위에 별도로 GUI를 구축하는 전통이 부족하기 때문입니다. 이로 인해 GUI 없이는 불가능한 일이 발생하는데, 이는 GUI가 너무 많은 이유 중 하나입니다.원격 데스크톱 시스템Windows의 경우 Linux와 비교됩니다. 이것이 바로 Linux가 모든 것을 원격으로 관리하는 클라우드 운영 체제가 된 이유 중 하나입니다. 명령줄 인터페이스는 "모든 것이 파일"이기 때문에 GUI보다 자동화하기가 더 쉽습니다.

SSH를 고려해보세요. 어떻게 작동하는지 물어볼 수 있습니까? SSH는 네트워크 소켓(파일과 유사)을 다음에 연결합니다.의사 터미널at /dev/pty*(파일과 유사). 이제 원격 시스템은 Unix 방식과 완벽하게 일치하는 연결을 통해 로컬 시스템에 연결됩니다.SSH 연결을 통해 데이터를 전송할 수 있습니다, 필요한 경우.

이제 이 개념이 얼마나 강력한지 아시겠습니까?

프로그램의 관점에서 파이프로 연결된 텍스트 스트림은 단방향이라는 점을 제외하면 파일과 다르지 않습니다. 프로그램은 파일에서 데이터를 읽는 것과 같은 방식으로 파이프에서 데이터를 읽습니다.파일 설명자. FD는 확실히 Unix의 핵심입니다. 파일, 파이프 및 네트워크 소켓이 모두 동일한 I/O 추상화를 사용한다는 사실이 여러분에게 시사하는 바가 있습니다.

Windows 세계에는 이러한 단순한 텍스트 통신의 전통이 부족하며 무거운 통신을 사용해야 합니다.객체 지향 프로그래밍인터페이스를 통해직렬 통신또는. 그물. 이러한 프로그램을 자동화해야 하는 경우 COM 또는 .NET 프로그램도 작성해야 합니다. 이는 Unix 시스템에서 파이프를 설정하는 것보다 조금 더 어렵습니다.

이러한 정교한 프로그래밍 API가 없는 Windows 프로그램은 클립보드나 파일/저장, 파일/열기와 같은 기본적인 인터페이스를 통해서만 통신할 수 있습니다.

긴 답변, 3부: 레지스트리와 구성 파일

Windows 레지스트리와 Unix 시스템 구성 방식 간의 실질적인 차이점은 "모든 것이 파일이다"라는 철학의 이점을 보여줍니다.

Unix 유형 시스템에서는 간단히 파일을 검사하여 명령줄에서 시스템 구성 정보를 볼 수 있습니다. 동일한 파일을 수정하여 시스템 동작을 변경할 수 있습니다. 대부분의 경우 이러한 구성 파일은 일반 텍스트 파일이므로 일반 텍스트 파일을 처리할 수 있는 Unix의 모든 도구를 사용하여 구성 파일을 조작할 수 있습니다.

스크립팅Windows의 레지스트리는 그렇게 쉽지 않습니다.

가장 쉬운 방법은 한 컴퓨터에서 레지스트리 편집기 GUI를 통해 변경한 다음regedit파일을 통해 *.reg이러한 변경 사항을 다른 컴퓨터에 맹목적으로 적용. 이것은 조건에 따라 아무것도 할 수 없도록 허용하는 "스크립트"가 아닙니다. 전부 아니면 전무입니다.

레지스트리 변경에 어느 정도의 논리가 필요한 경우 다음으로 가장 쉬운 옵션은 다음을 배우는 것입니다.전원 공급 장치 하우징.NET 시스템 프로그래밍을 배우는 것과 같습니다. Unix에는 Perl만 있고 모든 작업을 수행해야 하는 것과 같습니다.애드 혹이를 통해 시스템 관리가 이루어집니다. 저는 Perl 팬이지만 모든 사람이 그런 것은 아닙니다. Unix에서는 일반 텍스트 파일에서 작동할 수 있는 도구라면 무엇이든 사용할 수 있습니다.

각주:

계획 9네트워크 I/O를 노출하여 이 설계 오류를 수정했습니다.가상 /net파일 시스템.

배쉬는/dev/tcp일반 파일 시스템 기능을 통해 네트워크 I/O를 허용합니다. 커널 기능이 아닌 Bash 기능이므로 Bash 외부나 시스템에서는 표시되지 않습니다.Bash를 전혀 사용하지 않는 시스템. 반례를 통해 이는 파일 시스템을 통해 모든 데이터 리소스를 표시하는 것이 좋은 이유를 보여줍니다.
"최신 Windows"란 Windows NT와 Windows 2000, 모든 버전의 Windows Server 및 XP로 시작하는 모든 데스크톱 지향 Windows 버전을 포함하여 모든 직계 자손을 의미합니다. 나는 이 용어를 사용하여 Windows의 MS-DOS 기반 버전, 즉 Windows 95와 그 직계 자손, Windows 98과 Windows ME 및 16비트 이전 버전을 제외했습니다.

후자의 운영 체제에서는 통합 I/O 시스템이 없다는 점에서 차이점을 확인할 수 있습니다. ReadFile()Windows 95에서는 TCP/IP 소켓을 전달할 수 없으며 Windows 소켓 API에만 소켓을 전달할 수 있습니다. Andrew Schulman의 주요 기사를 참조하세요.Windows 95: 그렇지 않은 것이 주제를 더 자세히 살펴보세요.
/dev/null이것이 단지 특수한 경우의 표면적으로 동등한 파일 이름이 아니라 Unix 유형 시스템의 실제 커널 장치라는 점에는 의심의 여지가 없습니다 .NULWindows에서.

Windows에서는 파일 생성을 차단하려고 시도하지만 NUL이 보호 기능을 우회할 수 있습니다.그냥 트릭으로, Windows의 파일 이름 구문 분석 논리를 속이기 위해. Cygwin이나 Explorer를 사용하여 파일에 접근하려고 하면 cmd.exeWindows에서는 파일 열기를 거부하지만, 예제 프로그램과 비슷한 방법으로 파일을 열고 삭제할 수 있으므로 Cygwin을 통해 쓸 수 있습니다.비슷한 계략으로.

대조적으로, 유닉스는 rm /dev/null당신이 쓰기 권한을 갖고 있는 한 /dev그 자리에 새 파일을 다시 생성할 수 있도록 허용합니다.개발 노드또 다른 파일입니다. 개발 노드가 손실되더라도 커널의 빈 장치는 여전히 존재하며 다음을 통해 개발 노드를 다시 생성할 때까지 액세스할 수 없습니다.mknod.

다른 곳에서 빈 장치 개발 노드를 추가로 생성할 수도 있습니다. 호출 여부에 관계없이 /home/grandma/Recycle Bin빈 장치의 개발 노드인 것처럼 작동합니다 /dev/null.
실제로는 있습니다둘Windows의 고급 "디스크 포맷" API:SHFormatDrive()그리고Win32_Volume.Format().

두 개가 있는데 아주...글쎄...윈도우몇몇 이유. 첫 번째 방법은 Windows 탐색기에서 일반적인 "디스크 포맷" 대화 상자를 표시해야 합니다. 즉, 모든 최신 버전의 Windows에서 작동하지만 사용자가 대화형으로 로그인한 경우에만 작동합니다. 다른 하나는 사용자 입력 없이 백그라운드에서 호출할 수 있지만 Windows Server 2003까지는 Windows에 추가되지 않았습니다. 맞습니다. 2003년까지 Unix 릴리스 세계에서는 핵심 운영 체제 동작이 GUI 뒤에 숨겨져 있었습니다.mkfs 첫날부터.

내/etc/mkfs유닉스 V5 사본1974년부터 4136바이트의 정적 링크가 시작되었습니다.플라즈마 11실행 가능. (Unix는 동적 연결을 얻지 못합니다.1980년대 후반까지, 따라서 하나의 큰 도서관이 모든 실제 작업을 수행하는 다른 장소와는 다릅니다. ) 해당 소스 코드 - 아래와 같이 V5 시스템 이미지에 포함되어 있습니다./usr/source/s2/mkfs.c— 완전히 독립적인 457라인 C 프로그램입니다. 어떤 진술도 없습니다 #include!

mkfs이는 높은 수준의 기능을 확인할 수 있을 뿐만 아니라 Unix를 만드는 데 사용된 것과 동일한 도구 세트를 실험할 수도 있음을 의미합니다 .켄 톰슨, 40년 전. Windows에서 사용해 보세요. 오늘 얻을 수 있는 가장 가까운 것은 다운로드하는 것입니다.MS-DOS 소스 코드, 에 처음 게시됨2014년, 당신은 그것이 단지 무리라는 것을 알게 될 것입니다집회원천. 아마도 여러분이 가지고 있지 않은 구식 도구로 구축될 것이며, 결국 1974년의 것보다 훨씬 덜 강력한 운영 체제인 MS-DOS 2.0의 복사본을 갖게 될 것입니다.유닉스 V5, 거의 10년 후에 출시되었지만.

(Unix V5에 대해 이야기하는 이유는 존재하는 최초의 완전한 Unix 시스템이기 때문입니다. 이전 버전은분명 시간에 쫓겨났지. 가지다프로젝트이것은 Unix의 V1/V2 시대를 하나로 묶었지만 사라진 것 같습니다. mkfs위에 링크된 V1 매뉴얼 페이지의 존재는 그것이 언젠가 어딘가에 존재했음이 틀림없다는 것을 증명합니다. 이 프로젝트를 함께 진행한 사람들이 포함할 기존 복사본을 찾을 수 없거나 mkfs, 나에게 없고 find(1)이 시스템에 존재하지 않는 파일을 찾는 데 어려움을 겪고 있습니다. :))

이제 "그냥 직접 호출하면 안 될까 format.com? Windows에서 호출하는 것이 Unix에서 호출하는 것과 같지 않을까 mkfs?"라고 생각할 수도 있습니다. 아뇨, 여러 가지 이유로 동일하지 않습니다.
- 첫째, format.com스크립트를 작성하도록 설계되지 않았습니다. "준비되면 Enter 키를 누르십시오"라는 메시지가 표시됩니다. 이는 Enter 키를 입력으로 보내야 함을 의미합니다. 그렇지 않으면 작동이 중단됩니다.
- 그런 다음 성공/실패 상태 코드 이상의 것을 원한다면 읽기 위해 표준 출력을 열어야 합니다.Windows의 상황은 실제보다 훨씬 더 복잡합니다.. (Unix에서는 이 링크된 기사의 모든 내용에 간단한 명령을 통해 액세스할 수 있습니다.popen(3)부르다. )
- 이 모든 복잡성 때문에 format.com의 출력은 의 출력보다 구문 분석하기가 훨씬 더 어렵고 mkfs주로 사람이 사용하도록 의도되었습니다.
- 내용을 추적해 보면 format.com복잡한 일련의 호출을 수행한다는 것을 알 수 있습니다.DeviceIoControl(), ufat.dll, 등. 단순히 장치 파일을 열고 해당 장치에 새 파일 시스템을 쓰는 것이 아닙니다. 이것이 당신이 얻는 디자인입니다전 세계적으로 221,000명의 직원을 보유한 회사그리고 필요하다유지하다그들을 고용하세요.
  
  핵심 운영 체제 도구가 자원 봉사자들에 의해 여가 시간에 작성될 때 일어나는 일과 대조해 보십시오. 그들은 자신의 문제에 대한 임시방편, 최소한의 해결책을 제시하고 나머지 사람들에게 단순성 배당금을 제공합니다.
루프 장치에 대해 이야기할 때 일반적으로 Unix가 아닌 Linux에 대해서만 이야기하는 것입니다. 왜냐하면 루프 장치는 Unix 유형 시스템 간에 이식 가능하지 않기 때문입니다. macOS, BSD 등은 메커니즘이 비슷하지만 구문이 다릅니다.약간 다른.
디스크 드라이브가 세탁기 크기이고 부서 임원의 고급 자동차보다 가격이 더 비쌌던 시대에 대형 컴퓨터실은 현대 컴퓨팅 환경보다 더 큰 전체 디스크 공간을 공유했습니다. 원격 디스크를 로컬 파일 시스템으로 투명하게 마이그레이션하는 기능을 통해 이 분산 시스템을 더 쉽게 사용할 수 있습니다. /usr/share예를 들어, 이것이 우리가 얻는 곳입니다.

드라이브 문자가 기호 표현을 위한 선택 사항을 거의 제공하지 않는 Windows의 경우 이는 P:BigServer의 "공용" 공간을 의미합니까, 아니면 소프트웨어 미러 서버의 "패키지" 디렉터리를 의미합니까? UNC 대안을 사용하려면 원격 파일이 있는 서버를 기억해야 합니다. 이는 수백 또는 수천 개의 파일 서버가 있는 대규모 조직에서는 어렵습니다.

Windows는 2007년 Vista가 출시될 때까지 심볼릭 링크를 얻지 못했습니다.NTFS 심볼릭 링크이며, 제조되지 않았습니다.쓸 수 있는 10년 후까지. Windows 심볼릭 링크는 Unix 심볼릭 링크보다 더 강력합니다. 이는 Unix 기능입니다.1977년부터- 로컬 경로뿐만 아니라 원격 파일 공유도 가리킬 수 있기 때문입니다. 유닉스에서는 다음과 같이 다르게 수행합니다.1984년 NFS, 이는 Unix의 기존을 기반으로 구축되었습니다.마운트 포인트기능, 이것은 처음부터 있었던 것입니다.

따라서 Windows는 보는 관점에 따라 Unix보다 약 20, 30, 40년 뒤쳐져 있습니다. 당신은 "그러나 그것은 Unix 스타일의 심볼릭 링크를 가지고 있습니다"라고 반대할 수도 있습니다.지금!“그러나 이는 수십 년 된 전통이 없다는 의미이기 때문에 요점을 놓치고 있습니다.사용Windows에서 실행되므로 Unix 시스템이 일반적으로 사용하는 세계에서는 사람들이 이를 인식하지 못합니다. 심볼릭 링크를 이해하지 못하면 오랫동안 Unix 시스템을 사용할 수 없습니다.

윈도우는 도움이 안 돼요MKLINK프로그램예뒤로, 여전히 Windows 탐색기에서는 만들 수 없으며 Windows 탐색기에 해당하는 Unix는 일반적으로하다심볼릭 링크를 생성할 수 있습니다.
/dev/fdBash는 모든 곳에서 사용할 수 없는 시스템 기능을 기반으로 방법을 선택합니다 .

Question 2

글쎄, 단순화 자체로서 "모든 것이 파일이다"는 간단한 특성화가 필요합니다.

Ken Thompson과 Dennis Ritchie는 1969년에 UNIX 시스템을 구축하기 시작했을 때 컴퓨터와 인간 간의 상호 작용의 여러 측면을 단순화하는 구조를 발견했습니다. Thompson과 Ritchie는 시스템을 단순하게 유지하는 것을 목표로 했으며, 극소수의 기본 요소로 많은 작업을 수행할 수 있는 기본 요소 세트를 찾았습니다.

--AT&T 아카이브: UNIX 운영 체제 4:35

"모든 것이 파일이다"라는 생각은 모든 사용자 작업으로 인해 운영 체제가 제어하는 주소에서 비트가 읽히거나 쓰여진다는 사실을 반영합니다. 이는 시스템 호출, 할당된 메모리, 하드웨어 장치의 주소입니다. UNIX 셸을 통해 이러한 주소를 노출하면 사용자는 추가 소프트웨어 없이도 다양한 작업을 수행할 수 있습니다.

파일을 읽고, 쓰고, 실행하여 UNIX 쉘과 상호 작용합니다. 여기서 "파일"은 문자 그대로 쓰고, 읽고, 실행할 수 있는 것을 의미합니다. 이를 통해 스크립트와 사용자는 정확히 동일한 방식으로 시스템과 상호 작용할 수 있어 상호 작용의 일부 측면이 단순화됩니다.

Windows에는 그러한 철학이 없습니다. 많은 상황에서 동일한 기능을 제공하지만 원칙이 부족합니다. 예를 들어 Windows Shell은 시각적입니다. 최종 사용자의 경우 각 작업 세트에는 자체 도구 세트가 있는 경우가 많으며 이러한 도구 세트를 바인딩하려면 다른 도구 세트가 필요한 경우가 많습니다.

Answer

글쎄, 단순화 자체로서 "모든 것이 파일이다"는 간단한 특성화가 필요합니다.

Ken Thompson과 Dennis Ritchie는 1969년에 UNIX 시스템을 구축하기 시작했을 때 컴퓨터와 인간 간의 상호 작용의 여러 측면을 단순화하는 구조를 발견했습니다. Thompson과 Ritchie는 시스템을 단순하게 유지하는 것을 목표로 했으며, 극소수의 기본 요소로 많은 작업을 수행할 수 있는 기본 요소 세트를 찾았습니다.

--AT&T 아카이브: UNIX 운영 체제 4:35

"모든 것이 파일이다"라는 생각은 모든 사용자 작업으로 인해 운영 체제가 제어하는 주소에서 비트가 읽히거나 쓰여진다는 사실을 반영합니다. 이는 시스템 호출, 할당된 메모리, 하드웨어 장치의 주소입니다. UNIX 셸을 통해 이러한 주소를 노출하면 사용자는 추가 소프트웨어 없이도 다양한 작업을 수행할 수 있습니다.

파일을 읽고, 쓰고, 실행하여 UNIX 쉘과 상호 작용합니다. 여기서 "파일"은 문자 그대로 쓰고, 읽고, 실행할 수 있는 것을 의미합니다. 이를 통해 스크립트와 사용자는 정확히 동일한 방식으로 시스템과 상호 작용할 수 있어 상호 작용의 일부 측면이 단순화됩니다.

Windows에는 그러한 철학이 없습니다. 많은 상황에서 동일한 기능을 제공하지만 원칙이 부족합니다. 예를 들어 Windows Shell은 시각적입니다. 최종 사용자의 경우 각 작업 세트에는 자체 도구 세트가 있는 경우가 많으며 이러한 도구 세트를 바인딩하려면 다른 도구 세트가 필요한 경우가 많습니다.

Question 3

당신이 Linux생각한다면영어, file systems각각알파벳이것은 기본적으로 기본 블록입니다.영어.

~에서위키피디아파일 시스템 페이지,

컴퓨팅에서는 파일 시스템(또는 파일 시스템)을 사용하여 데이터 저장 및 검색 방법을 제어합니다. 파일 시스템이 없으면 저장 영역에 있는 정보는 한 정보가 어디서 멈추고 다음 정보가 시작되는지 구분할 수 없는 데이터 덩어리가 됩니다.

따라서 일반인의 관점에서 볼 때 영어의 올바른 언어 구조(문자로 구성됨)가 없으면 인간 상호 작용은 의미가 없습니다. 마찬가지로, 파일 시스템이 없으면 기본 저장 장치의 모든 데이터는 실제 의미가 없습니다.

Answer

당신이 Linux생각한다면영어, file systems각각알파벳이것은 기본적으로 기본 블록입니다.영어.

~에서위키피디아파일 시스템 페이지,

컴퓨팅에서는 파일 시스템(또는 파일 시스템)을 사용하여 데이터 저장 및 검색 방법을 제어합니다. 파일 시스템이 없으면 저장 영역에 있는 정보는 한 정보가 어디서 멈추고 다음 정보가 시작되는지 구분할 수 없는 데이터 덩어리가 됩니다.

따라서 일반인의 관점에서 볼 때 영어의 올바른 언어 구조(문자로 구성됨)가 없으면 인간 상호 작용은 의미가 없습니다. 마찬가지로, 파일 시스템이 없으면 기본 저장 장치의 모든 데이터는 실제 의미가 없습니다.

"모든 것이 파일이다"에 대한 일반인의 설명 - Windows와 어떻게 다른가요?

답변1

답변2

답변3

관련 정보