Pourquoi cp n'a-t-il pas une barre de progression comme wget?

55

S'il vous plaît noter que je ne demande pas comment . Je connais déjà des options comme pvet rsync -P.

Je veux demander pourquoi ne cpmet pas en place une barre de progression, au moins comme un drapeau?

wget cp architecture

— Lamnk
source

7

Que diriez-vous de "l'auteur n'en ressent pas le besoin"?

— Phunehehe

7

Pour les lecteurs qui ne connaissent pas pvet rsync -P, voir les fichiers déplacer avec barre de progression ( une des réponses cite un patch cpafin que cp -gdonne un indicateur de progression).

— Gilles 'SO- arrête d'être méchant'

2

Un meilleur endroit pour poser vos questions serait sur la nouvelle liste de diffusion des utilisateurs de coreutils (depuis 2010).

— Faheem Mitha

57

La tradition dans les outils Unix est d'afficher des messages uniquement en cas de problème. Je pense que c'est à la fois pour des raisons de conception et pratiques. La conception est destinée à rendre évident lorsque quelque chose ne va pas: vous obtenez un message d'erreur, et il n'est pas noyé dans des messages non réellement informatifs. La raison pratique en est qu’au tout début d’Unix, il y avait encore des téléimprimeurs ; c'est-à-dire que la sortie des programmes serait imprimée sur du papier et que vous ne voulez pas imprimer de barres de progression.

Quelle que soit la raison, la tradition d'affichage uniquement des messages utiles est restée gravée dans le monde Unix. Les outils modernes ont parfois introduit des barres de progression; Dans le cas de rsync, la principale motivation est que rsync est souvent exécuté sur le réseau et que les réseaux sont beaucoup plus volumineux que les disques locaux. La barre de progression est donc plus utile. Le même raisonnement s'applique à wget.

— Gilles, arrête de faire le mal
source

6

Cette. Et cpremonte au début des années 1970: c'est aussi traditionnel que possible.

— dmckee

3

@dmckee Alors pourquoi peut-on ddfaire des déclarations de progrès? ddremonte à 1966 (OS / 360). Les outils Unix peuvent être verbeux si l'utilisateur veut qu'ils soient verbeux, mais vous ne pouvez malheureusement pas dire à quel point cp doit être verbose (il n'y a qu'un seul niveau de verbosité supplémentaire:) -v.

— Taffer

7

@taffer ddest particulier à bien des égards (le plus évidemment, sa syntaxe d'option) car il ne s'agit pas d'unix, mais d'un clone d'un outil IBM. En outre, il était principalement utilisé pour les tâches longues sur des bandes. Ses messages vous invitaient donc à revenir de votre pause, contrairement à l' cpendroit où, dans la plupart des cas, il suffisait de cligner des yeux et de récupérer votre message.

— Gilles 'SO- arrête d'être méchant'

16

Dans le monde Unix, chaque outil est conçu pour faire un travail et le faire bien. Pourquoi cps’inquiéterait-il de la production des progrès alors qu’un autre outil comme le pvfait déjà? Dans le même ordre d'idées, pourquoi tant de programmes affichent-ils des éléments à l'écran sans aucune pagination? Parce qu'il existe déjà des outils pour ce travail tels que more(ou less). Pourquoi la plupart des programmes nécessitant l'édition de fichiers NE vous présentent PAS un éditeur et externalisent à la $EDITORplace? Parce que cela laisse tout le monde faire la tâche pour laquelle ils ont été conçus, et l'utilisateur utilise son éditeur favori pour toutes les tâches.

Tangentiellement, la plupart des programmes shell sont conçus pour que leur sortie soit acheminée vers d’autres programmes shell. Le seul résultat qu'ils sont susceptibles de donner est ce qu'il serait utile d'analyser dans la prochaine commande de la chaîne. Des programmes tels que ceux cputilisés dans les scripts ainsi que manuellement à partir d'un terminal. Son résultat est donc centré sur le code de sortie et la liste des fichiers ayant échoué ou réussi.

Attendez-vous toujours à combiner des outils pour obtenir l'effet souhaité.

— Caleb
source

3

Existait- pvil quand a cpété écrit? C'est un bon point, mais j'ai l'impression que dans ce cas, à l' cporigine , c'était délibérément écrit sans résultat de progrès, rien à voir avec d'autres outils, juste les autres raisons que vous et Gilles citez.

— Cascabel

1

@ Jefromi: Je ne suis pas sûr que cela compte. Ce n’est pas une question historique de savoir pourquoi cpétait un moyen lorsqu’il a été codé pour la première fois. La question est de savoir pourquoi est-ce ainsi maintenant . Cela fait de nombreuses années et quelqu'un aurait pu ajouter la fonctionnalité, mais a clairement décidé de ne pas le faire. Je suis sûr que la disponibilité d'autres outils est un facteur déterminant dans cette décision.

— Caleb

3

C'est l'une de ces choses marginales où il y a des arguments pour et contre l'ajout d'une option de barre de progression à cp. L'argument principal contre, est que vous ne pouvez pas savoir à l'avance que vous voulez connaître les progrès. Ctrl-T / SIGINFO est disponible sur BSD à cette fin, et si cela devenait disponible sur les plates-formes GNU / Linux, il y aurait peut-être plus de raison pour que cela déclenche la logique de la barre de progression dans cp. Entre-temps, une solution plus générale consiste à utiliser un outil distinct, tel que Coreutils Progress Viewer ( progressanciennement connu sous le nom de cv), pour afficher l’état de tout processus sur le système.

— Pádraig Brady
source