Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

discussion sur les pratiques des aidants

xubu1957

Résultat :

xubu@xubu-ThinkPad-T410:~$ dpkg -l | awk '$2~/^linux-([ghit]|[lm]o|si)/ && !/^rc/{print $1,$2,$3,$4}' OFS='\t' | sort -k3,3V
ii	linux-headers-4.15.0-44	4.15.0-44.47	all
ii	linux-headers-4.15.0-44-generic	4.15.0-44.47	amd64
ii	linux-image-4.15.0-44-generic	4.15.0-44.47	amd64
ii	linux-modules-4.15.0-44-generic	4.15.0-44.47	amd64
ii	linux-modules-extra-4.15.0-44-generic	4.15.0-44.47	amd64
ii	linux-tools-4.15.0-44	4.15.0-44.47	amd64
ii	linux-tools-4.15.0-44-generic	4.15.0-44.47	amd64
ii	linux-headers-4.15.0-45	4.15.0-45.48	all
ii	linux-headers-4.15.0-45-generic	4.15.0-45.48	amd64
ii	linux-image-4.15.0-45-generic	4.15.0-45.48	amd64
ii	linux-modules-4.15.0-45-generic	4.15.0-45.48	amd64
ii	linux-modules-extra-4.15.0-45-generic	4.15.0-45.48	amd64
ii	linux-tools-4.15.0-45	4.15.0-45.48	amd64
ii	linux-tools-4.15.0-45-generic	4.15.0-45.48	amd64
ii	linux-tools-common	4.15.0-45.48	all
ii	linux-generic	4.15.0.45.47	amd64
ii	linux-headers-generic	4.15.0.45.47	amd64
ii	linux-image-generic	4.15.0.45.47	amd64
ii	linux-tools-generic	4.15.0.45.47	amd64
xubu@xubu-ThinkPad-T410:~$

xubu@xubu-ThinkPad-T410:~$ echo; dpkg -l | grep -Ei "linux-(g|h|i|lo|mo|si|t)" | grep -v ^rc | sort -k3 | awk '{print $1,$2,$3,$4}' | column -s" " -t ; echo ; uname -mr

ii  binutils-x86-64-linux-gnu              2.30-21ubuntu1~18.04  amd64
ii  linux-headers-4.15.0-44                4.15.0-44.47          all
ii  linux-modules-4.15.0-44-generic        4.15.0-44.47          amd64
ii  linux-modules-extra-4.15.0-44-generic  4.15.0-44.47          amd64
ii  linux-headers-4.15.0-44-generic        4.15.0-44.47          amd64
ii  linux-tools-4.15.0-44                  4.15.0-44.47          amd64
ii  linux-tools-4.15.0-44-generic          4.15.0-44.47          amd64
ii  linux-image-4.15.0-44-generic          4.15.0-44.47          amd64
ii  linux-generic                          4.15.0.45.47          amd64
ii  linux-headers-generic                  4.15.0.45.47          amd64
ii  linux-image-generic                    4.15.0.45.47          amd64
ii  linux-tools-generic                    4.15.0.45.47          amd64
ii  linux-headers-4.15.0-45                4.15.0-45.48          all
ii  linux-tools-common                     4.15.0-45.48          all
ii  linux-modules-4.15.0-45-generic        4.15.0-45.48          amd64
ii  linux-modules-extra-4.15.0-45-generic  4.15.0-45.48          amd64
ii  linux-headers-4.15.0-45-generic        4.15.0-45.48          amd64
ii  linux-tools-4.15.0-45                  4.15.0-45.48          amd64
ii  linux-tools-4.15.0-45-generic          4.15.0-45.48          amd64
ii  linux-image-4.15.0-45-generic          4.15.0-45.48          amd64

4.15.0-45-generic x86_64
xubu@xubu-ThinkPad-T410:~$

nam1962

