Forum Linux.général Linux dépassé ?

Posté par Sharpshooter le 13 juin 2019 à 08:47. Licence CC By‑SA.

Étiquettes : aucune

juin

2019

Bonjour,

Je suis un vieux linuxien (depuis 1996) mais pour le boulot je dois travailler sous Windows avec Powershell… Et là j'avoue que je me pose des questions.

Avec Powershell, l'univers Windows est devenu complètement cohérent. On peut gérer les fichiers, la base de registre, le cloud ou les certificats de la même façon (lister, créer, copier avec les mêmes commandes). On peut utiliser des fonctions et des objets .Net sans problème.

Et surtout, Powershell est 100% objet. On lance une commande et le résultat est un objet que l'on peut passer en pipe, dont on peut exécuter les fonctions ou lister les variables. On peut boucler sur le résultat d'une commande avec un simple foreach.

Finalement plus j'utilise Powershell et plus je trouve limité les commandes Linux (Bash…) qui retournent du texte qu'il faut détricoter pour récupérer une simple valeur.

Ne trouvez-vous pas que Linux est en train de se faire dépasser par l'environnement Microsoft ? Je ne parle pas simplement de l'aspect objet mais de l'intégration des outils. Par intégration j'entends le fait de travailler avec toutes les couches de l'OS (noyau, FS, certificats, shells, GUI…)

Et quand je vois que Powershell est disponible sous Linux je prends peur !

A force de vouloir rester dans "l'esprit *nix", est-ce que Linux n'est pas en train de devenir une vieillerie dépassée par les futurs OS ?

A quand un shell 100% objet et 100% intégré sous Linux ?

La discussion est ouverte…

# ote moi d'un doute

Posté par mouvda le 13 juin 2019 à 09:14. Évalué à 7.

on est vendredi?

tant va la cruche à l'eau qu'à la fin elle t'explose en pleine tête
- [^] # Re: ote moi d'un doute
  
  Posté par ptit_poulet le 13 juin 2019 à 11:02. Évalué à 5.
  
  Ce qu'il dit est vrai. Je suis dans le même cas que lui.
  
  Au travail c'est environnement 100% Microsoft et gérer tout ça avec PS c'est juste un régal.
  Tout est objet, analyser le résultat d'une commande est carrément simpliste. C'est vraiment un outil très puissant pour faire de l'administration au quotidien sur du 100% Microsoft. Je me développe tous mes outils d'administration en PS, avec ou sans GUI.
  
  PS arrive aussi sur Linux, mais reste assez limité pour le moment, mais progresse très très bien.
  
  Ça ne m'empêche pas d'avoir en perso des serveurs sous Debian car pour faire ce que j'ai à leur faire faire c'est plus adapté. Mais le jour où je peux basculer tous mes scripts en PS je prend :D
  
  Donc non pas de troll du côté de cet utilisateur, juste un vrai constat.
  
  Après on peut se tromper, il existe peut-être la même chose sous Linux. Attention ne pas parler de Python ou autres… C'est une pièce rapportée que ce soit sous Linux ou Windows. Très bon langage mais Là on parle bien d'un langage livré clé en main et parfaitement intégré dans l'écosystème.
# Technologie & Liberté

Posté par chimrod (site web personnel) le 13 juin 2019 à 09:28. Évalué à 9.

— Il s'agit d'un faux problème. Et même de plusieurs faux-problèmes. À la rigueur on peut opposer bash à powershell, mais pas GNU/Linux…

— Tiens ça fait longtemps que je n'ai plus vu cette écriture : GNU/Linux au lieu de Linux… Il y a des trolls qui se perdent

— Ça n'est pas tant un troll que ça, en parlant de GNU/Linux on rappelle deux choses : la première est que Linux ne vient jamais seul mais avec tout un paquet de logiciels qui vont avec, et la seconde est que Linux est associé à la GPL

— Bah oui mais ça n'empêche pas que c'est dépassé par ce qu'on peut voir ailleurs

— Mais ça fait longtemps que ce débat existe ! souvient toi de la révolution Compiz ! On avait enfin un bureau qui pouvait impressionner les maceux, pourtant ça n'a pas empêché Linux de continuer à évoluer

— Il n'empêche, si on regarde ce qui se fait ailleurs, on trouve mieux…

— Et alors ? Demande toi pourquoi tu as choisi de remplacer le système de ton PC par une distribution Linux. Est-ce pour pouvoir faire des captures d'écran de ton bureau et les envoyer sur unixporn, ou est-ce parce que tu souhaites reprendre le contrôle de ton PC…

