Dd Vs Cat - Dd est-il toujours pertinent de nos jours ?

J'ai récemment réalisé que nous pouvions utiliser cat autant que dd , et c'est en fait plus rapide que dd

Je sais que dd était utile pour traiter les bandes où la taille des blocs importait réellement dans l'exactitude, pas seulement dans les performances. De nos jours, cependant, existe-t-il des situations où dd peut faire quelque chose cat ne peut pas? (Ici, je considérerais qu'une différence de performances inférieure à 20 % n'est pas pertinente.)

Des exemples concrets seraient bien !

Réponse acceptée :

En apparence, dd est un outil d'un système d'exploitation IBM qui a conservé son apparence étrangère (son passage de paramètres), qui exécute certaines fonctions très rarement utilisées (telles que les conversions EBCDIC en ASCII ou l'inversion de l'endianness... pas un besoin courant de nos jours).

J'avais l'habitude de penser que dd était plus rapide pour copier de gros blocs de données sur le même disque (grâce à une utilisation plus efficace de la mémoire tampon), mais ce n'est pas vrai, du moins sur les systèmes Linux actuels.

Je pense que certains de dd Les options de sont utiles lorsqu'il s'agit de bandes, où la lecture est réellement effectuée par blocs (les pilotes de bande ne masquent pas les blocs sur le support de stockage comme le font les pilotes de disque). Mais je ne connais pas les détails.

Une chose dd peut faire cela ne peut (facilement) être fait par aucun autre outil POSIX prend les N premiers octets d'un ruisseau. De nombreux systèmes peuvent le faire avec head -c 42 , mais head -c , bien que courant, n'est pas dans POSIX (et n'est pas disponible aujourd'hui, par exemple sur OpenBSD). (tail -c est POSIX.) Aussi, même où head -c existe, il peut lire trop d'octets à partir de la source (car il utilise la mémoire tampon stdio en interne), ce qui est un problème si vous lisez à partir d'un fichier spécial où la simple lecture a un effet. (Les coreutils GNU actuels lisent le nombre exact avec head -c , mais FreeBSD et NetBSD utilisent stdio.)

Plus généralement, dd donne une interface à l'API de fichier sous-jacente qui est unique parmi les outils Unix :uniquement dd peut écraser ou tronquer un fichier à tout moment ou chercher dans un dossier. (C'est dd sa capacité unique, et c'est une grande; assez curieusement dd est surtout connu pour des choses que d'autres outils peuvent faire.)

• La plupart des outils Unix écrasent leur fichier de sortie, c'est-à-dire qu'ils effacent son contenu et recommencent à zéro. Voici ce qui se passe lorsque vous utilisez > redirection dans le shell également.
• Vous pouvez ajouter au contenu d'un fichier avec >> redirection dans le shell, ou avec tee -a .

• Si vous souhaitez raccourcir un fichier en supprimant toutes les données après un certain point , ceci est pris en charge par le noyau sous-jacent et l'API C via le truncate fonction, mais non exposée par aucun outil de ligne de commande à l'exception de dd :

  dd if=/dev/null of=/file/to/truncate seek=1 bs=123456  # truncate file to 123456 bytes
  

• Si vous souhaitez écraser des données au milieu d'un fichier, encore une fois, cela est possible dans l'API sous-jacente en ouvrant le fichier en écriture sans tronquer (et en appelant lseek pour passer à la position souhaitée si nécessaire), mais uniquement dd peut ouvrir un fichier sans tronquer ni ajouter, ou rechercher depuis le shell (exemple plus complexe).

  # zero out the second kB block in the file (i.e. bytes 1024 to 2047)
  dd if=/dev/zero of=/path/to/file bs=1024 seek=1 count=1 conv=notrunc
  

Alors… En tant qu'outil système, dd est à peu près inutile. En tant qu'outil de traitement de texte (ou de fichier binaire), c'est très précieux !

En relation :Calculer le nombre de jours avant le paiement ?