C’est toujours mieux d’avoir un exemple pour comprendre une technique j’imagine. Mais chaque partie est indépendante et n’est pas obligatoire bien sûr, ce sont des recommandations en réalité, adaptable en fonction du sujet.

J’ai rectifié pour la partie branch main, je te remercie :)

J’ai un avis mitigé sur cet article. Le contenu est correct, aucun problème avec ça, mais ça décrit une méthode parmi tant d’autres…

Tout le monde n’est pas forcément d’accord, ce n’est pas forcément applicable à tous les projets, ça décrit plus une possibilité de workflow complet pour un projet particulier qu’une “procédure de merge request” générique comme le laisse entendre le titre.

Il manque une précision selon moi, pour dire que c’est “juste un exemple”, chaque élément décrit correspondant à une décision à prendre par les mainteneurs de chaque projet (convention de nommage des branches, langue utilisée, template de description de MR, etc.).

Cela étant dit, je suis quand même heureux de l’avoir lu, et je remercie l’auteur de partager ses connaissances/méthodes/habitudes ;)

PS: Une petite imprécision quand même, main n’est pas juste le nom de la branche principale sur GitHub, cette modification a aussi été appliquée sur GitLab (depuis la version 14.0), et pourrait potentiellement être appliquée un jour au niveau de git lui même (si ce n’est pas déjà fait, mais j’ai l’impression que non).

Merci du repost :D

Mec.

Mes remarques peuvent paraître pointilleuses mais c’est important pour la compréhension.

Tous les fichiers de configuration de mon système dans le répertoire /etc sont protégés en écriture pour un utilisateur courant.

find /etc -type f -writable

La commande cat combinée avec grep est fautive sans que l’on comprenne vraiment pourquoi. On pourrait penser que c’est plutôt équivalent à cat /etc/passwd ; grep bash /etc/passwd. L’utilisateur souhaite afficher le contenu du fichier, s’aperçoit que cat n’est pas adapté et réduit donc à l’essentiel ce qui est affiché grâce à grep. Néanmoins, il faut savoir que des commandes fonctionnent directement avec des fichiers et dans des pipes. Cela est éventuellement plus difficile dans la manière d’exposer mais le propos n’est pas forcément plus compliqué (quoique plus fastidieux).

