Retour de commandes bash vers json/xml

Bonjour à tous, je travail sur une petite app me permettant d'administrer via ssh une ferme de serveur sous ubuntu,
Je souhaite pouvoir automatiser mes commandes sur tout mes serveurs et pour que cela soit plus "facile" à traiter, je voudrai faire passer la sortie des commandes dans un format plus facilement manipulable (json ou xml)

Pour illustrer cela j'utilise très régulièrement la commande "lsof -i -N -P" qui me retourne toutes les connections actives :

Auriez-vous une idée de comment passer d'un "output" classique bash vers un format un peut plus manipulable ? (json, xml ou autres....)

Une autre solution serai de rendre accessible toutes ces informations via une api dédié afin d'éviter tout la surcouche de commande via ssh puis de le traiter manuellement avec des script, si vous avez quelques idées la dessus ... ;)

merci

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME sshd 1306 root 3u IPv4 54161 0t0 TCP *:22 (LISTEN) sshd 1306 root 4u IPv6 54163 0t0 TCP *:22 (LISTEN) apache2 1431 root 4u IPv6 18365 0t0 TCP *:80 (LISTEN) apache2 1435 www-data 4u IPv6 18365 0t0 TCP *:80 (LISTEN) apache2 1436 www-data 4u IPv6 18365 0t0 TCP *:80 (LISTEN) apache2 1437 www-data 4u IPv6 18365 0t0 TCP *:80 (LISTEN) apache2 1438 www-data 4u IPv6 18365 0t0 TCP *:80 (LISTEN) apache2 1439 www-data 4u IPv6 18365 0t0 TCP *:80 (LISTEN) dhclient 5994 root 6u IPv4 59801 0t0 UDP *:68 sshd 6681 root 3u IPv4 65725 0t0 TCP LABOVM.mtromain.local:22->10.0.0.99:38223 (ESTABLISHED) sshd 6683 root 3u IPv4 65732 0t0 TCP LABOVM.mtromain.local:22->10.0.0.99:38224 (ESTABLISHED) sshd 6742 userlabo 3u IPv4 65725 0t0 TCP LABOVM.mtromain.local:22->10.0.0.99:38223 (ESTABLISHED) sshd 6742 userlabo 9u IPv6 65818 0t0 TCP localhost:6010 (LISTEN) sshd 6742 userlabo 10u IPv4 65819 0t0 TCP localhost:6010 (LISTEN) sshd 6750 userlabo 3u IPv4 65732 0t0 TCP LABOVM.mtromain.local:22->10.0.0.99:38224 (ESTABLISHED) sshd 6993 root 3u IPv4 66306 0t0 TCP LABOVM.mtromain.local:22->10.0.0.99:38319 (ESTABLISHED) sshd 7024 userlabo 3u IPv4 66306 0t0 TCP LABOVM.mtromain.local:22->10.0.0.99:38319 (ESTABLISHED)

---

Quelque chose comme :

Code:

---

1 2	lsof -i -N -P | awk ' $2 ~ /[0-9]/ { print "<process>\n\t<name>"$1"</name>\n\t<pid>"$2"</pid>\n</process>" } '

---

super, c'est exactement ce que je cherchais, peux tu m'indiquer comment appel on cela ? Ca me fait penser un peut à du xml mais ca ne correspond pas tout à fait :aie:
Je vais utiliser ton exemple pour le compléter suivant mon besoin, top ;)

Awk est simplement un langage de scripts qui permet de traiter ligne par ligne des documents textes.
L'exemple est fictif mais il est facile de comprendre le mécanisme pour l'adapter.

Bonjour,

reformater un tableau simple et sans ambiguïté vers une format plus complexe et pénible à parser tel que json ou xml... :roll:

Citation:

---

Envoyé par N_BaH

Bonjour,
reformater un tableau simple et sans ambiguïté vers une format plus complexe et pénible à parser tel que json ou xml... :roll:

---

xml et json plus complexe et pénible à parser que un tableau ? O0

Citation:

---

Envoyé par N_BaH

Bonjour,

reformater un tableau simple et sans ambiguïté vers une format plus complexe et pénible à parser tel que json ou xml... :roll:

---

En quoi cette réponse fait avancer cette question ?

Non Le monde ne tourne pas exclusivement autour du shell script ! Il y a énormément de situations au un format différent json/xml ... autre sera plus intéressant qu'un "simple" fichier texte.


Cette sempiternelle bigoterie est particulièrement exaspérante

vous rigolez ?

entre ça :

Code:

---

mon beau tableau roi des tableaux...

---

et

Code:

---

<racine><premièreLigne><premierMot>mon</premierMot></deuxièmeMot>beau</deuxièmeMot>...<niÈmeMot>...</niÈmeMot></premièreLigne></racine><

---

lequel vous semble le plus simple à parser ?

:roll:

vous voulez pas utiliser un SGBD complet pour trois lignes de données ?

Tout dépend de l'utilisation que vous en faite, dire que un tableau est plus simple que utiliser un formatage de données c'est mettre la charrue avant les boeufs ... c'est comme choisir une solution sans connaître la problématique ;)

Dans mon cas l'utilisation de tableau rendrai mon code imbuvable puisque je dois pouvoir réutiliser dans d'autres langage le output de mes commandes bash.

