Pourquoi `cp` a-t-il été conçu pour remplacer silencieusement les fichiers existants? [fermé]

J'ai testé cpavec les commandes suivantes:

$ ls
first.html   second.html  third.html

$ cat first.html
first

$ cat second.html
second

$ cat third.html
third

Ensuite, je copie first.htmlà second.html:

$ cp first.html second.html

$ cat second.html
first

Le fichier second.htmlest écrasé en silence sans aucune erreur. Cependant, si je le fais dans une interface graphique de bureau en faisant glisser et en déposant un fichier avec le même nom, il sera suffixé comme first1.htmlautomatiquement. Cela évite d'écraser accidentellement un fichier existant.

Pourquoi ne cpsuit-il pas ce modèle au lieu d'écraser les fichiers en silence?

Le comportement d'écrasement par défaut de cpest spécifié dans POSIX.

3. Si le fichier source est de type fichier normal, les étapes suivantes doivent être suivies:

   3.a. Le comportement n'est pas spécifié si dest_file existe et a été écrit lors d'une étape précédente. Sinon, si dest_file existe, les étapes suivantes doivent être suivies:

   3.ai Si l'option -i est en vigueur, l'utilitaire cp doit écrire une invite à l'erreur standard et lire une ligne à partir de l'entrée standard. Si la réponse n'est pas affirmative, cp ne fera plus rien avec source_file et passera aux fichiers restants.

   3.a.ii. Un descripteur de fichier pour dest_file doit être obtenu en effectuant des actions équivalentes à la fonction open () définie dans le volume System Interfaces de POSIX.1-2017 appelée en utilisant dest_file comme argument de chemin, et le OU inclus au niveau du bit de O_WRONLY et O_TRUNC comme argument oflag.

   3.a.iii. Si la tentative d'obtention d'un descripteur de fichier échoue et que l'option -f est en vigueur, cp doit tenter de supprimer le fichier en effectuant des actions équivalentes à la fonction unlink () définie dans le volume System Interfaces de POSIX.1-2017 appelé à l'aide de dest_file comme argument de chemin. Si cette tentative réussit, cp continuera avec l'étape 3b.

Lorsque la spécification POSIX a été écrite, il existait déjà un grand nombre de scripts, avec une hypothèse intégrée pour le comportement d'écrasement par défaut. Beaucoup de ces scripts ont été conçus pour s'exécuter sans présence directe de l'utilisateur, par exemple en tant que tâches cron ou autres tâches d'arrière-plan. Changer le comportement les aurait brisés. Les examiner et les modifier tous pour ajouter une option pour forcer l'écrasement partout où cela était nécessaire était probablement considéré comme une tâche énorme avec des avantages minimes.

De plus, la ligne de commande Unix a toujours été conçue pour permettre à un utilisateur expérimenté de travailler efficacement, même au détriment d'une courbe d'apprentissage difficile pour un débutant. Lorsque l'utilisateur entre une commande, l'ordinateur doit s'attendre à ce que l'utilisateur le veuille vraiment, sans aucune hésitation; il est de la responsabilité de l'utilisateur de faire attention aux commandes potentiellement destructrices.

Lorsque l'Unix d'origine a été développé, les systèmes avaient alors si peu de mémoire et de stockage de masse par rapport aux ordinateurs modernes que l'écrasement des avertissements et des invites était probablement considéré comme un luxe inutile et inutile.

Lorsque la norme POSIX a été rédigée, le précédent était fermement établi et les rédacteurs de la norme étaient bien conscients des vertus de ne pas rompre la rétrocompatibilité .

En outre, comme d'autres l'ont décrit, tout utilisateur peut ajouter / activer ces fonctionnalités pour lui-même, en utilisant des alias de shell ou même en créant une cpcommande de remplacement et en les modifiant $PATHpour trouver le remplacement avant la commande système standard, et obtenir le filet de sécurité de cette façon si voulu.

Mais si vous le faites, vous constaterez que vous créez un danger pour vous-même. Si la cpcommande se comporte d'une manière lorsqu'elle est utilisée de manière interactive et d'une autre façon lorsqu'elle est appelée à partir d'un script, vous ne vous souvenez peut-être pas que la différence existe. Sur un autre système, vous pourriez finir par être négligent parce que vous êtes habitué aux avertissements et aux invites de votre propre système.