Watael a écritmoi, je vois un manque de maîtrise de la ligne de commande, et ça se manifeste dès qu'une commande se pipe "elle-même".
et c'est pire quand une commande, derrière, peut faire mieux toute seule.
dpkg -l | awk '$2~/^linux-([ghit]|[lm]o|si)/ && !/^rc/{print $1,$2,$3,$4}' OFS='\t' | sort -k3,3V
mais je préfère quand même la version courte :
dpkg -l linux-image* | grep '^ii'
c'est beaucoup plus clair :
dpkg affiche-moi les noyaux, et grep ne me montre que ceux sont installés.

Wiwiwi ! Très concis... Comme ta lecture des posts précédents...

Une fois informé des ii, comment fais tu pour supprimer les paquets en vrac dont tu n'as pas été informé ?

Je pense que si ça continue, je vais quitter ce fil que j'avais abordé avec enthousiasme : au lieu de suggestions constructives et observations qui pourraient aider les aidants, je ne vois que démontages hâtifs de gensses que je n'ai en plus jamais vu sur les fils de démerdage concernés.

:/

:/

:/

Watael

xubu1957 a écritRésultat

oui, ça démontre quoi ?

nam1962 a écritUne fois informé des ii, comment fais tu pour supprimer les paquets en vrac dont tu n'as pas été informé ?

je ne comprends pas de quoi tu parles sans exemple.
je tourne sur une toute petite Debian, qui ne me pose pas ce problème.

xubu1957

Watael a écritoui, ça démontre quoi ?

J'ai mis les deux retours pour comparer l'affichage.

Watael

ah, oui. dans le deuxième il y a binutils. est-ce pertinent ?

moko138

Watael a écritmoi, je vois un manque de maîtrise de la ligne de commande, et ça se manifeste dès qu'une commande se pipe "elle-même".
et c'est pire quand une commande, derrière, peut faire mieux toute seule.
dpkg -l | awk '$2~/^linux-([ghit]|[lm]o|si)/ && !/^rc/{print $1,$2,$3,$4}' OFS='\t' | sort -k3,3V
mais je préfère quand même la version courte :
dpkg -l linux-image* | grep '^ii'
c'est beaucoup plus clair :
dpkg affiche-moi les noyaux, et grep ne me montre que ceux sont installés.