— Arrête avec ce vieil argumentaire, si on se contentait d'avoir un bureau libre, ma carte graphique se tournerai les pouces pendant que mon CPU chaufferai mon salon

— C'est bien ce que je dis, il faut choisir, avoir un PC sous Linux signifie que tu n'auras jamais les technologies dernier cri, mais c'est un choix à faire

— Bah faut vivre avec son temps, si je t'écoutais je devrais ouvrir un terminal pour monter ma clef USB

— J'ai pas la solution, et je pense qu'elle n'existe pas, mais je t'assure qu'il existe encore des gens pour qui la liberté compte davantage que la technologie.
- [^] # Re: Technologie & Liberté
  
  Posté par Sharpshooter le 13 juin 2019 à 09:52. Évalué à 3.
  
  Sur le plan éthique je suis assez d'accord et je ne remets pas en cause ma préférence pour le libre et pour GNU/Linux.
  
  Mais d'un point de vue pratique je ne voudrais pas que Linux finisse comme BeOS : un environnement certes puissant, pratique, attachant… mais finalement une niche qui n'intéresse que quelques nostalgiques.
  - [^] # Re: Technologie & Liberté
    
    Posté par Lol Zimmerli (site web personnel, Mastodon) le 13 juin 2019 à 10:58. Évalué à 6.
    
    Sur le desktop on peut en discuter mais côté serveur…
    
    La gelée de coings est une chose à ne pas avaler de travers.
    - [^] # Re: Technologie & Liberté
      
      Posté par David Marec (site web personnel) le 13 juin 2019 à 13:37. Évalué à 3.
      
      Sur le desktop on peut en discuter mais côté serveur
      
      Peut-on considérer les smartphones et autres tablettes comme des bureaux ?
  - [^] # Re: Technologie & Liberté
    
    Posté par FantastIX le 13 juin 2019 à 14:27. Évalué à 5.
    
    […] je ne voudrais pas que Linux finisse comme BeOS : un environnement certes puissant, pratique, attachant… mais finalement une niche qui n'intéresse que quelques nostalgiques.
    
    Si par «niche» on entend "ceux qui ont compris en profondeur ce que le mot «liberté» signifie et implique", alors oui, peut-être que GNU/Linux, avec son lot de sacrifices mais aussi de grandes libertés est destiné uniquement à une poignée de gens — il n'y a qu'à voir à quel point il est facile de faire renoncer à ses droits et libertés à un humain pour un peu plus de confort et/ou de sécurité, pour ne citer que ça…
    
    Le jour où GNU/Linux finit comme BeOS, c'est qu'on aura un problème bien plus grand que ça sur les bras.
# Parle-en a Lennart Poettering

Posté par totof2000 le 13 juin 2019 à 11:15. Évalué à 3.

Avec Powershell, l'univers Windows est devenu complètement cohérent. On peut gérer les fichiers, la base de registre, le cloud ou les certificats de la même façon (lister, créer, copier avec les mêmes commandes). On peut utiliser des fonctions et des objets .Net sans problème.

Ya pas de base de registres sous Linux donc gérer la base de registre avec un shell on s'en moque un peu …

Par contre sous Linux ya systemd. Et je suis sur que si tu en touches 2 mots à son inventeur, il trouvera un moyen de recréer un clone de powershell qui te permettrait d'interagir directement avec systemd mais aussi avec toutes le sapplications installées sur tam achine (client sql pour Postgres/mysql.
- [^] # Re: Parle-en a Lennart Poettering
  
  Posté par totof2000 le 13 juin 2019 à 12:41. Évalué à 2.
  
  Pfff. désolé pour les espaces intempestifs. Je ne sais pas ce que j'ai fait en éditant mon message … J'ai voulu aller trop vite.
