Journal Lister les programmes installés sur un (ou plusieurs) poste(s) sous Windows (XP ou 7)

Posté par Marotte ⛧ le 03 juillet 2013 à 15:03. Licence CC By‑SA.

Étiquettes :

juil.

2013

Introduction

Le PowerShell vous devez grave kiffer ça ici ! Nan j'déconne… Mais voilà, moi j'apprends. Alors d'une part je voudrais bien connaître votre avis sur ce langage et d'autre part vous faire partager un petit script (c'est mon deuxième script en PowerShell !), ça pourrait servir à quelqu'un, qui sait…

La demande

Connaître la liste des programmes installés sur plusieurs postes de notre parc (je précise que je ne suis pas moi-même à la gestion de parc) qui tournent sous Windows.

Ma motivation

Cette demande a en fait été adressée à l'un de mes collègues. Il n'aime pas trop demander de l'aide et il a l'air plutôt fier qu'on lui ait confié cette mission. Quand je l'ai vu faire des copies d'écran de la fenêtre de dialogue « Programmes et fonctionnalités » du panneau de configuration et ouvrir un tableur Excel j'ai retenu un face palm, j'ai fermé ma gueule et je me suis demandé comment faire cela de manière plus automatique. La demande ne concernant que 5 postes je me suis dit que je pouvais le laisser se débrouiller, ça l'a bien occupé…

Les solutions existantes

Et bien en fait il n'y a pas vraiment de solution rapide et élégante, genre un dpkg -l |grep ^ii |grep -v "^ii lib" mais ça je m'en doutais, on est sous Windows après tout… Il y a bien la ligne de commande suivante :

wmic product get name,version

C'est sexy comme commande ?! Non ? Moi je trouve que si. Bon…

Ça peut même nous cracher une liste en HTML mais malheureusement ça ne liste que les programmes installés à l'aide d'un package MSI.

Après une recherche sur le web il apparaît que la meilleure méthode est d'aller lire deux clés dans le registre, allons y gaiment !

Mon script

$ErrorActionPreference= 'silentlycontinue'

if ($Args) { $Computer = $Args } else { $Computer = "hostname1","hostname2" }

function list_reg_to_csv ($C,$RG)
{

 $myobjs = @()
 $RemoteRegistry = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey("LocalMachine",$C)   
 $RegKey = $RemoteRegistry.OpenSubKey($RG)   
 foreach($key in $RegKey.GetSubKeyNames())   
  {   
    $SubKey = $RegKey.OpenSubKey($key)   
    $myobj = "" | Select-Object DisplayName,Version,Publisher,InstallLocation,InstallDate,InstallSource,EstimatedSize,URLInfoAbout,Contact,Comments
    $myobj.DisplayName = $SubKey.GetValue("DisplayName")   
    $myobj.Version = $SubKey.GetValue("DisplayVersion")   
    $myobj.Publisher = $SubKey.GetValue("Publisher")
    $myobj.InstallLocation = $SubKey.GetValue("InstallLocation")
    $myobj.InstallDate = $SubKey.GetValue("InstallDate")
    $myobj.InstallSource = $SubKey.GetValue("InstallSource")
    $myobj.EstimatedSize = $SubKey.GetValue("EstimatedSize")
    $myobj.URLInfoAbout = $SubKey.GetValue("URLInfoAbout")
    $myobj.Contact = $SubKey.GetValue("Contact")
    $myobj.Comments = $SubKey.GetValue("Comments")
    $myobjs += $myobj
  }
 return $myobjs
}

foreach ($H in $Computer)
 {
  if (-Not (Test-Connection -quiet $H))
   { 
     echo "Host $H is down."
     continue
   }
    else  
     {
      echo "Getting list of installed software products on host $H"
      $output = @()
      $output += list_reg_to_csv $H "SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall"
      $output += list_reg_to_csv $H "SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall"
      # $date = date -format yyyyMMdd-hhmm
      $filename = $H+".csv"
      $output | Export-Csv -NoTypeInformation -encoding Unicode -Delimiter ";" $filename
    }
 }

Le script s'utilise ainsi : softlist.ps1 [ <hostname1>, <hostname2>, … ] et il génère un fichier CSV par machine dans le répertoire depuis lequel il est lancé. Si on n'indique pas d'hôte ce sont une paire d'hôtes codés en dur qui sont utilisés.

Alors des fois, bien que l'hôte soit UP ça ne fonctionne pas (accès refusé), il faut encore virer les lignes vides (correspondant à des clés vides, des programmes qui ne sont manifestement plus installés mais qui laissent des traces dans le registre, ça se fait bien en virant les doublons dans Excel) mais dans l'ensemble c'est assez pratique. Et si un jour on nous demande de le faire sur d'autre postes j'ai un truc à proposer.

Peut-être que d'autre ici sauront me proposer une meilleure solution ou des améliorations possibles.

Merci pour votre attention.

PS : Je comptais poster dans le forum mais en fait non, je fais un nourjal tiens !

# Commentaire supprimé

Posté par Anonyme le 03 juillet 2013 à 15:36. Évalué à 10.

Ce commentaire a été supprimé par l’équipe de modération.
- [^] # Re: Problème DNS
  
  Posté par Marotte ⛧ le 03 juillet 2013 à 16:06. Évalué à 10.
  
  Roo putain ! Moi c'est l'inverse, c'est pour ça que j'ai posté au mauvais endroit ! >.<
  - [^] # Re: Problème DNS
    
    Posté par Misc (site web personnel) le 03 juillet 2013 à 16:16. Évalué à 9.
    
    Pourquoi ça parle de windows, c'est encore un journal de kadalka, tu abuses :p ?
# hop hop

Posté par Thomas Debesse (site web personnel) le 03 juillet 2013 à 15:40. Évalué à 10. Dernière modification le 03 juillet 2013 à 15:41.
Ça va peut-être moinsser sévère, mais j'ai trouvé ton journal intéressant… c'est parfois sympathique de changer de sujet ! Après une suite de journaux Steam/Espionnage/Intel/GNU\/linux/Libreoffice, ça exerce la curiosité !

Tout de même, le PowerShell je trouve ça un peu verbeux… ça semble plus se ranger sur le plan d'un python que d'un bash : y a une grande bibliothèque de fonctions disponibles en objet, mais on est obligé d'écrire 10 lignes là où l'écosystème GNU fournit un binaire tout prêt juste pour cette tâche.

Par exemple hier je cherchais un équivalent à wget dans les outils Microsoft, j'ai trouvé au détour de la toile le code PowerShell suivant :
```
param($url, $filename)
$client = new-object System.Net.WebClient 
$client.DownloadFile( $url, $filename)
```
À utiliser ainsi :
```
powershell Set-ExecutionPolicy Unrestricted
powershell -ExecutionPolicy RemoteSigned -File "download.ps1" "http://somewhere.com/filename.ext" "d:\f
```
Ben à coté d'un wget ou d'un curl saycompliquay !

Les gars du PowerShell nous on vanté un shell surpuissant… en oubliant ceux qui utilisent le shell comme interface utilisateur et pas seulement comme une interface de programmation…

ce commentaire est sous licence cc by 4 et précédentes
- [^] # Re: hop hop
  
  Posté par Marotte ⛧ le 03 juillet 2013 à 16:24. Évalué à 9.
  
  c'est parfois sympathique de changer de sujet !
  
  Et puis je suis convaincu que parmi tous les libristes présents ici je dois être loin d'être le seul à devoir continuer à toucher à du Windows pour gagner sa croûte.
  
  Merci pour l'exemple de l'équivalent à wget. Je suis de plus en plus convaincu que Microsoft (comme IBM ou d'autre d'ailleurs) fait exprès de rendre assez difficile l'utilisation de ses outils pour vendre de la formation et justifier le prix de ses certifications !
  
  Heureusement que quand on a quelque chose à scripter rapidement sous Windows on a Cygwin (ou encore la possibilité d'installer les outils UNIX comme grep ou wget seuls (et find !!)) quand on a pas le temps de se pencher sur PowerShell. Ou encore mintty ou mRemoteNG quand on veut un émulateur de terminal potable.
  
  Je n'ai pas encore mis trop les mains dedans mais je dois dire que certains trucs sont quand même mieux foutus que dans cmd.exe, je pense au formatage d'une date par exemple. L'aide aussi à l'air plus claire mais je me demande si, comme pour celle de cmd.exe, il n'y a pas toutes des options non référencées dans l'aide…
  
  Les gars du PowerShell nous on vanté un shell surpuissant… en oubliant ceux qui utilisent le shell comme interface utilisateur et pas seulement comme une interface de programmation…
  
  C'est sûr que c'est plus pour programmer que pour utiliser ce « shell » de manière interactive. Perso j'aurais du mal sous Windows sans bash pour ça.
- [^] # Re: hop hop
  
  Posté par ckyl le 03 juillet 2013 à 16:54. Évalué à 3. Dernière modification le 03 juillet 2013 à 16:55.
  
  Le problème c'est qu'on programme vite avec l'interface utilisateur et que ca devient rapidement n'importe quoi. Des mecs capables d'écrire des trucs robustes et pas imbitables en sh franchement y'en a pas des masses. Le sh est resté de la prog des années 70.
  
  Franchement dès que tu arrêtes de faire deux trucs à l'arrache, virer le sh pour le remplacer par quelque chose de moins masochiste c'est très bien. Il y a encore du travail à faire mais des modules comme sh vont dans le bon sens. Tu réutilises ce qui fait la force d'Unix en arrêtant de faire des trucs dégueulasses.
  
  Maintenant je suis d'accord avec toi. Les deux besoins existent et le compromis n'est pas facile à trouver. Mais en fait tu ne me semble pas critiquer powershell mais juste que ca manque de block qui font ce que tu veux.
  - [^] # Re: hop hop
    
    Posté par barmic le 03 juillet 2013 à 20:10. Évalué à 5.
    
    Des mecs capables d'écrire des trucs robustes et pas imbitables en sh franchement y'en a pas des masses.
    
    Je me demande si c'est vraiment que c'est imbitable ou si c'est juste que la plupart des gens utilisent très peu leur shell, s'en content et imaginent maîtriser le shell.
    
    Dis autrement si on pense le bash comme un langage apparentière et qu'on se laisse autant de temps pour l'apprendre que du C est-ce qu'on se dira vraiment que la plupart des scripts sont imbitables ? J'ai vraiment l'impression que ça vient la plupart du temps de fonctionnalités peu ou mal connues.
    
    Maintenant je suis d'accord avec toi. Les deux besoins existent et le compromis n'est pas facile à trouver. Mais en fait tu ne me semble pas critiquer powershell mais juste que ca manque de block qui font ce que tu veux.
    
    Ce qui est moins amusant c'est que pour faire ce bloc, tu as un choix limité powershell, C#, VB.Net et les langages de l'environnement .Net. Qui sont des langages moins connus dans nos contrés (alors que l'inverse utiliser du code C# dans mon terminal, j'ai aucun problème pour le faire).
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    - [^] # Re: hop hop
      
      Posté par J Avd le 03 juillet 2013 à 20:49. Évalué à 8.
      
      le bash comme un langage apparentière
      
      Apparentier, non ?
      
      Ok je ---->[]
      
      Ps: désolé mais celle ci pique bien les yeux…
      
      "Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"
      - [^] # Re: hop hop
        
        Posté par barmic le 03 juillet 2013 à 20:54. Évalué à 2.
        
        Tu as tout à fait raison et je la fait presque systématiquement…
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    - [^] # Re: hop hop
      
      Posté par ckyl le 03 juillet 2013 à 23:06. Évalué à 3.
      
      Dis autrement si on pense le bash comme un langage apparentière et qu'on se laisse autant de temps pour l'apprendre que du C est-ce qu'on se dira vraiment que la plupart des scripts sont imbitables ?
      
      Oui.
      
      Autant c'est génial pour faire des trucs crados vite fait à base de pipe, autant c'est la plaie pour tout le reste que ce soit à l'écriture, à la relecture, à la maintenance ou au test.
      
      Encore aujourd'hui j'avais un script tout con à écrire: tu récupères la sortie de hadoop fs -ls sur deux clusters, et tu transferts tous les fichiers manquant vers la destination over ssh. En gros tu fais une différence de set, et tu gères proprement si la connexion tombe, que tu ^C ou autre etc. Si tu veux on compare la facilité et la lisibilité les deux implémentations à fonctionnalité égale pour un truc aussi con. En sh tu vas bidouiller comme un cochon pour faire un bête set.difference().
      
      Franchement y'a encore du boulot, mais peaufiner les alternatives type process en Scala, sh en python et certainement beaucoup d'autres pour amener l'élégance du shell sur les cas simples tout en ayant en vrai outil entre les mains pour gérer toute la logique autour des pipes et fork/exec franchement ca ferait du bien.
      - [^] # Re: hop hop
        
        Posté par flan (site web personnel) le 04 juillet 2013 à 00:01. Évalué à 0.
        
        Tiens, je ne serais donc pas tout seul à penser qu'il serait temps de réinventer le shell ?
        
        Il y a beaucoup de choses bien en ligne de commande, mais je trouve qu'il faudrait vraiment remettre un coup de jeune par dessus.
        
        je trouve aberrant de devoir faire du awk, sed, grep, … dès qu'on veut récupérer juste un morceau de résultat (alors que ça se fait naturellement en powershell avec sa représentation objet)
        
        que le programme adapte sa sortie en fonction de ce qu'il sait du périphérique de sortie (console directe avec couleur ou fichier sans couleur), c'est moche. Ça devrait être au périphérique de sortie de rendre correctement la sortie
        
        pourquoi deux sorties seulement ? au final, on voit fréquemment l'usage de stderr utilisé comme stdout secondaire, quand on a deux types de sorties
        
        c'est tout de même très malpratique d'avoir stdout et stderr mélangés par défaut sur un terminal…
        
        je n'évoquerai même pas l'autocomplétion qui doit être connue du terminal (au lieu d'être fournie uniquement par le programme)
        
        Au final, je trouve la tentative de PowerShell plutôt intéressante (au moins pour le peu que j'en sache), mais pas assez utilisable (à cause de ces commandes trop longues) pour être vraiment réussie.
        
        [^] # Re: hop hop
        
        Posté par barmic le 04 juillet 2013 à 00:44. Évalué à 5.
        
        je trouve aberrant de devoir faire du awk, sed, grep, … dès qu'on veut récupérer juste un morceau de résultat (alors que ça se fait naturellement en powershell avec sa représentation objet)
        
        C'est bien ce que je dis. Faudrait se pencher sur ce que fait bash (voir zsh) avant d'affirmer qu'il ne fait rien, car dans un grand nombre de cas ces commandes ne sont plus utiles (man bas/man zshall sont des mines d'or).
        
        que le programme adapte sa sortie en fonction de ce qu'il sait du périphérique de sortie (console directe avec couleur ou fichier sans couleur), c'est moche. Ça devrait être au périphérique de sortie de rendre correctement la sortie
        
        C'est de cas que je vois assez rarement et qui sont du fait d'un --color=auto.
        
        pourquoi deux sorties seulement ? au final, on voit fréquemment l'usage de stderr utilisé comme stdout secondaire, quand on a deux types de sorties
        
        Tu as le droit à autant de sorties (et d'entrées) que tu le souhaite, les pipe només sont là pour ça.
        
        c'est tout de même très malpratique d'avoir stdout et stderr mélangés par défaut sur un terminal…
        
        Bof ça ne change pas grand chose quand tu fais du scripting.
        
        je n'évoquerai même pas l'autocomplétion qui doit être connue du terminal (au lieu d'être fournie uniquement par le programme)
        
        zsh est capable de déduire au moins une part de l'auto complétion si la commande est un peu standard (si je me souviens bien il faut que la sortie de cmd -h ou --help soit formatée d'une certaine façon). C'est implémenté comme avec powershell ?
        
        Au final, je trouve la tentative de PowerShell plutôt intéressante (au moins pour le peu que j'en sache),
        
        Moi aussi. J'aime bien l'idée de l'objet ça permet certaines simplicité (tout en restant fiable) quand à la manipulation de données. Mais je suis d'un autre coté gêné par le blocage sur .Net, il me semble que c'est un gap dommageable, mais qu'il n'est pas possible d'avoir l'un sans l'autre (une sémantique objet sans avoir un VM et devoir se limiter aux langages de celle-ci).
        
        mais pas assez utilisable (à cause de ces commandes trop longues) pour être vraiment réussie.
        
        Les commandes en elles-même sont plus longues mais ont des alias par défaut que tu peut changer si tu veux (on est d'accord ça ne change pas la taille des options à rallonge).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: hop hop
        
        Posté par daeldir le 04 juillet 2013 à 01:58. Évalué à 2.
        
        C'est implémenté comme avec powershell ?
        
        « C'est implémenté comment avec powershell ? » plutôt ? (ta question de base a du sens, mais est tellement « restrictive » que j'ai du mal à savoir si c'est pas une typo…)
        
        Moi, ça me fait penser à AppleScript (que j'ai utilisé petit). Le système arrivait à « deviner » les interfaces pour interagir avec les logiciels… C'était géré par le toolkit, je pense (On utilise une classe qui fait du copier/coller ? L'application va exporter cette possibilité.). Il y avait sûrement une intervention des programmeurs, aussi, bien sûr, pour certaines fonctionnalités, mais même Baldur's Gate avait quelques fonctions exportées (et je crois pas que les gars qui ont fait le portage aient prit la peine de les implémenter, surtout vu le peu de fonctions fournies, je pencherais plus pour de « l'automatique »).
        
        De ce que je lis sur Wikipédia (et je m'aventure sur un terrain que je ne connais absolument pas, en espérant que pBpG va venir préciser ou réparer mes erreurs), les applications peuvent exposer des fonctionnalités au PowerShell. Ça doit vouloir dire qu'à ce moment, le développeur définit une fonctionnalité, avec la doc associée, et PowerShell peut interroger l'appli (d'une manière standard bien définie par Microsoft, pas de manière anarchique comme la sortie de commande --help) pour afficher l'aide ou interagir.
        
        Une autre solution, si ça fonctionne de pair avec .net, serait que PowerShell inspecte les classes de l'application (comme on pourrait le faire avec Python).
        
        Je balance tout ça sans rien savoir (je précise), parce que je suis curieux du fonctionnement réel (mais pas assez pour aller chercher les infos correctement). Si quelqu'un sait déjà comment ça marche, il est bienvenu pour confirmer/démentir mes suppositions. Sinon, je vivrait dans l'ignorance jusqu'à avoir besoin de savoir (et si ça vient vite, je répondrais moi même à mes supposition ici, pour la postérité, mais il y a peu de chances, je n'utilise pas Windows).
        
        [^] # Re: hop hop
        
        Posté par pasBill pasGates le 04 juillet 2013 à 02:23. Évalué à 1.
        
        http://msdn.microsoft.com/en-us/library/windows/desktop/ms714395(v=vs.85).aspx
        
        Une "commande" powershell est un cmdlet, n'importe qui peut les ecrire, ils s'ecrivent en .net et derivent d'une classe parente nommee… cmdlet.
        
        L'utilisateur ecrit tout ce dont il a besoin la dedans : il definit les parametres, fait ce qu'il faut pour arriver a resultat(il peut faire des connections reseau, lire la registry, faire des appels DCOM, interpreter un parameter en ligne de commande comme etant un script dans un langage donne, invoquer des poupees voodoo etc…), et retourne un objet qui contient le resultat.
        
        Oh, et un truc bien sympa dans Powershell, il permet de tirer parti de toute l'infrastructure asynchrone presente dans .NET :
        Tu veux la liste de tous les softs installes sur toutes les machines du reseau, ben pas besoin que le script fasse une machine après l'autre, il peut faire les requetes en asynchrones sur toutes les machines, les resultats arrivent quand ils arrivent et il suffit de faire un 'wait' a la fin sur tous les resultats pour avoir le resultat final. Ca amenera le resultat enormement plus vite qu'un script qui fait une machine après l'autre. Bonne chance pour faire un truc pareil en bash/tcsh…
        
        [^] # Re: hop hop
        
        Posté par daeldir le 04 juillet 2013 à 04:05. Évalué à 2.
        
        Bonne chance pour faire un truc pareil en bash/tcsh…
        
        Euh… Avec ssh, & et wait ?¹ ²
        
        L'intérêt que je vois à PowerShell (et que je trouve proche de AppleScript, du coup), c'est qu'on peut avoir accès aux fonctionnalités d'une application qui n'est pas en ligne de commande. On pourrait par exemple scripter Firefox avec ça. Un équivalent sur linux serait possible si on avait un shell qui parlait de manière intégrée avec DBUS, non ?
        
        Avec un logiciel vraiment conçu « à la Unix », la question ne se poserait pas : tout serait en ligne de commande, et les interfaces graphiques seraient juste des interfaces qui pilotent un outil en ligne de commande par dessous (comme wicd le fait encore de nos jours). Mais je crois que si on a abandonné ce système, c'est que c'était pas efficace :-) (du coup, sur Linux, on doit choisir… CLI ou GUI)
        
        ¹ : Pour reprendre la commande de Barret Michel, ça donnerait un truc du genre :
        
        (for host in $(cat tout_mes_hosts.txt); do ssh -f $host dpkg -l; done; wait) | awk '$1~/ii/ && $2!~/^lib/'
        
        Bien sûr, à ce niveau, on préférera mettre en forme :
        
        get_installed_on(){ for host in $@; do ssh -f $host dpkg -l done wait } format_output(){ awk '$1~/ii/ && $2!~/^lib/' } get_installed_on $(cat tout_mes_hosts.txt) | format_output
        
        Pas testé, mais ça devrait faire l'affaire… (un habitué du shell corrigera, j'ai beau utiliser régulièrement, je fais rarement des trucs très compliqués)
        
        ² : du coup, c'est pas un bon exemple, plutôt dû à la méconnaissance du programme. Et PowerShell comme Unix sont tout les deux des programmes qui demandent de l'apprentissage, pas « intuitifs », donc à ce niveau, ils se valent, je pense (à moins de regarder la qualité de la doc, bien sûr, mais on n'est plus dans les fonctionnalités à ce moment…).
        
        [^] # Re: hop hop
        
        Posté par pasBill pasGates le 04 juillet 2013 à 06:49. Évalué à 3.
        
        Ben justement non…
        
        Avec Powershell, tout cela est implemente avec un threadpool, dans un processus, t'as un nombre limite de threads cree, tout est propre.
        La methode de lancer un ssh par machine, sur un reseau de 5000 machines par exemple (et 5000 c'est vraiment pas enorme, surtout avec la manie d'aujourd'hui de virtualiser tout et n'importe quoi), ca te cree … 5000 processus !
        Ca te met la machine a genoux tout de suite, parce que ces 5000 processus il faut leur allouer de la RAM, rien que la stack prend 2mb par thread par defaut sur Linux x86(en tout cas Redhat). Et c'est sans compter le fait que tu n'as aucun moyen de savoir lequel des processus s'est rate sans faire une tambouille bien sale alors qu'avec Powershell t'as un systeme de retour d'erreur bien propre pour chaque tache cree.
        
        Resultat, avec bash/tcsh, il faut te taper la gestion en batch a la main, faut te trouver un moyen de retourner les erreurs pour chaque processus plutot que le dernier comme wait le fait, … bref, c'est le bordel.
        
        [^] # Re: hop hop
        
        Posté par barmic le 04 juillet 2013 à 09:06. Évalué à 4.
        
        Tu as raison, c'est un cas où j'aurais plutôt envie d'utiliser un logiciel spécifique comme ansible ou fabric (mais avec ce dernier on utilise plus de shell).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: hop hop
        
        Posté par barmic le 04 juillet 2013 à 09:17. Évalué à 2.
        
        Je suis entrain de regarder c'est assez intéressant, il y a un paquet de paramètre ressources par défaut qui répondent à la plupart des cas d'usage. Je n'ai pas trouvé comment s'en créer mais je ne doute pas que ce soit faisable pour faire des choses de tordus comme récupérer la liste des possibilités sur internet.
        
        Du coup PowerShell récupère ça comment ? Les CmdLet sont des programmes à part entière ou bien il s'agit de simples classes qui sont lancées par le shell (et alors je présume qu'il récupère les arguments depuis leur déclaration dans les annotations) ?
        
        La contrainte c'est que c'est en vase clos. Il faut rester dans l'univers .Net pour que ça fonctionne ou écrire des wrappers .Net. Il me semble, mais c'est probablement une question d'habitude, qu'il est plus simple d'écrire un script d'autocomplétion pour mon zsh qu'un wrapper VB.Net ou C#.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: hop hop
        
        Posté par pasBill pasGates le 04 juillet 2013 à 09:38. Évalué à 2.
        
        Ce sont des classes, qui se trouvent dans une "assembly" (l'equivalent d'une librairie en .NET en gros).
        
        Il y a 2 manieres pour Powershell de les retrouver :
        a) Registration, tu peux "enregistrer" l'assembly, ce qui fait que Powershell saura quels cmdlet sont dans quelle assembly
        b) Tu utilises "Import-Module" qui charge dynamiquement une assembly contenant des cmdlet. Powershell v3 rend les choses encore plus simples car il importe automatiquement tous les modules qui se trouvent dans le path qu'il a
        
        Pour le vase clos, tu peux toujours lancer des softs non-cmdlet, simplement ce qu'ils retournent ne sera pas structure.
        
        [^] # Re: hop hop
        
        Posté par barmic le 04 juillet 2013 à 09:07. Évalué à 2.
        
        « C'est implémenté comment avec powershell ? » plutôt ? (ta question de base a du sens, mais est tellement « restrictive » que j'ai du mal à savoir si c'est pas une typo…)
        
        Si si c'est bien une typo.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
      - [^] # Re: hop hop
        
        Posté par zebra3 le 04 juillet 2013 à 09:21. Évalué à 2.
        
        Autant c'est génial pour faire des trucs crados vite fait à base de pipe, autant c'est la plaie pour tout le reste que ce soit à l'écriture, à la relecture, à la maintenance ou au test.
        
        Je suis bien d'accord. J'écris de plus en plus de scripts en Python y compris par des tâches système, parce que j'avais à les reprendre bien plus facilement par la suite.
        
        Après, il est vrai qu'il est possible d'écrire des scripts bash très propres, mais il est tellement facile de coder à l'arraché que coder proprement demande plus de réflexion et de temps.
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
      - [^] # Re: hop hop
        
        Posté par fearan le 04 juillet 2013 à 17:14. Évalué à 5.
        
        En sh tu vas bidouiller comme un cochon pour faire un bête set.difference()
        
        facile ;)
        
        join set2.sorted -v set1.sorted
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: hop hop
        
        Posté par ckyl le 04 juillet 2013 à 18:32. Évalué à 3.
        
        C'est exactement ce qu'on appelle bidouiller comme un cochon quand tu accumules toutes les étapes (sort vers fichier x2 vers join) que tu dois faire pour un truc aussi simple ;)
        
        Pour prendre l'exemple le plus défavorable au shell tu peux comparer avec:
        
        from sh import ssh def get_files(env, prefix, pattern): files = set() for line in ssh(env, "hadoop fs -ls %s/%s" % (prefix, pattern), _iter=True): fname = get_fname(line) if fname: files.add(fname) return files src_files = get_files_on("prod", src_prefix, pattern) dst_files = get_files_on("rec" , dst_prefix, pattern) files_to_upload = src_files.difference(dst_files)
        
        (je fais exprès de n'utiliser aucun idiome du langage choisi car ca ne me semble pas être le sujet)
        
        Là on est dans le cas simple où on ne gère rien. En pratique dans get_fname t'as trois lignes de code (qui vont te demander X pipes grep/awk/sed/cut & variable substitution pour arriver au même résultat), tu vas aussi gérer que si le répertoire n'existe pas la commande se termine en erreur et faut que tu te comportes comme un set vide etc.
        
        Tu peux très bien le faire en shell. Je sais le faire sans problème et je sais très bien reconnaitre la force des pipes textuels (je passe mes journées à analyser des gros gros fichiers textes). Maintenant regarde le temps que ca te prendre à écrire pour que ca juste marche et que ca soit relu par quelqu'un d'autre c'est vite vu. Le shell comme langage te force aux acrobaties et introduit énormément de bruit pour faire des choses simples en dehors des pipes et conditionnelles simples, bref la glue dont tu as besoin.
        
        Si tu ajoutes à ca que les admins codent de plus en plus par le DevOps et qu'ils commencent à savoir programmer des trucs pas trop crado dans des langages modernes (ou la sélection naturelle va bien finir par s'opérer). La question de la pertinence du Shell comme langage de prog pour les scripts aujourd'hui se pose beaucoup je trouve.
        
        C'est un peu comme les regex ou l'élégance en prog fonctionnelle. Ce sont des outils puissants et la recherche de la solution est intellectuellement satisfaisante. Maintenant on veut des trucs qui marchent, qui évoluent facilement, qui se testent et qui pourront être lu et compris rapidement dans X mois. Donc on réfléchi au meilleur outil pour le job.
        
        [^] # Re: hop hop
        
        Posté par barmic le 04 juillet 2013 à 19:59. Évalué à 4.
        
        C'est exactement ce qu'on appelle bidouiller comme un cochon quand tu accumules toutes les étapes (sort vers fichier x2 vers join) que tu dois faire pour un truc aussi simple ;)
        
        Va falloir expliquer clairement ce que vous entendez par bidouiller, parce que je ne vois pas ce qu'il y a de si moche que ça à faire :
        
        tmpdir="$(mktemp -d)" ssh "${host1}" "hadoop fs -ls ${host1}/${patern1}" > "${tmpdir}/${host1}" ssh "${host2}" "hadoop fs -ls ${host2}/${patern2}" > "${tmpdir}/${host2}" join "${tmpdir}/${host1}" -v "${tmpdir}/${host2}" rm -rf "${tmpdir}"
        
        Oui ça ne pas tout (comme le tiens) mais en en quoi c'est plus du bidouillage que ton code ?
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: hop hop
        
        Posté par ckyl le 04 juillet 2013 à 21:14. Évalué à 2.
        
        T'as oublié le sort en sortie du ssh
        
        La syntaxe c'est join -v 2 file1 file2
        
        Rajoute le traitement en sortie du ssh tu vas soit te retrouver avec un pipe de 10 elements et finir par te demander ce que ca fait ou comment modulariser tout ca, soit lire stdout en bash et puis tout rebalancer dans un fichier (gestion des espaces toujours cool, pas error prone partout etc.)
        
        Fais une typo dans un nom de variable ou fais une connerie type PREFIX_$var_SUFFIX et tu vas debuger pendant trois plombes ou fracasser un truc (je bosse avec des fichiers de plusieurs centaines de Go la typo fait vite mal…)
        
        Ton script il va continuer comme un bourrin si y'a une erreur et c'est comme ca que les drames arrivent. La gestion d'erreur c'est l'enfer en bash
        
        On peut continuer longtemps comme ca
        
        Bref tu as du code pas expressif du tout, une gestion d'erreur à chier et non triviale, vraiment pas grand chose à ta disposition sans contortions. On parle pauvre set la hein, tu vois si je script c'est pour faire des tâches.
        
        Je vois pas l'intêret de se priver d'un environemment moins hostile combinant un langage moderne avec la puissance, la souplesse et la performance des outils UNIX + flux textes… Passer mon temps à réinventer la roue en passant par 5 commandes et 3 fichiers, intestables, pour faire des trucs triviaux j'ai franchement mieux à faire.
        
        Après rien n'est tout rose des deux côtés. Mais on a vite fait de s'enfermer dans ce qu'on a appris sans voir les autres opportunités qui existent. Dès qu'on sort de son prompt, je trouve que ca vaut vraiment le coup de se demander si c'est vraiment du shell qu'on veut faire, en voyant à court et long terme.
        
        [^] # Re: hop hop
        
        Posté par barmic le 04 juillet 2013 à 22:06. Évalué à 5.
        
        Dommage que tu utilise un temps condescendant comme ça mais bon.
        
        Je pense que l'expressivité dans ce cas est réellement une histoire d'expérience. Dans ton script je ne sais pas ce que font la méthode get_fname par exemple.
        
        C'est nettement moins concis, alors que je trouve qu'en shell avec pipe, tu as tes traitements qui sont découpés et tu lis ton algo. Pour moi ça c'est un peu comme si tu reprochais au C++ d'avoir des templates compliqués, ça fait parti du langage et ça apporte beaucoup de choses.
        
        Pour la typo sur les noms de variables c'est bizarre d'en parler et d'expliquer que python c'est mieux parce qu'en effet c'est un peu mieux, mais si tu te rate uniquement sur une écriture intermédiaire dans ta variable tu est tout aussi mal. Pour les erreurs ça ce gère plutôt bien au pire avec set -e, mais aussi une bonne partie des erreurs que tu dois gérer manuellement avec d'autres langages (ou via des bibliothèques pour les rendre de très haut niveau) sont directement géré en shell, la gestion des ressources (la fermeture des fichiers par exemple) est gérée de base, etc
        
        Mais on a vite fait de s'enfermer dans ce qu'on a appris sans voir les autres opportunités qui existent.
        
        Je script en bourne shell, bash (en utilisant les spécifités qui vont avec), zsh (en utilisant les spécifités qui vont avec), perl, python et awk de temps en temps (je parle bien de awk sans passer par un shell). Bien sûr je ne les utilise pas tous tous les jours, mais j'ai dans ma besace des scripts avec chacun des ces langages. Je ne crois pas m'enfermer dans l'un ou l'autre de ces langages, j'ai mes préférences bien sûr, mais je n'hésite pas à sortir le man (ou la doc en ligne pour python) parce que je ne crois pas avoir fait le tour du moindre de ces langages (bourn shell peut être mais les binutils non).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: hop hop
        
        Posté par ckyl le 05 juillet 2013 à 00:56. Évalué à 3.
        
        Dommage que tu utilise un temps condescendant comme ça mais bon.
        
        Ce n'était pas mon intention. J'espère que depuis le temps, tu sais que si je parle de quelque chose c'est que je pense que l'échange est intéressant.
        
        Dans ton script je ne sais pas ce que font la méthode get_fname par exemple.
        
        Je l'ai volontairement omis. C'est une méthode qui se débrouille pour m'extraire ce dont j'ai besoin (ou rien) d'une ligne. Typiquement en shell tu ferais ca extrayant le dernier champs (awk) et tu traiterait ce champ pour virer un prefix et quelques autres règle métier pourries (plus chiant en shell ca).
        
        C'est nettement moins concis, alors que je trouve qu'en shell avec pipe, tu as tes traitements qui sont découpés et tu lis ton algo.
        
        Je ne considère plus la concision comme une bonne métrique, surtout pas en ce basant sur du code "facile". La facilité, lisibilité, la maintenance et la sécurité sont pour moi bien plus important.
        
        Tu retrouves avec les pipes les mêmes problème que quand tu joues en fonctionnel sur des collections. C'est itératif à développer, c'est plaisant mais tu as vite fait de faire des trucs imbitables à postériori. Il faut être vigilant
        
        Pour la typo sur les noms de variables c'est bizarre d'en parler et d'expliquer que python c'est mieux parce qu'en effet c'est un peu mieux, mais si tu te rate uniquement sur une écriture intermédiaire dans ta variable tu est tout aussi mal
        
        Je ne milite absolument pas pour Python et j'aimerai laisser de côté cela, je m'en suis servi comme exemple. L'idée c'est que tu as des langages mieux designé que le shell, avec des environnements de dev beaucoup mieux fourni et évolués. Pourquoi ne pas chercher à leur permettre de faire élégamment ce que tu fais avec des scripts shell. Il y a tout a y gagner. Tu gardes les mêmes fonctionnalité en te libérant de beaucoup de contraintes.
        
        Pour ton point précis, l'interpréteur Python sera beaucoup moins tolérant aux erreurs, et l'environnement t'apporte une plus grand sureté (IDE qui t'insulte, facilité à écrire des tests etc.). Mais comme j'ai dit, ce n'est qu'un exemple. J'aurais pu l'écrire avec autre chose, chaque choix à ses faiblesses.
        
        la gestion des ressources (la fermeture des fichiers par exemple) est gérée de base, etc
        
        Pour les mêmes opérations c'est la même chose. Si tu veux faire un pipe ou écrire dans un fichier, aucune raison de faire autre chose. Maintenant si je veux des set, je préfère utiliser un objet plutôt que de m'emmerder à jouer avec 4 commandes par ce qu'il n'y a pas mieux. Bref le but c'est que tu ne perde "rien" mais que tu gagnes beaucoup de choses.
        
        Tout le travail est d'exporter des API propre dans les autres langages. Par exemple en Scala
        
        val fname = "/tmp/uname" "uname -a" #| "sed s/Linux/Lunix/" #> new File(fname) #&& s"cat $fname" !
        
        Si a un endroit je pense qu'il faut mieux faire un traitement moi même plutôt que le déléguer à un outil je peux le faire très facilement. Il n'est pas question de remplacer l'un par l'autre.
        
        [^] # Re: hop hop
        
        Posté par barmic le 05 juillet 2013 à 08:15. Évalué à 3.
        
        Je pense qu'on est globalement d'accord. On a juste place juste pas au même endroit la limite entre ce qui doit être fait dans un langage ou dans un autre.
        
        Dommage que tu utilise un temps condescendant comme ça mais bon.
        
        Ce n'était pas mon intention. J'espère que depuis le temps, tu sais que si je parle de quelque chose c'est que je pense que l'échange est intéressant.
        
        T'inquiète pas c'était juste une remarque rapide. Je ne m'arrête pas à ça.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: hop hop
        
        Posté par fearan le 04 juillet 2013 à 20:06. Évalué à 7.
        
        lst_src=$(mktemp -u) mkfifo $lst_src lst_dst=$(mktemp -u) mkfifo $lst_dst ssh prod "hadoop fs -ls $SRC_PREFIX/$PATERN" | sort | $lst_src & ssh rec "hadoop fs -ls $SRC_PREFIX/$PATERN" | sort | $lst_dst & files_to_upload=$( join lst_src -v lst_dst ) rm $lst_src $lst_dst
        
        et encore ce n'est qu'une solution, tu peux aussi avoir une fonction qui te crée le pipe et te renvoie son nom (genre mkfifotemp)
        
        tu peux aussi faire une fonction qui va te renvoyer le pipe
        
        si tu veux éviter de passer par du mkfifo ou des descripteur de fichiers tu peux aussi utiliser la commande
        
        join <(cmd1) -v <(cmd2)
        
        ce qui te donnerai un
        
        recupLstFile(){ ssh $1 "hadoop fs -ls $2/$3" | sort } files_to_upload=$( join <(recupLstFile("prod", $PREFIX, $PATERN ) -v \ <(recupLstFile("rec", $PREFIX, $PATERN ) )
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
      - [^] # Re: hop hop
        
        Posté par groumly le 04 juillet 2013 à 23:17. Évalué à 2.
        
        A l'heure de chef (ou puppet, je suis pas sectaire) et ruby (ou python, je suis toujours pas sectaire), yen a encore qui sont suffisament malades pour utiliser bash/zsh/tcsh/whatever pour de l'admin systeme?
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: hop hop
        
        Posté par barmic le 04 juillet 2013 à 23:52. Évalué à 3.
        
        Ça dépend, je ne suis pas administrateur système de profession. Pour les quelques serveurs au quels il m'arrivent de toucher j'utilise plutôt fabric (même j'aimerais bien essayer ansible). Je fais du script pour des tâches d'administration local, pour résoudre tout un tas de problèmes récurent dans mon utilisation de l'ordinateur et un peu d'un point de vu professionnel pour analyser des logs et pour du code pour le client.
        
        Bref il n'y a pas que l'administration système dans la vie.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: hop hop
        
        Posté par Olivier Serve (site web personnel) le 08 juillet 2013 à 12:32. Évalué à 4.
        
        Ça arrive qu'on demande à faire un script sur une machine de prod AIX sans python ni ruby, oui. Et pas de puppet/chef/whatever. Tu as du ksh ou du perl.
        
        [^] # Re: hop hop
        
        Posté par lasher le 11 juillet 2013 à 01:08. Évalué à 4.
        
        Donc tu as Perl. Donc tout va bien. :)
        
        [^] # Re: hop hop
        
        Posté par Olivier Serve (site web personnel) le 11 juillet 2013 à 12:52. Évalué à 1.
        
        Euh oui, on peut voir ça comme ça… :-)
- [^] # Re: hop hop
  
  Posté par pasBill pasGates le 03 juillet 2013 à 19:32. Évalué à 9.
  Ben non… (Powershell v3) :
```
Invoke-WebRequest http://www.google.com/
```
  Ensuite… tu veux juste le contenu plutot que les headers ?
```
(Invoke-WebRequest 'http://www.google.com').Content
```
  Le titre seulement peut-etre ?
```
(Invoke-WebRequest 'http://www.google.com').ParsedHtml.title
```
  etc… Pour chaque exemple que tu me trouves plus complexe en powershell, je t'en trouves un plus complexe en shell unix…
  
  Sinon, tu m'expliqueras l'usage de tes 2 dernieres lignes, si tu es dans la console powershell tu n'en as pas besoin.
  - [^] # Re: hop hop
    
    Posté par Thomas Debesse (site web personnel) le 03 juillet 2013 à 19:51. Évalué à 6.
    
    label 1: Il faut croire que ce type de connaissance n'est pas vraiment partagée. ^^
    
    Pour les dernières lignes, c'est juste si tu fais un script, parce que c'est cool d'avoir plein de petits programmes pour chaque tâche.
    
    Note: je ne suis pas l'auteur de ce code, c'est un exemple de ce que je trouve quand je cherche.
    Donc si le code est mauvais, cela ne veut pas dire que je code mal, ça veut dire que soit je cherche mal, soit l'information n'est pas accessible facilement ^goto 1 …
    
    ce commentaire est sous licence cc by 4 et précédentes
  - [^] # Re: hop hop
    
    Posté par barmic le 03 juillet 2013 à 20:21. Évalué à 3.
    
    Je crois qu'il existe des sorte d'alias pour ce genre de commande, non ? (moi ej me suis jamais servi de PowerShell)
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    - [^] # Re: hop hop
      
      Posté par pasBill pasGates le 03 juillet 2013 à 20:49. Évalué à 1.
      
      Tout a fait, et tu peux les changer
- [^] # Re: hop hop
  
  Posté par SauronDeMordor (site web personnel) le 04 juillet 2013 à 10:47. Évalué à 2.
  assez d accord avec toi.
  
  et puis le libre c est bien l ouverture et donc etre ouvert implique de voir ce qui se fait de bien ailleur.
  
  avec powershell Microsoft a fait un net progrès pour le travail des admins, reste juste a le rendre compatible ssh et cela serais top.
  
  sinon au lieur d ecrire ou de sortir du dns ou d un csv la liste de machine on peut aussi demander a l AD de nous la donner si on est dans un domaine.
```
$strFilter = "computer" 
$objDomain = New-Object System.DirectoryServices.DirectoryEntry
$objSearcher = New-Object System.DirectoryServices.DirectorySearcher
$objSearcher.SearchRoot = $objDomain
$objSearcher.SearchScope = "Subtree" 
$objSearcher.PageSize = 1000 

$objSearcher.Filter = "(objectCategory=$strFilter)"
$colResults = $objSearcher.FindAll()

foreach ($i in $colResults) {
 $objComputer = $i.GetDirectoryEntry()
 $strComputer = $objComputer.name

 if (test-connection -computername $strComputer -quiet -count 1) {
    $h = [string] $objComputer.dnsHostname
    Write-Host $h.ToLower()
  }
}
```
  ou bien si tu veux le mettre dans un txt
```
$strFilter = "computer" 
$objDomain = New-Object System.DirectoryServices.DirectoryEntry
$objSearcher = New-Object System.DirectoryServices.DirectorySearcher
$objSearcher.SearchRoot = $objDomain
$objSearcher.SearchScope = "Subtree" 
$objSearcher.PageSize = 1000 

$objSearcher.Filter = "(objectCategory=$strFilter)"
$colResults = $objSearcher.FindAll()

foreach ($i in $colResults) {
 $objComputer = $i.GetDirectoryEntry()
 $strComputer = $objComputer.name

 if (test-connection -computername $strComputer -quiet -count 1) {
    $h = [string] $objComputer.dnsHostname
    out-file -filepath servers.txt -inputobject $h.ToLower() -append
  }
}
```
# markdown

Posté par Marotte ⛧ le 03 juillet 2013 à 16:40. Évalué à 3.
Je note que
```
```powershell

```
```
ça fonctionne très bien pour la coloration syntaxique. :) C'est une coloration générique et j'ai de la chance ou bien ce langage est effectivement supporté pour l'édition ici ?
- [^] # Re: markdown
  
  Posté par CrEv (site web personnel) le 03 juillet 2013 à 17:00. Évalué à 2.
  
  Je ne sais plus exactement pour linuxfr, mais en général la lib utilisée pour colorer les sources est pygments. En tout cas celle-ci supporte powershell et de (très) nombreux autres langages.
