cp a bet cat a > bquelle est la différence?
Dans le script d'installation x86 de l'arborescence source du noyau linux ( arch/x86/boot/install.sh), les deux sont utilisés:
cat $2 > $4/vmlinuz
cp $3 $4/System.map
Pourquoi ne gardent-ils pas simplement le même format si l'un est meilleur que l'autre?
Réponses:
Un autre problème me vient à l'esprit où catvs cpfait une différence significative:
Par définition, cat étendra les fichiers clairsemés, remplissant les lacunes avec de "vrais" octets zéro, tandis que cp au moins peut être invité à conserver les trous.
Les fichiers épars sont des fichiers dans lesquels des séquences de zéro octet ont été remplacées par des métadonnées pour préserver l'espace. Vous pouvez tester en créant un avec dd, et le dupliquer avec les outils de votre choix.
Créez un fichier clairsemé (en changeant / tmp au préalable pour éviter les problèmes - voir note finale):
15> cd /tmp
16> dd if=/dev/null of=sparsetest bs=512b seek=5
0+0 records in
0+0 records out
0 bytes (0 B) copied, 5.9256e-05 s, 0.0 kB/s
dimensionnez-le - il ne devrait pas prendre de place.
17> du -sh sparsetest
0 sparsetest
copiez-le avec cp et vérifiez la taille
18> cp sparsetest sparsecp
19> du -sh sparsecp
0 sparsecp
maintenant copiez-le avec le chat et vérifiez la taille
20> cat sparsetest > sparsecat
21> du -sh sparsecat
1.3M sparsecat
essayez vos outils préférés pour vérifier leur comportement
n'oubliez pas de nettoyer.
Note finale de prudence: des expériences comme celles-ci ont la chance inhérente d'augmenter votre renommée avec votre administrateur système local si vous les faites sur un système de fichiers qui fait partie de son plan de sauvegarde, ou critique pour le bien-être du système. Selon son choix d'outil de sauvegarde, il pourrait finir par avoir besoin de plus de supports de bande qu'il n'en avait jamais cru possible pour sauvegarder ce fichier de 0 octet qui est étendu à des téraoctets de zéros.
D'autres fichiers qui ne peuvent pas être copiés avec ni cat ni cp incluraient des fichiers spéciaux pour le périphérique, etc. Cela dépend de votre implémentation de l'outil de copie s'il est capable de dupliquer le nœud du périphérique, ou s'il copierait gaiement son contenu à la place.
cpa une option pour contrôler son comportement sur les fichiers épars; comme, avec --sparse=neverspécifié sur la ligne de commande, cpest aussi lent que cat.
Selon le commentaire de Keith , cpconserve certaines autorisations et catcrée le nouveau fichier comme umaskindiqué. Donc, $2la permission n'est pas préservée, ce qui $4/vmlinuzest assez propre, tandis que si une permission étrange est activée $3, $4/System.mapelle le gardera.
catla rapidité d '?
catplus rapide?
Les deux ont des fonctionnalités équivalentes dans ces deux cas, mais cp est purement une opération de fichier. "Prenez ce fichier et faites-en une copie là-bas".
cat, d'autre part, est destiné à vider le contenu d'un fichier sur la console. "Prenez ce fichier et affichez-le à l'écran" puis demandez à un ninja d'attaquer l'écran et de rediriger la sortie ailleurs.
cp serait généralement plus efficace, car il n'y a pas de redirection uniquement, simplement une copie directe des octets de l'emplacement A vers l'emplacement B.
le chat serait read bytes -> output to console -> intercept output -> redirect to new file.
catne sera pas vraiment output to console -> intercept output -> redirect to new file, le fichier de sortie pour cat peut être stdout ou un fichier normal, il ne fera que sortir dans le fichier, tant que l'entrée n'est pas la même que la sortie.
catn'a rien à voir avec la console. Les deux catet cplisent à partir du fichier d'entrée et écrivent dans le fichier de sortie. Avec cat, le fichier de sortie est ouvert par le shell, tandis qu'avec cp, le fichier de sortie est ouvert par cp; cela ne fait aucune différence dans les performances. cppeut être plus rapide, mais pour une raison complètement différente: certaines implémentations de cptentent de deviner la bonne taille de bloc pour les performances en fonction des appareils source et cible; une mise en œuvre de catne dérangerait pas.
C'est vraiment une question de préférence, à mon humble avis.
Il n'y a techniquement aucune différence réelle à moins que vous n'utilisiez la commande cp avec le commutateur -p pour conserver la propriété / le groupe de fichiers. Sinon, c'est la même chose fonctionnellement. La réponse de Marc est beaucoup plus claire et précise.
cpsans -pne conserve certaines autorisations. Par exemple, si le fichier source est exécutable, cple fichier cible catsera exécutable, mais ne le sera pas.
cpun fichier comme l'original, tout encatcréant un nouveau fichier avec le même contenu.