Si le comportement des scripts correspond toujours à la norme POSIX, vous vous habituerez probablement aux invites en utilisation interactive, puis écrivez un script qui effectue une copie de masse - et constatez ensuite que vous avez écrasé quelque chose par inadvertance.

Si vous appliquez également l'invite dans les scripts, que fera la commande lorsqu'elle sera exécutée dans un contexte sans utilisateur, par exemple des processus d'arrière-plan ou des tâches cron? Le script sera-t-il bloqué, abandonné ou écrasé?

Suspendre ou abandonner signifie qu'une tâche qui était censée être effectuée automatiquement ne sera pas effectuée. Le non-écrasement peut parfois également causer un problème en lui-même: par exemple, il peut entraîner le traitement deux fois des anciennes données par un autre système au lieu d'être remplacées par des données à jour.

Une grande partie de la puissance de la ligne de commande vient du fait qu'une fois que vous savez comment faire quelque chose sur la ligne de commande, vous saurez également implicitement comment le faire automatiquement par script . Mais cela n'est vrai que si les commandes que vous utilisez de manière interactive fonctionnent exactement de la même manière lorsqu'elles sont appelées dans un contexte de script. Toute différence significative de comportement entre une utilisation interactive et une utilisation scriptée créera une sorte de dissonance cognitive qui dérange un utilisateur expérimenté.

cpvient du début d'Unix. Il était là bien avant que la norme Posix ne soit écrite. En effet: Posix vient d'officialiser le comportement existant de cpà cet égard.

On parle d'Epoch (01/01/1970), quand les hommes étaient de vrais hommes, les femmes étaient de vraies femmes et de petites créatures à fourrure ... (je m'égare). À cette époque, l'ajout de code supplémentaire a agrandi le programme. C'était un problème alors, car le premier ordinateur qui exécutait Unix était un PDP-7 (extensible à 144 Ko de RAM!). Les choses étaient donc petites, efficaces, sans dispositifs de sécurité.

Donc, à cette époque, vous deviez savoir ce que vous faisiez, car l'ordinateur n'avait tout simplement pas le pouvoir de vous empêcher de faire tout ce que vous regrettiez plus tard.