On comprend que grep "PS1" /etc/* est incorrect puisque le motif du nom de fichier donne accès à des fichiers quelconques (caractère de substitution étoile) dans un répertoire rempli de fichiers. Peu importe que la recherche soit poursuivie dans les sous-répertoires mais cela paraît plus logique et surtout correct.

1. /usr/bin est accessible en lecture à tout le monde.

2. On s’en fiche des processus lancés par -exec. C’est un cours d’introduction au shell, pas un exposé sur l’optimisation à outrance des commandes du shell.

3. L’exemple avec le “useless use of cat” est avant tout pédagogique. D’ailleurs il aurait suffi de lire la phrase juste après pour s’en rendre compte. C’est expliqué. Suffit de lire l’article.

4. Ben non, la recherche n’est pas récursive. Rien ne le dit dans le texte.

Pourquoi vaut-il mieux être root pour se lancer dans la recherche d’un fichier de configuration du système ?

Le système signale comme il se devrait qu’on ne peut pas lancer la recherche dans tel répertoire à cause des droits d’accès.

find /usr/bin -size +1M -exec ls -lh {} + \;

find lance un nouveau processus ls pour chaque résultat.

Mais en ajoutant un signe plus après les accolades, find ne lance de nouveau processus que lorsque le nombre de noms de fichiers a dépassé le nombre limite d’arguments de la ligne de commande.

cat /etc/passwd | grep bash

C’est vraiment montrer le mauvais exemple ; fournir plutôt la bonne explication.

grep "PS1" /etc/*

Le motif de noms de fichiers ne correspond pas absolument : la recherche n’est pas récursive, ….

grep -R "PS1" /etc/

On rappel à toutes fins utiles qu’une œuvre «libre de droit» ne peut exister par essence. On parlera donc d’une oeuvre sous licence libre ou dans le domaine public.

En effet, la terminologie de cryptage reviendrait à chiffrer un fichier sans en connaître la clé et donc sans pouvoir le déchiffrer ensuite.

Cette assertion frise l’illogisme puisque l’opération consiste à transformer un message intelligible pour qu’il soit incompréhensible, illisible ou inaccessible. Indéchiffrable (très difficile à comprendre, à deviner ou à résoudre) dans le sens où il faut pouvoir le comprendre d’une manière ou d’une autre ; mais pas intranscriptible. En toute logique, cela signifie retrouver le message original. Sinon le message n’a aucune valeur. Les sens pourvus par les termes « cryptage » ou « crypter » tout comme « cryptologie » ou « chiffrer » ou « message codé indéchiffrable » se retrouvent dans plusieurs définitions courantes car ces termes ont des traits communs : caché et énigmatique (ce qu’il est difficile de comprendre, d’expliquer, de connaître).

je vais mon grammar nazi pour certains mais : https://chiffrer.info/ pour l’explication de la blague du début :)

Merci pour l’inclusion de mon dernier article ! :D :p

La remarque à propos de info relève à mon avis d’un jugement mal avisé.

À en juger par les commentaires des utilisateurs chevronnés de systèmes Unix dans les forums ou les listes de diffusion, les pages info ont moins bonne presse que les pages man, en raison de leur système de navigation quelque peu désuet et, surtout, de l’impossibilité de les mettre en forme, notamment pour en imprimer un extrait ou la totalité.

On peut produire divers formats en compilant les même fichiers sources : HTML, PDF ou Info. Il existe aussi plusieurs lecteurs de documents Info. Il est plus efficace et pratique de parcourir un sujet dans le système Info qu’en utilisant la commande less. Le système Info est recommandé par le projet GNU car il vise à former des utilisateurs et non pas à informer (comme les pages man).

Qu’en est-il de la compréhensibilité des pages de manuel ? Il faut comprendre l’anglais, avoir des notions d’administration système (pour appréhender les choses) et savoir situer son niveau technique. Cela n’est pas forcément problématique pour ceux ayant une formation. Parce que certains sujets sont complexes à traiter.

(Livre) Unix & Linux : utilisation et administration [de Jean-Michel Léry]

8.2.5 La documentation sur les shells

Les différents environnements sont très complexes (même pour les plus simples), et nombre de fonctionnalités, parfois accessoires, sont disponibles. Dans ce chapitre, nous présenterons, de manière précise mais non exhaustive, les fonctionnalités importantes et intéressantes de ces environnements. Le système UNIX propose des manuels sur les différents shells. Celui de la commande ksh s’affiche après la saisie de man ksh.

Attention

La documentation fournie par les manuels est à la fois imposante et condensée. Il est difficile de s’y retrouver sans avoir déjà une bonne maîtrise de l’environnement, voire parfois quelques connaissances en programmation. Plutôt que comme un point de départ, mieux vaut l’utiliser comme un complément d’apprentissage qui permet d’aller encore plus loin.

On indique d’utiliser cat pour visualiser des fichiers textes peu long par souci de simplification : cat est une commande simple à utiliser (pédagogiquement). Mais cat a été conçue pour concaténer des fichiers vers la sortie standard. Normalement, on ne doit pas avoir à se soucier de la longueur du fichier lu pour choisir quelle est la commande adéquate.

Pourquoi ne pas utiliser cat ?

J’aime bien la présentation du livre « Reprenez le contrôle à l’aide de Linux » de Mathieu Nebra.

La commande cat permet d’afficher tout le contenu d’un fichier dans la console d’un seul coup.

Pour faire simple, la différence entre more et less c’est que more est vieux et possède peu de fonctionnalités, tandis que less est beaucoup plus puissant et rapide.

cat ne devrait pas (selon moi) être utilisée afin de visualiser le contenu d’un fichier : less -FX fichier.

Les exemples avancés comme justificatifs sont quelque peu douteux.

printf("%d", (5,3) );

On fournit deux nombres entiers pour finalement n’en afficher qu’un seul : ce qui est insensé.

if( argc > 2 && argv[2][0] == '0' )
    action = 4, color = false;

Le guide complet du langage C (Claude Delannoy) > 11. L’opérateur séquentiel

Certes, un tel opérateur pourrait théoriquement être utilisé pour réunir plusieurs instructions en une seule. Dans la pratique, ce n’est pas là le principal usage que l’on fera de cet opérateur séquentiel. En revanche, il interviendra fréquemment dans les instructions de choix ou dans les boucles : là où la syntaxe n’a prévu qu’une seule expression, l’opérateur séquentiel permet d’en placer plusieurs, et partant, d’y réaliser plusieurs calculs ou plusieurs actions.

if (argc > 2 && argv[2][0] == '0') 
  {
    action = 4; color = false;
  }

Clairement, cette portion de code peut être écrite de façon usuelle. L’opérateur séquentiel n’a pas vraiment de sens dans le contexte.

printf("%d", a<b ? a : b);

if (a < b)
    printf("%d", a);
else
    printf("%d", b);

On a une écriture plus compacte sauf que initialement le sens du code est inapparent. Ce morceau de code aurait-il une pertinence ? Quelle pertinence aurait-il pu avoir ?

printf("%d", *(tab+2));
printf("%d", 2[tab]);

En programmation, les tableaux sont conventionnellement indexés en utilisant la syntaxe tab[i]. L’équivalence est admise car elle a un sens intrinsèque dans la conception du langage C. L’identificateur de tableau tab est converti en un pointeur constant sur le premier élément du tableau : on accède à une structure de donnée.

printf("%c", "!=~"[is_good]);

// Ou comme on l'a vu :
printf("%c", is_good["!=~"] ); // Affiche '!' si is_good vaut 0
                               //         '=' si is_good vaut 1
                               //         '~' si is_good vaut 2

Pour moi, ce code est totalement incompréhensible (ou vraiment incroyable, avec mes rudiments du C).

int tab[10] = {[2] = 5};

Au cours de ma lecture du livre « Le guide complet du langage C » de Claude Delannoy, je ne me souviens pas de ce genre de notation (?).

Édition : Ce genre de notation est apparue à partir de C99. La norme C appelle cela « designated initializer ».

L’explication paraît fautive puisque c’est peu probable que cela soit toujours identique à int tab[10] = {0, 0, 5}; en termes d’initialisation de tableau. Cela n’est vrai que pour les tableaux d’entiers de classe statique (les tableaux définis dans une fonction sont de classe automatique et ne sont pas initialisés, les valeurs qui n’ont pas été initialisées explicitement sont, de fait, imprévisibles).

int tab[10]; tab[2] = 5;

Mon niveau n’est pas suffisant pour me faire une idée de ce qui est valide ou pas dans le reste de l’article. Je reste sceptique.

“En revanche, si vous avez des arguments pour me convaincre que je me trompe, je n’aurai aucun mal à dire que j’ai changé d’avis s’ils m’ont convaincu.”

Les commentaires de ce billet sont fermés sur le blog haha.
Bon j’avais rien à dire mais l’ironie était à noter.

Je n’ai pas le même avis sur la conclusion, qui relève du mythe (voir ci-dessous). Il est omis qu’il faut maîtriser plusieurs commandes mais également le shell. D’autant plus qu’il faut pouvoir créer de nouvelles commandes.

À partir du moment où vous maîtrisez ne serait-ce qu’une poignée de commandes Unix, vous apprendrez à les combiner pour résoudre les problèmes de manière efficace.

Les choses sont exposées avec plus de réalisme dans la documentation de GNU Coreutils.

31. Opening the Software Toolbox > 31.1. Toolbox introduction

(An important additional point was that, if necessary, take a detour and build any software tools you may need first, if you don’t already have something appropriate in the toolbox.)

Il faut également prendre en considération la complexité du processus en question pour effectuer une tâche donnée : voir l’article Wiki « ParsingLS » pour avoir un aperçu.

L’article était pour répondre à un besoin particulier. Mais en effet je préfère largement Anydesk qui est fonctionnel correctement et disponible directement en flatpak. D’ailleurs j’ai mis la petite phrase dans l’intro “A noter que je préfère personnellement Anydesk qui est disponible directement en Flatpak.”