Journal Microsoft: Powershell libéré

Posté par (page perso) . Licence CC by-sa
21
19
août
2016

https://github.com/PowerShell/PowerShell/

PowerShell intègre un interface en ligne de commande, le langage de script PowerShell ainsi qu'un kit de développement. Il est inclus depuis Windows 7 et s'appuie sur le framework Microsoft .NET.

Après avoir libéré le Framework .NET, Microsoft vient de faire la même chose pour son Shell en le rendant disponible sous Linux et OSX.

Pas pu tester pour le moment car il ne fonctionne pas sous ArchLinux. Mais je suis curieux de voir comment Microsoft va intégrer cela avec notre OS. En effet, Powershell se base sur des couches d'abstractions pour communiquer avec le système, lui permettant de renvoyer des données formatées et donc d'éviter certaines galères communes aux Shell Unix comme:

$ ip addr | grep 'state UP' -A2 | tail -n1 | awk '{print $2}' | cut -f1  -d'/'

vs

>Get-NetIPAddress –AddressFamily IPv4

Merci de ne pas poster votre version plus courte pour obtenir l'ip courante, j'ai juste copié collé le premier résultat depuis Google

Bref, à suivre.

  • # Grilled

    Posté par (page perso) . Évalué à 8.

  • # Héhé

    Posté par . Évalué à 7.

    Comme tu t'es fais griller, je me permet parce que ça ne devrait pas trop polluer la discussion.

    Moi j'aime bien cette solution :

    ip addr | awk '/state UP/{iface=$2}/inet/&&iface!=""{split($2,a,"/");print iface,a[1];iface=""}'

    pas plus courte, mais elle montre toutes les adresses et sur quelle interface :

    # ip addr | awk '/state UP/{iface=$2}/inet/&&iface!=""{split($2,a,"/");print iface,a[1];iface=""}'
    eth0: 16.16.46.247
    wlan0: 10.10.1.209
    

    Car le plus simple reste encore : netstat -ie | awk '/inet /{print substr($2, 5)}' ;)

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Héhé

      Posté par (page perso) . Évalué à 6.

      Pour trier déjà sur les IPv4 et sur les interfaces actives, autant le demander à ip :

      $ ip -4 address show up|sed '/inet /!d;s%^ *inet \(.*\)/.*$%\1%'|tail -n1
      • [^] # Re: Héhé

        Posté par . Évalué à 4.

        Je ne connaissais pas, merci. Mais comme tu fais de toute manière un filtre ça ne change pas grand chose. Par contre pour faire plus simple que le /inet /!d; tu peux faire :

        ip -4 address show up | sed -n 's% *inet \(.*\)/.*%\1%p'

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Héhé

        Posté par (page perso) . Évalué à 2.

        Mouais, mais ça donne le même résultat uniquement si tu n'as qu'une interface avec une ip.

        Exemple chez moi :

        > ip addr | grep 'state UP' -A2 | tail -n1 | awk '{print $2}' | cut -f1  -d'/'
        

        192.168.1.65 → juste

        Mais:

        > ip -4 address show up | sed '/inet /!d;s%^ *inet \(.*\)/.*$%\1%' | tail -n1
        

        192.168.148.1 → faux !

        Par contre :

        > ip -4 address show up  | grep 'state UP' -A2 | sed '/inet /!d;s%^ *inet \(.*\)/.*$%\1%' 
        

        192.168.1.65 → juste

        --
        Mes 2 ¢

        Sed fugit interea, fugit inreparabile tempus, singula dum capti circumvectamur amore

        • [^] # Re: Héhé

          Posté par (page perso) . Évalué à 4. Dernière modification le 19/08/16 à 11:56.

          Je dirais que le souci vient plutôt du fait que je n'ai pas géré la diversité des cas. Par exemple :

          inet 192.xx.xx.xx/24 brd 192.xx.xx.xx scope global eth2

          et

          inet 90.xx.xx.xx peer 193.xx.xx.xx/32 scope global ppp0

          donc il ne faut pas utiliser le '/' du '/24' pour délimiter l'IP.

          $ ip -o -4 address show up|sed -n 's%.*inet \([0-9.]*\).*%\1%p'|tail -n1
      • [^] # Re: Héhé

        Posté par (page perso) . Évalué à 2.

        Une pétition aux auteurs de la commande ip (et ifconfig aussi tant qu'on y est) pour ajouter ce genre de fonctionnalité dont les sysadmins ont besoin?

        • [^] # Re: Héhé

          Posté par (page perso) . Évalué à 4.

          Une pétition aux auteurs de la commande ip

          On appelle ça un rapport de bug

          et ifconfig aussi tant qu'on y est

          Vu le nombre d’année que c’est deprecated, on ne va pas forcer.

          our ajouter ce genre de fonctionnalité dont les sysadmins ont besoin

          Quelle fonctionnalité ont-ils besoin ? Parce que par défaut, dans le commentaire auquel tu réponds, il y a déjà les IP sur une ligne.

          « 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: Héhé

      Posté par (page perso) . Évalué à 6.

      Gros inconvénient de ce genre de manip : on peut avoir de mauvaises surprises vu qu'on compte sur un format de sortie qui n'a aucune garantie de stabilité (par exemple quand l'OS est en français). À ce niveau, PowerShell a un gros avantage.

      • [^] # Re: Héhé

        Posté par (page perso) . Évalué à 3.

        J'ai du mal à voir l'intérêt de choisir la dernière IP, si on ne contrôle pas quelle est la dernière interface. A priori il y a déjà un souci dans la requête initiale. Soit on veut une interface portant tel nom (une eth3 ou un ppp0 par exemple), soit on cherche une IP ayant telle forme (un 192.168.42.xx par exemple).

        Exemple : deviner quelle sera la dernière interface listée entre eth1 ou eth3 :

        $ ip -6 -o add 
        1: lo    inet6 ...
        2: eth3    inet6 ...
        3: eth1    inet6 ...
      • [^] # Re: Héhé

        Posté par (page perso) . Évalué à 3.

        (par exemple quand l'OS est en français).
        À ce niveau, PowerShell a un gros avantage.

        Sous Windows 7, PowerShell répond en français:

        > Get-NetIPAddress -AddressFamily IPv4
        Le terme « Get-NetIPAddress » n'est pas reconnu comme nom d'applet de commande, fonction, fichier de script ou programm
        e exécutable. Vérifiez l'orthographe du nom, ou si un chemin d'accès existe, vérifiez que le chemin d'accès est correct
         et réessayez.
        Au niveau de ligne : 1 Caractère : 17
        + Get-NetIPAddress <<<<  -AddressFamily IPv4
            + CategoryInfo          : ObjectNotFound: (Get-NetIPAddress:String) [], CommandNotFoundException
            + FullyQualifiedErrorId : CommandNotFoundException
        
        • [^] # Re: Héhé

          Posté par . Évalué à 4.

          Oui mais tu manipule des objets .Net pas une sortie texte.

          Après dans un script tu nettoie ton environnement pour que les commandes te sortent du français et en cli tu t'en fout c'est de la commande que tu n'utilisera pas plus de quelques jours grand maximum.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Héhé

            Posté par (page perso) . Évalué à 5.

            Oui mais tu manipule des objets .Net pas une sortie texte.

            Quel rapport ? Il s'agit pour l'auteur de comparer deux commandes "shell".

            D'un coté, il fournit une commande Linux honteusement compliquée, alors qu'un hostname -I suffit.
            De l'autre, il fournit un équivalent Windows qui n'existe pas sous Windows 7, OS mentionné dans l'article.

            • [^] # Re: Héhé

              Posté par . Évalué à 3.

              Je croyais que ce qui te gênait c'était qu'il réponde en français.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Héhé

              Posté par (page perso) . Évalué à 10.

              D'un coté, il fournit une commande Linux honteusement compliquée, alors qu'un hostname -I suffit.

              Petite précision, la commande hostname fournie par le projet net-tools ne reconnaît pas d’option -I. Cette option est une invention de l’implémentation propre à Debian.

              Toutes les distributions n’ont pas repris cette implémentation et fournissent à la place la commande hostname d’origine du projet net-tools (sans l’option -I, donc).

            • [^] # Re: Héhé

              Posté par . Évalué à 6. Dernière modification le 19/08/16 à 15:54.

              $ hostname -i
              hostname: illegal option -- i
              usage: hostname [-fs] [name-of-host]

              grilled…

              Depending on the time of day, the French go either way.

          • [^] # Re: Héhé

            Posté par (page perso) . Évalué à 4.

            Oui mais tu manipule des objets .Net pas une sortie texte.

            Ben justement, je ne suis pas sur que cela soit toujours une bonne idée !

            Avec le shell UNIX et en pensant à faire un LANG=C, les scripts sont relativement robuste dans le temps. Si les versions changent, c'est du texte, on met à jour mais tout cela reste des chaînes de caractères immutable.

            C'est assez lispsien comme approche. Dans la construction de Perl6, ils expliquent bien pourquoi ils ne font pas du tout objet.

            Tes objets, ils ont plein de méthodes et tu joues au final avec un nombre fini de méthode. Avec l'approche ASCII, on fait du traitement de chaîne en terme de flux. Chacun peut imaginer tout ce qu'il veut, c'est un monde très ouvert et très souple. Avec le temps, les arbres de classes ont tendance a se rigidifier et à se scléroser. Il devient paradoxalement très compliqué de modifier certain schéma interne.

            Alors certes, l'approche ASCII n'est pas performante mais on n'est pas là pour faire toujours du HPC ;-)

            • [^] # Re: Héhé

              Posté par . Évalué à 7.

              Alors certes, l'approche ASCII n'est pas performante mais on n'est pas là pour faire toujours du HPC ;-)

              Ce n'est pas vraiment une question de performance (le shell surpasse tous les langages qui existant), c'est plus de la fiabilité et de la simplicité.

              Je trouve l'idée assez bonne, mais l'implémentation pas terrible personnellement. Ce n'est peut être qu'un effet de bord ou peut être que j'ai un biais de pensé, mais le shell est un langage que je parle véritablement couramment. Pour des raisons que j'ai du mal à expliquer mes tentatives avec PowerShell n'ont rien donné de très concluant (et je suis ouvert, je suis entrain d'essayer de passer à ipython comme login 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: Héhé

                Posté par (page perso) . Évalué à 3.

                je n'ai pas beaucoup regardé Powershell (je n'utilise pas Windows), mais j'ai la même impression. Je suis assez fan du concept mais la syntaxe me semble peu amène. Après, s'il y a une autocomplétion (un peu comme iPython), ça peut aider.

                Faudrait que j'essaie iPython par défaut, tiens. Pour l'instant, je suis resté à zsh.

              • [^] # Re: Héhé

                Posté par . Évalué à 10.

                ipython, c'est dépassé.

                La nouvelle tuerie c'est xon.sh.
                Cf; presentation au pycon
                https://www.youtube.com/watch?v=uaje5I22kgE

              • [^] # Re: Héhé

                Posté par . Évalué à 2. Dernière modification le 19/08/16 à 19:20.

                houps doublon à supprimer SVP si un modo passe par là

            • [^] # Re: Héhé

              Posté par (page perso) . Évalué à 5.

              Tes objets, ils ont plein de méthodes et tu joues au final avec un nombre fini de
              méthode.

              C'est de la mauvaise fois ça, avec Unix aussi tu joues au final avec un nombre fini d'option par commande au lieu d'un nombre fini de méthode par objet.

              • [^] # Re: Héhé

                Posté par (page perso) . Évalué à 5.

                Pas tout à fait vrai. Tu travailles en shell sur un pipe ASCII. En gros sur un texte qui se fait transformer. C'est assez proche du langage avec des possibilités très large. Ainsi, il y a plus d'une manière de faire une chose comme on le vois régulièrement dans les réponses sur le forum. TimTowTdi - There Is More Than One Way To Do It. Rare sont les langages objets a inscrire cela dans leur cœur. C'est à mon avis un gage de pérennité, de souplesse.

                De plus, tu peux écrire une nouvelle commande dans le langage que tu veux, comme tu veux. Tout s'interface juste par traitement de texte. L'API imposé est hyper simple et très souple.

            • [^] # Re: Héhé

              Posté par (page perso) . Évalué à -1.

              Si les versions changent, c'est du texte, on met à jour mais tout cela reste des chaînes de caractères immutable.

              Tu es sérieux dans le fait de trouver ca "robuste"?
              "on met à jour", c'est tout, tu le crois vraiment? (genre tu sais que ton script ne tourne que sur une distro précise avec une version précise)

              Avec l'approche ASCII, on fait du traitement de chaîne en terme de flux. Chacun peut imaginer tout ce qu'il veut, c'est un monde très ouvert et très souple.

              et du coup on se retrouve avec des scripts Perl incompréhensibles (plein de "formules magiques") même par son auteur.

              toi, tu dois regretter SysV qui faisait ton bonheur à coup de maintenance complexe mais il a été remplacé (les salauds!) par systemd pour justement éviter le "bonheur" dont tu parles (tout le monde n'a pas le temps l'envie de jouer à "si le texte change on met à jour", certains travaillent)

              • [^] # Re: Héhé

                Posté par (page perso) . Évalué à 0.

                Bonjour,

                depuis que j'ai systemd ma vie d'administrateur système est plus compliquée.
                Quand je lance un service j'ai rarement un retour. Parfois j'ai pour retour : ça marche pas, va regarder le journal pour savoir pourquoi.

                Quand je n'ai aucun retour, c'est pire parce que je dois vérifier si ke service tourne.

                Je suis donc obligé d'avoir un terminal de plus ouvert pour afficher les journaux de systemd.

                Systemd apporte bien plus de complexité. Avant, c'était simple. On avait le retour directement.

                • [^] # Re: Héhé

                  Posté par (page perso) . Évalué à 6.

                  Quand je n'ai aucun retour, c'est pire parce que je dois vérifier si ke service tourne.

                  Si tu n'a pas de retour, c'est que le service fonctionne… Avec Sysinit, tu avais juste un echo "Starting toto"… J'appelle pas ça un retour…

                  • [^] # Re: Héhé

                    Posté par . Évalué à 3.

                    D'expérience ce n'est pas toujours le cas. J'ai eu plusieurs fois aucun retour pour le service fcgiwrap ou fcgiwrap.socket, alors même que le service ne s'était pas lancé correctement.

                    • [^] # Re: Héhé

                      Posté par (page perso) . Évalué à 3.

                      D'expérience ce n'est pas toujours le cas. J'ai eu plusieurs fois aucun retour pour le service fcgiwrap ou fcgiwrap.socket, alors même que le service ne s'était pas lancé correctement.

                      Il y avait le même genre de problème avec sysinit.

                      • [^] # Re: Héhé

                        Posté par . Évalué à 4.

                        J'adore ce genre de réponse. Avant on nous vendait systemd comme un sysinit killer qui allait tout mieux faire, bien proprement et qu'on était vraiment des dinosaures à vouloir encore rester avec sysinit. Là, on est passé à un stade où on doit accepter d'avoir les mêmes bugs (parce que c'est un bug) que sysinit. Tout changer pour que rien ne change. D'autant plus que la réponse ne correspond pas à la question. On s'en fout qu'il y ait les mêmes problèmes avec sysinit. On l'a enterré sysinit (ou presque), le problème là il est bien dans systemd.

                        • [^] # Re: Héhé

                          Posté par . Évalué à 7.

                          D'autant plus que la réponse ne correspond pas à la question. On s'en fout qu'il y ait les mêmes problèmes avec sysinit.

                          Ben quand la remarque c'est « avant j'avais pas de problème avec sysvinit », c'est normal de faire la comparaison.

                          Et justement c'est un problème de compréhension.

                          • sysvinit te met OK si la commande qui lance le démon ne renvoie pas un code d'erreur
                          • systemd t'indique qu'il y a un problème si ton deamon a renvoyé un code d'erreur ou s'il s'est arrêté immédiatement (et je crois qu'il a d'autres solution)

                          En soit savoir qu'un deamon fonctionne est un problème bien plus complexe (et bien trop complexe pour un système d'init). La seule façon fiable consiste à faire du monitoring. Ici on est plus sur une question d’expérience utilisateur. C'est rassurant d'avoir ta commande qui te dis « ça va » que si elle ne te dis rien (même si ça a la même signification).

                          La solution probablement très complexe pour l'administrateur système consisterais à se créer une fonction :

                          function runsrv () {
                              systemctl start "$1" && systemctl status "$1"
                          }

                          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                          • [^] # Re: Héhé

                            Posté par (page perso) . Évalué à 7.

                            Je trouve que c'est bien plus simple de débugguer avec systemd.
                            J'ai eu un souci récemment avec ElasticSearch dont le paquet officiel se lance encore avec sysvinit.
                            Le service ne se lançait pas, et aucun log nulle part.

                            J'aurais bien aimé lancer la commande à la main, mais retrouver la commande réellement exécutée est particulièrement pénible vu la taille du script sysvinit.
                            Au contraire, avec systemd on a 4 lignes qui donnent l'utilisateur, le dossier, la ligne de commande et l'environnement. Du coup, c'est très facile de le lancer directement (et en l'occurrence de se rendre compte que java n'avait pas été installé).

                            • [^] # Re: Héhé

                              Posté par . Évalué à 7.

                              J'aurais bien aimé lancer la commande à la main, mais retrouver la commande réellement exécutée est particulièrement pénible vu la taille du script sysvinit.

                              bash -x /etc/init.d/elasticsearch start

                              • [^] # Re: Héhé

                                Posté par (page perso) . Évalué à 3.

                                bash -x /etc/init.d/elasticsearch start

                                Pourquoi pas directement « /etc/init.d/elasticsearch start » ?

                                • [^] # Re: Héhé

                                  Posté par . Évalué à 10. Dernière modification le 22/08/16 à 17:47.

                                  Pour pouvoir passer l’option -x qui demande à bash de logguer les commandes lancées par le script, ce qui répond à la problématique initiale (comment savoir quelle commande lance réellement le script d’init ?).

                          • [^] # Re: Héhé

                            Posté par (page perso) . Évalué à 1.

                            Bonjour,

                            Quand je relance nginx, s'il y a une erreur, avec systemd j'ai uniquement l'information comme quoi il y a eu une erreur, et je dois regarder le journal pour avoir les détails. Très chiant.

                            Avec sysvinit, j'avais directement les informations sur l'erreur.

                            Il y a clairement une régression avec systemd.

                            Concernant les retours vides avec sysvinit je regarderai en détail.

                            • [^] # Re: Héhé

                              Posté par . Évalué à 4.

                              Avec sysvinit, j'avais directement les informations sur l'erreur.

                              Et si ça se passe au démarrage du système ça va être perdu dans tous les messages de démarrage sans moyen d'aller le retrouver, alors qu'avec systemd ce sera quand même dans le journal et tu pourra retrouver l'information.
                              En plus, un systemctl status t'affiche les dernières lignes du journal pour l'unité concernée.

                              • [^] # Re: Héhé

                                Posté par (page perso) . Évalué à 2.

                                Mais pourquoi systemd ne laisse pas l'information lorsque je relance le service manuellement? Pour m'obliger à lire son journal. Donc à effectuer une operation de plus…

                                • [^] # Re: Héhé

                                  Posté par (page perso) . Évalué à 1.

                                  En même temps, je ne vois pas trop comment systemd pourrait déterminer le moment opportun pour afficher le log ?

                                  Imaginons, que ce soit dès que le processus est lancé: tu verras dans le log des lignes du genres "Starting service…." et tu ne verras pas qu'un peu plus tard le service n'arrive pas à atteindre certains fichiers. Là tu auras l'impression que systemd a menti car il a indiqué le status "OK", alors qu'en réalité le service a échoué.

                                  En fait, le seul cas que je vois pour que systemd puisse t'afficher un retour est le cas où le processus ne peut pas être exécuté (lanceur introuvable par systemd par exemple) ou la configuration du service ne suit pas les attentes de systemd. Il me semble que dans ce cas, systemd renvoie bien des erreurs.

                                  • [^] # Re: Héhé

                                    Posté par (page perso) . Évalué à -3.

                                    le retour que j'ai (quand il y a une erreur) c'est qu'il ya eu une erreur sans les détails. c'est une importante régression par rapport à sysvinit.

                                    • [^] # Re: Héhé

                                      Posté par . Évalué à 2.

                                      Ah ? Y'avait les détails dans SysVInit au démarrage ? (première nouvelle)
                                      Y'a des cas où journalctl ne donne pas le détail ? (deuxième nouvelle)

                                      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                                      • [^] # Re: Héhé

                                        Posté par (page perso) . Évalué à 1.

                                        Depuis le début je ne parle pas du démarrage du serveur.

                                        Je parle des cas où je change la configuration et que je regarde si le service se lance bien ensuite.

                                        journalctl va donner les détails, mais autant les avoir directement à la commande de relance du service, non? plutôt que de devoir lancer une autre commande pour avoir les détails.

                                • [^] # Re: Héhé

                                  Posté par (page perso) . Évalué à 4.

                                  Pour m'obliger à lire son journal.

                                  Ben non tu ne lis pas le journal quand tu fais : "systemctl status nginx"

                • [^] # Re: Héhé

                  Posté par . Évalué à 4.

                  depuis que j'ai systemd ma vie d'administrateur système est plus compliquée.

                  Difficile à croire, mais ok…

                  Quand je n'ai aucun retour, c'est pire parce que je dois vérifier si ke service tourne.

                  WUT ?!

                  Toi apprendre systemd, et revenir ensuite. Sérieusement !

                  "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                  • [^] # Re: Héhé

                    Posté par (page perso) . Évalué à 3.

                    J'ai eu ce cas.
                    Peut être un script mal foutu.

                    Je sais me servir des comandes de bases de systemd, et c'est devenu plus compliqué. En particulier parce qu'on a pas le retour complet en cas d'erreurs. Il faut lire le journal. Avant on avait directement les erreurs. Certes c'est plus difficile à parser éventuellement par d'autres scripts, et encore.

                    • [^] # Re: Héhé

                      Posté par (page perso) . Évalué à 5.

                      et c'est devenu plus compliqué.

                      Ce qui a l'air compliqué en 2016, c'est le fonctionnement d'Unix… Si tu veux les messages directement, il y'a plein de façon de faire sous Linux. Ça m'a pris 5 minutes…

                      [root@adm-cb bellegardec]# systemctl start sshd
                      -- Logs begin at ven. 2016-03-11 20:58:24 CET, end at jeu. 2016-08-25 09:27:07 CEST.
                      août 25 09:27:07 adm-cb systemd[1]: Started OpenSSH Daemon.
                      août 25 09:27:07 adm-cb sshd[1925]: /etc/ssh/sshd_config: line 5: Bad configuration o
                      août 25 09:27:07 adm-cb sshd[1925]: /etc/ssh/sshd_config: terminating, 1 bad configur
                      août 25 09:27:07 adm-cb systemd[1]: sshd.service: Main process exited, code=exited, s
                      août 25 09:27:07 adm-cb systemd[1]: sshd.service: Unit entered failed state.
                      août 25 09:27:07 adm-cb systemd[1]: sshd.service: Failed with result 'exit-code'.

        • [^] # Re: Héhé

          Posté par (page perso) . Évalué à 8.

          Mais en PowerShell tu n'as normalement pas besoin de parser le message d'erreur. Tu regardes le type de l'exception (CommandNotFoundException) et tu te moques royalement que le message d'erreur soit en klingon ou en anglais.

          Au contraire, le shell t'oblige à parser en permanence et le moindre petit changement de syntaxe peut amener des bugs aussi imprévisibles que pénibles à détecter.

          • [^] # Re: Héhé

            Posté par . Évalué à 1.

            Au contraire, le shell t'oblige à parser en permanence et le moindre petit changement de syntaxe peut amener des bugs aussi imprévisibles que pénibles à détecter.

            Les utilitaires UNIX modernes comme GNU find ou encore ls ont des options comme --format=comma ou -printf "…" qui permettent de s’assurer que ça ne va pas casser dans le futur… disons que ça en réduit la probabilité…

            Déterminer un format pour l’option -printf de la commande find ou choisir parmi les membres d’un objet PowerShell je ne vois pas trop la différence, c’est de l’objet dans les deux cas.

            • [^] # Re: Héhé

              Posté par (page perso) . Évalué à 5.

              Oui, peut-être pour find. Et pour les 9 999 autres commandes utilisables en shell ?

              Accessoirement, il faut quand même parser la sortie (ce qui est vite pénible quand elle ne se présente pas exactement sous la bonne forme).

              • [^] # Re: Héhé

                Posté par . Évalué à 2.

                On utilise pas 9 999 commandes en shell… Surtout si on se limite aux commandes qui produisent une information en sortie (donc exit cut, awk, sed, tr, …)

                Mais bon. J’ai rien contre PowerShell hein. Il m’arrive de l’utiliser. Dernièrement je m’étais penché sur la bonne manière de mesurer une charge CPU, c’est à dire en faisant plusieurs mesures et en calculant une moyenne, en prenant en compte le nombre de cœurs. Je l’ai fait pour AIX et Linux et par curiosité j’ai cherché comment faire de même sous Windows. La solution que j’ai trouvé en PowerShell est tout aussi simple que les solutions pour AIX ou Linux qui utilisent awk.

          • [^] # Re: Héhé

            Posté par . Évalué à 4.

            Pour les codes d'erreur Unix, ils sont à peu près standardisés dans sysexit.h. Pour les commandes de base, ça me semble assez bien suivi, j'irai pas dire comme tu le dis qu'il est nécessaire de parser en permanence.

          • [^] # Re: Héhé

            Posté par (page perso) . Évalué à 2. Dernière modification le 21/08/16 à 00:39.

            Au contraire, le shell t'oblige à parser en permanence et le moindre petit changement de syntaxe peut amener des bugs aussi imprévisibles que pénibles à détecter.

            En shell, je checke $?, pas toi ?

            • [^] # Re: Héhé

              Posté par (page perso) . Évalué à 0.

              Le rapport? C'est pas ça qui va te dire que ton expr précédent n'a pas matché le bon truc parce que la sortie de la commande a changé…

    • [^] # Re: Héhé

      Posté par . Évalué à 10. Dernière modification le 19/08/16 à 12:08.

      Sinon hostname -I ça marche bien aussi.

      Mais je comprend aussi très bien la devise Shadock : pourquoi faire simple quand on peut faire compliqué ? :)

      • [^] # Re: Héhé

        Posté par . Évalué à 1.

        Ouf Merci …

      • [^] # Re: Héhé

        Posté par (page perso) . Évalué à 2.

        hostname -I lit le fichier /etc/hosts pour te dire à quel point c'est limité: ne marche pas pour tout ce qui n'est pas serveur…

        • [^] # Re: Héhé

          Posté par . Évalué à 5. Dernière modification le 19/08/16 à 16:36.

          Heu… non.

          $ strace hostname -I 2>&1 | grep /etc
          access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
          access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
          open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
          access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
          access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
          

          (si tu fais un strace complet tu peux voir qu’il interroge directement le kernel via netlink)

  • # Pour qui?

    Posté par . Évalué à 5.

    Il ne reste que des developpeurs .JS de nos jours. :P

    • [^] # Re: Pour qui?

      Posté par . Évalué à 0.

      Et plutôt que de libérer des choses qui existent déja et en mieux, pourquoi ne pas libérer ce qui manque réellement, je sais pas moi, DirectX par exemple. :)

      • [^] # Re: Pour qui?

        Posté par . Évalué à 2.

        Si les gamers ne sont plus tenu par les c……s, la perte de part de marché risque de se sentir.

        • [^] # Re: Pour qui?

          Posté par . Évalué à -5.

          Ah ca c'est sur, si Linux reste à 1% sur le desktop c'est parce que les gamers sont tenus par les couilles sous Windows…

          Ah tiens, on me répond que les gamers ne sont pas 99% de la population desktop, et que les non-gamers n'en ont rien à battre de Linux non plus.

        • [^] # Re: Pour qui?

          Posté par (page perso) . Évalué à -10.

          Ils iront sur Mac alors, certainement pas Linux… Ou resteront sous Windows.
          Question idiote : pourquoi donc plein de non utilisateurs de DirectX (majoritaires sous Windows) sont toujours sous Windows?

          Je parie qu'on va trouver une raison "c'est la faute aux autres" et pas "ouais, on est pas bons", toujours reporter sur les autres ses (ou ici de sa "communauté") échecs plutôt que de se regarder en face.

          • [^] # Re: Pour qui?

            Posté par . Évalué à -9.

            Ils iront là où on leur dira d'aller pour la majorité : par exemple sur SteamOS.

            Les gamers se fouttent de la plateforme tant qu'ils ont leur dix icones et leur copains sur quakenet, je voulais dire Facebook pardon.

            Après il y a des mecs qui veulent faire des taffes de portage comme ce qu'a fait loki il fut un temp (ex : postal plus) mais ils étaient solides en terme de compétences.

            Bioware a créer un moteur qui utilise Opengl et DirectX et certains jeux fonctionnent sous Windows et sous Linux ca doit représenter un travail fou à déveloper tout en double.

            Et je ne parle pas des mecs qui continuent à retourner le passé dans FreeDos et Cedega.

            • [^] # Re: Pour qui?

              Posté par . Évalué à 0.

              Ils iront là où on leur dira d'aller pour la majorité : par exemple sur SteamOS.

              LOL!!1!one

              1000 jeux (pour la plupart bogués/injouables) sous Steam Linux / SteamOS, environ 7400 pour Steam sous Windows.

              Essaie encore…

              "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

          • [^] # Re: Pour qui?

            Posté par . Évalué à 4.

            Question idiote : pourquoi donc plein de non utilisateurs de DirectX (majoritaires sous Windows) sont toujours sous Windows?

            Je pense qu'un grosse part tiens du fait qu'en dehors de windows on n'ai aucune assurance que les périphériques que l'on possède ou achètera dans le futur sera compatible. En dehors des imprimantes, même les Maceux se limitent souvent à l'écosystème brandé Apple pour tout ce qui est réseau et périfs car ils ont peur des incompatibilités.

            D'après une sondage dans mon entourage, c'est parce qu'ils ne veulent pas prendre le temps de réapprendre autre chose que ce qu'ils utilisent au bureau. Un exemple con: ma compagne admet que openoffice répondrait à son besoin d'utilisation bureautique à la maison mais les menus sont pas tout à fait présentés pareils ete elle ne l'utilisera jamais assez à la maison pour justifier la courbe d'apprentissage. Aussi, dans l'hypothétique cas où elle devrait envoyer un document à quelqu'un (ça n'est à ma connaissance jamais arrivé, elle ne bosse pas à la maison) ayant office elle aurait besoin de faire vérifier chaque document aavant envoir final sur un pc avec MS office. Donc au final autant avoir office directement.

            Vue que de nos jours l'utilisation d'un ordinateur à la maison se résume de plus en plus à n'ouvrir qu'une seule application, un navigateur, je comprends aussi que personne ne soit intéressé à apprendre l'utilisation d'un OS différent, quelque soit la facilité/difficulté de la période d'apprentissage.

            • [^] # Re: Pour qui?

              Posté par (page perso) . Évalué à 4.

              Je pense qu'un grosse part tiens du fait qu'en dehors de windows on n'ai aucune assurance que les périphériques que l'on possède ou achètera dans le futur sera compatible.

              http://www.clubic.com/windows-os/windows-10/actualite-814102-webcam-windows-10-anniversaire.html

              * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

              • [^] # Re: Pour qui?

                Posté par . Évalué à 5.

                Sous Linux, les périphériques nouveaux ne marchent pas toujours par manque de support de la part des constructeurs qui ne se font pas chier à écrire un pilote pour un nombre d'utilisateurs assez réduit. Malheureusement c'est un cercle vicieux : pas de support pour les périphériques => faible adoption => marché de niche => pas de support pour les périphériques.

                A contrario, sous Window, les périphériques anciens ne marchent pas toujours par manque de support de la part des constructeurs qui ne se font pas chier à écrire un pilote pour un produit qui n'est plus sous garantie. Malheureusement ça conforte les fabricants dans leur choix puisque la réaction naturelle du client est de remplacer le produit par un plus plus récent.

    • [^] # Re: Pour qui?

      Posté par (page perso) . Évalué à 2. Dernière modification le 21/08/16 à 19:38.

      Il ne reste que des developpeurs .JS de nos jours. :P

      [mode vendredi]

      Ne leur donne pas d'idée malheureux !
      Ou on va se retrouver avec une sortie JSON sur tous les coreutils sous peu.
      Et un shell nodeJS à la place de bash.

      [/mode vendredi]

  • # Tu vends du rêve

    Posté par . Évalué à 6.

    >  Get-NetIPAddress –AddressFamily IPv4
    IPAddress         : 169.254.49.116
    InterfaceIndex    : 7
    InterfaceAlias    : Connexion au r?seau local* 3
    AddressFamily     : IPv4
    Type              : Unicast
    PrefixLength      : 16
    PrefixOrigin      : WellKnown
    SuffixOrigin      : Link
    AddressState      : Tentative
    ValidLifetime     : Infinite ([TimeSpan]::MaxValue)
    PreferredLifetime : Infinite ([TimeSpan]::MaxValue)
    SkipAsSource      : False
    PolicyStore       : ActiveStore
    
    IPAddress         : 169.254.146.157
    InterfaceIndex    : 4
    InterfaceAlias    : Ethernet
    AddressFamily     : IPv4
    Type              : Unicast
    PrefixLength      : 16
    PrefixOrigin      : WellKnown
    SuffixOrigin      : Link
    AddressState      : Tentative
    ValidLifetime     : Infinite ([TimeSpan]::MaxValue)
    PreferredLifetime : Infinite ([TimeSpan]::MaxValue)
    SkipAsSource      : False
    PolicyStore       : ActiveStore
    
    IPAddress         : 169.254.49.116
    InterfaceIndex    : 7
    InterfaceAlias    : Connexion au r?seau local* 3
    AddressFamily     : IPv4
    Type              : Unicast
    PrefixLength      : 16
    PrefixOrigin      : WellKnown
    SuffixOrigin      : Link
    AddressState      : Tentative
    ValidLifetime     : Infinite ([TimeSpan]::MaxValue)
    PreferredLifetime : Infinite ([TimeSpan]::MaxValue)
    SkipAsSource      : False
    PolicyStore       : ActiveStore
    
    IPAddress         : 169.254.146.157
    InterfaceIndex    : 4
    InterfaceAlias    : Ethernet
    AddressFamily     : IPv4
    Type              : Unicast
    PrefixLength      : 16
    PrefixOrigin      : WellKnown
    SuffixOrigin      : Link
    AddressState      : Tentative
    ValidLifetime     : Infinite ([TimeSpan]::MaxValue)
    PreferredLifetime : Infinite ([TimeSpan]::MaxValue)
    SkipAsSource      : False
    PolicyStore       : ActiveStore
    

    Bref, c'est l'équivalent de ip -4 a sous Linux.

    Pour afficher uniquement l'IP, je dois faire :

    > (Get-NetIPAddress –AddressFamily IPv4 -AddressState Preferred | Where-Object { $_.InterfaceAlias -ne 'Loopback Pseudo-Interface 1' }).IPAddress
    

    Je dois cependant reconnaitre que :

    • je suis naze en powershell, on peut probablement mieux faire
    • ça doit être sexy de manipuler des objets, une fois qu'on s'est habitue à la syntaxe(ce qui n'est pas mon cas)

    Par contre, la commande ne fonctionne pas avec powershell sous linux. Vu qu'il y a seulement le shell mais pas l'écosystème en dessous, beaucoup de choses ne doivent pas être fonctionnels.
    En revanche, ça peut être intéressant pour récupérer des infos/métriques de machines windows depuis une machine linux. A voir à l'usage si c'est plus pratique/complet/intéressant que SNMP/NRPE ou que faire tourner munin/collectd sous windows.

    • [^] # Re: Tu vends du rêve

      Posté par (page perso) . Évalué à 3.

      (Get-NetIPAddress –AddressFamily IPv4 -AddressState Preferred | Where-Object { $_.InterfaceAlias -ne 'Loopback Pseudo-Interface 1' }).IPAddress

      Si cette ligne de commande est la bonne, alors 102 % des arguments pro-PowerShell tombent à l'eau.
      J'ai trouvé des lignes de commande similaires. Quelqu'un a plus simple/court ?

      • [^] # Re: Tu vends du rêve

        Posté par . Évalué à 4.

        Get-NetIPAddress | select ipaddress

        Mais ces exemples sont un peu vains, le PowerShell est un langage orienté objets et plus haut niveau que Bash, avec une syntaxe plus clean.

        A noter l'autocomplétion très bien foutue du PowerShell sous Windows 10, avec un équivalent ncurse proposant les différentes options et arguments. Faites ctrl-espace pour l'essayer, le menu est ensuite navigable au clavier.

        Mieux, l'autocomplétion Intellisense. Par exemple :

        $svc = get-service
        $[svc]. < tab >

        Et hop, toutes les méthodes et propriétés applicables aux objets de la variable s'affichent, ici des services.

        Autre truc sympa, certaines méthodes de sysadmin. Exemple, supprimer tous les programmes contenant "runtime" :

        $apps = Get-WmiObject win32_product | where name -match "runtime"
        $apps | %{ $_.uninstall}

        Dans cet exemple PS voit que $apps est de type array, juste l'invoquer va donc envoyer les entrées de l'array dans un pipe, dont la sortie sera énumérée par une boucle foreach (%).
        $_ est la sortie du pipe, que l'on peut réutiliser autant que l'on souhaite.

        Evidemment, on pourrait autant faire un
        for i in $(rpm -qa | grep runtime); do rpm -e $i; done
        Mais au niveau syntaxe, c'est autrement moins bien foutu.

        Autre truc sympa en PS, le typage statique :
        [int]$i = 42
        $test = $42.tostring() + 2
        $test
        422
        $test.GetType()
        String

        Et pour ne rien oublier, il y a aussi la longue liste d'alias linux. Faites un man ps pour le fun. :-)

        • [^] # Re: Tu vends du rêve

          Posté par (page perso) . Évalué à 4. Dernière modification le 21/08/16 à 00:29.

          for i in $(rpm -qa | grep runtime); do rpm -e $i; done
          Mais au niveau syntaxe, c'est autrement moins bien foutu.

          $ yum remove '*runtime*'

          Ou si tu veux vraiment faire dans l'inutile (ou faire une démo de syntaxe), au choix :

          $ rpm -qa | grep runtime | xargs rpm -e
          $ rpm -e $(rpm -qa | grep runtime)
          
          # pour tout rpm moderne
          $ rpm -qa "*runtime*" | xargs rpm -e
          $ rpm -e $(rpm -qa "*runtime*")
        • [^] # Re: Tu vends du rêve

          Posté par (page perso) . Évalué à 4.

          Get-NetIPAddress | select ipaddress

          Ça donne ce résulat :

          ipaddress
          fe80::845d:be88:6a51:bbe4%14
          ::1
          192.168.1.8
          127.0.0.1
          

          Donc il faut ajouter autre chose. Toujours pas terrible par rapport à un bête Bash pour obtenir une information basique du système.

          • [^] # Re: Tu vends du rêve

            Posté par . Évalué à 0.

            C'est le ipaddress qui te gêne ? Tu peux rajouter -expandproperty après select pour sortir le texte brut, sans les métadonnées de l'objet.

            • [^] # Re: Tu vends du rêve

              Posté par . Évalué à 3.

              Je crois que ce qui le gêne, c'est qu'il liste toutes les IP.

              C'est équivalent à :

              ip a | grep -Eo '([0-9]+\.){3}[0-9]+'
              

              On peut même faire plus court en powershell :

              (Get-NetIPAddress).ipaddress
              

              Du coup j'explicite ma commande précédente :
              Get-NetIPAddress affiche les infos sur les interfaces réseaux
              –AddressFamily IPv4 affiche uniquement les IP IPv4
              -AddressState Preferred affiche uniquement les interfaces actives (exclu le ethernet non branché qui a quand même reçu une adresse APIPA)

              Dans mon example, j'obtiens donc 2 interfaces :
              - l'interface loopback
              - l'interface réseau active

              Pour exclure loopback, je pipe le résultat avec Where-Object { $_.InterfaceAlias -ne 'Loopback Pseudo-Interface 1' }

              J'obtiens alors uniquement l'interface active. Il ne reste plus qu'à extraire uniquement l'IP avec ().IpAddress (ou | Select IPAddress)

              La commande est alors celle que j'ai donné :

              (Get-NetIPAddress –AddressFamily IPv4 -AddressState Preferred | Where-Object { $_.InterfaceAlias -ne 'Loopback Pseudo-Interface 1' }).IPAddress
              

              Le lecteur attentif remarquera que :

              • ça renverra plusieurs IP si il y a plusieurs interfaces actives (VPN par exemple), mais c'est aussi le cas de la commande linux dans le journal
              • on peut gagner quelques caractères :
              (Get-NetIPAddress –AddressFamily IPv4 -AddressState Preferred | ?{ $_.InterfaceAlias -notmatch 'Loop
              back' }).IPAddress
              

              (« ? » est un alias pour Where-Object)

              • [^] # Re: Tu vends du rêve

                Posté par (page perso) . Évalué à 4.

                (Get-NetIPAddress –AddressFamily IPv4 -AddressState Preferred | ?{ $_.InterfaceAlias -notmatch 'Loop
                back' }).IPAddress

                On arrive à un degré d'illisibilité de la ligne tout à fait équivalent à celui de Bash.
                Donc l'argument comme quoi PowerShell est bien plus lisible/facile/etc car plus haut niveau, je ne suis pas convaincu.

                J'ai écrit 3 « programmes » en PowerShell d'une vingtaine de lignes utiles chaque, ils sont meilleurs qu'en Bash car ils permettent de gérer les exceptions, et ça c'est vraiment un énorme plus. Pour le reste, c'est kif-kif.

                • [^] # Re: Tu vends du rêve

                  Posté par . Évalué à 6.

                  Pour moi c'est pas vraiment la longueur de la ligne qui serait un avantage pour Powershell (bash serait probablement plus court), mais le fait que le coté objet donne une assurance que ce qu'un élèment veut recevoir du pipe est vraiment ce qu'il recevra, et pas la colonne d'avant - d'après parce que le format a changé ou que le texte avait un tab dedans qui a merdé le formattage, etc…

                  Ca fait des lignes plus longues à lire oui, mais plus claires et plus solides.

                  • [^] # Re: Tu vends du rêve

                    Posté par (page perso) . Évalué à 5.

                    Ca fait des lignes plus longues à lire oui, mais plus claires et plus solides.

                    Parles pour toi. Perso, je trouve cela imbitable… En plus il y a un mélange de CamelCase et de non camel case.

                    Dans la philosophie shell bash, tu passes effectivement par du traitement de texte dont dans 99% des cas, une commande sors du texte que tu vas traiter avec : sed, grep, awk, cut… Bref, cela revient toujours à faire a peu près la même chose. Pas besoin de connaitre un arbre de classe et de méthode, on travaille sur une analyse de texte.

                    Ensuite, l'objectif est de rester sur du script shell donc on ne fait pas un programme de 20000 lignes ;-) Quand tu commences à vectoriser les variables en bash (en gros simuler un dictionnaire), c'est qu'on va un peu loin…

                    • [^] # Re: Tu vends du rêve

                      Posté par . Évalué à 2.

                      Parles pour toi. Perso, je trouve cela imbitable… En plus il y a un mélange de CamelCase et de non camel case.

                      Question d'habitude.

                      Pas besoin de connaitre un arbre de classe et de méthode, on travaille sur une analyse de texte.

                      Ben euh… tu sais qu'il y a la completion en PowerShell hein ?

                      Mais sinon, le problème de nouveau c'est pas le nombre de commandes ou le nombre d'options, c'est la fragilité du bousin à cause du formattage en texte plutôt qu'avec un format solide qui assure que tu ne lis pas la mauvaise colonne 3 mois plus tard à cause d'un tab ou espace mal placé.

                      • [^] # Re: Tu vends du rêve

                        Posté par (page perso) . Évalué à 2.

                        Oui, mais laisse tombé, c'est juste de la mauvaise fois… Un script shell(init de distro, installeur de soft proprio, …) qui se vautre à cause de la raison que tu énonces, j'en vois au moins un par an…

                        • [^] # Re: Tu vends du rêve

                          Posté par . Évalué à 6.

                          Le vrai problème c'est que des outils qui sérialisent des objets .Net sur stdout pour pouvoir les manipuler en powershell j'en vois pas (et j'ai pas l'impression que ça se soit beaucoup exporté hors de soft écris par MS…). Et awk/perl (pour moi) reste imbattable lorsque je dois traiter du texte (un jour j'aimerais me mettre à emacs pour ça…). Du coup hors des actions de base du système et peut être de la suite Office, il faut aller les chercher les utilitaires pour faire à peu prêt tout et n'importe quoi.

                          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                          • [^] # Re: Tu vends du rêve

                            Posté par . Évalué à 4.

                            Je préfère justement Ruby pour traiter du texte à Bash.

                            De ce que je comprends, Ruby est très proche de Perl. Du coup, je suis curieux de savoir ce qui te gêne dans Perl spécifiquement pour traiter du texte ?

                            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                            • [^] # Re: Tu vends du rêve

                              Posté par . Évalué à 6.

                              Je ne connais pas très bien ruby, mais perl est vraiment bon pour ça. En fait c'est simple :

                              • quand c'est pour moi et rapide, c'est du zsh/awk. C'est ce que je pratique au quotidien pour mon utilisation de mon ordinateur donc je passe facilement de commandes complexe à script sans changer de langage (à quelque chose près je prends mon historique de commande et je le mets dans un fichier)
                              • quand c'est pour d'autres, j'utilise le born shell, comme ça je sais que ça passe partout
                              • quand j'ai des besoins plus sophistiqués, que je prends un peu de temps pour le faire j'utilise perl. Je maîtrise moins perl que zsh donc ça me prend forcément plus de temps

                              Je n'utilise pas perl en cli (sauf cas particulier) parce qu'il n'est pas très pratique je trouve (il est plus verbeux qu'un awk pour faire la même chose - même s'il a des idiomes très intéressant).

                              Globalement je fais bien plus de code glue que du traitement de texte donc je sors finalement rarement du shell (j'aimerais bien un peu plus me servir de perl - j'ai pas encore touché à perl6 -)

                              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                              • [^] # Re: Tu vends du rêve

                                Posté par . Évalué à 3.

                                Titre de l'image

                                Depending on the time of day, the French go either way.

                              • [^] # Perl vs AWK

                                Posté par . Évalué à 2.

                                Je n'utilise pas perl en cli (sauf cas particulier) parce qu'il n'est pas très pratique je trouve (il est plus verbeux qu'un awk pour faire la même chose - même s'il a des idiomes très intéressant).

                                Tu as des exemples où perl serait nettement plus verbeux ?

                                À mon avis, man perlrun
                                Notamment les options -n -l -a -F (-p aussi, mais plutôt pour remplacer sed).
                                Alors OK, souvent, j’arrive à un résultat un poil plus long avec perl qu’avec awk (de quelques caractères seulement)… jusqu’à ce que j’aie besoin d’une fonctionnalité qu’awk n’a pas, et là…

                                Je me demande toujours pourquoi, à part contrainte de portabilité, des gens utilisent encore awk voire sed, alors qu’ils sont beaucoup plus limités que perl et pas plus faciles.

                                Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

                                • [^] # Re: Perl vs AWK

                                  Posté par (page perso) . Évalué à 2.

                                  Je me demande toujours pourquoi, à part contrainte de portabilité, des gens utilisent encore awk voire sed, alors qu’ils sont beaucoup plus limités que perl et pas plus faciles.

                                  Je connais Awk, je ne connais pas Perl.
                                  Donc j'ai quand même une nette tendance à choisir un langage que je connais.

                                  Je ne suis pas contre d'apprendre un autre langage cela dit.

                                  • [^] # Re: Perl vs AWK

                                    Posté par (page perso) . Évalué à 5.

                                    Je connais Awk, je ne connais pas Perl.

                                    On passe facilement d'Awk à Perl car Awk est une des bases d'inspiration de Perl ;-)

                        • [^] # Re: Tu vends du rêve

                          Posté par (page perso) . Évalué à 4.

                          script shell(init de distro, installeur de soft proprio, …) qui se vautre à cause de la raison que tu énonces, j'en vois au moins un par an…

                          Pour ma part les script PowerShell que j'ai vu, je les ai justement vus car ils se vautrent. Et pas seulement une fois par an.
                          Les Bash qui se vautrent, j'en ai vu dans les trucs proprios ou pas, mais pas dans les init des distributions (Ça arrivera forcément un jour, mais pour l'instant aucun qui ne se plante à cause de l'entrée qui aurait magiquement changée).

                          c'est juste de la mauvaise fois

                          Voilà, c'est exactement ça :-)

                      • [^] # Re: Tu vends du rêve

                        Posté par (page perso) . Évalué à 6. Dernière modification le 23/08/16 à 12:03.

                        Ben euh… tu sais qu'il y a la completion en PowerShell hein ?

                        Oui ;-)

                        Mais sinon, le problème de nouveau c'est pas le nombre de commandes ou le nombre d'options, c'est la fragilité du bousin à cause du formattage en texte plutôt qu'avec un format solide qui assure que tu ne lis pas la mauvaise colonne 3 mois plus tard à cause d'un tab ou espace mal placé.

                        awk gère pas mal les espaces variables ;-)

                        Comment je fais un programme Fortran qui s'intègre bien dans PowerShell, comment je connecte tout cela avec mes scripts Perl ou OCamel ? Le paradigme du shell (Bash) et très simple : une entrée standard, deux sorties et un code entier de retour. C'est pas top top mais c'est universel. On enchaîne alors du traitement de texte pour faire de la glu sur tout cela. C'est pas objet, c'est pas typé mais c'est souple comme un langage humain et ça marche pas si mal depuis des dizaines d'année (pour certaines tâches précises).

                        Pour d'autres tâches, un langage plus typé est mieux. C'est pas pour rien que Larry Wall a crée Perl qui a donné un boom énorme ensuite à tous les langages de script.

                        Bref, je n'ai pas dis que PowerShell est de la merdiasse. Je dis juste que l'approche texte du shell Bash qui est orthogonale au langage de programmation "classique" est aussi très intéressante et assez universelle pour ce qu'on lui demande de faire ;-)

                      • [^] # Re: Tu vends du rêve

                        Posté par . Évalué à 7.

                        Mais sinon, le problème de nouveau c'est pas le nombre de commandes ou le nombre d'options, c'est la fragilité du bousin à cause du formattage en texte plutôt qu'avec un format solide qui assure que tu ne lis pas la mauvaise colonne 3 mois plus tard à cause d'un tab ou espace mal placé.

                        Non pas que je pense que c'est un bon design, mais bon.
                        Les tabulations, formatage etc font partie de l'api publique d'un outil en ligne de commande. Le changer, c'est Peter cette api, et les auteurs le savent. Tout comme les mecs de chez ms ne vont pas changer le nom d'un champs public, les mecs de ps ne vont pas changer leur format de sortie. En tout cas, je l'espère.

                        Après, on peut discuter de la pertinence d'un format plain text comme api publique en 2016, du manque de typage, de la résistance au changement en prétendant qu'un awk des bois est mieux qu'une api de haut niveau, et du temps gâché à maintenir les tabulations et tout en plaçe, et t'aurais pas tord, mais risque de peter sur une mise à jour est pas vraiment un argument valable.

                        Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                        • [^] # Re: Tu vends du rêve

                          Posté par . Évalué à 1. Dernière modification le 24/08/16 à 09:03.

                          Je ne parles pas d'un changement dans la sortie de l'application, mais le parsage de texte est super fragile car la séparation entre champs est très fragile.

                          Combien de ces softs te sortent des colonnes basées soit sur un espace ou un tab ? Imagine que le contenu d'une des colonnes contienne un tab ou un espace, pas ta prochaine commande dans le pipe va pas faire la diffèrence et verra une colonne de plus sur cette ligne…

                          Voila, c'est tout ce qu'il faut pour pêter le pipe, et c'est purement dû au fait que le formattage texte empêche une séparation forte entre les champs.

                          Et je ne parles pas du bordel que c'est de gèrer les nombres et faire du tri avec le formattage texte…

                          • [^] # Re: Tu vends du rêve

                            Posté par . Évalué à 2.

                            faire du tri avec le formattage texte…

                            sort -n ?

                            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                            • [^] # Re: Tu vends du rêve

                              Posté par . Évalué à 0.

                              0xaef

                              • [^] # Re: Tu vends du rêve

                                Posté par . Évalué à 3.

                                sort -g ?

                                Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                                • [^] # Re: Tu vends du rêve

                                  Posté par . Évalué à 1.

                                  Ben non… cf. cet exemple et la valeur 20400001000
                                  ```
                                  ubuntu@ip-172-31-1-133:~$ cat val3.txt
                                  400000000 _crt0
                                  400000039 __newr0
                                  400001C14 get_new_task_id
                                  400001385 output_str_j1
                                  200000020 reg1
                                  200000038 reg4
                                  20400001000 status
                                  400001E0C t1
                                  400001E70 t2
                                  400001D14 task
                                  id_to_ec_range

                                  ubuntu@ip-172-31-1-133:~$ cat val3.txt |sort -k1 -g

                                  400001C14 get_new_task_id
                                  400001D14 task_id_to_ec_range
                                  400001E0C t1
                                  200000020 reg1
                                  200000038 reg4
                                  400000000 _crt0
                                  400000039 _newr0
                                  400001385 output
                                  str
                                  j1
                                  20400001000 status
                                  400001E70 t2
                                  ```

                                  • [^] # Re: Tu vends du rêve

                                    Posté par . Évalué à 2.

                                    faut arrêter un minimum la mauvaise foi, pas que je critique ta religion, j'ai aussi tendance à la pratiquer, mais tu as demandé explicitement 0xaef, notation hexadécimale facilement reconnaissable; dans l'exemple que tu donnes.

                                    Rajoute un 0x en début de chaque ligne tu auras le résultat escompté.

                                    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                                    • [^] # Re: Tu vends du rêve

                                      Posté par . Évalué à 1.

                                      Ben tu commences à comprendre la problématique. J'ai filé des exemples de base pour montrer à quel point cela devient le bordel si le format change un tout petit peu. Tu remarqueras que dans le monde réel, c'est fréquemment plus compliqué que juste une colonne dont toutes les valeurs ont le même format.

                                      Tu as un type de donnée (un entier), et selon sa représentation textuelle, il faut utiliser 32 méthodes diffèrentes pour le traiter : utiliser des options diffèrentes, utiliser des commandes diffèrentes,…

                                      Rappelons la problématique : traitement de données arbitraire.

                                      Les données, elles pourraient être une colonne d'entiers en base 10, ça pourrait aussi être 5 colonnes dont la 3ême est la colonne de chiffres avec des colonnes séparées par des espaces ou tabs, mais pas de bol, les 2 premières colonnes sont des colonnes de texte, avec potentiellement des tabs-espaces dans le contenu. Et là ben tu vas t'amuser à rajouter ton 0x ou sortir la 3ème colonne pour la mettre en 1er

                                      Les données, tu contrôles par forcèment leur format, tu dois vivre avec. Alors oui, c'est "possible" de tout faire avec bash, mais mon dieu quel bordel et douleur pour le faire hors des cas simples.

                                      • [^] # Re: Tu vends du rêve

                                        Posté par . Évalué à 1.

                                        dans le monde réel

                                        Puis

                                        Rappelons la problématique : traitement de données arbitraire.

                                        Hum hum… Dans la vraie vie donc…

                                        Dans la vraie vie on a soit pas le problème (on s'appuie sur des formats stables ou maîtrisé comme un log par exemple), soit on ne fait pas de traitement de données (le shell c'est d'abord de la glue) soit on est déjà dans un langage largement mieux que n'importe quel shell.

                                        Donc dans la vraie vie, ça sert à quoi ? Une application concrète, hein ? Pas du big data non structuré.

                                        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                        • [^] # Re: Tu vends du rêve

                                          Posté par . Évalué à 1.

                                          Mais tu assumes que tu connais les données à l'avance, ce qui n'est évidemment pas le cas.

                                          Là cette semaine, je m'amuses à devoir traiter des données qui sont le résultat d'opérations sur un fichier reçu d'une boite externe histoire de sortir des stats.

                                          J'ai pas choisi le format, j'ai pas choisi quelles infos extraire, … J'ai essayé de le faire avec une ligne de pipes dans bash (le processus en question tourne sous Linux), j'ai perdu des cheveux et assez vite abandonné.

                                          • [^] # Re: Tu vends du rêve

                                            Posté par . Évalué à 4.

                                            Si tu essaie de me faire dire que le shell n'est pas fait pour tout, ben oui et ?

                                            Parser un fichier dont tu ne maitrise pas le contenu sera pas trivial quelque soit le langage. Le principal avantage d'autres langages sera qu'ils valident plus facilement les données (tu peut toujours valider en shell unix avec une expression régulière si tu veux avoir quelque chose plus fiable) et te remontent une erreur plus claire.

                                            Comment aurait-tu fait en powershell pour l'exemple que tu donne ? Une étape de déserialisation de chaque ligne dans un objet ? Cette désrialisation s'appuie sur quoi pour faire de l'arbitraire ?

                                            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                            • [^] # Re: Tu vends du rêve

                                              Posté par . Évalué à 2.

                                              Parser un fichier dont tu ne maitrise pas le contenu sera pas trivial quelque soit le langage. Le principal avantage d'autres langages sera qu'ils valident plus facilement les données (tu peut toujours valider en shell unix avec une expression régulière si tu veux avoir quelque chose plus fiable) et te remontent une erreur plus claire.

                                              Pas seulement, les autres langages ont aussi l'avantage que la déserialisation et conversion texte -> chiffre n'est à faire qu'une fois, au début.

                                              Comment aurait-tu fait en powershell pour l'exemple que tu donne ? Une étape de déserialisation de chaque ligne dans un objet ? Cette désrialisation s'appuie sur quoi pour faire de l'arbitraire ?

                                              Tout à fait, et évidemment cette étape initiale peut être plus ou moins complexe selon les données, mais une fois faite, je peux avoir 32 stages à mon pipe, et je n'ai plus à faire de conversion ou autres, c'est bien plus simple.

                                              Et oui évidemment tu peux faire ça en python très bien, c'est ce que j'ai fait au final (flemme de passer le fichier sur Windows).

                                          • [^] # Re: Tu vends du rêve

                                            Posté par . Évalué à 1. Dernière modification le 26/08/16 à 09:42.

                                            quand je fais du shell, je connais le format à l'avance, c'est généralement un enchainement de commandes; si c'est pour traiter des fichiers textes, j'aurais tendance à utiliser perl ou python; pour ton exemple simple, le shell suffit.

                                            sed -r 's/^/0x/' < val3.txt | sort -g -k1

                                            tu n'es vraiment pas allé cherché loin.

                                            je m'amuses à devoir traiter des données qui sont le résultat d'opérations sur un fichier reçu d'une boite externe histoire de sortir des stats.

                                            et comment fais-tu la différence entre un nombre en octal/décimal/binaire/hexadécimal?

                                            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                                            • [^] # Re: Tu vends du rêve

                                              Posté par . Évalué à 2.

                                              tu n'es vraiment pas allé cherché loin.

                                              La question n'est pas si je suis allé chercher loin. Bash est turing complet, au final tu peux écrire un browser web complet en bash si tu veux. C'était simplement de démontrer à quel point bash peut être douloureux à cause du traitement en texte de tout ce qui passe, à chaque étape

                                              et comment fais-tu la différence entre un nombre en octal/décimal/binaire/hexadécimal?

                                              Si il n'a aucune indication, ca va être impossible évidemment, mais t'as typiquemment un préfixe. Et pour n'importe quel traitement un peu complexe tu fais simplement une première passe ou tu déserialise les données et les convertit pour les tourner en objet, et ensuite tu peux faire les traitement que tu veux de manière simple et sûre, là ou en bash tu es forcé de traiter du texte à chaque stage de ton pipe et te retaper de maudites conversion - parsing à chaque étape.

                                              • [^] # Re: Tu vends du rêve

                                                Posté par . Évalué à 2.

                                                Oui enfin là on attends toujours ton exemple de comment faire en PS; comme il semblerai que tu ais agrégé des sources hors contrôle, je doute que tu puisse t'affranchir du parsing du texte pour le convertir en objet comme tu dis avec le risque de te planter lors de la rédaction de la desserialisation ou sérialisation; j'ajouterai que si pour trier un bête fichier texte sur une clé hexa, je dois écrire 5 lignes, c'est qu'il y a une couille quelque part.

                                                et ensuite tu peux faire les traitement que tu veux de manière simple et sûre,

                                                Qu'entends tu par simple et sure? Pour prendre exemple sur le c++ ou le java c'est pas le fait qu'un langage soit objet à typage fort qui le rend simple ou sûr; à moins de blinder ton parseur, il est très probable que l'on trouve des solutions pour l'envoyer dans les choux, et là on se heurte au premier problème, si ça devient trop gros/compliqué, on passe par du perl/c/c++/python/ruby…

                                                Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                                                • [^] # Re: Tu vends du rêve

                                                  Posté par . Évalué à 1.

                                                  Tout a fait, il faut faire ton parsing avec n'importe quel langage utilisé

                                                  En powershell, la ligne pour du hex serait :

                                                  Get-Content val.txt | sort {[convert]::toint64($_.split()[0],16)}

                                                  Je te dirais que c'est bien plus lisible et comprehensible, la function te lance une erreur si la conversion ne fonctionne pas, il est explicite dans la ligne que c'est de l'hex, tu n'as pas à devoir rajouter un '0x' en texte et risquer un problème si par hasard il y en a déjà un, la fonction supporte 0x 0X ou même pas de préfixe.

                                                  • [^] # Re: Tu vends du rêve

                                                    Posté par . Évalué à 3.

                                                    oh un truc comme ça alors :

                                                    cat val.txt| while IFS=" " read hex reste ; do RES[16#$hex]="$hex $reste"; done && printf "${RES[*]}"

                                                    ou si tu veux en perl (je pense qu'il y a moyen de faire plus simple, mais j'ai la flemme de chercher)

                                                    perl -we 'print sort { hex((split / /,$a)[0]) <=> hex((split / /,$b)[0]) } <>' val.txt

                                                    selon la version de perl il faudra potentiellement utiliser les bigint

                                                    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                                                    • [^] # Re: Tu vends du rêve

                                                      Posté par . Évalué à 0.

                                                      Ben oui bien sur que c'est faisable, je ne doutes pas de la faisabilité.

                                                      Mais regarde ta version bash, tu trouves ça pratique et simple?

                                                      • [^] # Re: Tu vends du rêve

                                                        Posté par . Évalué à 2.

                                                        Clairement, non.

                                                        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                                                      • [^] # Re: Tu vends du rêve

                                                        Posté par . Évalué à 3.

                                                        Mais regarde ta version bash, tu trouves ça pratique et simple?

                                                        Pratique non, simple oui.

                                                        (sinon pour ceux que ça intéresse, y a encore une autre solution mixant perl et bash :

                                                        perl -lpe '$_=hex' file.txt | \
                                                        paste -d" " - file.txt  | \
                                                        sort -n | \
                                                        cut -d" " -f 2-

                                                        trouvé ici (en même temps que la question originale ) http://ask.systutorials.com/813/how-sort-file-hexadecimal-numbers-linux-using-sort-command (Mai 2014)

                                                        Manque encore une réponse python et awk, qui s'y colle.

                                                        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                                            • [^] # Re: Tu vends du rêve

                                              Posté par . Évalué à 5.

                                              si c'est pour traiter des fichiers textes, j'aurais tendance à utiliser perl ou python; pour ton exemple simple, le shell suffit.

                                              sed -r 's/^/0x/' < val3.txt | sort -g -k1

                                              D'ailleurs ça n'a rien de spécifique au shell.
                                              Tu as des données → tu les valides → tu les normalise → tu fais ton calcul dessus.
                                              Je veux dire, même dans le plus puissant des langages si tu as une entrée tu va soit normaliser soit valider (soit les deux).

                                              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                      • [^] # Re: Tu vends du rêve

                                        Posté par . Évalué à 4.

                                        Alors oui, c'est "possible" de tout faire avec bash, mais mon dieu quel bordel et douleur pour le faire hors des cas simples.

                                        Et encore, quand tu dois traiter / faire des tests sur des valeurs numériques, la manière de faire en script shell est à pleurer (première raison pour laquelle j'utilise Ruby à la place)

                                        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                          • [^] # Re: Tu vends du rêve

                            Posté par . Évalué à 10.

                            Faut surtout arrêter le délire. les shell (que ce soit bash, zsh ou PowerShell) sont là pour faire du glue code.

                            Ça fait 30 ou 40 ans que le shell POSIX existe et on a une myriades de langages qui sont largement capable de faire tous les traitements que tu peux imaginer des dizaines de fois plus efficacement. La majorité des unix arrivent de base avec un perl et un python, hein ?

                            De la même manière PowerShell arrive avec .Net ce qui permet de faire du VB.Net et c'est tant mieux parce que la quantité de logiciels qui peuvent vraiment discuter en powershell est assez faible (encore une fois je n'en connais pas hors outils de base de windows et outils spécifiques) et il est impossible si tu n'a pas fait le choix à l'origine d'un langage compatible…

                            Bref les capacités de traitements de texte d'un shell servent la majorité du temps à manipuler du log. C'est un cas ou powershell est inefficace (du moins tant qu'il n'y a pas quelque chose comme Lumberjack qui se démocratise) et où tu as un format à peu près stable (pour une sortie donnée).

                            Bref tu peux troller comme tu veux, mais :

                            • là où les shells unix sont null, il existe déjà des alternatives nettement plus efficaces que PowerShell
                            • les problèmes des shells sont très limité quand on regarde les cas d'usage réels (et pas les idées théoriques qu'on voit partout)
                            • PowerShell est joli (sincèrement) avec du typage et tout mais il pèche par un besoin d'écosystème spécifique, par le fait que cet écosystème est très petit et que la croissance de cet écosystème est limité par les contraintes technique (il faut utiliser .Net pour pouvoir discuter avec PowerShell)

                            Bref c'est cool que PowerShell arrive sur linux, ça simplifie un peu le portage Windows → Linux, mais ça s'arrête là il est très loin de pouvoir changer quoi que ce soit à la donne des langages utilisés sur unix (ou linux).

                            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                            • [^] # Re: Tu vends du rêve

                              Posté par . Évalué à 2.

                              Tu as raté un élément très important de Powershell :

                              il peut utiliser n'importe quel objet COM de manière naturelle, sans que l'application ait été prévue pour Powershell.

                              Et les interfaces COM dans les softs sous Windows sont super-répandues pour permettre l'administration, et cela depuis des siècles.

                              cf. Citrix par exemple : https://www.citrix.com/blogs/2008/07/25/powershell-and-mfcom-lets-get-started/

                              • [^] # Re: Tu vends du rêve

                                Posté par . Évalué à 3.

                                J'ai aussi vu que vmware expose une api powershell. C'est cool :-)

                                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Tu vends du rêve

      Posté par . Évalué à 7.

      Vu qu'il y a seulement le shell mais pas l'écosystème en dessous, beaucoup de choses ne doivent pas être fonctionnels.

      bah, j'imagine que Red Hat a mis Lennart Poettring pour travailler activement dessus, et d'ici 4-5 ans c'est powershell qui va remplacer bash sur toutes les distributions.

Suivre le flux des commentaires

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