"Her şey bir dosyadır" biraz glib. "Her şey dosya sisteminde bir yerde görünür " işaretine daha yakındır ve o zaman bile, sistem tasarım yasalarından daha idealdir.
Örneğin, Unix etki alanı soketleri dosya değildir, ancak dosya sisteminde görünürler. Şunları yapabilirsiniz ls -lBir etki alanı soketi, onun özelliklerini görüntülemek için cat, birinden / 'e veri yoluyla kendi erişim kontrolü değiştirebilir chmod, vb
Ama, düzenli halde TCP / IP ağ yuvaları hazırlanmış olup, aynı ile manipüle edilir BSD soketleri Unix alan soketi gibi sistem çağrıları, TCP / IP yuvaları yok değil bu should hiçbir özellikle iyi bir neden olsa bile ¹, dosya sisteminde göstermek Gerçek olmak.
Dosya sisteminde görünen dosya dışı nesnelerin bir başka örneği de Linux'un /procdosya sistemidir . Bu özellik, çekirdeğin çalışma zamanı işlemi hakkında , çoğunlukla sanal düz metin dosyaları olarak kullanıcı alanına çok fazla ayrıntı sunar . Birçok /procgiriş salt okunurdur, ancak /procçoğu da yazılabilirdir, böylece bir dosyayı değiştirebilecek herhangi bir programı kullanarak sistemin çalışma şeklini değiştirebilirsiniz. Ne yazık ki, burada yine bir kayıtsızlığa/proc sahibiz: BSD tipi Unixler genel olarak onsuz çalışırlar ve System V Unixler /procLinux'tan çok daha az gösterir .
Bunu MS Windows ile kıyaslayamam.
Birincisi, çevrimiçi bulabileceğiniz ve Unix ile ilgili kitapların hepsinin G / Ç dosyaları ve Windows’un bu konuda "kırılmaları" hakkında olduğu düşüncesi çok eski. Windows NT bunu çok düzeltti.
Windows'un modern sürümlerinde, tıpkı Unix'te olduğu gibi birleşik bir G / Ç sistemi bulunur; böylece, ağ verilerini, ReadFile()isterseniz Windows Sockets belirli API'si yerine bir TCP / IP soketinden okuyabilirsiniz WSARecv(). Bu tam paralellik Unix Way Eğer jenerik ya sahip bir ağ soketinden okuyabilir, read(2)Unix sistem çağrı veya yuva özgü recv(2)call.²
Bununla birlikte, Windows hala bu kavramı 2018'de bile Unix'le aynı seviyeye getiremiyor. Windows mimarisinde, dosya sisteminden erişilemeyen veya dosya gibi görülemeyen birçok alan var. Bazı örnekler:
Sürücüler.
Windows'un sürücü alt sistemi, Unix'ler kadar kolay ve zengindir, ancak sürücüleri yönetmek için programlar yazmak için, genellikle C veya .NET kodunu yazmak anlamına gelen Windows Sürücü Kitini kullanmanız gerekir .
Unix tipi işletim sistemlerinde, komut satırından sürücülere çok şey yapabilirsiniz. Neredeyse kesinlikle zaten keşke bağlı istenmeyen çıkışları yönlendirerek, bu yaptık /dev/null.³
Programlar arası iletişim.
Windows programları birbirleriyle kolayca iletişim kurmazlar.
Unix komut satırı programları, metin akışları ve borular aracılığıyla kolayca iletişim kurar. GUI programları genellikle komut satırı programlarının üstüne inşa edilir veya bir metin komut arayüzü dışa aktarır; böylece aynı basit metin tabanlı iletişim mekanizmaları da GUI programlarıyla çalışır.
Kayıt defteri
Unix'in Windows kayıt defterine doğrudan bir karşılığı yoktur. Aynı bilgiler bunun çoğu, dosya sistemi aracılığıyla dağınık /etc, /procve /sys.
Sürücüleri, boruları ve Unix'in Windows kayıt defterine verdiği cevabı görmüyorsanız, "her şey bir dosyadır" ile ilgili bir şeyler okuyun.
"Her şey bir dosyadır" felsefesi burada nasıl bir fark yaratır?
Bunu yukarıda üç noktama genişleterek, detaylı olarak açıklayacağım.
Uzun cevap, bölüm 1: Sürücüler vs Aygıt Dosyaları
Diyelim ki CF kart okuyucunuz E:Windows ve /dev/sdcLinux altında gözüküyor . Hangi pratik farkı yaratır?
Bu sadece küçük bir sözdizimi farkı değildir.
Linux'ta dd if=/dev/zero of=/dev/sdciçeriğinin üzerine /dev/sdcsıfır yazdığını söyleyebilirim .
Bunun bir saniye için ne anlama geldiğini düşünün. Burada dd(1), sanal bir cihazdan ( /dev/zero) verileri okumak /dev/sdcve birleşik Unix dosya sistemi aracılığıyla okuduğunu gerçek bir fiziksel cihaza ( ) yazmak istediğim normal bir kullanıcı alanı programına ( ) sahibim . ddözel cihazlardan okuduğunu ve yazdığını bilmiyor. Aşağıda da göreceğimiz gibi düzenli dosyalar üzerinde veya aygıt ve dosyaların bir karışımı üzerinde çalışacaktır.
E:Sürücüyü Windows'ta sıfırlamanın kolay bir yolu yoktur ; çünkü Windows, dosyalar ve sürücüler arasında bir ayrım yapar, bu nedenle bunları değiştirmek için aynı komutları kullanamazsınız. Alabileceğiniz en yakın sürücü, sürücü içeriğinin çoğunu sıfırlayan Hızlı Biçimlendirme seçeneği olmadan bir disk formatı yapmaktır , ancak üzerine yeni bir dosya sistemi yazar. Ya yeni bir dosya sistemi istemiyorsam ? Ya gerçekten diskin sıfırdan başka bir şeyle doldurulmasını istemezsem?
Cömert olalım ve gerçekten yeni bir dosya sistemi istiyoruz diyelim E:. Bunu yapmak için Windows'taki bir programda, özel bir biçimlendirme API'si çağırmalıyım. Linux'ta, işletim sisteminin "biçim diski" işlevselliğine erişmek için bir program yazmanıza gerek yoktur. Sadece Oluşturmak istediğiniz dosya sistemi türü için uygun kullanıcı uzay programını çalıştırın: mkfs.ext4, mkfs.xfsveya sizi ne var. Bu programlar geçirdiğiniz dosya veya /devdüğüme bir dosya sistemi yazacaktır .
Çünkü mkfsUnixy sistemlerinde tip programlar cihazlar ve normal dosyaları arasında yapay ayrım yapmaksızın dosya üzerinde çalışmak, ben bir oluşturmak anlamına gelir ext4 dosya sistemini Linux makinemde normal dosyası içinde:
$ dd if=/dev/zero of=myfs bs=1k count=1k
$ mkfs.ext4 -F myfs
Kelimenin tam anlamıyla, geçerli dizinde adı verilen 1 MiB disk görüntüsü oluşturur myfs. Daha sonra herhangi bir harici dosya sistemiymiş gibi bağlayabilirim:
$ mkdir mountpoint
$ sudo mount -o loop myfs mountpoint
$ grep $USER /etc/passwd > mountpoint/my-passwd-entry
$ sudo umount mountpoint
Şimdi my-passwd-entrybenim kullanıcı /etc/passwdgirişi içeren içinde denilen bir dosya ile bir ext4 disk görüntüsü var .
İstersem, bu görüntüyü CF kartıma atabilirim:
$ sudo dd if=myfs of=/dev/sdc1
Ya da, ben, bu disk imajını toparlanıp size postalayamıyoruz ve bir orta yazalım olabilir sizin böyle bir USB bellek gibi seçeceği:
$ 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
Bunların hepsi Linux'ta mümkündür, çünkü dosyalar, dosya sistemleri ve cihazlar arasında yapay bir ayrım yoktur. Unix sistemleri üzerinde pek çok şey ya vardır dosyalar, ya da o kadar dosya sistemi aracılığıyla erişilen gibi görünen dosya veya başka bir şekilde bakmak yeterince file benzeri onlar gibi tedavi edilebilir.
Windows'un dosya sistemi kavramı bir saklanma yeridir; dizinler, sürücüler ve ağ kaynakları arasında ayrım yapar. Hepsi Windows'ta harmanlanmış üç farklı sözdizimi vardır: Unix benzeri ..\FOO\BARyol sistemi, sürücü harfleri C:ve UNC yolları gibi \\SERVER\PATH\FILE.TXT. Bunun nedeni , tek bir tutarlı tasarımdan ziyade Unix, CP / M , MS-DOS ve LAN Manager'dan alınan fikirlerin bir araya gelmesidir. Windows dosya adlarında çok fazla yasa dışı karakter bulunmasının nedeni budur .
Unix, ortak bir sistem tarafından erişilen her şeye sahip birleştirilmiş bir dosya sistemine sahiptir. Linux kutu üzerinde çalışan bir program için, orada arasında hiçbir işlevsel fark /etc/passwd, /media/CF_CARD/etc/passwdve /mnt/server/etc/passwd. Yerel dosyalar, harici medya ve ağ paylaşımları aynı şekilde ele alınır.
Windows yukarıdaki disk imaj örneğime benzer sonuçlar verebilir, ancak nadiren yetenekli programcılar tarafından yazılmış özel programları kullanmak zorundasınız. Bu yüzden Windows'ta bu kadar çok "sanal DVD" tipi program var . Çekirdek bir işletim sistemi özelliğinin olmaması, programları boşluğu doldurmak için yapay bir pazar yarattı; bu, en iyi sanal DVD türü programı oluşturmak için yarışan bir sürü insanınız olduğu anlamına gelir. * İx sistemlerinde bu tür programlara ihtiyacımız yok, çünkü bir döngü aygıtı kullanarak sadece bir ISO disk görüntüsü bağlayabiliriz .
Aynı şey Unix sistemlerinde de ihtiyacımız olmayan disk silme programları gibi diğer araçlar için de geçerli. CF kartınızın içeriğinin yalnızca sıfırlanmak yerine geri alınamaz bir şekilde karıştırılmasını mı istiyorsunuz? Tamam, /dev/randomveri kaynağı olarak kullanmak yerine /dev/zero:
$ sudo dd if=/dev/random of=/dev/sdc
Linux'ta bu tür tekerlekleri yeniden icat etmeye devam etmiyoruz çünkü çekirdek işletim sistemi özellikleri sadece yeterince iyi değil, çok iyi çalışıyorlar. Bir Linux kutusunu başlatmak için kullanılan tipik bir şema, yukarıda gösterdiğim teknikler kullanılarak oluşturulan bir örnek için sanal disk görüntüsünü içerir.
Unix'in TCP / IP I / O’yu baştan beri dosya sistemine entegre etmesine rağmen, netcatvs socatvs Ncatvs karmaşasına sahip olmayacağımızı belirtmemizin adil olacağını düşünüyorum . Windows üzerinde disk görüntüleme ve silme aracı proliferasyonu: kabul edilebilir bir işletim sistemi tesisinin olmaması.nc
Uzun Cevap, bölüm 2: Sanal Dosyalar Olarak Borular
DOS'taki köklerine rağmen, Windows hiçbir zaman zengin bir komut satırı geleneğine sahip olmamıştır.
Bu, Windows olmadığını söylemek değildir sahip bir komut satırı, ya da birçok komut satırı programları yoksun olduğunu. Windows bu günlerde, PowerShell olarak adlandırılan çok güçlü bir komut kabuğuna bile sahip .
Yine de, bu bir komut satırı geleneği eksikliğinin olumsuz etkileri vardır. DISKPARTNeredeyse Windows dünyasında bilinmeyen araçlar elde edersiniz , çünkü çoğu insan disk bölümleme yapar ve böyle bir Bilgisayar Yönetimi MMC ek bileşeni aracılığıyla. Daha sonra bölüm oluşturma komutunu yazmanız gerektiğinde DISKPART, bunun gerçekten başka bir program tarafından yönlendirilmediğini fark edersiniz . Evet, bir komut dosyasına bir dizi komut yazıp onu çalıştırabilirsiniz DISKPART /S scriptfile, ancak hepsi ya da hiçbiridir. Ne gerçekten böyle bir durum istemek daha gibi bir şey GNUparted gibi tek komutları kabul eder, parted /dev/sdb mklabel gpt. Bu, komut dosyanızın adım adım hata işlemesini sağlar.
Bütün bunların "her şey bir dosya" ile ne ilgisi var? Kolay: borular , komut satırı programındaki G / Ç'yi "dosya" haline getirir. Borular tek yönlü akışlardır , normal bir disk dosyası gibi rastgele erişime sahip değildir , ancak çoğu durumda farkın bir sonucu yoktur. Önemli olan, bağımsız olarak geliştirilen iki programı ekleyip basit metinlerle iletişim kurabilmenizdir. Bu anlamda Unix Yolu ile tasarlanan iki program iletişim kurabilir.
Gerçekten bir dosyaya ihtiyaç duyduğunuz durumlarda, program çıktısını bir dosyaya dönüştürmek kolaydır:
$ some-program --some --args > myfile
$ vi myfile
Fakat neden "her şey bir dosyadır" felsefesi size daha iyi bir yol verirse çıktıyı geçici bir dosyaya yazar? Tek yapmak istediğiniz komutun çıktısını bir vieditör tamponuna okumaksa, vibunu doğrudan sizin için yapabilir. Gönderen vi"Normal" modunda, de ki:
:r !some-program --some --args
Bu, programın çıktısını geçerli imleç konumunda olan aktif editör tamponuna ekler. Kaputun altında, viprogramın çıktısını bir dosyadan okumak için kullanacağı aynı işletim sistemi çağrılarını kullanan bir koda bağlamak için borular kullanıyor. İki durum :r- yani, olan ve olmayan !- ikisi de ortak uygulamalarda aynı genel veri okuma döngüsünü kullanırsa şaşırmam vi. Yapmamak için iyi bir sebep düşünemiyorum.
Bu da yeni bir özellik videğil; Antik ed(1)metin editörüne geri döndü.
Bu güçlü fikir, Unix'te tekrar tekrar ortaya çıkıyor.
Bunun ikinci bir örneği için muttyukarıdaki e-posta komutumu hatırla. İki ayrı komut olarak yazmamın tek nedeni, geçici dosyanın adlandırılmasını istemek ve *.gzböylece e-posta ekinin doğru şekilde adlandırılmasını sağlamaktı. Dosyanın adını umursamıyorsam , geçici dosyayı oluşturmaktan kaçınmak için işlem değiştirmeyi kullanabilirdim:
$ echo "Here's the disk image I promised to send you." |
mutt -a <(gzip -c myfs) -s "Password file disk image" you@example.com
Bu, çıktısını gzip -cbir FIFO (dosya benzeri) veya bir /dev/fdnesneye ( dosya benzeri) dönüştürerek geçici olanı engeller . (Bash, /dev/fdher yerde kullanılamadığından sistemin yeteneklerine göre yöntemi seçer .)
Yine de, bu güçlü fikir Unix'te ortaya çıkan üçüncü bir yol gdbolarak Linux sistemlerini düşünün . Bu, C ve C ++ ile yazılmış herhangi bir yazılım için kullanılan hata ayıklayıcıdır. Unix'e diğer sistemlerden gelen programcılar bakarlar gdbve neredeyse kaçınılmaz şekilde “Yuck, bu çok ilkel!” Diye düşünürler. Sonra bir GUI hata ayıklayıcısını aramaya giderler, var olan birkaç tanesini bulurlar ve mutlu bir şekilde çalışmalarına devam ederler ... genellikle GUI'nin sadece gdbaltında çalıştığını , bunun üzerine güzel bir kabuk sağladığını asla fark etmezler . Çoğu Unix sistemlerinde rakip düşük seviye hata ayıklayıcıları yoktur, çünkü programların bu seviyede rekabet etmesine gerek yoktur. İhtiyacımız olan tek şey, eğer düşük seviyeli alet borularla kolayca iletişim kurabiliyorsa, üst seviyedeki aletlerimizi temel alabileceğimiz iyi bir düşük seviye alettir.
Bunun anlamı gdb, birincil yarışmacının düşürülmesinin değiştirilmesine izin verecek , ancak ne yazık ki, gdb düşük sürtünme yolunu kullanmayan belgelenmiş bir hata ayıklayıcı arayüzümüz olduğu anlamına gelir .
Yine de, en azından gelecekteki bazı değişikliklerin komut satırı arayüzünü klonlayarak şeffaf bir şekilde düşmesi mümkündürgdb . Aynı şeyi bir Windows kutusundan çıkarmak için, değiştirilebilir aracın yaratıcıları bir tür resmi eklenti veya otomasyon API'si tanımlamak zorunda kalacaktı. Bu, en popüler programlar dışında gerçekleşmeyeceği anlamına geliyor, çünkü hem normal bir komut satırı kullanıcı arayüzü hem de eksiksiz bir programlama API'si oluşturmak çok fazla iş gerektiriyor.
Bu sihir, yaygın metin tabanlı IPC'nin lütfu ile gerçekleşir .
Her ne kadar Windows çekirdeği Unix tarzı anonim borulara sahip olsa da, normal kullanıcı programlarının bir komut kabuğunun dışında IPC için kullandıklarını görmek nadirdir; ayrı ayrı üst. Bu, GUI olmadan bazı şeyleri yapamamaya neden olur; bu nedenle , Linux'a kıyasla Windows için çok uzak masaüstü sistemlerinin olmasının bir nedeni budur : Windows, GUI'siz kullanımı çok zordur.
Bunun aksine, Unix, BSD, OS X ve Linux kutularını SSH üzerinden uzaktan yönetmek yaygındır. Peki bu nasıl çalışıyor? SSH için (dosya gibi) bir ağ soket bağlayan bir uçbirim de /dev/pty*(dosya gibi). Artık uzaktaki sisteminiz, yerel sisteminize, gerektiğinde SSH bağlantısı üzerinden veri aktarabileceğiniz Unix Yolu ile kusursuz bir şekilde eşleşen bir bağlantı üzerinden bağlanıyor .
Bu kavramın şimdi ne kadar güçlü olduğu konusunda bir fikriniz mi var?
Borulu bir metin akışı, bir program açısından tek yönlü olması dışında bir dosyadan ayırt edilemez. Bir program, bir dosyadan okuduğu gibi bir borudan okur: bir dosya tanıtıcısı aracılığıyla . FD'ler kesinlikle Unix'in özüdür; Dosya ve boruların her ikisinde de G / Ç için aynı soyutlamayı kullanması size bir şey söylemelidir.
Bu basit metin iletişimi geleneğinden yoksun olan Windows dünyası, COM veya .NET üzerinden ağır OOP arayüzleri ile ilgili . Böyle bir programı otomatikleştirmeniz gerekirse, bir COM veya .NET programı da yazmanız gerekir. Bu, bir Unix kutusuna bir boru koymaktan daha zor.
Bu karmaşık programlama API'leri olmayan Windows programları, yalnızca pano veya Dosya / Kaydet ve ardından Dosya / Aç gibi fakirleştirilmiş arabirimler aracılığıyla iletişim kurabilir.
Uzun Cevap, bölüm 3: Kayıt Konfigürasyon Dosyaları vs
Windows kayıt defteri ve Unix Way sistem yapılandırması arasındaki pratik fark, "her şey bir dosyadır" felsefesinin faydalarını da göstermektedir.
Unix tipi sistemlerde sadece konfigürasyonu yapılan dosyaları inceleyerek komut satırından sistem konfigürasyon bilgisine bakabilirim. Aynı dosyaları değiştirerek sistem davranışını değiştirebilirim. Çoğunlukla, bu yapılandırma dosyaları yalnızca düz metin dosyalarıdır; bu, Unix'te herhangi bir aracı düz metin dosyalarıyla çalışabilecek şekilde kullanmak için kullanabileceğim anlamına gelir.
Kayıt defterinin komut dosyası , Windows'ta neredeyse hiç kolay değil.
En kolay yöntem, bir makinede Registry Editor GUI aracılığıyla daha sonra değişiklik etmektir körlemesine ile diğer makinelere bu değişiklikleri uygulamak regedityoluyla *.regdosyaları . Bu gerçekten "betik" değildir, çünkü şartlı olarak bir şey yapmanıza izin vermez: hepsi ya da hiçbiri.
Kayıt defteri değişiklikleriniz herhangi bir miktarda mantığa ihtiyaç duyuyorsa, bir sonraki en kolay seçenek, temel olarak .NET sistem programlamasını öğrenmeye çalışan PowerShell'i öğrenmektir . Unix'in sadece Perl olması ve tüm geçici sistem yönetimini bunun üzerinden yapmanız gerekiyordu. Şimdi, ben bir Perl hayranıyım, ama herkes değil. Unix, düz metin dosyalarını değiştirebildiği sürece, istediğiniz herhangi bir aracı kullanmanızı sağlar.
Dipnotlar:
Plan 9 bu tasarımın yanlış yapılmasını sağladı ve /netsanal dosya sistemi üzerinden ağ giriş / çıkışlarını ortaya çıkardı .
Bash, düzenli dosya sistemi işlevleri aracılığıyla ağ G / Ç işlemlerine izin veren bir özelliğe/dev/tcp sahiptir . Bir Bash özelliği, bir çekirdek özelliği olduğundan, Bash'in dışında veya Bash'i kullanmayan sistemlerde görünmez . Bu, örnek olarak, tüm veri kaynaklarını dosya sistemi üzerinden görünür kılmanın neden iyi bir fikir olduğunu göstermektedir.
"Modern Windows" derken, Windows NT ve Windows 2000'i, Windows Server'ın tüm sürümlerini ve Windows'tan tüm masaüstü tabanlı sürümlerini içeren doğrudan soyundan gelenleri kastediyorum. Terimin, Windows 95 ve doğrudan torunları, Windows 98 ve Windows ME, ayrıca 16 bit öncülleri olan DOS tabanlı Windows sürümlerini dışlamak için kullanıyorum.
Farklılığı, bu işletim sistemlerinde birleşik bir G / Ç sisteminin bulunmamasından görebilirsiniz. Bir TCP / IP soketini ReadFile()Windows 95'te geçiremezsiniz ; soketleri yalnızca Windows Sockets API'lerine geçirebilirsiniz. Andrew Schulman'ın yazdığı makale olan Windows 95'e bakın: Bu konuyla ilgili daha derin bir dalış için ne değildir .
Hata yapmayın, Windows'taki /dev/nullyüzeysel olarak eşdeğer olduğu gibi sadece özel kasalı bir dosya adı değil, Unix tipi sistemlerde gerçek bir çekirdek aygıtı NUL.
Her ne kadar Windows bir NULdosya oluşturmanızı engellemeye çalışmasa da, bu korumayı yalnızca bir hile ile atlamak , Windows'un dosya adı ayrıştırma mantığını kandırmak mümkündür . Bu dosyaya cmd.exeveya Explorer ile erişmeye çalışırsanız , Windows dosyayı açmayı reddedecektir, ancak örnek programa benzer yöntemler kullanarak dosyaları açtığından Cygwin aracılığıyla yazabilirsiniz ve benzer numaralarla silebilirsiniz .
Buna karşılık, Unix, rm /dev/nullyazma erişiminiz olduğu sürece size mutlu bir şekilde izin verecek /devve hile yapmadan yeni bir dosyayı yeniden oluşturmanıza izin verecektir , çünkü bu dev düğümü yalnızca başka bir dosyadır. Bu dev düğüm eksikken, çekirdeğin boş aygıtı hala var; Bu dev düğümü yeniden yaratıncaya kadar erişilemez mknod.
Başka bir yerde başka boş cihaz dev düğümleri bile oluşturabilirsiniz: /home/grandma/Recycle Binboş cihaz için bir dev düğüm olduğu sürece, onu çağırıp çağırmamanın önemi yoktur , tam olarak aynı şekilde çalışacaktır /dev/null.
Windows'ta aslında iki tane üst düzey "format diski" API'si var: SHFormatDrive()ve Win32_Volume.Format().
İki tane var ... çok ... iyi ... Windows bir sebep. İlki, Windows Gezgini'nden normal "Diski Biçimlendir" iletişim kutusunu görüntülemesini ister; bu, Windows'un herhangi bir modern sürümünde çalışır, ancak yalnızca bir kullanıcı etkileşimli olarak oturum açtığında, diğeri kullanıcı girişi olmadan arka planda arayabilir. ancak Windows Server 2003'e kadar Windows'a eklenmedi. Bu doğru, çekirdek işletim sistemi davranışı, Unix'in mkfs 1. günden itibaren gönderildiği bir dünyada 2003 yılına kadar bir GUI'nin arkasına gizlendi .
Benim Unix V5 kopyası 1974 den içeren /etc/mkfsbir 4136 bayt statik olarak bağlanan PDP-11 yürütülebilir. (Unix 1980'lerin sonuna kadar dinamik bir bağlantı kurmadı , bu yüzden gerçek bir işi yapan başka bir yerde büyük bir kütüphane yok.) Kaynak kodu - V5 sistem görüntüsünde olduğu gibi /usr/source/s2/mkfs.ctamamen kendi kendine yeten bir 457- C satırı programı. Herhangi bir #includeaçıklama bile yok !
Bu demek oluyor ki, sadece mkfsyüksek seviyede ne olduğunu incelemekle kalmaz, aynı zamanda, Unix ile yaratılmış aynı araç setini kullanarak deneyimleyebilirsiniz, tıpkı Ken Thompson gibi , onlarca yıl önce. Bunu Windows ile dene. Bugün gelebilecek en yakın şey , ilk olarak 2014'te yayımlanan ve yalnızca bir miktar kaynak derleme kaynağını bulabileceğiniz DOS kaynak kodunu indirmektir . Sadece muhtemelen elinizde olmayacak eski araçları kullanarak inşa edecek ve sonunda , on yıl sonra piyasaya sürülmesine rağmen, 1974'ün Unix V5'inden çok daha az güçlü bir işletim sistemi olan DOS 2.0'ın kendi kopyasını alacaksınız .
(Neden Unix V5 hakkında konuşalım? Hala mevcut olan en eski Unix sistemi olduğundan. Daha önceki sürümlerde görünüşte zaman kaybedilmiştir . Bir V1 / V2 dönemi Unix'i bir araya getiren bir proje vardı, ancak mkfsvarlığına rağmen eksik görünüyor. Yukarıda bağlanan V1 kılavuz sayfasının bir yerde, bir yerde olması gerektiğini kanıtladı. Bu projeyi bir araya getirenlar, içermek üzere olan eski bir kopyasını bulamadılar mkfsya find(1)da bu sistemde bulunmayan dosyaları bulmadan emildim. . :))
Şimdi, "Sadece arayamıyorum format.commu? Windows'ta mkfsUnix'i aramakla aynı değil mi? " Diye düşünüyor olabilirsiniz. Ne yazık ki, hayır, bir sürü nedenden dolayı aynı değil:
İlk önce, format.comkomut dosyası olarak tasarlanmamıştı. Sizden "hazır olduğunda ENTER tuşuna basın" uyarısını verir, bu da girişine bir Enter tuşu göndermeniz gerektiği anlamına gelir, yoksa sadece kilitlenir.
Ardından, bir başarı / başarısızlık durum kodundan başka bir şey istiyorsanız , Windows'ta olması gerekenden çok daha karmaşık olan okuma için standart çıktısını açmanız gerekir . (Unix'te, bu bağlantılı makaledeki her şey basit bir popen(3)çağrı ile gerçekleştirilebilir .)
Tüm bu komplikasyonlardan geçtikten sonra, format.combilgisayar programlarının çıktısını, mkfsöncelikle insan tüketimine yönelik olmak üzere , çıktısından daha zordur .
Ne iz varsa format.comyapar, bunu karmaşık aramaların bir demet yapar bulmak DeviceIoControl(), ufat.dllve böyle. Bir cihaz dosyasını açmak ve o cihaza yeni bir dosya sistemi yazmak değildir. Bu, 126000 çalışanı olan bir şirketten aldığınız tasarımdır ve onları işe almaya devam etmesi gerekir.
Döngü aygıtları hakkında konuşurken, genel olarak Unix yerine sadece Linux hakkında konuşurum, çünkü döngü aygıtları Unix tipi sistemler arasında taşınabilir değildir. OS X, BSD, vb'de benzer mekanizmalar var, ancak sözdizimi biraz değişiyor .
Disk sürücülerinin çamaşır makinelerinin büyüklüğü olduğu ve departman başkanının lüks otomobilinden daha pahalı olduğu günlerde, büyük bilgisayar laboratuvarları, modern bilgisayar ortamlarına kıyasla kolektif disk alanlarının daha büyük bir bölümünü paylaşacaktı. Bir uzak diski yerel dosya sistemine şeffaf bir şekilde yerleştirme yeteneği, dağıtılmış sistemlerin kullanımını çok daha kolaylaştırmıştır. /usr/shareMesela aldığımız yer burası .
Kontrastlı bir uzak diskin tipik olarak bir sürücü harfine eşlendiği veya saydam bir şekilde yerel dosya sistemine entegre edilmek yerine bir UNC yolu ile erişilmesi gereken Windows. Sürücü harfleri sembolik ifadeler için size birkaç seçenek sunar; yok P:BIGSERVER üzerinde veya yazılım ayna sunucu üzerinde "paketler" dizinine "kamusal" alana işaret? UNC yolları, uzak dosyalarınızın hangi sunucuda bulunduğunu, yüzlerce veya binlerce dosya sunucusuyla büyük bir organizasyonda zorlandığınızı hatırlamanız gerektiği anlamına gelir.
Windows, NTFS sembolik bağlarını tanıtan, 2007 yılında piyasaya sürülen Windows Vista'ya kadar sembolik bağlantılar alamadı . Windows'un sembolik bağları, Unix'in sembolik bağlarından ( 1977'den beri Unix'in bir özelliği) olan sembolik bağlarından biraz daha güçlüdür , bu sayede uzak bir dosya paylaşımına işaret edebilir, sadece yerel bir yola değil. Unix , 1984'te NFS aracılığıyla , Unix'in baştan beri sahip olduğu önceden varolan bağlama noktası özelliğinin üzerine inşa edilen farklı bir şekilde yaptı .
Bu yüzden, nasıl baktığınıza bağlı olarak, Windows Unix'i yaklaşık 2 ya da 3 yıl takip etti.
O zaman bile, sembolik bağlar, birkaç nedenden dolayı, bir Windows kullanıcı deneyiminin normal bir parçası değildir.
İlk önce, onları geriye dönük komut satırı programıyla oluşturabilirsiniz MKLINK. Windows Gezgini için Unix eşdeğerleri tipik oysa, Windows Gezgini onları yaratamaz mı sen sembolik oluşturalım.
İkincisi, varsayılan Windows yapılandırması normal kullanıcıların sembolik bağlantılar oluşturmasını engeller , ya da komut kabuğunu Yönetici olarak çalıştırmanızı ya da ortalama bir kullanıcının görmediği bir araçta belirsiz bir yolla bunları oluşturmak için kullanıcıya izin vermesini gerektirir. nasıl kullanılır. (Windows'taki çoğu Yönetici ayrıcalık sorunlarından farklı olarak, UAC bu durumda yardımcı olmaz.)
Linux kutuları her zaman önyükleme sırasında sanal disk görüntüsü kullanmaz. Bunu yapmanın bir sürü yolu var .
man ed
Ağ soketi tanımlayıcıları da bu arada altında FD'lerdir.