- [^] # Re: Parle-en a Lennart Poettering
  
  Posté par David Marec (site web personnel) le 13 juin 2019 à 13:33. Évalué à 3.
  
  Par contre sous Linux ya systemd. Et je suis sur que si tu en touches 2 mots à son inventeur
  
  En fait, c'est déjà plus ou moins accessible.
  systemd a lancé une 'mode': Tout est sur DBus.
  
  De fait, nombre d'informations du système se retrouvent sous forme d'objets sur ce bus, avec leurs méthodes et leurs propriétés.
  
  Ya pas de base de registres sous Linux donc gérer la base de registre avec un shell on s'en moque un peu …
  
  D'un autre coté, un nombre considérable d'information se trouve dans /proc, /sys voire dans /dev.
  Il manque peut-être un outil comme xo/libxo de FreeBSD pour modifier la sortie des commandes usuelles.
  
  Le problème est le même qu'avec powershell: connaitre le conteneur et son interface. Si la syntaxe powershell est assez compréhensible,
  - quoique passablement compliquée lorsque l'on veut faire des choses simples -
  savoir quel module/interface donnera les informations requise est loin d'être évident.
  
  Ceci dit, lorsque que l'on doit coder l'accès à une bête information système, c'est sensiblement plus facile de se contenter de lire le contenu de /proc/trucinfo.
# Y a pas que le shell dans la vie

Posté par Benoît Sibaud (site web personnel) le 13 juin 2019 à 11:43. Évalué à 9.

Le shell est pur texte, avec des pipes, et globalement deux états OK / KO.
Les outils de déploiement permettent déjà la même chose et plus : entrées plus structurées, avec une bibliothèque standard définie, renvoyant des états plus structurés (trois états OK / Failed / Changed par exemple, mais aussi des infos liées à chaque état), apportant l'idempotence, etc. Et globalement celui qui utilise le shell peut utiliser ansible par exemple (d'ailleurs il devra se rabattre sur le shell quand ansible n'a pas la fonctionnalité dans sa bibliothèque standard).
Les plus développeurs pourraient d'ailleurs directement utiliser une session interactive python ou n'importe langage de développement pour faire cela (mais ça serait surdimensionné).

Le shell n'est de toute façon pas l'idéal pour faire du json (merci jq) ou du yaml (merci yq) ou du xml ou…
- [^] # Re: Y a pas que le shell dans la vie
  
  Posté par ptit_poulet le 13 juin 2019 à 14:56. Évalué à 0.
  
  Sous Linux je suis d'accord avec toi.
  Mais du coup sous Windows ce n'est pas vrai. L'outil étant un outil Microsoft il fait parti à 100% du système et permet donc d'obtenir toutes les informations que tu souhaites sous la forme de ton choix.
  Aucun soucis pour faire du JSON, XML… sous PS par exemple.
  
  Sous un environnement Windows, SCCM + PS c'est une tuerie. Je ne connais pas assez Ansible pour juger mais sous Windows je ne pense pas qu'il soit aussi abouti que couple SCCM/PS.
- [^] # Re: Y a pas que le shell dans la vie
  
  Posté par Nodeus le 14 juin 2019 à 14:48. Évalué à 1.
  
  Le shell est pur texte, avec des pipes, et globalement deux états OK / KO.
  
  Je croyais qu'on pouvait renvoyer 256 codes retour en shell
  et éventuellement des informations sur la sortie d'erreur.
  
  Il suffit de structurer son script non ?
  
  Je me trompe peut-être ?
  
  Merci de détailler :D
  - [^] # Re: Y a pas que le shell dans la vie
    
    Posté par David Marec (site web personnel) le 14 juin 2019 à 16:04. Évalué à 4.
    Je croyais qu'on pouvait renvoyer 256 codes retour en shell
    
    Oui, sachant que les codes de 126 à 255 sont réservés par le shell lui-même. Ce qui ne vous empêche pas de les utiliser, par ailleurs.
    
    La convention veut juste que l'on retourne 0 en cas de succès.Ce qui donne bien deux états:
    - 0: succès
    - sinon, échec.
    - [^] # Re: Y a pas que le shell dans la vie
      
      Posté par Nodeus le 17 juin 2019 à 19:46. Évalué à 1.
      
      ça fais encore 128 codes utilisable :D
# Bof

Posté par goernil le 13 juin 2019 à 13:08. Évalué à 7.

Pour avoir utilisé un peu le Powershell, je le comparerais plutôt à Python qui doit permettre de faire les mêmes choses.

Le shell historique (bash et co) c'est plutôt proche de CMD.exe
- [^] # Re: Bof
  
  Posté par lolop (site web personnel) le 13 juin 2019 à 13:31. Évalué à 3.
  
  Et en utilisant le module psutils on doit pouvoir faire une couche objet en Python comme ils l'ont fait avec les outils dans PowerShell (jamais compris pourquoi ils avaient créé un nouveau langage alors qu'ils avaient IronPython).
  
  Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
# Python et consort

Posté par MrBidon le 13 juin 2019 à 14:37. Évalué à 7. Dernière modification le 13 juin 2019 à 14:37.

