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

discussion sur les pratiques des aidants

erresse

Finalement, au fil de ce sujet, il apparaît (ce dont on doutait d'ailleurs pas) qu'il existe une méga-chiée de commandes diverses et variées que l'on peut modeler à coup de filtres, de paramètres et d'options pour obtenir le résultat souhaité...

Comment voulez-vous faire un "pense-bête" des commandes utiles avec une telle richesse en stock ?

C'est bien pour cela que chaque aidant va proposer telle ou telle commande en fonction de ce qu'il cherche à obtenir comme information, et ce sera différent pour chaque personne ou chaque problème abordé, parce-que tout le monde n'a pas le même schéma de pensée pour établir son diagnostic, mais l'objectif reste le même : tenter de dépanner celui qui est venu réclamer de l'aide.

Bien sûr, le forum est à la disposition de tous pour y rechercher des informations sur un problème peut-être déjà débattu, mais ce n'est pas un cours d'enseignement de programmation ou d'apprentissage des commandes bash...
Entre un dépannage d'une situation complexe inattendue et un exercice bien bordé d'apprentissage, il y a quand même un monde, ne pensez-vous pas ?

Qu'un utilisateur, même avisé sans être expert, utilise une session de dépannage de son propre problème comme une formation pour pouvoir comprendre et réutiliser ultérieurement les commandes qui lui auront été suggérées me paraît assez douteux.
Certes, on apprend de ses erreurs, parfois même aussi de celles des autres, mais il faut une démarche un tant soit peu pédagogique pour pouvoir comprendre et assimiler ces notions.

[supprimé]

erresse a écritComment voulez-vous faire un "pense-bête" des commandes utiles avec une telle richesse en stock ?

Haha 🙂 --> https://forum.ubuntu-fr.org/viewtopic.php?pid=22062303#p22062303

Watael

erresse a écritcelui qui est venu réclamer de l'aide

celui-là, je ne l'ai[md]e pas.
je n'aide que celui qui demande, et poliment en plus. 🙂

bruno

eresse a écritEntre un dépannage d'une situation complexe inattendue et un exercice bien bordé d'apprentissage, il y a quand même un monde, ne pensez-vous pas ?

Dans la mesure où les situations complexes et inattendues sont dues à 99% aux mauvaises manipulations des utilisateurs, l'exercice d'apprentissage me paraît être un corollaire inévitable. 😉

erresse

@bruno: Tout informaticien sait pertinemment que dans 99% des cas, l'erreur se trouve entre la chaise et le clavier ! :lol:
Toutefois, depuis quelques années que je traîne sur ce forum, jamais un utilisateur ne m'a demandé : Veux-tu me former au dépannage de ma machine qui présente "tel problème" ?
Lorsque je donne une commande à exécuter au demandeur, jamais l'un d'eux ne me demande : Peux-tu m'expliquer ce que fait cette commande, comment fonctionne-t-elle et quelles infos fournit-elle ?
Je ne refuserais certes pas de fournir toutes les informations et même formations tout court (pour autant que je maîtrise moi-même le sujet), si les personnes me le demandaient, mais ce n'est simplement jamais arrivé...
Attention ! Je parle là, dans les cas où je proposais mon aide pour dépanner la personne.
Il va de soi que, lorsque le "problème" consiste en une incompréhension du fonctionnement d'une application, ou d'une commande, bien sûr que la pédagogie s'impose !
On va alors expliquer en détail la manipulation ou le fonctionnement de l'application ou de la commande.
Mais dans ce cas, je ne considère pas cette intervention comme un dépannage, tout simplement.

maxire

@naziel, en réponse à https://forum.ubuntu-fr.org/viewtopic.php?pid=22062891#p22062891?
Si c'est tout de même un peu gếnant car tu peux économiser un grep et rendre la commande plus compréhensible en faisant ;

bionic@k72f-J48-ubgnome:~$ echo; dpkg-query -l linux-generic* linux-headers* linux-image* linux-lowlatency* linux-modules* linux-signed* linux-tools* | grep -Ev "^rc|^un" ; echo ; echo "Noyau courant : $(uname -mr)"

dpkg-query: aucun paquet ne correspond à linux-generic*
dpkg-query: aucun paquet ne correspond à linux-lowlatency*
dpkg-query: aucun paquet ne correspond à linux-signed*
Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder
| État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements
|/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais)
||/ Nom                                    Version      Architecture Description
+++-======================================-============-============-===============================================================
ii  linux-image-4.15.0-43-generic          4.15.0-43.46 amd64        Signed kernel image generic
ii  linux-image-4.15.0-44-generic          4.15.0-44.47 amd64        Signed kernel image generic
ii  linux-image-4.15.0-45-generic          4.15.0-45.48 amd64        Signed kernel image generic
ii  linux-image-generic                    4.15.0.45.47 amd64        Generic Linux kernel image
ii  linux-modules-4.15.0-43-generic        4.15.0-43.46 amd64        Linux kernel extra modules for version 4.15.0 on 64 bit x86 SMP
ii  linux-modules-4.15.0-44-generic        4.15.0-44.47 amd64        Linux kernel extra modules for version 4.15.0 on 64 bit x86 SMP
ii  linux-modules-4.15.0-45-generic        4.15.0-45.48 amd64        Linux kernel extra modules for version 4.15.0 on 64 bit x86 SMP
ii  linux-modules-extra-4.15.0-44-generic  4.15.0-44.47 amd64        Linux kernel extra modules for version 4.15.0 on 64 bit x86 SMP
ii  linux-modules-extra-4.15.0-45-generic  4.15.0-45.48 amd64        Linux kernel extra modules for version 4.15.0 on 64 bit x86 SMP