"manque de maîtrise de la ligne de commande"
Évidemment : le peu que je sais en informatique, je l'ai appris sur ce site et dans les man.
C'est bien pour ça que je suis preneur d'améliorations ! (en conservant l'alignement des colonnes et le nom du noyau actif.)

Et oui, exclure binutils du retour ce serait bien ! Bien vu !
Et donc, que proposes-tu de mieux que

echo; dpkg -l | grep -Ei "linux-(g|h|i|lo|mo|si|t)" | grep -Ev "^rc|binutils" | sort -k3 | awk '{print $1,$2,$3,$4}' | column -s" " -t ; echo ; uname -mr

Qu'est-ce qu'une « commande [qui] se pipe "elle-même" » ?
| grep ceci | grep -v cela ?
Si oui, en quoi est-ce à éviter ?

Watael a écrit mais je préfère quand même la version courte : (...)

La version courte suffit pour un utilisateur chevronné. Ce n'est pas l'objet de ce fil.
La version courte ne satisfait pas aux besoins du dénoyautage chez un non-spécialiste en carafe.

Watael

je propose awk.

le but est de recueillir des informations; peu importe la méthode, tant que le code respecte les pratiques recommandées (aka best practices).
donc, si sur la ligne de commande, l'une des commandes peut faire ce que font les autres, on privilégie celle-là. donc, awk!!!!!! 😉
peu importe comment, mais pas n'importe comment.

ils vont refaire ce qu'on leur montre.
c'est pourquoi je fustige ceux qui initient au codage en parsant une sortie de ls, parce qu'ensuite les débutants croient que c'est comme ça qu'on parse une liste de fichiers.

Qid

Faut aussi voir les problèmes de compréhension syntaxique des commandes qu'on donne...
Et sur ce point il me semble bien plus facile de faire/comprendre/relire un grep que un awk...

Watael

les deux commandes utilisent la même regex, et il n'y a que la regex à comprendre, avec cet avantage pour awk de pouvoir les appliquer à des champs uniquement.

moko138

Un cas de système à headers manquant : ./viewtopic.php?pid=22029186#p22029186
[center]= =[/center]

Je n'ai jamais rien compris au man d'awk.
Je n'ai pas trouvé ce qu'apportait ici OFS='\t'

man awk
     OFS       inserted between fields on output, initially = " ".

à part contrarier l'alignement des colonnes.

Pour saisir, par contre, l'intérêt de sort -k3,3V il faut le tester non pas sur vos systèmes bien entretenus, mais sur un fichier compilant les embrouilles.(*)
Et là - ô miracle ! - les numéros de version paraissent dans l'ordre

ii  linux-headers-4.4.0-14-generic         4.4.0-14.999          amd64
ii  linux-headers-4.4.0-90-generic         4.4.0-90.999          amd64
iU  linux-image-extra-4.4.0-142-generic    4.4.0-140.168         amd64
iF  linux-image-4.4.0-142-generic          4.4.0-142.168         amd64
ii  linux-tools-euclid                     4.4.0.9029.30         amd64
ii  linux-modules-4.15.0-43-generic        4.15.0-43.46          amd64

À première vue, du moins.

Parce qu'en réalité, l'option -V de sort traite les 0. après les 0- ! Donc sépare des paquets ayant le même numéro de version :

echo; cat noyaux_test.txt | awk '{print $1,$2,$3,$4}' | sort -k3,3V | column -s" " -t

ii  binutils-x86-64-linux-gnu              2.30-21ubuntu1~18.04  amd64
ii  linux-headers-3.13.0-53                3.13.0-53.89          all
ii  linux-headers-3.13.0-150               3.13.0-150.99         all
ii  linux-headers-4.4.0-14-generic         4.4.0-14.999          amd64
ii  linux-headers-4.4.0-90-generic         4.4.0-90.999          amd64
iU  linux-image-extra-4.4.0-142-generic    4.4.0-140.168         amd64
iF  linux-image-4.4.0-142-generic          4.4.0-142.168         amd64
ii  linux-headers-4.4.0-142                4.4.0-142.168         all
ii  linux-headers-4.4.0-142-generic        4.4.0-142.168         amd64
ii  linux-tools-common                     4.4.0-142.168         all
iU  linux-image-extra-4.4.0-142-generic    4.4.0-142.168         amd64
iU  linux-signed-image-4.4.0-142-generic   4.4.0-142.168         amd64
ii  linux-tools-4.4.0-9029-euclid          4.4.0-9029.31         amd64
### Et hop, le tri redémarre à partir de "0." :
ii  linux-image-machin                     4.4.0.43.45           amd64
ii  linux-tools-truc                       4.4.0.43.45           amd64
iU  linux-signed-image-generic             4.4.0.140.148         amd64
ii  linux-headers-generic                  4.4.0.142.148         amd64
iU  linux-generic                          4.4.0.142.148         amd64
iU  linux-image-generic                    4.4.0.142.148         amd64
iU  linux-signed-generic                   4.4.0.142.148         amd64
iU  linux-signed-image-generic             4.4.0.142.148         amd64
rc  linux-signed-nawak-en-r-c              4.4.0.142.148         amd64
ii  linux-tools-euclid                     4.4.0.9029.30         amd64
ii  linux-modules-4.15.0-43-generic        4.15.0-43.46          amd64
ii  linux-modules-extra-4.15.0-43-generic  4.15.0-43.46          amd64

Et ça, dans les méthodes de dénoyautage, ce serait un fâcheux retour en arrière.

/!\ Mais ça permet de définir une prochaine amélioration :
ordonner correctement les numéros de version, tout en gardant l'alignement des colonnes. 🙂

[center]= =[/center]

En tâtonnant, je suis arrivé à rétablir l'alignement :

echo; dpkg -l | awk '$2~/^linux-([ghit]|[lm]o|si)/ && !/^rc/{print $1,$2,$3,$4}' | column -s" " -t | sort -k3 ; echo ; uname -mr

Apparemment, ça marche aussi bien que

echo; dpkg -l | grep -Ei "linux-(g|h|i|lo|mo|si|t)" | grep -Ev "^rc|binutils" | sort -k3 | awk '{print $1,$2,$3,$4}' | column -s" " -t ; echo ; uname -mr

et que

echo; dpkg -l | grep -Ei "linux-(g|h|i|lo|mo|si|t)" | grep -Ev "^rc|binutils" | sort -k3 | tr -s " " | cut -d" " -s -f1,2,3,4 | column -s" " -t ; echo ; uname -mr

qui (à part le binutils) donnait toute satisfaction jusqu'au 19/01/2019

mais je ne sais toujours pas pourquoi l'une des trois vaudrait mieux que les autres.

____
(*) Exemple de fichier compilant des possibilités d'embrouilles, voici mon noyaux-test.txt du moment :

ii  binutils-x86-64-linux-gnu             2.30-21ubuntu1~18.04  amd64
rc  linux-signed-nawak-en-r-c             4.4.0.142.148  amd64
ii  linux-headers-3.13.0-53               3.13.0-53.89   all
iU  linux-generic                         4.4.0.142.148  amd64
iU  linux-signed-generic                  4.4.0.142.148  amd64
ii  linux-headers-generic                 4.4.0.142.148  amd64
iU  linux-image-generic                   4.4.0.142.148  amd64
iU  linux-signed-image-generic            4.4.0.142.148  amd64
ii  linux-headers-4.4.0-142               4.4.0-142.168  all
ii  linux-tools-common                    4.4.0-142.168  all
iU  linux-image-extra-4.4.0-142-generic   4.4.0-142.168  amd64
ii  linux-headers-4.4.0-142-generic       4.4.0-142.168  amd64
iF  linux-image-4.4.0-142-generic         4.4.0-142.168  amd64
iU  linux-signed-image-4.4.0-142-generic  4.4.0-142.168  amd64
ii  linux-tools-euclid                    4.4.0.9029.30  amd64
ii  linux-tools-4.4.0-9029-euclid         4.4.0-9029.31  amd64
ii  linux-headers-4.4.0-14-generic        4.4.0-14.999   amd64
ii  linux-headers-4.4.0-90-generic        4.4.0-90.999   amd64
ii  linux-headers-3.13.0-150              3.13.0-150.99  all
iU  linux-image-extra-4.4.0-142-generic   4.4.0-140.168  amd64
iU  linux-signed-image-generic            4.4.0.140.148  amd64
ii  linux-image-machin                    4.4.0.43.45    amd64
ii  linux-tools-truc                      4.4.0.43.45    amd64
ii  linux-modules-extra-4.15.0-43-generic 4.15.0-43.46   amd64
ii  linux-modules-4.15.0-43-generic       4.15.0-43.46   amd64

moko138

Watael a écrit je propose awk.

le but est de recueillir des informations; peu importe la méthode, tant que le code respecte les pratiques recommandées (aka best practices).
donc, si sur la ligne de commande, l'une des commandes peut faire ce que font les autres, on privilégie celle-là. donc, awk!!!!!! 😉

Tu te comprends, c'est très bien.
Maintenant, peux-tu nous expliquer l'esprit de ce "on privilégie" ? En te mettant à la portée de ceux qui n'ont pas ton savoir ?

[center]= =[/center]

peu importe comment, mais pas n'importe comment.

Ça sonne très bien ! 🙂 Mais qu'est-ce que ça veut dire ?

[center]= =[/center]

Watael a écrit ils vont refaire ce qu'on leur montre.
c'est pourquoi je fustige ceux qui initient au codage en parsant une sortie de ls, parce qu'ensuite les débutants croient que c'est comme ça qu'on parse une liste de fichiers.

Je te remercie d'avoir apporté tes fustigations-maison.
Mais je reste avec mes questions sans réponses :

Qu'est-ce qu'une « commande [qui] se pipe "elle-même" » ?
| grep ceci | grep -v cela ?
Si oui, en quoi est-ce à éviter ?

Et pourquoi nous sors-tu maintenant un "ls" dont il n'a pas été question jusqu'ici ?

Que signifie « en parsant une sortie de ls » ?
Déjà, "parser", j'ai du mal : j'avais demandé jadis, et noté la réponse :

parse veut dire "parcourir", "filtrer"

Est-ce à dire que ls...|grep et ls...|sort bien que marchant, seraient à proscrire ?
Si oui, pourquoi ? (Mais pour éviter le hors-sujet, Watael, merci d'ouvrir un fil).

[center]= =[/center]

Si tu veux bien troquer la badine, empruntée à va savoir qui, pour l'écharpe d'Iris, tu rendras service à tout le monde,
merci !

Watael

quand les aidants ont besoin d'aide :rolleyes:

grep + awk = awk #c'est plus clair ?

awk peut faire ce que fait grep, et plus encore; donc, on n'emploie que awk.
dans le même ordre d'idée, je ne vais pas appeler un programme de regex (grep sed awk...) derrière un parser xml, je sélectionne avec le parseur XML ce que je veux conserver.
je n'utilise pas sed avec awk non plus : les deux peuvent faire la même chose, mais soit je travaille sur des champs (awk) soit sur des lignes.

bon, pour le grep | grep -v, je suis allé un peu vite (c'est vrai) : je n'ai pas prêté attention au -v à cause du awk qui suit, et qui discrédite l'emploi de grep comme je viens de le montrer.
mais j'en vois tellement des grep | grep...

et, oui ls | grep, et pire ls | sort, sont à proscrire.
en général, ça passe, mais des fois pas, donc par prudence on ne le fait pas.
essaye avec un nom de fichier qui contient un passage à la ligne !

nam1962

Un fil type pour moi : https://forum.ubuntu-fr.org/viewtopic.php?id=2037604
- questions basiques quand un comportement est anormal, pour savoir comment l'install est organisée
- précos pour nettoyer et traiter le problème en indiquant ce qui va se passer
- résolution rapide
- alors, oui, l'aidée a appliqué scrupuleusement et pas tout pigé, certaines des commandes sont absconses mais le fil est réutilisable

j'essaie en général

méthode : d'abord s'assurer que la base est saine
simplicité : on pose des questions progressives pour déterminer le problème
pédagogie : le demandeur peut suivre (et les lecteurs ultérieurs aussi)
pérennité : la solution résout et évite que le problème se répète

Sinon, un point fort de Hugo (réflexion sur la refonte du forum) : la possibilité d'indiquer quelle réponse apporte la soluce est un vrai plus : https://forum.manjaro.org/t/swapfile-fstab-solution-systemd-swap-thank-you-all/77654

bruno

Je crois que ce qui manque, en fait, c'est un endroit où regrouper toutes les commandes et scripts utiles pour dépanner. Et où chacun pourrait y proposer des améliorations.

Sur le fil cité par nam1962, je ne vois rien à redire si ce n'est que les commandes proposées devraientt être un tout petit peu plus expliquées. Ici par exemple ./viewtopic.php?pid=22062166#p22062166 :
Nettoyage du dépôt local des paquets :

sudo apt clean

Suppression des résidus de configuration :

dpkg -l | grep ^rc | cut -d' ' -f3 | xargs sudo dpkg -P

nam1962

bruno a écritJe crois que ce qui manque, en fait, c'est un endroit où regrouper toutes les commandes et scripts utiles pour dépanner. Et où chacun pourrait y proposer des améliorations.

(....)

C'est la propal que je réitère !
Créer une page dans la doc, rappelant les principes :

méthode : d'abord s'assurer que la base est saine
simplicité : on pose des questions progressives pour déterminer le problème
pédagogie : le demandeur peut suivre (et les lecteurs ultérieurs aussi)
pérennité : la solution résout et évite que le problème se répète

Et autres trucs de base, par exemple sortir du cercle : quand je vois un problème Teamviewer, je suggère Anydesk ou DWservice, par exemple. Dans le fil Manjaro que j'indique, le pose une question sur /swapfile et les aidants, m'indiquent de la remplacer par systemd-swap, etc...

Puis les commandes courantes (ou les adresses des fils qui traitent de sujets précis, comme le post wifi ou le post de nany)

Ce fil de discussion pouvant servir à indiquer ce qui doit être dans cette doc

Pour l'explication plus détaillée dans un fil, oui, ça dépend aussi du temps qu'on a 😉 )

Mornagest

Salut,

Moins (beaucoup) de temps pour aider sur le forum, mais je profite de ce sujet et de ces derniers messages pour souscrire à la proposition d'une page de doc pour l'aide. Déjà pour les gens qui en ont besoin, et pour ceux qui en proposent.

Je pense qu'il pourrait être intéressant de lister les commandes selon leur utilité : diagnostic (donc aucune altération du système), réparation (système de paquets cassés, par exemple, quoi qu'on fait dans ce cas-là ?), mise à jour, installation de paquets/pilotes en ligne de commandes (notamment les pilotes proprio dont la procédure n'est pas toujours évidente)...

Bref, de classer et expliciter ces commandes pour qu'un néophyte puisse savoir s'il peut utiliser telle ou telle commande sans craindre d'effacer son système ou de foutre le feu au salon.

nam1962

Je plussoie !
Je suis souvent effrayé de voir une aide commençant par "passe :"

sudo apt update 
sudo apt full-upgrade

Quand on ne sait pas si le système ne contient pas du proposed ou des PPA pourris.
Le diagnostic sans altération du système doit être une première priorité !

La dite page de doc pourra également permettre à moindre temps passé, d'expliquer au demandeur ce qui lui arrive (si il en est curieux).

Qid

nam1962 a écritJe plussoie !
Je suis souvent effrayé de voir une aide commençant par "passe :"
sudo apt update 
sudo apt full-upgrade 
Quand on ne sait pas si le système ne contient pas du proposed ou des PPA pourris.
Le diagnostic sans altération du système doit être une première priorité !

Bof... Pas d'accord... Ppa ou autres joyeusetés présents ou pas je refuse de faire un dépannage sur une machine qui n'a potentiellement pas été mise à jour depuis plus d'un mois...

nam1962

Euhhh...
Tu as une idée de ce que fait une mise à jour avec du proposed ou du nilarimogard ?

...eh ben ça t'installe des paquets avec des numéros de version ultérieurs, voire parfois incohérents...
Donc pas rattrapables autrement qu'en les virant/remplaçant un à un car dpkg et apt ne remplacent que des numéros antérieurs ou qu'ils connaissent.
Exemple type : le kernel installé "à la main". Tu peux toujours tenter tous les upgrades que tu veux, même 5 mois après....

Et après, amuse toi à retrouver les paquets/dépendances qui fusillent le système !

Peut-être possible avec

apt-forktracer -v

Mais la mise à jour rallonge ton fil de pas mal de manips (si ne plante pas définitivement le système malade)

Perso, je commence par regarder les sources du problème (ou de soucis ultérieurs) via :

cat /etc/apt/sources.list
ls /etc/apt/sources.list.d -1

(Pour déminer ceusses qui diront que la seconde commande ne montre pas les PPA désactivés : ça permet de savoir si des toxiques avec nomenclature foireuse n'ont pas été utilisés, laissant des scories)

erresse

nam1962 a écrit la possibilité d'indiquer quelle réponse apporte la soluce est un vrai plus

Ma signature incitait déjà à mentionner brièvement la solution finale dans le premier message du sujet, lorsqu'on le passait en résolu. Y indiquer quel message apporte la solution est évidemment ce qu'on peut trouver de plus bref comme mention.
Je dis "bravo", si la solution est apportée par un seul message dans la conversation. Si elle est apparue au fil de plusieurs messages, il serait alors plus simple de synthétiser la solution finale par une mention plus explicite dans ce premier message.
Cela étant, comme chaque message ne peut être édité (et c'est bien normal) que par son rédacteur, il incombe forcément au demandeur de faire cette démarche, l'aidant ne peut guère que l'y inciter...

« Page précédente Page suivante »