Citation:

---

vous voulez pas utiliser un SGBD complet pour trois lignes de données ?

---

Vous pouvez aussi arrêter les sarcasmes c'est pas super utile dans une discussion ;)

C'est assez comique de voir l'inutilité de votre intervention avec au dessus de votre pseudo "Modérateur", ca donne une super image bravo :roll:
becket c'est donné la peine de me répondre de façon constructive, vous vous contentez de balancer des morceaux de vérité sans démontrer quoi que ce soit, donnez vous la peine d'illustrer votre propos avec un exemple concret en rapport avec ma question. Si il est concluant je vous remercierai de m'avoir indiqué une autre solution moins lourde que celle que j'avais en tête en attendant mieux vaut vous abstenir si c'est simplement pour balancer ca.
Amicalement

et d'autres langages (probablement plus puissant que bash (ce n'est pas difficile)) ne peuvent pas traiter des données dans un tableau simple ?

plutôt que de transformer les données avec awk, traite les données directement avec awk !

quand tu seras modérateur, tu pourras caresser les intervenants dans le sens du poil jusqu'à te renier si tu veux.

Bonjour :coucou:

La meilleure réponse est évidemment la première réponse de becket. J'ai répondu pareil en mon for intérieur.
Mais je soutiens N_BaH quand il dit que la question n'est pas bonne.

J'ai l'impression d'assister à une discussion écologiste entre les partisans de légumes tels quels, et ceux qui veulent des légumes sous emballages. Ces derniers prétendent que c'est plus propre, et les premiers indiquent que cela ne sert à rien de mettre un plastique (->pétrole) superfétatoire. Mon cœur penche pour les légumes tels quels.

L'information, toute l'information, rien que l'information. Le balisage xml ou les séparateurs multiples du format JSON (accolades ouvrantes, fermantes, crochets ouvrants, fermants, les deux points, la virgule) sont compliqués. Pour rien. l'information brute est déjà donnée par la commande lsof elle-même. La seule justification d'un tel reformatage serait une exigence client. Sinon :( c'est une perte de temps. Pour aucun gain de productivité.

Bon. Je vais me mettre sous cellophane pour me protéger de la vague de critique. :mouarf:

On ne peut pas mettre JSON et XML dans le même sac en papier ou en plastique d'amidon (attention, le panier d'osier fait son retour en force). Enfonçons les portes grandes ouvertes de l'AMAP:

• Le JSON est un format léger qui sert exclusivement à la transmission de données. Chaque langage a sa petite fonction ou au pire sa bibliothèque pour l'importer facilement dans une structure de données qui lui est propre. Et ça ne sert qu'à ça.¹
  (Au passage on peut aussi se demander si le CSV n'est pas un meilleur candidat dans le cas présent car encore plus léger que l'original et tout aussi répandu que le format JSON.)
• Par contre le XML, s'il est plus lourd, ouvre plus de perspectives. Ce n'est pas juste un format de données, c'est surtout l'accès à XSD pour valider, XSLT pour transformer, XPath pour trouver, XQuery pour interroger... Ce qu'on peut faire de la même manière dans pratiquement tous les langages et avec de nombreux outils.

On peut raisonnablement se demander l'intérêt de convertir ce tableau au format JSON (CSV même combat) si ce n'est pour éviter trois lignes de code, et tout ça pour aboutir à une structure de données imposée qui ne colle pas forcément à ce qu'on veut en faire et chiante comme la mort à interroger (à grand renfort de boucles). Mais bon parfois on a pas le choix, genre le logiciel qui ne sait importer que ça.

Avec le XML on n'est plus dans la simple transmission de données. On se place d'emblée dans la perspective de l'exploitation des données. De fait, la lourdeur du parsing (que le développeur n'a pas à supporter) devient secondaire.


_{1. Il existe bien l'outil jq pour traiter directement du JSON, ainsi que le langage de requête JSONiq, mais il est très peu diffusé.}

Je prend note de vos remarques ;)

Les formats json et XML sont des formats structurés mais restant lisibles par l'humain (bien que n'étant pas le but premier). Les sorties des commandes systèmes ne sont pas faites pour être retraités bien que tu puisses les envoyer à d'autres commandes via des pipes par exemples.

L’intérêt de "transformer" tes sorties brutes en XML ou autres, c'est de les exploiter avec des outils attendant du XML justement. Je suppose que c'est ce que tu cherches à faire, que l'outil soit de toi ou un produit existant.

Regardes ceci :
https://antoine-solnichkin.developpe...ec-prometheus/
Tu verras qu'il y a des briques te permettant de te faciliter la tâche.

Il existe aussi des produits tout fait répondant à ton besoin.
on
Edit : En gros c'est à toi de récupérer la sortie des commandes et de la mettre au bon format.
Pour le XML, tu peux regarder du coté de XMLStartlet qui va te permettre de manipuler un fichier XML depuis la ligne de commande (non exhaustif, d'autres utilitaires doivent exister), car les commandes de type awk etc tu auras vite fait d'avoir un XML invalide.

Il y a une option spéciale de lsof pour une sortie dans un format facilement traitable par un programme externe sans ambiguïté sur les champs:

Code:

---

man -P'less "+/^OUTPUT FOR OTHER PROGRAMS"' lsof

---