Noyau courant : 4.15.0-45-generic x86_64
bionic@k72f-J48-ubgnome:~$

À noter que je ne vois pas trop l'intérêt du sort -k 3 et de la suppression de la 4ème colonne via awk, de plus dans le cas du traitement du cas«Partition /boot pleine», s'intéresser aux paquets n'installant rien dans cette partiton comme linux-headers* ou linux-modules* (j'avoue ne pas savoir ce que font les paquets linux-tools*) me semble superflu.
Ces paquets sont supposés disparaître lors de la suppression du noyau correspondant ou lors d'une opération autoremove postérieure.

diesel

diesel83140 a écritÇa, je sais

mount | grep -Ei "emmc|hd|nvme|sd" | sed -E -e 's/type.*//' -e 's/.* on //'

Et comme tu n'utilises pas d'expressions régulières

mount | grep -Ei "emmc|hd|nvme|sd" | sed -e 's/type.*//' -e 's/.* on //'

marche aussi bien.

Amicalement.

Jean-Marie

On peut même faire mieux (même si j'ai mis un moment pour élaborer la bonne syntaxe)

mount | grep -Ei "emmc|hd|nvme|sd" | sed -E 's/(^.*on | type.*)//g'

La subtilité qui m'a bloquée pendant un bon moment est que, dans la mesure où, sur une ligne, il y a deux remplacements, il faut bien évidemment le "g" à la fin.

Amicalement.

Jean-Marie

nam1962

erresse a écrit(...)
Lorsque je donne une commande à exécuter au demandeur, jamais l'un d'eux ne me demande : Peux-tu m'expliquer ce que fait cette commande, comment fonctionne-t-elle et quelles infos fournit-elle ?
Je ne refuserais certes pas de fournir toutes les informations et même formations tout court (pour autant que je maîtrise moi-même le sujet), si les personnes me le demandaient, mais ce n'est simplement jamais arrivé...
(...)

Tu rigoles ? --> https://forum.ubuntu-fr.org/viewtopic.php?pid=22059173#p22059173

Nuliel

J'avoue avoir un peu perdu le fil... du fil. Je ne réponds à aucun message en particulier mais je donne mon avis sur le tout en prenant un exemple.
sort -k 3 doit servir à trier selon les noyaux afin de voir si les noyaux sont entièrement installés
awk sert sûrement à éviter ce problème

naziel@naziel-HP-desktop:~$ echo; dpkg -l | grep -Ei "linux-(g|h|i|lo|mo|si|t)" | grep -v ^rc | sort -k3 | column -s" " -t

ii  binutils-x86-64-linux-gnu              2.30-21ubuntu1~18.04  amd64  GNU       binary   utilities,  for       x86-64-linux-gnu  target
ii  linux-headers-4.15.0-34                4.15.0-34.37          all    Header    files    related     to        Linux             kernel   version  4.15.0
ii  linux-headers-4.15.0-34-generic        4.15.0-34.37          amd64  Linux     kernel   headers     for       version           4.15.0   on       64         bit           x86       SMP
ii  linux-headers-4.15.0-44                4.15.0-44.47          all    Header    files    related     to        Linux             kernel   version  4.15.0
ii  linux-modules-4.15.0-44-generic        4.15.0-44.47          amd64  Linux     kernel   extra       modules   for               version  4.15.0   on         64            bit       x86  SMP
ii  linux-modules-extra-4.15.0-44-generic  4.15.0-44.47          amd64  Linux     kernel   extra       modules   for               version  4.15.0   on         64            bit       x86  SMP
ii  linux-headers-4.15.0-44-generic        4.15.0-44.47          amd64  Linux     kernel   headers     for       version           4.15.0   on       64         bit           x86       SMP
ii  linux-tools-4.15.0-44                  4.15.0-44.47          amd64  Linux     kernel   version     specific  tools             for      version  4.15.0-44
ii  linux-tools-4.15.0-44-generic          4.15.0-44.47          amd64  Linux     kernel   version     specific  tools             for      version  4.15.0-44
ii  linux-image-4.15.0-44-generic          4.15.0-44.47          amd64  Signed    kernel   image       generic
ii  linux-generic                          4.15.0.45.47          amd64  Complete  Generic  Linux       kernel    and               headers
ii  linux-signed-generic                   4.15.0.45.47          amd64  Complete  Signed   Generic     Linux     kernel            and      headers  (dummy     transitional  package)
ii  linux-headers-generic                  4.15.0.45.47          amd64  Generic   Linux    kernel      headers
ii  linux-image-generic                    4.15.0.45.47          amd64  Generic   Linux    kernel      image
ii  linux-tools-generic                    4.15.0.45.47          amd64  Generic   Linux    kernel      tools
ii  linux-headers-4.15.0-45                4.15.0-45.48          all    Header    files    related     to        Linux             kernel   version  4.15.0
ii  linux-tools-common                     4.15.0-45.48          all    Linux     kernel   version     specific  tools             for      version  4.15.0
ii  linux-modules-4.15.0-45-generic        4.15.0-45.48          amd64  Linux     kernel   extra       modules   for               version  4.15.0   on         64            bit       x86  SMP
ii  linux-modules-extra-4.15.0-45-generic  4.15.0-45.48          amd64  Linux     kernel   extra       modules   for               version  4.15.0   on         64            bit       x86  SMP
ii  linux-headers-4.15.0-45-generic        4.15.0-45.48          amd64  Linux     kernel   headers     for       version           4.15.0   on       64         bit           x86       SMP
ii  linux-tools-4.15.0-45                  4.15.0-45.48          amd64  Linux     kernel   version     specific  tools             for      version  4.15.0-45
ii  linux-tools-4.15.0-45-generic          4.15.0-45.48          amd64  Linux     kernel   version     specific  tools             for      version  4.15.0-45
ii  linux-image-4.15.0-45-generic          4.15.0-45.48          amd64  Signed    kernel   image       generic
naziel@naziel-HP-desktop:~$

diesel

C'est pas pour moi.

Il s'agissait d'un aparté sur la simplification d'un enchaînement de commandes sed.

Amicalement.

Jean-Marie

Watael

mount | grep -Ei "emmc|hd|nvme|sd" | sed -E 's/(^.*on | type.*)//g'

grrr !!!

mount | sed -rE '/emmc|hd|nvme|sd/Is/(^.*on | type.*)//g'

moko138

Ben non :

mount | sed -rE '/emmc|hd|nvme|sd/Is/(^.*on | type.*)//g'
Utilisation: sed [OPTION]... {script-seulement-si-pas-d'autre-script}
[fichier-d'entrée]...

  -n, --quiet, --silent
                 supprimer l'écriture automatique de l'espace des motifs
(...)
Si aucune option -e, --expression, -f ou --file n'est donnée, le
premier argument qui n'est pas une option sera pris comme étant le script
sed à interpréter. Tous les arguments restants sont les noms des fichiers
d'entrée; si aucun fichier d'entrée n'est spécifiée, l'entrée standard
est lue.

Et, enchâssé dans
ls -lat $( ) | head
ça donne, au mieux, le home.

Alors que

mount | sed -e '/^\//!d' -e 's/type.*//' -e 's/.* on //'

ls -lat $(mount | tail -1 | sed -e '/^\//!d' -e 's/type.*//' -e 's/.* on //') | head

Variante :

mount | grep -Ei "emmc|hd|nvme|sd" | sed -E 's/(^.*on | type.*)//g'

ls -lat $(mount | tail -1 | grep -Ei "emmc|hd|nvme|sd" | sed -E 's/(^.*on | type.*)//g') | head

font parfaitement le boulot espéré.

Watael

oops.
il y a des trucs qui ne sont pas passés à la recopie, ou j'ai édité sans valider les modifs...
il fallait lire :

mount | sed -rn '/emmc|hd|nvme|sd/Is/(^.*on | type.*)//gp'

d'ailleurs, -r et -E sont la même option : -E, -r, --regexp-extended

les voitures, ça déplace des gens, mais c'est dégueulasse.
le nucléaire, ça éclaire les gens, mais c'est dégueulasse.
« ça fait le boulot », mais c'est dégueulasse.

diesel

On s'éloigne un peu du sujet, quoi que...

Votre débat pointe une différence de philosophie entre vous deux.

L'un prône la concision (le minimum de commandes), l'autre la simplicité de chaque commande prise individuellement.

A titre personnel, je préfère la deuxième façon de faire qui est tout à fait dans la ligne de l'approche KISS d'UNIX (et je ne vois pas trop ce qu'elle a de "dégueulasse").

Une fois qu'on a compris le principe du pipe (le résultat de la commande précédente passé en entrée de la commande suivante. Même un débutant est capable de le comprendre), il est très facile de suivre la logique du traitement.

Alors que, comprendre instantanément "/emmc|hd|nvme|sd/Is/(^.*on | type.*)//gp", moi, je n'y arrive pas (il me faut au moins un petit tour dans le man de sed ou regex pour comprendre).

Amicalement.

Jean-Marie

Qid

Merci Jean Marie... La facilité de lecture pour se rendre accessible/compréhensible c'est quand-même pas mal... Je redis ce que quelqu'un a déjà dit ici mais que j'entends perso aussi IRL : avec des commandes certes qui font ce qu'on veut mais qui sont incompréhensible facilement Linux restera pour la majeur partie des gens un système pour les élites développeur... Alors que c'est tout autant si ce n'est plus un système grand public que les 2 autres grand gourou du secteur...

bruno

D'accord avec diesel83140 et Qid.
Il vaut mieux éviter de proposer des commandes complexes en première intention et les réserver aux cas les plus difficiles après un minimum d'investigation à l'aide de questions et commandes simples.
D'autant que ces commandes avec quantités de filtres à coup d'expressions régulières peuvent vite montrer leur limites :

$ mount | sed -rn '/emmc|hd|nvme|sd/Is/(^.*on | type.*)//gp'
/
/sys/fs/cgroup/unified
/home

Autre exemple où en plus on ne voit pas / :

# mount | sed -rn '/emmc|hd|nvme|sd/Is/(^.*on | type.*)//gp'
/sys/fs/cgroup/unified
/proc/fs/nfsd
/srv

Watael

quand le médecin me fait une ordonnance de deux pages, j'ai l'impression que j'ai quelque chose de grave.

diesel

Watael a écritquand le médecin me fait une ordonnance de deux pages, j'ai l'impression que j'ai quelque chose de grave.

Je suis aussi d'accord avec toi sur ce point (voir le début du sujet).

Cependant, pour reprendre ton analogie du médecin ; quand il emploie des mots plus compliqué que "bobo" ou "rhume", j'ai aussi l'impression d'avoir quelque chose de grave.

Amicalement.

Jean-Marie

nam1962

diesel83140 a écrit(...)

Cependant, pour reprendre ton analogie du médecin ; quand il emploie des mots plus compliqué que "bobo" ou "rhume", j'ai aussi l'impression d'avoir quelque chose de grave.
(...)

Il est clair que si il te sort : "vous avez une lésion traumatique superficielle de type bénin et un catarrhe de l'arbre respiratoire supérieur d'origine virale associé à un coryza aigu", tu vas direct modifier ton testament chez ton notaire !

[supprimé]

Je vous propose d'ici la fin de la semaine que je publie un git pour regrouper toutes vos commandes. L'objectif sera d'avoir un .bashrc avec les aliases standard et formalisé à tout le monde. À voir aussi de l'intégrer à la doc.

« Page précédente Page suivante »