"Tout est un fichier" est un peu désinvolte. "Tout apparaît quelque part dans le système de fichiers " est plus proche de la marque, et même alors, c'est plus un idéal qu'une loi de la conception de système.
Par exemple, les sockets de domaine Unix ne sont pas des fichiers, mais ils apparaissent dans le système de fichiers. Vous pouvez ls -lutiliser une socket de domaine pour afficher ses attributs, ses catdonnées, modifier son contrôle d'accès via chmod, etc.
Mais, même si les sockets réseau TCP / IP ordinaires sont créés et manipulés avec les mêmes appels système de sockets BSD que les sockets de domaine Unix, les sockets TCP / IP n'apparaissent pas dans le système de fichiers, ¹ même s'il n'y a pas de raison Sois sincère.
Le /procsystème de fichiers de Linux est un autre exemple d'objet non-fichier apparaissant dans le système de fichiers . Cette fonctionnalité fournit une grande quantité de détails sur l'opération d'exécution du noyau dans l'espace utilisateur , principalement sous forme de fichiers de texte brut virtuels. De nombreuses /procentrées sont en lecture seule, mais de nombreuses entrées sont /procégalement inscriptibles. Vous pouvez donc modifier le fonctionnement du système à l'aide de tout programme capable de modifier un fichier. Hélas, là encore, nous avons une non-réalité: les Unix de type BSD fonctionnent généralement sans/proc , et les Unix de System V exposent beaucoup moins de choses /procque Linux.
Je ne peux pas contraster cela avec MS Windows
Premièrement, une grande partie du sentiment que vous pouvez trouver en ligne et dans des livres sur Unix comme étant tout au sujet des fichiers d'E / S et de Windows comme étant "cassé" à cet égard est obsolète. Windows NT a corrigé beaucoup de cela.
Les versions modernes de Windows ont un système d'E / S unifié, comme Unix, ce qui vous permet de lire les données réseau à partir d'un socket TCP / IP via ReadFile()plutôt que l'API spécifique à Windows Sockets WSARecv(), si vous le souhaitez. Cela correspond exactement à la manière Unix , où vous pouvez lire à partir d'une prise réseau avec l' read(2)appel système Unix générique ou l'appel spécifique aux recv(2)sockets.²
Néanmoins, Windows ne parvient toujours pas à prendre ce concept au même niveau qu'Unix, même ici en 2018. De nombreux domaines de l'architecture Windows sont inaccessibles via le système de fichiers ou ne peuvent pas être visualisés sous forme de fichier. Quelques exemples:
Pilotes
Le sous-système de pilotes Windows est facilement aussi riche et puissant qu’Unix, mais pour écrire des programmes permettant de manipuler les pilotes, vous devez généralement utiliser le Kit de pilotes Windows , qui signifie écrire du code C ou .NET.
Sur les systèmes d'exploitation de type Unix, vous pouvez faire beaucoup avec les pilotes en ligne de commande. Vous avez certainement déjà déjà fait cela, ne serait-ce qu'en redirigeant une sortie indésirable vers /dev/null.³
Communication entre programmes.
Les programmes Windows ne communiquent pas facilement les uns avec les autres.
Les programmes en ligne de commande Unix communiquent facilement via des flux de texte et des canaux. Les programmes d'interface graphique sont souvent soit construits sur des programmes en ligne de commande, soit exportés par une interface de commande de texte, de sorte que les mêmes mécanismes de communication simples basés sur du texte fonctionnent également avec les programmes d'interface graphique.
Le registre.
Unix n'a pas d'équivalent direct du registre Windows. Les mêmes informations sont dispersées à travers le système de fichiers, la plupart dans /etc, /procet /sys.
Si vous ne voyez pas que les pilotes, les pipes et la réponse d'Unix au registre Windows ont quelque chose à voir avec "tout est un fichier", lisez la suite.
Comment la philosophie "Tout est un fichier" fait une différence ici?
Je vais expliquer cela en développant mes trois points ci-dessus, en détail.
Réponse longue, partie 1: Lecteurs vs fichiers de périphérique
Disons que votre lecteur de carte CF apparaît E:sous Windows et /dev/sdcsous Linux. Quelle différence pratique cela fait-il?
Ce n'est pas juste une différence de syntaxe mineure.
Sous Linux, je peux dire dd if=/dev/zero of=/dev/sdcd’écraser le contenu de /dev/sdczéros.
Pensez à ce que cela signifie pendant une seconde. Ici, j’ai dd(1)demandé à un programme d’espace utilisateur normal ( ) de lire des données à partir d’un périphérique virtuel ( /dev/zero) et d’écrire ce qu’il lit dans un périphérique physique réel ( /dev/sdc) via le système de fichiers Unix unifié. ddne sait pas qu'il lit et écrit sur des appareils spéciaux. Cela fonctionnera tout aussi bien sur des fichiers classiques, ou sur un mélange de périphériques et de fichiers, comme nous le verrons ci-dessous.
Il n’existe pas de moyen simple de mettre le E:lecteur à zéro sous Windows, car Windows fait une distinction entre les fichiers et les lecteurs. Vous ne pouvez donc pas utiliser les mêmes commandes pour les manipuler. Le plus proche que vous pouvez obtenir est de créer un format de disque sans l'option Quick Format, qui remet à zéro la plupart du contenu du lecteur, mais écrit ensuite un nouveau système de fichiers. Et si je ne veux pas d' un nouveau système de fichiers? Et si je veux vraiment que le disque ne soit rempli que de zéros?
Soyons généreux et disons que nous voulons vraiment un nouveau système de fichiers E:. Pour faire cela dans un programme sous Windows, je dois appeler une API de formatage spéciale.⁴ Sous Linux, il n'est pas nécessaire d'écrire un programme pour accéder à la fonctionnalité de "disque de formatage" du système d'exploitation. Vous exécutez juste le programme de l' espace utilisateur approprié pour le type de système de fichiers que vous voulez créer: mkfs.ext4, mkfs.xfsou ce que vous avez. Ces programmes vont écrire un système de fichiers sur le fichier ou le /devnoeud que vous transmettez.
Comme mkfsles programmes de type sur les systèmes Unixy fonctionnent sur des fichiers sans faire de distinction artificielle entre les périphériques et les fichiers normaux, cela signifie que je peux créer un système de fichiers ext4 dans un fichier normal de ma machine Linux:
$ dd if=/dev/zero of=myfs bs=1k count=1k
$ mkfs.ext4 -F myfs
Cela crée littéralement une image disque de 1 Mio dans le répertoire en cours, appelée myfs. Je peux ensuite le monter comme s'il s'agissait d'un autre système de fichiers externe:
$ mkdir mountpoint
$ sudo mount -o loop myfs mountpoint
$ grep $USER /etc/passwd > mountpoint/my-passwd-entry
$ sudo umount mountpoint
Maintenant, j'ai une image disque ext4 avec un fichier appelé my-passwd-entryqui contient mon /etc/passwdentrée d'utilisateur .
Si je le souhaite, je peux supprimer cette image sur ma carte CF:
$ sudo dd if=myfs of=/dev/sdc1
Ou bien, je peux emballer cette image disque, vous la poster et vous permettre de l'écrire sur un support de votre choix, tel qu'une clé 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
Tout cela est possible sous Linux⁵ car il n'y a pas de distinction artificielle entre les fichiers, les systèmes de fichiers et les périphériques. Beaucoup de choses sur les systèmes Unix sont des fichiers ou sont accessibles via le système de fichiers afin de ressembler à des fichiers, ou d'une autre manière, ressemblent suffisamment à des fichiers pour pouvoir être traitées comme telles.
Le concept de système de fichiers de Windows est un méli-mélo; il fait la distinction entre les répertoires, les lecteurs et les ressources réseau. Il existe trois syntaxes différentes, toutes mélangées dans Windows: le système de ..\FOO\BARchemin d'accès de type Unix , les lettres de lecteur du type C:et les chemins UNC du type \\SERVER\PATH\FILE.TXT. En effet, il s’agit d’un ajout d’idées provenant d’Unix, de CP / M , de MS-DOS et de LAN Manager , plutôt que d’une conception cohérente unique. C'est pourquoi il y a tant de caractères illégaux dans les noms de fichiers Windows .
Unix a un système de fichiers unifié, avec tout accès par un schéma commun unique. Pour un programme en cours d' exécution sur une machine Linux, il n'y a aucune différence fonctionnelle entre /etc/passwd, /media/CF_CARD/etc/passwdet /mnt/server/etc/passwd. Les fichiers locaux, les médias externes et les partages réseau sont tous traités de la même manière.
Windows peut atteindre des objectifs similaires à ceux de mon exemple d'image disque ci-dessus, mais vous devez utiliser des programmes spéciaux écrits par des programmeurs au talent inhabituel. C’est la raison pour laquelle il existe tant de programmes de type "DVD virtuel" sous Windows . L'absence de fonctionnalité de base du système d'exploitation a créé un marché artificiel pour les programmes destinés à combler le vide, ce qui signifie que de nombreuses personnes se font concurrence pour créer le meilleur programme de type DVD virtuel. Nous n'avons pas besoin de tels programmes sur les systèmes * ix, car nous pouvons simplement monter une image disque ISO à l'aide d'un périphérique en boucle .
Il en va de même pour d'autres outils tels que les programmes de nettoyage de disque , dont nous n'avons pas non plus besoin sur les systèmes Unix. Voulez-vous que le contenu de votre carte CF soit irrémédiablement brouillé au lieu d'être mis à zéro? OK, utilisez /dev/randomcomme source de données au lieu de /dev/zero:
$ sudo dd if=/dev/random of=/dev/sdc
Sous Linux, nous ne continuons pas à réinventer de telles roues car les fonctionnalités de base du système d'exploitation ne fonctionnent pas assez bien, elles fonctionnent si bien qu'elles sont utilisées de manière généralisée. Un schéma typique de démarrage d'une machine Linux implique une image de disque virtuel, pour un seul exemple, créé à l'aide de techniques telles que celle que je viens de montrer ci-dessus.
Je pense qu'il est juste de préciser que si Unix avait intégré les E / S TCP / IP au système de fichiers dès le début, nous n'aurions pas le désordrenetcat vs socatvs Ncatvs , ce qui était dû à la même faiblesse de conception qui a conduit à la imagerie de disque et prolifération des outils d'essuyage sous Windows: absence d'un système d'exploitation acceptable.nc
Réponse longue, partie 2: Pipes en tant que fichiers virtuels
Malgré ses racines sous DOS, Windows n’a jamais eu une riche tradition de ligne de commande.
Cela ne veut pas dire que Windows n'a pas avoir une ligne de commande, ou qu'il ne dispose pas de nombreux programmes de ligne de commande. Windows a même un shell de commande très puissant de nos jours, appelé à juste titre PowerShell .
Pourtant, cette absence de tradition de ligne de commande a des répercussions. Vous disposez d'outils comme DISKPARTce qui est presque inconnu dans le monde Windows, car la plupart des gens partitionnent les disques et autres par le biais du composant logiciel enfichable MMC Gestion de l'ordinateur. Ensuite, lorsque vous avez besoin de créer un script pour la création de partitions, vous constatez que ce DISKPARTn’est pas vraiment fait pour être piloté par un autre programme. Oui, vous pouvez écrire une série de commandes dans un fichier de script et l'exécuter via DISKPART /S scriptfile, mais c'est tout ou rien. Ce que vous voulez vraiment dans une telle situation ressemble davantage à GNUparted , qui acceptera des commandes uniques telles que parted /dev/sdb mklabel gpt. Cela permet à votre script de gérer les erreurs étape par étape.
Qu'est-ce que tout cela a à voir avec "tout est un fichier"? Facile: les canaux transforment les E / S des programmes de ligne de commande en "fichiers", en quelque sorte. Les pipes sont des flux unidirectionnels , et non à accès aléatoire comme un fichier sur disque, mais dans de nombreux cas, la différence n’a aucune conséquence. L'important est que vous puissiez attacher deux programmes développés indépendamment et les faire communiquer via un texte simple. En ce sens, deux programmes conçus dans l’esprit Unix peuvent communiquer.
Dans les cas où vous avez vraiment besoin d'un fichier, il est facile de transformer la sortie du programme en un fichier:
$ some-program --some --args > myfile
$ vi myfile
Mais pourquoi écrire la sortie dans un fichier temporaire alors que la philosophie "tout est fichier" vous donne une meilleure solution? Si tout ce que vous voulez faire, c'est lire le résultat de cette commande dans un vitampon d'éditeur, vous vipouvez le faire directement pour vous. À partir du vimode "normal", dites:
:r !some-program --some --args
Cela insère la sortie de ce programme dans le tampon de l'éditeur actif à la position actuelle du curseur. Sous le capot, viutilise des tubes pour connecter la sortie du programme à un morceau de code qui utilise les mêmes appels de système d’exploitation qu’il utiliserait pour lire à partir d’un fichier. Je ne serais pas surpris si les deux cas :r- c'est-à-dire avec et sans le !- utilisaient la même boucle de lecture de données générique dans toutes les implémentations courantes de vi. Je ne peux pas penser à une bonne raison de ne pas le faire.
Ce n'est pas une caractéristique récente de vi, non plus; cela revient clairement à l'ancien ed(1)éditeur de texte.
Cette idée puissante revient sans cesse sous Unix.
Pour un deuxième exemple, rappelez ma muttcommande email ci-dessus. La seule raison pour laquelle j'ai dû écrire cela en tant que deux commandes distinctes, c'est que je voulais que le fichier temporaire soit nommé *.gz, afin que la pièce jointe à l'e-mail soit correctement nommée. Si le nom du fichier ne m'importait pas, j'aurais pu utiliser la substitution de processus pour éviter de créer le fichier temporaire:
$ echo "Here's the disk image I promised to send you." |
mutt -a <(gzip -c myfs) -s "Password file disk image" you@example.com
Cela évite le temporaire en transformant la sortie de gzip -cen une FIFO (qui ressemble à un fichier) ou un /dev/fdobjet (qui est comme un fichier). (Bash choisit la méthode en fonction des capacités du système, car il /dev/fdn'est pas disponible partout.)
Pour la troisième fois, cette puissante idée apparaît sous Unix, pensez gdbaux systèmes Linux. C'est le débogueur utilisé pour tout logiciel écrit en C et C ++. Les programmeurs qui utilisent Unix d’autres systèmes le regardent gdbet le traitent presque invariablement, "Beurk, c’est tellement primitif!" Ensuite, ils vont à la recherche d’un débogueur d’interface graphique, trouvent l’un des nombreux logiciels existants et continuent joyeusement leur travail… ne réalisant souvent jamais que l’interface graphique ne fonctionne que gdbdessous, offrant ainsi un joli shell. Il n'y a pas de débogueurs de bas niveau concurrents sur la plupart des systèmes Unix, car les programmes n'ont pas besoin de rivaliser à ce niveau. Tout ce dont nous avons besoin, c'est d'un bon outil de bas niveau sur lequel nous pouvons tous baser nos outils de haut niveau, si cet outil de bas niveau communique facilement via des canaux.
Cela signifie que nous avons maintenant une interface de débogueur documentée qui permettrait le remplacement immédiat de gdb, mais malheureusement, le principal concurrent à gdb ne pas suivre le chemin à faible frottement .
Néanmoins, il est au moins possible qu'un gdbremplacement futur intervienne de manière transparente simplement en clonant son interface de ligne de commande. Pour obtenir la même chose sur un ordinateur Windows, les créateurs de l'outil remplaçable auraient dû définir une sorte de plug-in formel ou d'API d'automatisation. Cela signifie que cela ne se produit pas, à l'exception des programmes les plus populaires, car créer une interface utilisateur en ligne de commande normale et une API de programmation complète demande beaucoup de travail.
Cette magie se produit grâce à la grâce d'un IPC omniprésent basé sur du texte .
Bien que le noyau de Windows comporte des canaux anonymes de style Unix , il est rare de voir les programmes utilisateur normaux les utiliser pour IPC en dehors d'un interpréteur de commande, car Windows n'a pas cette tradition consistant à créer tous les services de base dans une version en ligne de commande, puis à créer l'interface graphique sur en haut séparément. Cela conduit à être incapable de faire certaines choses sans l'interface graphique, ce qui est l'une des raisons pour lesquelles il existe autant de systèmes de postes de travail distants pour Windows par rapport à Linux: Windows est très difficile à utiliser sans l'interface graphique.
En revanche, il est courant d’administrer à distance les systèmes Unix, BSD, OS X et Linux à distance via SSH. Et comment ça marche, demandez-vous? SSH connecte un socket réseau (semblable à un fichier) à un pseudo tty at /dev/pty*( semblable à un fichier). Maintenant, votre système distant est connecté à votre système local via une connexion qui correspond si parfaitement à la manière Unix que vous pouvez diriger les données via la connexion SSH , si vous en avez besoin.
Avez-vous une idée de la puissance de ce concept?
Un flux de texte transmis ne peut pas être distingué d'un fichier du point de vue d'un programme, sauf qu'il est unidirectionnel. Un programme lit à partir d'un tuyau de la même façon qu'il lit un fichier: via un descripteur de fichier . Les FD sont absolument essentiels à Unix; le fait que les fichiers et les tubes utilisent la même abstraction pour les E / S sur les deux devrait vous dire quelque chose.
Le monde Windows, dépourvu de cette tradition de communication texte simple, se contente d’ interfaces POO lourdes via COM ou .NET . Si vous devez automatiser un tel programme, vous devez également écrire un programme COM ou .NET. C'est un peu plus difficile que d'installer un tuyau sur une boîte Unix.
Les programmes Windows dépourvus de ces API de programmation compliquées ne peuvent communiquer qu'à travers des interfaces appauvries telles que le presse-papiers ou Fichier / Enregistrer, puis Fichier / Ouvrir.
Réponse longue, partie 3: le registre et les fichiers de configuration
La différence pratique entre le registre Windows et la configuration système Unix Way illustre également les avantages de la philosophie "tout est un fichier".
Sur les systèmes de type Unix, je peux consulter les informations de configuration du système à partir de la ligne de commande en examinant simplement les fichiers. Je peux changer le comportement du système en modifiant ces mêmes fichiers. Pour la plupart, ces fichiers de configuration ne sont que des fichiers de texte brut, ce qui signifie que je peux utiliser n'importe quel outil sous Unix pour les manipuler pouvant fonctionner avec des fichiers de texte brut.
L'écriture de scripts sur le registre n'est pas aussi facile sous Windows.
La méthode la plus simple consiste à effectuer vos modifications via l'interface graphique de l'éditeur de registre sur une machine, puis à les appliquer aveuglément à d'autres machines avec des fichiers regeditvia*.reg . Ce n'est pas vraiment du "script", car cela ne vous permet pas de faire quelque chose sous condition: c'est tout ou rien.
Si les modifications apportées à votre registre nécessitent une certaine logique, l'option la plus simple consiste à apprendre PowerShell , ce qui revient essentiellement à apprendre la programmation système .NET. Ce serait comme si Unix n'avait que Perl et que vous deviez faire toute l' administration système ad hoc à travers elle. Maintenant, je suis un fan de Perl, mais tout le monde ne l’est pas. Unix vous permet d'utiliser n'importe quel outil, tant qu'il peut manipuler des fichiers texte.
Notes de bas de page:
Plan 9 a corrigé cette erreur de conception en exposant les E / S réseau via le /netsystème de fichiers virtuel .
Bash a une fonctionnalité appelée/dev/tcp qui permet aux E / S de réseau via des fonctions de système de fichiers standard. Puisqu'il s'agit d'une fonctionnalité Bash, plutôt d'une fonctionnalité du noyau, elle n'est pas visible en dehors de Bash ou sur des systèmes qui n'utilisent pas du tout Bash . Cela montre, par contre-exemple, pourquoi il est si judicieux de rendre toutes les ressources de données visibles à travers le système de fichiers.
Par «Windows moderne», j'entends Windows NT et tous ses descendants directs, ce qui inclut Windows 2000, toutes les versions de Windows Server et toutes les versions orientées bureau de Windows à partir de XP. J'utilise le terme pour exclure les versions de Windows sous DOS, Windows 95 et ses descendants directs, Windows 98 et Windows ME, ainsi que leurs prédécesseurs 16 bits.
Vous pouvez voir la distinction par l'absence d'un système d'E / S unifié dans ces derniers systèmes d'exploitation. Vous ne pouvez pas passer un socket TCP / IP ReadFile()sur Windows 95; vous ne pouvez transmettre des sockets qu'aux API Windows Sockets. Consultez l'article phare d'Andrew Schulman, Windows 95: Ce qui ne l'est pas, pour une plongée plus en profondeur dans ce sujet.
Ne vous y trompez pas, /dev/nullc’est un véritable périphérique noyau sur les systèmes de type Unix, et pas seulement un nom de fichier en casse spéciale, comme l’équivalent superficiellement NULdans Windows.
Bien que Windows essaie de vous empêcher de créer un NULfichier, il est possible de contourner cette protection avec de simples astuces , en trompant la logique d'analyse du nom de fichier de Windows. Si vous essayez d'accéder à ce fichier avec cmd.exeou Explorer, Windows refusera de l'ouvrir, mais vous pourrez y écrire via Cygwin, car il ouvre les fichiers en utilisant des méthodes similaires à celles du programme exemple, et vous pouvez le supprimer en utilisant une tromperie similaire .
En revanche, Unix vous laissera volontiers rm /dev/null, tant que vous avez un accès en écriture /dev, et vous permet de recréer un nouveau fichier à sa place, le tout sans fioritures, car ce nœud dev est juste un autre fichier. Tant que ce nœud dev est manquant, le périphérique null du noyau existe toujours; c'est simplement inaccessible jusqu'à ce que vous recréiez le nœud dev via mknod.
Vous pouvez même créer des nœuds de développement supplémentaires pour un périphérique null ailleurs: peu importe si vous l'appelez /home/grandma/Recycle Bin, tant qu'il s'agit d'un nœud de développement pour le périphérique null, il fonctionnera exactement de la même manière /dev/null.
Il existe en réalité deux API de "disque de formatage" de haut niveau dans Windows: SHFormatDrive()et Win32_Volume.Format().
Il y en a deux pour un très… bien… genre de raison Windows . La première demande à l’explorateur Windows d’afficher sa boîte de dialogue normale "Formater le disque", ce qui signifie que cela fonctionne sur n’importe quelle version moderne de Windows, mais uniquement lorsqu'un utilisateur est connecté de manière interactive. mais il n'a pas été ajouté à Windows avant Windows Server 2003. C'est vrai, le comportement du système d'exploitation principal était caché derrière une interface graphique jusqu'en 2003, dans un monde où Unix était disponible mkfs dès le premier jour .
Ma copie d'Unix V5 de 1974 comprend /etc/mkfsun exécutable PDP-11 lié statiquement de 4136 octets . (Unix n’a pas eu de liaison dynamique jusqu’à la fin des années 1980 , alors ce n’est pas comme si une grande bibliothèque faisait tout le travail à la place.) Son code source - inclus dans l’image système V5 en tant que /usr/source/s2/mkfs.c- est totalement autonome. programme de la ligne C. Il n'y a même pas de #includedéclarations!
Cela signifie que vous pouvez non seulement examiner ce qui se mkfspasse à un niveau élevé, vous pouvez également l'expérimenter en utilisant le même ensemble d'outils avec lequel Unix a été créé, tout comme vous êtes Ken Thompson , il y a quatre décennies. Essayez cela avec Windows. Le plus proche que vous puissiez faire aujourd'hui est de télécharger le code source DOS , publié pour la première fois en 2014 , qui, selon vous, ne représente qu'une pile de sources d' assemblage . Il ne sera construit qu’avec des outils obsolètes que vous n’auriez probablement pas sous la main et vous obtiendrez finalement votre propre copie de DOS 2.0, un système d’exploitation bien moins puissant que celui de Unix V5 de 1974 , bien qu’il soit publié près de dix ans plus tard.
(Pourquoi parler de Unix V5? Parce qu’il s’agit du premier système Unix complet encore disponible. Les versions antérieures sont apparemment perdues dans le temps . Il y avait un projet qui assemblait un Unix d’époque V1 / V2, mais il semble manquer mkfs, malgré l’existence de la page de manuel V1 liée ci-dessus prouvant qu'il doit exister quelque part, quelque part. Soit les concepteurs de ce projet n'ont pas trouvé de copie existante mkfsà inclure, soit je suis nul à trouver des fichiers sans find(1), ce qui n'existe pas non plus dans ce système . :))
Maintenant, vous pensez peut-être, "Je ne peux pas simplement appeler format.com? N'est-ce pas la même chose sous Windows que d'appeler mkfssous Unix?" Hélas, non, ce n'est pas la même chose, pour plusieurs raisons:
Tout d'abord, format.comn'a pas été conçu pour être scripté. Il vous invite à "appuyer sur ENTRÉE une fois prêt", ce qui signifie que vous devez envoyer une touche Entrée à son entrée, sinon elle se bloque.
Ensuite, si vous voulez autre chose qu'un code d'état de réussite / échec, vous devez ouvrir sa sortie standard en lecture, ce qui est beaucoup plus compliqué que nécessaire . (Sous Unix, tout dans cet article lié peut être accompli avec un simple popen(3)appel.)
Après avoir traversé toute cette complication, le résultat de format.comest plus difficile à analyser pour les programmes informatiques que le résultat de mkfs, étant principalement destiné à la consommation humaine.
Si vous tracez quoi format.com fait, vous trouvez qu'il fait un tas d'appels compliqués à DeviceIoControl(), ufat.dllet tel. Il ne s'agit pas simplement d'ouvrir un fichier de périphérique et d'écrire un nouveau système de fichiers sur ce périphérique. C'est le type de conception que vous obtenez d' une entreprise qui emploie 126 000 personnes et doit continuer à les employer.
Lorsque je parle de périphériques en boucle, je parle uniquement de Linux plutôt que d'Unix en général, car les périphériques en boucle ne sont pas portables entre systèmes de type Unix. Des mécanismes similaires existent sous OS X, BSD, etc., mais la syntaxe varie quelque peu .
À l'époque où les lecteurs de disque avaient la taille d'un lave-linge et coûtaient plus cher que la voiture de luxe du chef de département, les grands laboratoires informatiques partageaient une plus grande partie de leur espace disque collectif par rapport aux environnements informatiques modernes. La possibilité de greffer de manière transparente un disque distant dans le système de fichiers local a rendu l’utilisation de ces systèmes distribués beaucoup plus simple. C'est là que nous obtenons /usr/share, par exemple.
Contraste Windows, où un disque distant est généralement mappé sur une lettre de lecteur ou doit être accessible via un chemin UNC, plutôt que d'être intégré de manière transparente dans le système de fichiers local. Les lettres de lecteur vous offrent peu de choix pour l'expression symbolique; fait-il P:référence à l'espace "public" sur BigServer ou au répertoire "packages" sur le serveur miroir logiciel? Les chemins UNC signifient que vous devez vous rappeler sur quel serveur se trouvent vos fichiers distants, ce qui devient difficile dans une grande entreprise comptant des centaines, voire des milliers, de serveurs de fichiers.
Windows n'a pas eu de lien symbolique avant Windows Vista, sorti en 2007, qui introduisait les liens symboliques NTFS . Les liens symboliques de Windows sont un peu plus puissants que les liens symboliques d'Unix - une fonctionnalité d'Unix depuis 1977 - en ce sens qu'ils peuvent également pointer vers un partage de fichiers distant, pas seulement vers un chemin d'accès local. Unix a fait cela différemment, via NFS en 1984 , qui s’appuie sur la fonctionnalité de point de montage préexistante d’Unix , qu’elle possédait depuis le début.
Donc, selon votre point de vue, Windows traînait sous Unix d’environ 2 ou 3 décennies.
Même dans ce cas, les liens symboliques ne font pas partie de l'expérience d'un utilisateur Windows, et ce pour plusieurs raisons.
Tout d'abord, vous ne pouvez les créer qu'avec le programme de ligne de commande arrièreMKLINK . Vous ne pouvez pas les créer à partir de l'Explorateur Windows, alors que les équivalents Unix à l'Explorateur Windows ne vous permettent de créer des liens symboliques.
Deuxièmement, la configuration Windows par défaut empêche les utilisateurs normaux de créer des liens symboliques. Vous devez donc exécuter le shell de commande en tant qu'administrateur ou autoriser l'utilisateur à les créer via un chemin obscur dans un outil que l'utilisateur moyen n'a jamais vu, et encore moins le sait. comment utiliser. (Et contrairement à la plupart des problèmes de privilèges d’administrateur dans Windows, le contrôle de compte utilisateur n’est d'aucune aide dans ce cas.)
Les machines Linux n'utilisent pas toujours une image de disque virtuel dans la séquence de démarrage. Il y a plusieurs façons de le faire .
man ed
Les descripteurs de prise de réseau sont également des FD en dessous.