Je ne connais pas le powershell, mais j'ai un principe assez fort lorsque j'écris un script shell "ne jamais s'entêter sur un script bash, si ça ne marche pas au bout de 3 essais passer au python (au autre:))", ma vie en est devenu que plus belle depuis.
# Powershell

Posté par Sharpshooter le 13 juin 2019 à 16:41. Évalué à 0. Dernière modification le 13 juin 2019 à 16:43.

A lire les commentaires je pense que beaucoup ne connaissent pas Powershell (et pour cause !). Il ne s'agit pas seulement d'accéder à des info systèmes ou d'avoir des commandes avancées dans le shell.

Prenons un exemple :

Si je fais un simple
Get-ChildItem -Path .

j'obtiens un tableau contenant tous les fichiers et dossiers du répertoire courant. Ce ne sera pas simplement une liste affichée à l'écran mais un tableau d'objets que je peux mettre dans une variable.
$a = Get-ChildItem -Path .

$a.length()
18

$a.Gettype()
IsPublic IsSerial Name BaseType

True True Object[] System.Array

$a[9].LastAccessTime
jeudi 20 décembre 2018 11:52:04

$a[9].LastAccessTime.DayOfWeek
Thursday

On voit tout de suite la facilité pour scripter un traitement des fichiers quand toutes les propriétés de tous les fichiers sont accessibles via une simple variable.

Bien entendu on peut faire la même chose sous Linux à coup de "ls", "cut" et autres tout comme on peut faire de l'objet avec Python mais c'est toujours un peu bancal et on voit nettement la différence entre du natif et du bricolage.
- [^] # Re: Powershell
  
  Posté par NeoX le 13 juin 2019 à 19:47. Évalué à 5. Dernière modification le 13 juin 2019 à 19:49.
  
  A lire les commentaires je pense que beaucoup ne connaissent pas Powershell (et pour cause !). Il ne s'agit pas seulement d'accéder à des info systèmes ou d'avoir des commandes avancées dans le shell.
  
  comme on peut faire de l'objet avec Python mais c'est toujours un peu bancal et on voit nettement la différence entre du natif et du bricolage.
  
  finalement la force n'est pas dans windows, mais dans le nouveau shell qui a été developpé/publié en 2006.
  
  Heureusement alors pour nous qu'un shell de conception "recente" sache faire plus de chose et mieux qu'un shell imaginé en 1989
  
  soit … 17ans plus tot
  
  Ce n'est donc pas non plus Linux qui est depassé, mais juste bash.
  
  Certains shell ont essayé d'evoluer, mais conserver le fonctionnement sans rien casser n'est pas simple, et on garde donc le coté un peu archaique
  
  Maintenant si bash ne te plait pas, tu peux lancer un autre shell,
  tu cites python mais ce n'est pas le seul
  
  si tu lances python sans option, ca ouvre un prompt, ah tiens comme quand tu lances powershell,
  et ben tu auras toutes la puissance de python à ta disposition,
  mais evidemment python n'est pas le seul shell linux, et heureusement.
- [^] # Re: Powershell
  
  Posté par lolop (site web personnel) le 13 juin 2019 à 22:45. Évalué à 5.
  
  Tu confonds le langage (PowerShell) et les API auxquelles il donne accès sous la forme objet. Ça pourrait être fait dans d'autres langages sans être bancal¹, mais en bénéficiant de la puissance et de l'écosystème de ces autres langages d'utilisation plus générale.
  
  ¹ Si tu construits bien ton API, pourquoi veux-tu que ça soit plus bancal en Python qu'en PowerShell ?
  
  Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
  - [^] # Re: Powershell
    
    Posté par lolop (site web personnel) le 13 juin 2019 à 23:09. Évalué à 3.
    
    En complément, je suis un adepte de Python et le préfère à Ruby pour du code de programme… mais les raisons de cette préférence¹ font de Ruby un candidat qui est je pense plus adapté à un usage de shell que ne l'est Python, dont la syntaxe est plus lourde.
    
    ¹ Ruby permet entre autres l'appel de fonction sans les parenthèses.
    
    Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
- [^] # Re: Powershell
  
  Posté par David Marec (site web personnel) le 14 juin 2019 à 00:34. Évalué à 7. Dernière modification le 14 juin 2019 à 00:34.
  A lire les commentaires je pense que beaucoup ne connaissent pas Powershell
  
  Si. Et le soufflé est retombé très vite.
  
  Si je fais un simple
  Get-ChildItem -Path .
  j'obtiens un tableau contenant tous les fichiers et dossiers du répertoire courant.
  
  J'espère que vous n'allez pas prétendre que c'est intuitif ? Pas plus que:
