Bonjour,
Avec find tu vas galérer et faire une usine à gaz. rsync est le moyen le pl us simple et le plus efficace, voire même le plus élégant.
il y a une raison particulière de vouloir absolument le faire avec find?
La commande tar offre aussi des fonctionnalités intéressantes. C’est un peu plus lourd car ça passe par la création d’une archive avant un désarchivage mais ça peut rendre de précieux services, plus particulièrement avec ses options --backup et -C.
Bonjour. Je trouve la commande quelque peu compliquée … pourquoi pas une approche comme: for fichier in $(find .-name '*.mp4'); do cp --parents "$fichier" /tmp; rm "$fichier"; done ?
l’intérêt der rsync c’est que ce ne sont que des options donc standard sans complication autre que de comprendre correctement le man.
Une approche par programmation implique une augmentation de
la complexité et de la maintenabilité.
Pas forcément, encore faut-il que la programmation soit bien lisible . De façon générale, certaines options des commandes Linux ne sont quasiment jamais utilisées et peuvent disparaître ou ne pas suivre un engouement au niveau de la maintenabilité.
je voudrais exergué la commande de MPython_Alaplancha : cp --parents copie effectivement avec les dossiers parents , je ne connaissais pas
ça me sera utile
Les options évoquées sont des options standards; aucune n’est exotique.
Et pour ce qui est de l’obsolescence, les options sont plus facile à gérer que de la maintenance de code qui implique plus de fonction (si on suis cet argument des options obsolète).
Après c’est un classique de la gestion de risque; une commande avec des options comporte moins de risque qu’un code avec plus de commande et plus d’options.
Pour ce qui est de la lisibilité du code, au vue de toute la programmation approximative de ces 20 dernières annnées avec des librairie pleine de bug non corrigées un peut partout, les pages web dont moins de 5% sont conformes aux normes du HTML.
On va dire que la lisibilité du code n’est qu’une légende.
Les options évoquées sont des options standards; aucune n’est exotique.
Je tiens mes propos en m’appuyant sur ceux de Welsh dans son ouvrage de référence « Le système Linux » qui encourage de faire usage des options les plus fréquentes car on peut souvent faire la même chose avec une autre commande que de s’évertuer à tenter de maîtriser toutes les options d’une commande particulière. Cela ne remet pas en question les options évoquées mais apporte un élément essentiel au niveau de la méthode. Par extension on se doit d’aller vers la programmation, d’ailleurs celle-ci est mis au programme très tôt dans le système scolaire en Grande Bretagne.
Je ne partage pas ce point de vue, plus particulièrement en ce qui concerne les procédures de backup/restoration. Combien de pertes de données à cause d’une commande saisie trop rapidement, ce qui n’arrive pas ou plus difficilement avec un script ou un petit programme. Qui n’a jamais connu la suppression malencontreuse de fichiers avec la commande rm par exemple, n’a pas suffisamment pratiqué et le risque est important qu’il arrive un jour, souvent au pire moment. C’est d’autant plus facile que cela se produise avec le rappel des dernières lignes de commandes tout en n’étant pas dans le bon répertoire !
Ce sont les clients qui vont être contents ! Il est vrai que l’agilité ne pousse pas en ce sens avec les sprints Scrum. La lisibilité du code n’est pas une légende, en tout cas pas dans certains secteurs ou certaines entreprises, ou tout simplement auprès de certains développeurs et chefs d’équipes. En développement, j’ai reçu de précieux conseils en matière de lisibilité de code et j’en suis reconnaissant à ceux qui m’ont soutenu ou incité dans cette voie. Je ne suis pas dupe, ce n’est pas pour moi qu’ils l’ont fait mais un code lisible est plus facilement réutilisable. Et un code réutilisable ce sont des économies de temps et d’argent. Avec certains outils de tests unitaires, la lisibilité est renforcé par l’ajout de chaînes de caractères dans le source servant aussi pour la documentation finale. Lisibilité ne signifie pas forcément conformité avec une norme. On peut très bien avoir un code répondant à une norme et n’être pas du tout lisible, la réciproque est vrai aussi.
La lisibilité du code ainsi que la documentation technique associée est une marque de professionnalisme, de respect des clients, ou tout simplement d’expérience. Bien évidemment si un code n’est pas lisible, la première question que je me pose c’est « Est-ce que le développeur a eu (ou pris) suffisamment de temps ? »
. De façon générale, certaines options des commandes Linux ne sont quasiment jamais utilisées et peuvent disparaître ou ne pas suivre un engouement au niveau de la maintenabilité.