(Il y a un joli dessin animé de Zevar; recherchez "zevar cerveaux assiste par ordinateur" pour retrouver l'évolution de l'ordinateur. Ou essayez http://perinet.blogspirit.com/archive/2012/02/12/zevar-et- cointe.html tant qu'il existe)

Pour ceux qui sont vraiment intéressés (j'ai vu des spéculations dans les commentaires): L'original cpsur le premier Unix était d'environ deux pages de code assembleur (C est venu plus tard). La partie pertinente était:

sys open; name1: 0; 0   " Open the input file
spa
  jmp error         " File open error
lac o17         " Why load 15 (017) into AC?
sys creat; name2: 0     " Create the output file
spa
  jmp error         " File create error

(Donc, dur sys creat)

Et, pendant que nous y sommes: la version 2 d'Unix est utilisée (code sniplet)

mode = buf[2] & 037;
if((fnew = creat(argv[2],mode)) < 0){
    stat(argv[2], buf);

ce qui est également difficile creatsans tests ni garanties. Notez que le code C pour V2 Unix cpest inférieur à 55 lignes!

Parce que ces commandes sont également destinées à être utilisées dans des scripts, s'exécutant éventuellement sans aucune supervision humaine, et aussi parce qu'il y a de nombreux cas où vous souhaitez en effet écraser la cible (la philosophie des shells Linux est que l'homme sait quoi elle fait)

Il y a encore quelques garanties:

• GNU cpa un -n| --no-clobberoption
• si vous copiez plusieurs fichiers dans un seul cp, vous vous plaindrez que le dernier n'est pas un répertoire.

Est-ce "faire une chose à la fois"?

Ce commentaire ressemble à une question sur un principe général de conception. Souvent, les questions à ce sujet sont très subjectives et nous ne sommes pas en mesure d'écrire une réponse appropriée. Soyez averti que nous pouvons fermer les questions dans ce cas.

Parfois, nous avons une explication pour le choix de conception d'origine, car les développeurs ont écrit à leur sujet. Mais je n'ai pas une si belle réponse à cette question.

Pourquoi cpest conçu de cette façon?

Le problème est qu'Unix a plus de 40 ans.

Si vous créez un nouveau système maintenant, vous pouvez faire des choix de conception différents. Mais changer Unix briserait les scripts existants, comme mentionné dans d'autres réponses.

Pourquoi a- t-il étécp conçu pour remplacer silencieusement les fichiers existants?

La réponse courte est "je ne sais pas" :-).

Comprenez que ce cpn'est qu'un problème. Je pense qu'aucun des programmes de commande d'origine protégé contre l'écrasement ou la suppression de fichiers. Le shell a un problème similaire lors de la redirection de la sortie:

$ cat first.html > second.html

Cette commande écrase également silencieusement second.html.

Je suis curieux de savoir comment tous ces programmes pourraient être repensés. Cela peut nécessiter une complexité supplémentaire.

Je pense que cela fait partie de l'explication: les premiers Unix mettaient l'accent sur les implémentations simples . Pour une explication plus détaillée de cela, voir "pire c'est mieux", lié à la fin de cette réponse.

Vous pouvez changer > second.htmlpour qu'il s'arrête avec une erreur, s'il second.htmlexiste déjà. Cependant , comme nous l' avons mentionné, parfois l'utilisateur ne veut remplacer un fichier existant. Par exemple, elle peut créer une commande complexe, en essayant plusieurs fois jusqu'à ce qu'elle fasse ce qu'elle veut.

L'utilisateur peut s'exécuter en rm second.htmlpremier s'il en a besoin. Cela pourrait être un bon compromis! Il présente certains inconvénients possibles.

1. L'utilisateur doit taper le nom de fichier deux fois.
2. Les gens ont aussi beaucoup de mal à utiliser rm. Je voudrais donc rendre la rmsécurité aussi. Mais comment? Si nous faisons rmafficher chaque nom de fichier et demandons à l'utilisateur de confirmer, il doit maintenant écrire trois lignes de commandes au lieu d'une. De plus, si elle doit le faire trop souvent, elle prendra une habitude et tapera «y» pour confirmer sans réfléchir. Cela pourrait donc être très ennuyeux, et cela pourrait tout de même être dangereux.

Sur un système moderne, je recommande d' installer la trashcommande et de l'utiliser plutôt rmque possible. L'introduction du stockage Trash était une excellente idée, par exemple pour un PC graphique à utilisateur unique .

Je pense qu'il est également important de comprendre les limites du matériel Unix d'origine - RAM et espace disque limités, sortie affichée sur les imprimantes lentes ainsi que le système et le logiciel de développement.

Notez que Unix d'origine n'avait pas de tabulation , pour remplir rapidement un nom de fichier pour une rmcommande. (De plus, le shell Bourne d'origine n'a pas d'historique de commandes, par exemple lorsque vous utilisez la touche flèche vers le haut bash).

Avec la sortie de l' imprimante, vous devez utiliser éditeur en ligne, ed. C'est plus difficile à apprendre qu'un éditeur de texte visuel. Vous devez imprimer certaines lignes actuelles, décider comment vous souhaitez les modifier et saisir une commande d'édition.

Utiliser, > second.htmlc'est un peu comme utiliser une commande dans un éditeur de ligne. Son effet dépend de l'état actuel. (S'il second.htmlexiste déjà, son contenu sera supprimé). Si l'utilisateur n'est pas sûr de l'état actuel, il doit s'exécuter lsou d' ls second.htmlabord.

"Mise en œuvre simple" comme principe de conception

Il existe une interprétation populaire de la conception Unix, qui commence:

La conception doit être simple, à la fois dans la mise en œuvre et l'interface. Il est plus important que l'implémentation soit simple que l'interface. La simplicité est la considération la plus importante dans une conception.

...

Gabriel a fait valoir que "Worse is better" a produit des logiciels plus performants que l'approche MIT: tant que le programme initial est fondamentalement bon, il faudra beaucoup moins de temps et d'efforts pour le mettre en œuvre initialement et il sera plus facile de s'adapter aux nouvelles situations. Le portage de logiciels sur de nouvelles machines, par exemple, devient beaucoup plus facile de cette façon. Ainsi, son utilisation se répandra rapidement, bien avant qu'un [meilleur] programme ait une chance d'être développé et déployé (avantage du premier arrivant).

https://en.wikipedia.org/wiki/Worse_is_better

La conception de "cp" remonte à la conception originale d'Unix. En fait, il y avait une philosophie cohérente derrière la conception Unix, qui a été légèrement moins que ce qu'on appelle à moitié en plaisantant Worse-is-Better ^* .

L'idée de base est que garder le code simple est en fait une considération de conception plus importante qu'avoir une interface parfaite ou "faire la bonne chose".

• Simplicité - la conception doit être simple, à la fois dans la mise en œuvre et l'interface. Il est plus important que l'implémentation soit simple que l'interface . La simplicité est la considération la plus importante dans une conception.

• Exactitude - la conception doit être correcte dans tous les aspects observables. Il vaut mieux être simple que correct.

• Cohérence - la conception ne doit pas être trop incohérente. La cohérence peut être sacrifiée pour la simplicité dans certains cas, mais il est préférable de supprimer les parties de la conception qui traitent de circonstances moins courantes que d'introduire une complexité de mise en œuvre ou une incohérence.

• Complétude - la conception doit couvrir autant de situations importantes que possible. Tous les cas raisonnablement attendus doivent être couverts. L'exhaustivité peut être sacrifiée au profit de toute autre qualité. En fait, l'exhaustivité doit être sacrifiée chaque fois que la simplicité de mise en œuvre est compromise. La cohérence peut être sacrifiée pour atteindre l'exhaustivité si la simplicité est conservée; la cohérence de l'interface est particulièrement inutile.

^{(c'est moi qui souligne )}

En se souvenant que c'était en 1970, le cas d'utilisation de "Je veux copier ce fichier uniquement s'il n'existe pas déjà" aurait été un cas d'utilisation assez rare pour quelqu'un qui effectuait une copie. Si c'est ce que vous vouliez, vous seriez tout à fait capable de vérifier avant la copie, et cela peut même être scripté.

Quant à savoir pourquoi un OS avec cette approche de conception s'est avéré être celui qui a gagné sur tous les autres OS en cours de construction à l'époque, l'auteur de l'essai avait également une théorie pour cela.

Un autre avantage de la philosophie du pire est le meilleur est que le programmeur est conditionné à sacrifier la sécurité, la commodité et les tracas pour obtenir de bonnes performances et une utilisation modeste des ressources. Les programmes écrits en utilisant l'approche du New Jersey fonctionneront bien à la fois sur les petites machines et les grandes, et le code sera portable car il est écrit sur un virus.

Il est important de se rappeler que le virus initial doit être fondamentalement bon. Dans l'affirmative, la propagation virale est assurée tant qu'elle est portable. Une fois que le virus s'est propagé, il y aura une pression pour l'améliorer, peut-être en augmentant sa fonctionnalité plus près de 90%, mais les utilisateurs ont déjà été conditionnés pour accepter pire que la bonne chose. Par conséquent, le logiciel le pire est le meilleur sera d'abord accepté, le second conditionnera ses utilisateurs à en attendre moins, et le troisième sera amélioré à un point qui est presque la bonne chose.

^{* - ou ce que l'auteur, mais personne d'autre, n'a appelé "l'approche du New Jersey"} .

La raison principale est qu'une interface graphique est par définition interactive, alors qu'un binaire /bin/cpest juste un programme qui peut être appelé depuis toutes sortes d'endroits, par exemple depuis votre interface graphique ;-). Je parie que même aujourd'hui, la grande majorité des appels vers /bin/cpne proviendront pas d'un véritable terminal avec un utilisateur tapant une commande shell, mais plutôt d'un serveur HTTP ou d'un système de messagerie ou d'un NAS. Une protection intégrée contre les erreurs des utilisateurs prend tout son sens dans un environnement interactif; moins dans un simple binaire. Par exemple, votre interface graphique appellera très probablement /bin/cpen arrière-plan pour effectuer les opérations réelles et devra traiter les questions de sécurité sur la sortie standard même si elle vient de demander à l'utilisateur!

Notez qu'il était dès le premier jour presque trivial d'écrire un wrapper sûr /bin/cpsi vous le souhaitez. La philosophie * nix est de fournir des blocs de construction simples pour les utilisateurs: l'un d'eux en /bin/cpest un.