```
a=( $(ls) )
echo ${#a[@]}
echo ${a[5]}
stat -f %Sa ${a[1]}
```
  On voit tout de suite la facilité pour scripter un traitement des fichiers quand toutes les propriétés de tous les fichiers sont accessibles via une simple variable.
  
  Franchement, non. Car elles ne sont pas accessible si facilement: comme les commandes précédentes sous bash, les API powershell sont assez raides à trouver et à digérer.
  D'autant qu'un autre sérieux problème que j'ai rencontré par le passé sous powershell ne semble pas résolu, une même date se trouve dans votre exemple même exprimée en français puis en anglais. Sans raison.
  - [^] # Re: Powershell
    
    Posté par lolop (site web personnel) le 14 juin 2019 à 10:36. Évalué à 7.
    Un petit test similaire avec l'API standard Python:
```
>>> from pathlib import Path
>>> a = list(Path('.').iterdir())
>>> len(a)
142
>>> type(a)
<class 'list'>
>>> a[9]
PosixPath('Desktop')
>>> a[9].stat().st_atime
1560495647.251184
>>> from datetime import datetime
>>> datetime.fromtimestamp(a[9].stat().st_atime).weekday()
4
```
    Avec la définition de classes ad-hoc, ça pourrait être plus user-friendly (typiquement, que les temps soient retournés sous forme d'objets dont on peut directement appeler des méthodes/attributs, plutôt que de float en secondes unix).
    
    Pour moi la limite à l'usage en tant que shell (le truc que tu lances pour faire rapidement une opération à la console), c'est les éléments de syntaxe genre parenthèses pour les appels de fonction, virgule entre les arguments, quotes obligatoires pour les chaînes, regexp via une lib… par contre je trouve que c'est une force si c'est dans le cadre d'un script shell.
    
    Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
  - [^] # Re: Powershell
    
    Posté par Sharpshooter le 15 juin 2019 à 12:35. Évalué à 1.
    
    Intéressant.
    
    Mais c'est un peu comme si un programmeur C disait "je peux faire la même chose que ce qui se fait en C++, les langages objets ça ne sert à rien !
    
    C'est ce qui se passe d'ailleurs en python. Il y a bien une tentative pour tordre le truc et obtenir de la POO mais ça n'a rien à voir avec un vrai langage objet.
    
    Powershell est un shell objet et je pense que ça manque terriblement sous Linux (même s'il y a des tentatives).
    
    Ce n'est pas tant dans les commandes (qui sont effectivement peu intuitives, lourdes et difficilement lisibles) mais dans les retours de commandes.
    
    La question de mon post d'origine est surtout "est-ce que Linux ne va pas devenir largement dépassé dans les quelques années qui viennent ?
    
    En tant qu'informaticien, linuxien de longue date et Windowsien par obligation je me pose sérieusement des questions.
    - [^] # Re: Powershell
      
      Posté par lolop (site web personnel) le 15 juin 2019 à 13:16. Évalué à 3.
      
      C'est ce qui se passe d'ailleurs en python. Il y a bien une tentative pour tordre le truc et obtenir de la POO mais ça n'a rien à voir avec un vrai langage objet.
      
      Tu peux détailler ?
      
      Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
# Il manque des trucs quand même

Posté par Piervit le 14 juin 2019 à 15:05. Évalué à 3.

Moi aussi je trouve que windows progresse(je ne connais pas PowerShell), en particulier en permettant d'embarquer un linux non-graphique depuis le store.
Pour autant, c'est pour moi du paliatif de pauvre:
- utiliser vim sous windows me semble une plaie (je ne sais pas ce qu'il en ai d'emacs)
- un certain nombre de technos pointus ne me semblent pas fonctionner (facilement) sous windows: Ocaml, Haskell (je ne suis pas sur), la virtualisation (les containeurs)
- [^] # Re: Il manque des trucs quand même
  
  Posté par chimrod (site web personnel) le 14 juin 2019 à 15:47. Évalué à 3.
  
  Pour OCaml, à l'aide du dépôt ocaml for windows, les problèmes se sont grandement réduits
# Commentaire supprimé

Posté par drec le 18 juin 2019 à 12:23. Évalué à -2. Dernière modification le 18 juin 2019 à 15:26.

Ce commentaire a été supprimé par l’équipe de modération.
# Un marronnier ?

Posté par ookaze le 02 juillet 2019 à 16:47. Évalué à 1.

Cela fait plus de 10 ans que je n’avais pas entendu cette question.
À l’époque, PowerShell venait de sortir, et mes détracteurs sous Windows venaient me dire que c’était super PowerShell, que c’était 100 fois mieux que le shell sous Linux.
Je ne voyais pas en quoi ce truc compliqué était plus efficace pour le boulot d’un administrateur système. Mais bon, ils m’annonçaient déjà la mort de Linux à l’époque aussi, et le fait qu’il était dépassé. Finalement, plus de 10 ans après, mon intuition était la bonne et c’est plutôt le PowerShell qui est complètement inadapté et inutile face à un bash, à tel point que c’est MS qui doit émuler les API système Linux sur son OS serveur pour utiliser bash plutôt que PS.
Pire encore, le PowerShell n’a même pas pris le pas sur des Python ou même le Javascript (via Node.js ou autre), qui a complètement détruit le moindre intérêt que pouvait avoir le PowerShell (prototypage, outil rapide en langage interprété).
Est-ce que cette question est un marronnier annuel sorti par les jeunes qui débutent et ne comprennent rien aux enjeux de ces différents outils informatiques ?
Déjà à l’époque je pensais qu’il fallait avoir zéro expérience et peu de compréhension de l’informatique pour dire des bêtises pareilles (c’était le cas de tous les power user Windows que je connaissais, ils ne comprenaient rien), alors imaginez aujourd’hui.

En général mon intuition ne me trompe pas en informatique donc je lui fais entièrement confiance, comme quand j’ai découvert Linux en 1991 (en pensant que ça allait tout bouffer) ou systemd à ses débuts (en pensant que ça allait tout bouffer, alors que je cherchais depuis des mois un remplaçant à simpleinit-msb que je maintenais tout seul). C’est pourquoi à l’époque j’ai fini par dire « on verra qui avait raison dans quelques années ». Et on a vu. Mais apparemment, il y a des gens aujourd’hui qui croient que tout le monde découvre le produit en même temps qu’eux. Je ne comprends pas cette façon de penser, les gens ont perdu la notion du temps qui passe ? Ils ne comprennent plus qu’un produit sorti il y a plus de 10 ans ne se comporte pas comme s’il venait de sortir et que sa pertinence a eu le temps d'être validée ou non ?
# structured data

Posté par steph1978 le 03 juillet 2019 à 15:24. Évalué à 3.

Ton message me rappelle une initiative pour faire évoluer les commandes GNU afin qu'elles manipulent du XML au lieu de text brut. Je n'ai pas remis la main sur l'article.. J'imagine que aujourd’hui on proposerait plutôt du JSON.

J'en convient, il est quelque fois fastidieux de parsemer ses scripts de grep truc | cut -d, -f 12 pour extraire la donnée voulu pour la suite du traitement.

Mais l'enjeu est de trouver un format qui soit le plus universelle possible - qui soit à la fois utilisable par un programme et par un être humain. J'imagine que le format de PS est un format binaire en mémoire ; ça doit très bien marcher mais ce n'est pas interopérable.

Je rejoints les commentaires qui disent que quand cela devient trop compliqué en shell, il faut passer à un autre langage : awk puis python dans mon cas.

Le langage shell doit se limiter à ce pour quoi il est prévu : enchaîner des commandes avec quelques variations selon le statut de sortie.
- [^] # Re: structured data
  
  Posté par steph1978 le 03 juillet 2019 à 22:13. Évalué à 2.
  
  Je n'ai pas remis la main sur l'article..
  
  j'ai quand même trouvé ça : xml-coreutils.
- [^] # Re: structured data
  
  Posté par NeoX le 04 juillet 2019 à 21:36. Évalué à 2.
  
  Mais l'enjeu est de trouver un format qui soit le plus universelle possible
  
  avant pour debug un programme tu faisais un
  tail -f /var/log/messages
  et tu lancais le programme
  
  pour debugger plus loin tu faisais
  tail -f /var/log/messages | grep tonprogramme | grep tonmessage
  
  pour trouver toutes les occurences de tonprogramme contenant tonmessage, en temps réel, pendant que ton programme tourne…
  
  maintenant avec systemd et journalctl
  il faut faire un journalctl -xn .... pour avoir une sortie formatée
  sinon on accede à rien
  
  (note j'ai pas testé toutes les options de systemctl non plus)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.