# Honnêteté intellectuelle

Posté par zebra3 le 03 juillet 2013 à 17:21. Évalué à 10.

C'est pas mon genre de dire du bien de Windows surtout face à Debian, mais faut être honnête :

Et bien en fait il n'y a pas vraiment de solution rapide et élégante, genre un dpkg -l |grep ⁱⁱ |grep -v "ⁱⁱ lib" mais ça je m'en doutais, on est sous Windows après tout…

Suivi un peu plus loin de :

malheureusement ça ne liste que les programmes installés à l'aide d'un package MSI.

Bah c'est pareil pour Debian, si c'est pas installé par dpkg ta commande ne marchera pas. Windows a assez de défauts pour qu'on n'ait pas à lui reprocher ce qui est le même problème partout.

Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
- [^] # Re: Honnêteté intellectuelle
  
  Posté par Marotte ⛧ le 03 juillet 2013 à 19:33. Évalué à 5. Dernière modification le 03 juillet 2013 à 19:33.
  
  Sauf que Debian (comme n'importe qu'elle distribution) a la très grande majorité de ses programmes installés de cette manière. Alors oui pour compléter la liste faudra farfouiller un peu dans /opt ou /usr/local, trop dur…
  
  Alors que là c'est quand même moche dans la base de registre, tantôt la clé ressemble à {54544788df8789…} tantôt un nom qui te parle pas, des clés avec une seule valeur à "(default)" qui sauf erreur de ma part ne servent plus à rien… (en tous cas pas visiblement)
  
  Il y a peut-être moyen de faire plus propre (ce n'est pas moi qui ait fait le master auquel j'ai eu affaire) mais quand même…
  
  Bref, tu trolles comme un goret et je marche dedans.
  - [^] # Re: Honnêteté intellectuelle
    
    Posté par pasBill pasGates le 03 juillet 2013 à 19:58. Évalué à -1.
    
    C'est toujours bancal, le jour ou tu as une machine qui n'est pas Debian/Ubuntu, tu rates cette machine.
    - [^] # Re: Honnêteté intellectuelle
      
      Posté par Marotte ⛧ le 03 juillet 2013 à 20:18. Évalué à 5.
      
      L'équivalent pour RPM n'est pas très compliqué non-plus.
      - [^] # Re: Honnêteté intellectuelle
        
        Posté par pasBill pasGates le 03 juillet 2013 à 21:00. Évalué à 2.
        
        Tout a fait, maintenant fait une commande qui te sort Rpm+Deb, qui affiche ca de maniere uniforme, et qui est solide (genre ca ne pete pas parce que les gars de dpkg ont decide d'afficher une ligne supplementaire dans la version suivante), ca sera l'equivalent de ton powershell (ou du mien plus bas)
        
        [^] # Re: Honnêteté intellectuelle
        
        Posté par barmic le 03 juillet 2013 à 21:24. Évalué à 2.
        
        genre ca ne pete pas parce que les gars de dpkg ont decide d'afficher une ligne supplementaire dans la version suivante
        
        Si tu affiche cette contrainte il va falloir le faire des deux cotés et demander à avoir un script power shell, qui prends un éventuel changement dans le chemin codé en dur dans ton script (ça là \Software\Microsoft\Windows\CurrentVersion\Uninstall\*).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Honnêteté intellectuelle
        
        Posté par Marotte ⛧ le 03 juillet 2013 à 21:43. Évalué à 2.
        
        Sauf qu'il va te sortir que de toutes façons OSEF car ce chemin à pas changé depuis WinNT4 :)
        
        Mais je te rejoins sur le fait que beaucoup de libertés sont laissé aux packagers au niveau de la base de registre qu'on peut voir le pire comme le meilleur selon le système d'installation utilisé.
        
        Pour GNU/Linux c'est plutôt uniforme si ont considère qu'il y en a deux : deb et rpm. Comparé à MSI, Inno Setup, Le truc maison codé en VB, etc… On est bien lotis :)
        
        D'ailleurs la page http://en.wikipedia.org/wiki/List_of_installation_software est assez parlante :
        
        5 cross-platforme
        27 !! pour Windows
        5 pour OSX
        2 Symbian
        
        et une conclusion :
        
        package management system, the primary method to install software on Linux-based systems
        
        [^] # Re: Honnêteté intellectuelle
        
        Posté par pasBill pasGates le 03 juillet 2013 à 23:07. Évalué à 0.
        
        Euh visiblement t'as pas tout compris a la page… Il y a plein de ces softs qui te permettent de creer des installers, mais beaucoup de ces softs creent un MSI a la fin.
        
        Ensuite si tu veux une liste exhaustive(parce que ta liste, elle contient plein de formats que quasi personne utilise sous Windows) tu regardes Linux :
        
        deb, rpm, tgz, ebuild, opkg,PiSi, Conary…
        
        C'est pas forcement mieux hein, surtout va la difference enorme de taille des bases installees.
        
        [^] # Re: Honnêteté intellectuelle
        
        Posté par Marotte ⛧ le 04 juillet 2013 à 00:06. Évalué à 2.
        
        Il y a plein de ces softs qui te permettent de creer des installers, mais beaucoup de ces softs creent un MSI a la fin.
        
        Combien s'il te plaît ? Non parce que déjà que je les ai compté, j'allais pas non plus me renseigner sur tous. Je pense que tu es peut-être mieux à même que moi de donner les bons chiffres. Alors combien sur ces 27, génèrent du MSI (en bon et dû forme) ? Que font les X % qui restent ?
        
        D'après toi, quels sont les logiciels d'empaquetage qui ont le vent en poupe actuellement sous Windows ?
        
        Lors de mes test j'ai pu m'apercevoir par exemple que Inno Setup utilisait la base de registre comme il se doit, pour stocker toute sorte d'informations utiles comme la version du build ou le chemin du package (.msi, .exe) lancé pour réaliser l'installation.
        
        [^] # Re: Honnêteté intellectuelle
        
        Posté par pasBill pasGates le 04 juillet 2013 à 00:38. Évalué à 1.
        
        Euh… tu regardes la liste que tu donne sur la page, tu regardes la derniere colonne, c'est ecrit hein. 13/27 creent du MSI. Les autres font leur proper sauce, mais au final stockent ce qu'ils doivent au bon endroit. Ils ne remplissent probablement pas la base MSI par contre.
        
        D'après toi, quels sont les logiciels d'empaquetage qui ont le vent en poupe actuellement sous Windows ?
        
        MSI est le format de loin le plus utilise. Install Shield et WiX semblent etre les installers les plus souvent vus de mon experience.
        
        [^] # Re: Honnêteté intellectuelle
        
        Posté par pasBill pasGates le 03 juillet 2013 à 23:10. Évalué à 1.
        
        Cela n'arrivera pas car ce chemin fait partie de l'API documente : http://msdn.microsoft.com/en-us/library/ms954376.aspx C'est pas un truc cache qui n'est pas sense etre utilize, c'est un chemin officiel.
        
        Alors que la sortie des outils ligne de commande, elle n'est en rien garantie.
        
        [^] # Re: Honnêteté intellectuelle
        
        Posté par Marotte ⛧ le 03 juillet 2013 à 23:39. Évalué à 2.
        
        Alors que la sortie des outils ligne de commande, elle n'est en rien garantie.
        
        Excuse-moi mais la sortie d'un df -P elle a pas beaucoup changé non plus hein.
        
        D'un coté la norme POSIX et l'historique d'UNIX de l'autre des spécifications sommaires édictées par une firme américaine (forcément à la solde de la NSA, m'voyez).
        
        [^] # Re: Honnêteté intellectuelle
        
        Posté par pasBill pasGates le 03 juillet 2013 à 23:55. Évalué à -1.
        
        df c'est posix, eh, ps aussi c'est posix, va donc lancer cette commande sur 3 Unix differents et dis moi si la sortie est identique…
        
        Pour dpkg : https://launchpad.net/debian/+source/dpkg/+changelog
        
        1.16.5
        
        Superseded in sid-release on 2012-07-02
        
        Add an Architecture column to «dpkg-query -l» before the Description column
        
        Je te laisse imaginer ce que ce genre de changements aurait eu comme effet sur un script utilisant awk ou cut
        
        [^] # Re: Honnêteté intellectuelle
        
        Posté par Marotte ⛧ le 04 juillet 2013 à 00:15. Évalué à 0.
        
        Je te laisse imaginer ce que ce genre de changements aurait eu comme effet sur un script utilisant awk ou cut
        
        Un script qui plante un jour, suite à une montée de version. Mais facile à corriger.
        
        Et pour :
        
        c'est posix, eh, ps aussi c'est posix, va donc lancer cette commande sur 3 Unix differents et dis moi si la sortie est identique…
        
        Oui, si une commande spécifie que telle option produit une sortie aux normes POSIX n'importe quelle autre fonction qui se conforme a cette norme pourra y aller les yeux fermés.
        
        Alors oui, si tu lance un ps -ef sans plus d'option sur Debian,Solaris,NetBSD tu n'auras peut-être pas la même sortie, sauf si tu le spécifies expressément.
        
        [^] # Re: Honnêteté intellectuelle
        
        Posté par pasBill pasGates le 04 juillet 2013 à 00:40. Évalué à -1.
        
        Un script qui plante un jour, suite à une montée de version. Mais facile à corriger.
        
        Il plante ? Ou il te rend le mauvais resultat sans que tu t'en rende compte, ce qui est infiniment plus grave. Surtout selon ce que le script fait.
        
        [^] # Re: Honnêteté intellectuelle
        
        Posté par Marotte ⛧ le 04 juillet 2013 à 01:08. Évalué à 0. Dernière modification le 04 juillet 2013 à 01:09.
        
        Il plante ? Ou il te rend le mauvais resultat sans que tu t'en rende compte
        
        Si c'est un cut sauvage de la sortie d'une commande qui fait foirer le programme on va vite le voir en effet. Facile à corriger à J+1 je maintiens.
        
        [^] # Re: Honnêteté intellectuelle
        
        Posté par pasBill pasGates le 04 juillet 2013 à 01:17. Évalué à 6.
        
        Mais tu vas le voir comment ?
        
        Si ils rajoutent une colonne qui contient un entier devant une autre colonne qui contient un entier, ton script il ne va pas planter, il va juste te filer le mauvais resultat, et selon ce que le script fait, tu pourrais:
        - ne rien voir pendant des semaines alors que le script te fait perdre/endommager des donnees lentement mais surement
        - t'en rendre compte tres vite sans dommages
        - t'en rendre compte parce que la moitie de ton parc a disparu du reseau et tous tes utilisateurs hurlent.
        
        C'est un vrai cauchemard ce genre de truc, surtout le 1, parce que bonne chance pour aller debugger tes scripts qui s'appellent les uns les autres, et arriver a comprendre ce qui se passe exactement.
        
        C'est pas pour rien que les interfaces definies et solides sont importantes, que les donnees structurees sont importantes, c'est justement pour eviter ce genre de bordel. Si le format n'est pas bon ca plante, ca ne corrompt rien. Si l'interface est definitive, ca ne plante pas.
        
        [^] # Re: Honnêteté intellectuelle
        
        Posté par barmic le 04 juillet 2013 à 09:22. Évalué à 2.
        
        Après c'est une question de validation des données d'entrée (comme pour tout langage), c'est loin d'être infaisable en bash/zsh/tcsh. Faut juste prendre le temps de le faire. On est d'accord si c'est fait par un type statique¹ c'est plus simple (automatique) et systématique.
        
        ¹ : Je présume que la validation du typage ce fait avant l'exécution de la commande.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Honnêteté intellectuelle
        
        Posté par daeldir le 04 juillet 2013 à 01:34. Évalué à 1.
        
        Pour en rajouter, on peut dire que c'est « prévu » dans la philosophie Unix : être le plus laxiste et intelligent possible sur les entrées (car elles peuvent venir de différents programmes, ou d'un humain qui fait des fautes), et le plus strict possible sur la sortie, pour une analyse facile du résultat.
        
        …
        
        Mais ça bat pas une définition (et une seule) du format des données entre programmes…
        
        Si on avait un switch sur tout les programmes pour qu'ils acceptent et pondent du json (par exemple, ou un quelconque format définit par la norme et avec un parser fournit dans les libs standard), peut-être que ça serait plus simple d'avoir le niveau d'interactions entre les programmes que pBpG décrit… En même temps, Unix a été pendant longtemps en avance à ce niveau avec les pipes, et le powershell est très récent…
        
        Au fait, quelqu'un s'est amusé avec le rc shell de plan 9 ? J'avais lu et été tenté (comme pour pas mal de trucs de plan 9, d'ailleurs), mais j'ai jamais prit le temps de vraiment tester. Je suppose que c'est « mieux » que sh, mais pas encore au niveau de PowerShell (à supposer qu'il y ait du « mieux » et du « moins bien », ce qui finalement dépend beaucoup des préférences…).
        
        [^] # Re: Honnêteté intellectuelle
        
        Posté par palm123 (site web personnel) le 04 juillet 2013 à 11:37. Évalué à 3.
        
        Il y avait un truc bien sous OpenVMS, les fonctions lexiques
        
        tu veux savoir
        
        à quel moment a démarré le process dont le pid est 204002B4 ? C'est dans f$getjpi("204002B4","LOGINTIM")
        
        si le disque DSA3 est en cours de shadow copy ? c'est dans f$getdvi("DSA3,"SHDW_CATCHUP_COPYING")
        Extrait de
        http://h71000.www7.hp.com/doc/84final/9996/9996pro_98.html
        
        Voir plus généralement
        http://h71000.www7.hp.com/doc/84final/9996/9996pro_136.html#lex_func_sec
        
        pas de commande | grep xxx
        ou
        command | awk …
        
        ウィズコロナ
    - [^] # Re: Honnêteté intellectuelle
      
      Posté par Marotte ⛧ le 03 juillet 2013 à 21:48. Évalué à 3.
      
      Parce que je peux interroger la base de registre d'un AIX à distance avec une commande PowerShell peut-être ?
      - [^] # Re: Honnêteté intellectuelle
        
        Posté par pasBill pasGates le 03 juillet 2013 à 23:07. Évalué à -2.
        
        On parle du meme OS. Debian & Redhat c'est le meme OS : GNU/Linux.
        
        Windows XP/2003/Vista/Seven/8 c'est le meme OS : Windows.
        
        [^] # Re: Honnêteté intellectuelle
        
        Posté par zebra3 le 04 juillet 2013 à 09:27. Évalué à 2.
        
        Que ce soit Windows ou Linux, je ne dirais pas que c'est le même OS mais la même famille.
        
        Debian et Red Hat sont deux OS très différents sur pas mal de points (les paquets puisque c'est le sujet, l'init, config réseau, SElinux par défaut dans l'un et qui demande du boulot d'intégration dans l'autre, etc).
        
        Quant à Windows je ne suis pas spécialiste mais je ne mettrais pas au même niveau XP/2003 et Seven/2008R2. Ils sont proches certes, mais je trouve que beaucoup de choses ont changé dans la manière d'administrer (ne serait-ce que le pare-feu).
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: Honnêteté intellectuelle
        
        Posté par pasBill pasGates le 04 juillet 2013 à 09:46. Évalué à 2.
        
        Moi ce que je vois :
        
        Meme noyau
        
        Memes softs
        
        Binaire sur l'un peut tourner sur l'autre (memes syscalls, memes librairies, …)
        
        Bref, c'est vraiment le meme OS a la base, juste configure differemment ou avec des binaires de versions differentes. Il n'y a aucunes differences architecturales ou incompatibilite binaire.
        
        [^] # Re: Honnêteté intellectuelle
        
        Posté par claudex le 04 juillet 2013 à 11:36. Évalué à 5.
        
        Meme noyau
        
        Pas avec les mêmes options de compilation ni les mêmes backports. Ça de l'influence sur les pilotes ou sur les trucs plus exotiques (iSCSI, option de montage des FS…)
        
        Memes softs
        
        Pas les même init, pas la même libc…
        
        inaire sur l'un peut tourner sur l'autr
        
        Peut mais rien n'est garanti.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Honnêteté intellectuelle
        
        Posté par deasy le 05 juillet 2013 à 05:03. Évalué à 2.
        
        Tu risques de faire des mécontents en avouant qu'ils paient pour la même chose :)
  - [^] # Re: Honnêteté intellectuelle
    
    Posté par daeldir le 03 juillet 2013 à 21:47. Évalué à 2.
    
    Sauf que Debian (comme n'importe qu'elle distribution) a la très grande majorité de ses programmes installés de cette manière. Alors oui pour compléter la liste faudra farfouiller un peu dans /opt ou /usr/local, trop dur…
    
    Mais… Sur Windows, on n'a pas la majorité des programmes installés avec un programme d'installation, et donc accessible dans le panneau « Programmes et fonctionnalités » ? La liste dans ce panneau n'est pas la même que celle renvoyée par wmic product get name,version ?
    
    Bon, je suis pas un gros utilisateur de Windows, mais j'avais très peu de programmes qui n'étaient pas accessibles à partir de là… Autant que de programmes dans /opt sur linux, on pourrait dire… (très peu).
    
    Puis sur Linux, il y a des programmes dans /opt, dans /usr/local, dans le dossier personnel… Et même pas l'équivalent de ton astuce avec la base de registres ! Linux, çaynul ;-)
    
    … Perso, j'adore les gestionnaires de paquets (installer en une commande, toujours la même, désinstaller, pareil, recherche rapide de logiciels et mise à jour de tout les programmes installés en même temps) mais je suis d'accord avec zebra3, le problème est le même sur Linux (ou alors, tu as pas de chance si la plupart de tes programmes n'utilisent pas un installateur correct).
    
    Ça n'empêche pas le journal d'être intéressant, de nous présenter ce truc étrange qu'est le PowerShell. J'en avais jamais vu, mais j'avais lu je sais plus où que « microsoft avait enfin fait un truc utilisable » (d'où mon qualificatif « étrange » :-°).
    
    Bon, voilà, j'en rajoute au troll \o/
    
    miam…
  - [^] # Re: Honnêteté intellectuelle
    
    Posté par zebra3 le 03 juillet 2013 à 22:01. Évalué à 4.
    
    Sauf que Debian (comme n'importe qu'elle distribution) a la très grande majorité de ses programmes installés de cette manière. Alors oui pour compléter la liste faudra farfouiller un peu dans /opt ou /usr/local, trop dur…
    
    Autant /opt je veux bien, autant j'ai du mal à voir comment tu vas gérer /usr/local/. Si tu listes le contenu du bin, tu vas te retrouver avec plein de commandes qui appartiennent au même programme sans savoir auquel elles correspondent, comme LibreOffice qui installe en fonction loffice, lowriter, localc, limpress, etc. Là c'est un cas simple car on sait que loffice = LibreOffice, mais dès que tu multiplies les logiciels installés tu es obligé de gérer au cas par cas, donc manuellement.
    
    Tu peux aussi fouiller dans share ou doc, mais rien ne dit que tes logiciels y installent quelque chose.
    
    Après, faut aussi voir les logiciels type PlayOnLinux qui t'installent 42 versions de Wine dans ~/.PlayOnLinux…
    
    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# FusionInventory

Posté par Spack le 03 juillet 2013 à 18:03. Évalué à 5.

Chez FusionInventory, ils le font en Perl /o\ par contre l'agent est installé sur la machine.

Ça te donnera peut-être des idées.
# C'est bien trop long...

Posté par pasBill pasGates le 03 juillet 2013 à 19:54. Évalué à 2.
Marrant, chez moi ca fait une ligne…
```
Invoke-Command -ComputerName this-ubook -ScriptBlock { gp HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* }
```
- [^] # Re: C'est bien trop long...
  
  Posté par barmic le 03 juillet 2013 à 20:20. Évalué à 3.
  T'inquiète pas, la version pour Debian aussi pourrait être simplifiée (pas autant) :
```
dpkg -l | awk '$1~/ii/ && $2!~/^lib/'
```
  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
  - [^] # Re: C'est bien trop long...
    
    Posté par pasBill pasGates le 03 juillet 2013 à 20:55. Évalué à 1.
    
    Oui, a part le fait que ma commande, elle marche sur un systeme remote et elle retourne une structure de donnees tres simple a reutilizer plutot que du texte qu'il faut formatter soi meme…
    - [^] # Re: C'est bien trop long...
      
      Posté par barmic le 03 juillet 2013 à 21:26. Évalué à 2.
      J'ai pas dis le contraire. J'ai juste profité de ta remarque pour sortir ma version. Pour sortir un CSV on peut faire ça :
      
      dpkg -l | awk 'BEGIN{OFS=";"}$1~/ii/ && $2 !~ /^lib/{print $1,$2,$3,$4}'
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    - [^] # Re: C'est bien trop long...
      
      Posté par Marotte ⛧ le 03 juillet 2013 à 21:26. Évalué à 1.
      sur un systeme remote
      
      Pas compliqué de faire un ssh user@host [la commande] non plus.
      
      elle retourne une structure de donnees tres simple a reutilizer
      
      reutilaïzé ? ;)
      
      Et bien justement, là, la sortie de la commande dpkg -l c'est exactement ce qui lui fallait au client, un listing avec nom,version,archi,description c'était parfait. Comme quoi…
      
      Là il faut écrire $MonSuperObjet.nom, $MonSuperObjet.version, etc, ou itérer… Il te faut au minimum 3 lignes de code (et un niveau d'indentation).
      
      Après je reconnais que c'est un peu une question de goûts.
      
      Et puis il y a le même genre d'information déjà formaté d'autres manières disponibles : par exemple dans /var/lib/dpkg, selon le besoin.
      
      Si je veux connaître les fichiers de conf initiaux de deux logiciels je peux faire par exemple :
      
      $ cat /var/lib/dpkg/info/{bash,wget}.conffiles /etc/bash.bashrc /etc/skel/.bash_logout /etc/skel/.bashrc /etc/skel/.profile /etc/wgetrc
      
      Je sais qu'il n'y en a pas ailleurs à priori.
      
      Une entrée par ligne, ça revient exactement à un objet avec des membres.
      - [^] # Re: C'est bien trop long...
        
        Posté par pasBill pasGates le 03 juillet 2013 à 23:17. Évalué à 2.
        
        T'as remarque que ma commande ne comportait pas la liste des attributs mais un '*' ? Pas besoin de tous les lister
        
        Une entrée par ligne, ça revient exactement à un objet avec des membres.
        
        Pas trop non, il y a les dates, tailles, etc… qui sont des attributs aussi. Ensuite sous tcsh/bash/… il faut arriver a les lier a l'element de depart quand tu les passes d'une commande a l'autre, etc… Compare a Powershell c'est totalement primitif
        
        [^] # Re: C'est bien trop long...
        
        Posté par Marotte ⛧ le 04 juillet 2013 à 00:40. Évalué à 2.
        
        :)
        
        T'as gagné.
        
        Il y a juste que :
        
        il faut arriver a les lier a l'element de depart quand tu les passes d'une commande a l'autre, etc
        
        Anéfé, http://fr.wikipedia.org/wiki/Tube_%28shell%29
    - [^] # Re: C'est bien trop long...
      
      Posté par shbrol le 03 juillet 2013 à 21:28. Évalué à 3.
      
      il suffit de rajouter 'ssh this-ubook' devant la commande pour l'exécuter a distance, pas vraiment de différence de ce point de vue.
    - [^] # Re: C'est bien trop long...
      
      Posté par Thomas Debesse (site web personnel) le 04 juillet 2013 à 10:20. Évalué à 3.
      
      Oui, a part le fait que ma commande, elle marche sur un systeme remote.
      
      Tiens d'ailleurs, parfois j'utilise winexe pour exécuter des commandes sur des postes Windows distants.
      
      Qu'est ce qui fait que ça ne marche que sur les postes appartenant à un domaine ? Je suppose que c'est du à un service qui tourne par défaut quand la machine appartient à un domaine, mais peut-on démarrer ce service même si la machine n'est pas en domaine ? J'ai deux/trois exceptions qui ne doivent pas appartenir à l'un ou l'autre des domaines que j'administre et c'est un peu frustrant. ^^
      
      ce commentaire est sous licence cc by 4 et précédentes
      - [^] # Re: C'est bien trop long...
        
        Posté par pasBill pasGates le 04 juillet 2013 à 11:18. Évalué à 1.
        
        Aucune idee de ce qu'est ce truc, faudrait regarder une trace reseau et voir ce qui merde. Ca pourrait etre l'authentification par exemple, ou autre, dur a dire comme ca.
        
        [^] # Re: C'est bien trop long...
        
        Posté par Thomas Debesse (site web personnel) le 04 juillet 2013 à 11:42. Évalué à 3.
        
        Ben c'est juste un client tierce-partie pour un service de chez microsoft (lequel ?)… et c'est pas du coté du client mais du coté de Windows que le fonctionnement est aléatoire…
        
        Exemple avec une machine distante en domaine :
        
        $ winexe //computer --interactive=1 -U DOMAIN/user "cmd.exe" Password for [DOMAIN\user]: Microsoft Windows XP [version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\WINDOWS\system32>ver ver Microsoft Windows XP [version 5.1.2600] C:\WINDOWS\system32>help help help help Fournit des informations d'aide sur les commandes de Windows XP. HELP [commande] commande - affiche des informations d'aide sur cette commande.
        
        Avec une machine hors domaine je reçois :
        
        ERROR: Failed to open connection - NT_STATUS_CONNECTION_REFUSED
        
        Ou bien :
        
        ERROR: Failed to open connection - NT_STATUS_REMOTE_NOT_LISTENING
        
        Ça semble dépendre de la version de Windows de la machine adressée.
        
        Il semble que ce soit un service qui est actif lorsqu'une machine entre dans un domaine, et inactif par défaut…
        
        ce commentaire est sous licence cc by 4 et précédentes
- [^] # Re: C'est bien trop long...
  
  Posté par Marotte ⛧ le 03 juillet 2013 à 20:23. Évalué à 4. Dernière modification le 03 juillet 2013 à 20:24.
  
  Tu serais pas en 32bit ?
  
  Sinon, t'as pas une HKLM:\Software\Microsoft\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall dans ton registre avec d'autres clés pour d'autres programmes dedans ?
  
  Wow6432Node
  
  C'est lié au fait d'être en 64bit à ce que j'ai pu lire.
  
  Mais je testerai ton code ! Si ça me renvoie tout c'est cool.
  - [^] # Re: C'est bien trop long...
    
    Posté par pasBill pasGates le 03 juillet 2013 à 20:51. Évalué à 3.
    
    Tout a fait, faut prendre les 2 pour etre sur d'avoir les softs 64 ET 32bit. Wow6432 est pour les softs 32bit installes sur un systeme 64bit
# c'est quoi un programme installé ?

Posté par steph1978 le 10 juillet 2013 à 20:29. Évalué à 2.

parce que là t'as choppé ce qui est inscrit dans le registre.
mais j'ai plein de programmes qui sont juste un exécutable sur lequel tu double-cliques pour le lancer.
voire un jar qui est lancé par la jvm.
- [^] # Re: c'est quoi un programme installé ?
  
  Posté par Marotte ⛧ le 11 juillet 2013 à 06:58. Évalué à 3.
  
  J'en ai bien conscience mais comment faire autrement ?
  
  Ô que c'est beau une distribution GNU/Linux avec un gestionnaire de packages, comparé à cet OS de merde ! :)
  - [^] # Re: c'est quoi un programme installé ?
    
    Posté par steph1978 le 11 juillet 2013 à 10:01. Évalué à 2.
    
    Je ne visais aucun système en particulier.
    Sous Linux aussi on peut "installer" des programmes sans passer par le gestionnaire de packages, qui reste par contre la voie naturelle.
  - [^] # Re: c'est quoi un programme installé ?
    
    Posté par barmic le 11 juillet 2013 à 13:48. Évalué à 2.
    
    Ô que c'est beau une distribution GNU/Linux avec un gestionnaire de packages, comparé à cet OS de merde ! :)
    
    Oui sur mes linux, j'ai des trucs dans /usr/local, dans /opt (en principe les binaires qui s'y trouvent ont un lien symbolique dans /usr/local/bin), dans ~/.bin et dans ~/.zsh_functions.
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    - [^] # Re: c'est quoi un programme installé ?
      
      Posté par Marotte ⛧ le 11 juillet 2013 à 13:53. Évalué à 2.
      
      Moi aussi mais il faut bien reconnaitre que la majorité des programmes sont installés via le système de gestion des packages et que ça aide bien à voir ce qui est installé.
      - [^] # Re: c'est quoi un programme installé ?
        
        Posté par lasher le 11 juillet 2013 à 14:54. Évalué à 2.
        
        Sous win aussi, la majorité des programmes est installée dans 2 répertoires (Program Files), non?
        
        [^] # Re: c'est quoi un programme installé ?
        
        Posté par Marotte ⛧ le 11 juillet 2013 à 17:50. Évalué à 3.
        
        Une majorité nettement moins majoritaire :)
        
        Et puis des fois c'est Program Files\Editeur\Program, des fois Program Files\Program1Part1 + Program Files\Program1Part2
        
        Bon je suis un peu de mauvaise foi, c'est de moins en moins le bordel je dois le reconnaître. Mais obtenir une liste pertinente des programmes installés en se basant sur le(s) répertoire(s) Program Files c'est pas forcément évident.

Suivre le flux des commentaires

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