Journal PowerShell: tapez rm -rf c:\Windows ! ;)

Posté par  .
Étiquettes : aucune
0
15
nov.
2006
La nouvelle version du shell de Microsoft vient de sortir en version stable comme l'indique Clubic ici :
http://www.clubic.com/actualite-65426-windows-powershell-dis(...)

L'idée de ce journal n'est pas de lancé un troll, mais surtout de partager ma joie de pouvoir enfin avoir un shell digne de ce nom sous Windows. Et le plus fort, c'est que les commande Linux y sont reconnues.

Le principe de ce shell, n'est pas de traiter du texte comme sous Linux, mais des objets (grosso modo du C#) pour des exemples comparants la syntaxe avec KSH :

http://blogs.msdn.com/powershell/archive/2006/04/25/583272.a(...)

Enfin bref, une bonne nouvelle pour les admins Linuxiens qui ont aussi des serveurs Windows.
  • # GNU is Not Unix

    Posté par  . Évalué à 9.

    Those who do not understand Unix are condemned to reinvent it, poorly.

    Henry Spencer, November 1987
    • [^] # Re: GNU is Not Unix

      Posté par  . Évalué à 5.

      En quoi, c'est plus pauvre ? Tu devrais regarder le lien montrant la syntaxe, ça donne des choses assez sympa. Enfin bref, j'ai fais l'erreur de mettre "Microsoft" dans le journal ^_^

      C'est sur que c'est pas aussi mature que du Bash et consort, mais au moins ça va dans le bon sens. Et ça fait un argument a envoyer aux anti linuxien primaires qui considère la ligne de commande comme has-been.
      • [^] # Re: GNU is Not Unix

        Posté par  . Évalué à 10.

        Ben... *C'est* has-been la ligne de commande, c'est juste qu'on n'a pas encore inventé mieux...

        Yth.
  • # Amis journalistes

    Posté par  . Évalué à 5.

    Prenez le temps de lire les commentaires de http://blogs.msdn.com/powershell/archive/2006/04/25/583272.a(...) avant de faire "woaaw" sur les exemples.
    • [^] # Re: Amis journalistes

      Posté par  . Évalué à 5.

      De toute facon ca ce voit au premier coup d'oeil ... les exemples mettent en valeur le fait que avec le powershell, c'est plus facile : c'est sur qu'en choisissant des commandes bourrées de sed , awk et compagnie, ca fait des commandes un peu obscures quand on ne maitrise pas.
      Mais en fait c'est du vent !
      Déjà l'auteur ne semble pas connaitre des commandes comme "pkill" ou "du", ensuite, il est facile d'imaginer de simples aliases/fonctions ou commandes supplémentaires pour reproduire les "super" possibilités de ce powershell ...

      A la rigueur, seule la syntaxe objet "xxx.methode" est nouvelle, mais entre manipuler des objets et des chaines de carcateres, y'a en effet un grand pas à franchir ... les exemples ne vont pas bien loin, il faudrait vraiment voir quelles sont les possibilités d'extension et d'utilisation dans des cas de besoin réels ...
      • [^] # Re: Amis journalistes

        Posté par  . Évalué à 8.


        Déjà l'auteur ne semble pas connaitre des commandes comme "pkill" ou "du"


        En général, il ne faut jamais prendre de l'incompétence pour de la malice. Cependant, dans le contexte fortement marketing...
      • [^] # Re: Amis journalistes

        Posté par  (site Web personnel) . Évalué à 6.

        ce qui transparait de manière évidente c'est que tu es limité à faire ce que l'objet te permet de faire.

        Le texte, tu le manipules comme tu veux.

        $process.memory pour avoir la mémoire. Ok. Mais si tu veux faire autre chose ?

        En plus l'argument comme quoi "la commande avec ps -e est fragile. Que se passe-t-il sur les systèmes ou y'a pas de -e à ps ?"

        naaaan... pas possible ? Et on fait quoi sur les systèmes ou $process à pas de .memory ??

        Vraiment pas convaincu sur ce coup-ci.
        • [^] # Re: Amis journalistes

          Posté par  (site Web personnel) . Évalué à 8.

          ce qui transparait de manière évidente c'est que tu es limité à faire ce que l'objet te permet de faire.

          Le texte, tu le manipules comme tu veux.

          En .NET (vu que c'est du .NET dessous), tous les objets héritent de la méthode ToString. Donc après tu fais ce que tu veux :)
          • [^] # Re: Amis journalistes

            Posté par  . Évalué à 7.

            Heureusement que sous linux c'est pas le cas :
            tu lance ton kernel, tu as une merde tu veux booter sur init=/bin/sh
            Non non faut récup les librairies .net avant :-d
            • [^] # Re: Amis journalistes

              Posté par  (site Web personnel) . Évalué à 2.

              C'est clair que le shell UNIX est au coeur du système et que de très grande partie sont scripté en shell.

              Un des problèmes est que Windows ne démarre pas en mode terminal même si j'ai cru voir qu'une version de Vista le pourra. Le problème suivant est je n'ai pas connaissance qu'une seule partie de l'OS soit pour le moment en script. Il y a donc encore du boulot pour avoir un système souple et adaptable facilement.

              Sur un UNIX, toute la connaissance que l'on apprend dans le terminal peut ensuite être réutiliser au coeur du système. C'est très positif.

              Ce nouveau shell windows, c'est bien mais n'aurait-il pas été plus intéressant pour Microsoft d'intégrer un langage de script existant (et non de shell) à .Net, un langage dont le coeur est objet, je pense à Ruby par exemple, pour ensuite reprogrammer un partie de Windows en script justement.
              • [^] # Re: Amis journalistes

                Posté par  . Évalué à 3.

                http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPytho(...)

                Désolé Ruby ca sera pour une autre fois o:)
                • [^] # Re: Amis journalistes

                  Posté par  (site Web personnel) . Évalué à 2.

                  J'ai fait exprès de mettre Ruby pour ne pas tomber dans le troll Perl/Python.

                  Python, c'est bien mais comme Perl, c'est pas du pur objet.

                  Ruby est complètement objet dès le début, avec l'intropection et tout et tout. Bref, cela me parait clairement un meilleur choix pour l'architecture .Net. Et c'est pas parce que je suis fanat de Ruby, je ne l'a jamais vraiment utilisé...
                  • [^] # Re: Amis journalistes

                    Posté par  (site Web personnel) . Évalué à 2.

                    Le but de .NET c'est aussi de proposer le choix des langages : .NET a déjà de nombeux langages de script, que ce soit JScript (javascript en gros), IronPython, Boo ou encore RubyCLR. Pourquoi choisir tel ou tel langage ? Question de situation. Visiblement Microsoft a préférer faire un nouveau langage de script, fortement inspiré de la syntaxe C/C#, orienté script. Après on aime ou on aime pas, les goûts et les couleurs hein :) La syntaxe C a quand même l'avantage d'être la plus "traditionnelle" et donc la plus compréhensible par tous.
                    • [^] # Re: Amis journalistes

                      Posté par  (site Web personnel) . Évalué à 4.

                      Je sais qu'on n'aime pas dire du mal de python sur ce site mais de la à perdre des points...

                      Sinon, je sais que .Net est ouvert sur les langages, cela n'empêche que Microsoft pousse particulièrement C# devant les autres.

                      Au niveau des langages de scripts qui existe, je persiste à penser que Ruby est plus proche de l'esprit .Net que Python (Ben oui, en Python, on se traine le self pour chaque méthode... C'est pas mieux en Perl).

                      Ensuite, Ruby est aussi basé sur une syntaxe à la C, bien plus que Python.

                      Bref, je ne critique pas le choix du shell de Microsft ici au niveau syntaxe. Mais à partir du moment ou ils ont fait un choix pour privilégier un langage compilé à typage fort (C#) et un langage shell, je dis simplement qu'ils auraient pu faire le choix pour un langage de script.
                      • [^] # Re: Amis journalistes

                        Posté par  (site Web personnel) . Évalué à 1.

                        Je sais qu'on n'aime pas dire du mal de python sur ce site mais de la à perdre des points...
                        Paf, -1 (non, je plaisante)

                        Ben oui, en Python, on se traine le self pour chaque méthode...
                        C'est fait exprès, c'est expliqué là pourquoi (en anglais):
                        http://effbot.org/pyfaq/why-must-self-be-used-explicitly-in-(...)

                        Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

                        • [^] # Re: Amis journalistes

                          Posté par  (site Web personnel) . Évalué à 2.

                          Je sais que c'est fait exprès, mais du coup, ce n'est plus vraiment un langage pur objet.

                          C'est pas forcément un mal. Perl6 avec Parrot prennent aussi une direction intéressante. Ils ont choisis de ne pas faire du pur objet pour pas mal de raison et notament cela permet de faire du multi-dispatch.

                          Bref, j'essaye de me placer ici dans le contexte .Net (que je connais très mal) et non dans mon contexte personnel ;-)
                  • [^] # Re: Amis journalistes

                    Posté par  . Évalué à 2.

                    Tu peux détailler ton "Python c'est pas du pur objet" ?
          • [^] # Re: Amis journalistes

            Posté par  . Évalué à 2.

            on en revient continuellement au problème de l'oeuf et de la poule : en quoi faut-il écrire nos scripts et applis pour configurer windows la première fois et pour lui installer par exemple le framework ?

            Microsoft a une solution autre que vbscript ou part-il dans le tout-framework ?
          • [^] # Re: Amis journalistes

            Posté par  . Évalué à 3.

            En effet ... mais est-ce que ca offre la même souplesse ?

            Par exemple, pour le stockage des informations dans un fichier:
            le résulatt du "ps" je peux le vider dans un fichier, ensuite, je peux tout à fait relire ce fichier (humainement parlant:c'est du texte), mais je peux aussi réutiliser ce fichier en le vidant dans d'autres commandes comme si c'était le résultat direct de mon "ps".

            Qu'en est-il ici ?
            Si je balance le résulat de mon "getprocess" dans un fichier :
            - pourrais humainement relire ce fichier ?
            - pourrais effectuer un "stopprocess < mon_fichier" ?
            • [^] # Re: Amis journalistes

              Posté par  . Évalué à 1.

              "pourrais humainement relire ce fichier ?"

              Ben la méthode toString comme son nom l'indique étant réservé à l'affichage il vaut mieux que ses concepteurs aient prévu un format lisible
              • [^] # Re: Amis journalistes

                Posté par  . Évalué à 5.

                Evidemment !
                Mais est ce qu'une redirection dans un fichier permettra ensuite une utilisation identique lors de la lecture du fichier vers d'autres commandes ?
                Y'a 2 besoins dans ma remarque, les unix-shell répondent aux 2, est-ce que le power shell le fait aussi ?
                (je rajouterai presque un "faut lire jusqu'au bout!")
                • [^] # Re: Amis journalistes

                  Posté par  (site Web personnel) . Évalué à 4.

                  Je suis d'accord avec toi.

                  Le principe de base du shell est d'être unifié avec l'approche fichier d'UNIX.

                  Donc, on doit tout pouvoir rediriger dans un fichier puis traiter ce fichier plus tard ou balancer dans un pipe. Bref, il n'y a pas de différence entre pipe et fichier.

                  La, si le pipe n'est pas un "fichier", cela change tout.

                  C'est vrai qu'on a tendance à balancer dans un fichier en remplacement d'un stockage dans une variable. Mais quand même...

                  Bref, ce nouveau shell, faut le voir à l'usage.
                  • [^] # Re: Amis journalistes

                    Posté par  (site Web personnel) . Évalué à 5.

                    L'astuce, c'est que la plupart des objets de base du framework .NET sont "serializables" en fichier XML. Ca permet de faire des choses comme ca dans le powershell :
                    PS> $a=get-process ps
                    PS> $a

                    Handles PM(K) WS(K) VS(M) Id ProcessName
                    ------- ----- ----- ----- -- -----------
                    270 18536 25188 127 804 ps
                    514 55288 56944 175 2356 ps

                    PS> get-process ps |export-clixml abc.xml
                    PS> import-clixml abc.xml

                    Handles PM(K) WS(K) VS(M) Id ProcessName
                    ------- ----- ----- ----- -- -----------
                    270 18536 25188 127 804 ps
                    562 55300 56956 175 2356 ps

                    (désolé pour les tabulations)
                    Bref, tu ne perds pas le type de tes objets :)
                    • [^] # Re: Amis journalistes

                      Posté par  (site Web personnel) . Évalué à 2.

                      Effectivement, j'avais oublié cela.

                      Bon d'un point de vu syntaxe, c'est pas très beau. Peut être des redirection < et > particulière serait les bienvenues.
        • [^] # Re: Amis journalistes

          Posté par  (site Web personnel) . Évalué à 4.

          $process à pas de .memory
          Là l'intérêt c'est que ta variable process est typée par une classe du framework, en l'occurence System.Diagnostics.Process ( http://msdn2.microsoft.com/fr-fr/library/system.diagnostics.(...) ). C'est compilé, en standard dans le framework. Bref, t'es sûr que ta propriété "memory" existe. C'est d'ailleur tout l'intérêt du truc.
          Et le truc génial c'est surtout que tu peux faire :
          foreach($proc in get-process){ $proc.
          là tu appuis sur [TAB] et il te propose l'ensemble des propriétés de l'objet $proc, il a deviné tout seul qu'il était de type Process par introspection sur la méthode get-process qui renvoie une List < Process > .
          • [^] # Re: Amis journalistes

            Posté par  . Évalué à 10.

            ça a l'air trop bien, dommage que ça n'existe pas sous unix, on pourrait
            refaire tout ce qu'on fait deja, mais en different...!
  • # ya du progrès

    Posté par  (site Web personnel) . Évalué à 10.

    Whaouu, ya un bond technologique indéniable chez Microsoft.

    Mais est-ce que ça permet d'administrer à distance des serveurs Windows avec autant de facilité et de puissance que sous Linux ?


    Avec Linux/SSH/Bash je peut controler à 200% mes machines. Y compris mettre à jour une distrib après avoir modifier les partitions du disque système en seulement 3 reboots...

    La puissance du shell unix, vient du fait qu'on assemble la puissance et la fonctionnalités de plein de programmes indépendants les uns des autres. Chacun de ces programmes ayant eux-mêmes des capacités insoupconnées et extensibles.

    Ici avec ce shell de MS on est limité aux fonctions intégrés. Certes le bond est prodigieux comparé à command.com, mais encore bien loin d'un vrai shell.
    • [^] # Re: ya du progrès

      Posté par  . Évalué à 1.

      Je me posai la question d'un SSH, je sais qu'il existe des serveurs SSH sous Windows mais la plupart sont payants (enfin je crois). Mais si ça peut marcher avec un serveur SSH ça pourrait etre pas mal.

      Aprés les outils en ligne de commande comme fdisk me semble pas existait mais rien empecherait des projets de le faire, non ? (je sais pas si Microsoft offre une API ou aux autres pour interagir avec les partoches et compagnie).
      • [^] # Re: ya du progrès

        Posté par  (site Web personnel) . Évalué à 5.

        Je me posai la question d'un SSH, je sais qu'il existe des serveurs SSH sous Windows mais la plupart sont payants (enfin je crois). Mais si ça peut marcher avec un serveur SSH ça pourrait etre pas mal.


        Openssh server existe sous windows et fonctionne bien.
      • [^] # Re: ya du progrès

        Posté par  (site Web personnel) . Évalué à 2.

        Je me posai la question d'un SSH, je sais qu'il existe des serveurs SSH sous Windows mais la plupart sont payants (enfin je crois).

        Copssh n'est pas payant, est assez simple à installer, et fonctionne bien.

        http://www.itefix.no/phpws/index.php?module=pagemaster&P(...)

        Je l'ai mis en place pour pouvoir faire du contrôle distant de machine via une connexion sécurisée (et via UltraVNC pour le déport d'affichage... c'est quand même sous Windows, tout ne se fait pas encore via la ligne de commande).

        Maintenant, si Microsoft rend tous ses outils d'admin utilisables avec PowerShell, ça va être sympa.

        Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

    • [^] # Re: ya du progrès

      Posté par  (site Web personnel) . Évalué à 3.

      Ici avec ce shell de MS on est limité aux fonctions intégrés.
      Ah non pas du tout. C'est comme sous n'importe quel unix, tu peux utiliser n'importe quel soft qui lit ou écrit sur l'entrée/sortie standard. Là c'est juste qu'il y a une gestion "intelligente" des objets .NET et COM grâce à l'introspection, offrant une approche orientée objet aux scripts.
      Alors non, ce n'est pas limité aux fonctions prédéfinis, c'est plutôt extensible à l'infini.
    • [^] # Re: ya du progrès

      Posté par  . Évalué à 2.

      Pas besoin de ca, il y a deja qqe chose qui existe depuis longtemps et qui fait ca tres tres bien, ca s'appelle WMI, et niveau simplicite et homogeneite ca ridiculise ssh (va t'amuser a faire un ssh sur 2500 machines differentes de ton parc pour effectuer qqe operations, meme avec un script c'est tres rigolo), d'un autre cote, SSH et WMI sont pas prevus pour la meme chose, SSH n'a jamais ete prevu pour faire de l'administration de gros parcs a distance, c'est juste un abus d'utilisation par manque d'outils adaptes.

      La puissance du shell unix, vient du fait qu'on assemble la puissance et la fonctionnalités de plein de programmes indépendants les uns des autres. Chacun de ces programmes ayant eux-mêmes des capacités insoupconnées et extensibles.

      Ici avec ce shell de MS on est limité aux fonctions intégrés. Certes le bond est prodigieux comparé à command.com, mais encore bien loin d'un vrai shell.


      Ah bon ? T'as vu ou qu'il etait impossible d'ajouter tes propres commandes ?
      • [^] # Re: ya du progrès

        Posté par  (site Web personnel) . Évalué à 6.

        > SSH n'a jamais ete prevu pour faire de l'administration de gros parcs a distance

        Mais comment qu'ils font alors pour administrer les clusters du top500 ??!!
        Ils vont devant chaque noeuds de calcul une disquette à la main pour mettre à jour les logiciels ?
        • [^] # Re: ya du progrès

          Posté par  . Évalué à 3.

          Ils utilisent un tas d'outils differents, dont SSH, ca veut pas dire que c'est le meilleur outil possible pour ce job.

          Mais a mon avis tu n'as aucune idee de ce que WMI est et est simplement convaincu que SSH est ce qu'il y a de mieux pour ce boulot.

          Qu'on ne s'y trompe pas, SSH est un tres bon soft, mais ca veut pas dire qu'il est adapte a toutes les situations.
        • [^] # Re: ya du progrès

          Posté par  (site Web personnel) . Évalué à 4.

          Il y a des outils pour administrer les clusters qui ont la particularité d'avoir des noeuds homogène dans de nombreux cas.

          Sinon, pour un parc hétérogène, ssh ne suffit pas. ClusterSsh aide et permet d'administrer par exemple un vingtaine de machine en parallèle mais ce n'est pas suffisant.

          Très vite se pose le problème de la gestion au quoditien...

          Personnellement, j'utilise cfengine qui autoconfigure tous mes postes Linux et permet de gérer de manière souple et dans le temps des machines très différentes de manière centralisé.
      • [^] # Re: ya du progrès

        Posté par  . Évalué à 7.

        WMI a pas vraiment besoin de ridiculiser SSH vu que c'est pas du tout la même chose et que ca sert pas du tout à la même chose.
        Et evidemment qu'il faut eviter d'administrer 2500 machines une par une avec du SSH...
        Par contre les outils adaptés (dont certains se servent de SSH comme primitive d'ailleurs, pas besoin de reinventer la roue), je dirais qu'il y en a plutot trop que pas assez :)
  • # comme dcop/dbus ?

    Posté par  (site Web personnel) . Évalué à 7.

    Avec dcop/dbus, on peut faire la meme chose, on a acces en ligne de commande a la structure objet des applications, propriété... bref, ca a franchement l'air d'y ressembler. (et au passage, c'est extrement puissant).

    C'est par contre limité aux appli graphique gnome/kde qui gerent kcop/dbus, il manque ca sur toute la couche systeme.
    • [^] # Re: comme dcop/dbus ? bsh , js shell, ipython

      Posté par  . Évalué à 1.

      on a acces en ligne de commande a la structure objet
      Dans ce genre on peut citer aussi:
      java bsh: http://www.beanshell.org/
      js shell: http://developer.mozilla.org/en/docs/Introduction_to_the_Jav(...)
      ipython: http://ipython.scipy.org/moin/
      • [^] # Re: comme dcop/dbus ? bsh , js shell, ipython

        Posté par  . Évalué à 3.

        Je ne connais pas ipython mais si c'est ce à quoi je pense, c'est juste un shell python interactif un peu amélioré.

        Tout comme python, il ne t'offre pas un véritable accès aux entités du système en tant qu'objets.

        J'illustre ca par un exemple:
        Je veux ouvrir le répertoire courant et récupérer la liste de tous les fichiers qu'il contient


        import os
        l=os.listdir('.')
        l
        ['..... j'obtient tous les fichiers du système dans une liste...]

        print l[0].__class__
        --- > <type 'str'>


        On obtient une chaine au lieu d'un objet "File"

        J'ai la complétion sur une chaine et non sur un objet File.
        Je suis donc obligé de me palucher toute la doc de python pour connaitre la fonction d'accès du groupe sur ce fichier et découvrir stat dans le module os
        os.stat(l[0]).st_gid
        qui me renvoie encore un type de base.


        Avec un shell objet j'aurais : l|0].get_Group()
        et je pourrais lui appliquer un setGroup à la volée

        Remarquez que ce n'est pas inhérent au langage python mais simplement à la conception de la librairie qui est parti du paradigme procédural (wrapper au dessus de POSIX j'imagine)

        Pour obtenir un truc équivalent sous Linux, il faudrait faire une rétroconception sur tout le système puis créer une API objet qui serait en fait une facade au dessus des fonctions de base du noyau (écrites en C)
        Ainsi tous les langages et frameworks pourraient s'appuyer dessus
        y compris Gnome et KDE qui proposent déjà à travers DBUS un accès à des objets d'applications.

        J'imagine que c'est ce qui a été fait avec .NET car je doute que Windows soit un OS purement objet.

        A ce propos Timaniac :

        Est-ce que Mono propose cette API ? Si tel est le cas, il suffit de se baser dessus pour se créer un shell à la powershell.(avec une syntaxe Ironpython ca serait top)
        Je me doute qu'étant donné la différence de conception entre les 2 os, il doit y avoir des incompatibilités (genre ACL pour Windows et droits à la UNIX par défaut si l'on active pas les ACL sous Linux)

        Mono permet t'il réellement l'interopérabilité ?
        • [^] # Re: comme dcop/dbus ? bsh , js shell, ipython

          Posté par  . Évalué à 1.

          Pour obtenir un truc équivalent sous Linux, il faudrait faire une rétroconception sur tout le système puis créer une API objet qui serait en fait une facade au dessus des fonctions de base du noyau (écrites en C)
          Le java bsh ci-dessus donne accès à toutes les classes de la plate-forme java, et donc encapsule de manière objet la plupart des API d'un OS.
          Avec XUL et ActionScript, le js shell devrait évoluer dans le même sens.
          • [^] # Re: comme dcop/dbus ? bsh , js shell, ipython

            Posté par  . Évalué à 2.

            beanshell, c'est reste quand meme une commande java interactive, une syntaxe un peu plus souple et surtout avec des perfs plutot faiblardes.
            Surtout que l'api java est quand meme mechamment limitee pour penser en faire une ligne de commande.

            Bref, ca a une utilite certaine, mais ca n'a pas du tout la meme finalite que ce shell.
            • [^] # Re: comme dcop/dbus ? bsh , js shell, ipython

              Posté par  . Évalué à 4.

              Surtout que l'api java est quand meme mechamment limitee pour penser en faire une ligne de commande.
              Tu penses à quoi ? Il y a les droits d'acces et les ACL par exemple dans java
              .et surtout avec des perfs plutot faiblardes.
              Quand on veut des perfs on utilise pas un script.

              Bref, ca a une utilite certaine, mais ca n'a pas du tout la meme finalite que ce shell.
              Ce serait intéressant d'argumenter cela par un exemple.
              • [^] # Re: comme dcop/dbus ? bsh , js shell, ipython

                Posté par  . Évalué à 2.

                j'ai mange pas mal de beanshell ya de ca 2-3 ans, le projet a surement du evolue a l'epoque, ce que j'en retiens c'est surtout ca :
                - ENORME bug dans l'interpreteur : impossible de scripter une classe qui prend un double ou un long en argument. reponse du mainteneur au bug :
                http://sourceforge.net/tracker/index.php?func=detail&aid(...)
                Un an pour fermer un bug critique. et encore, "for next release".

                Tu penses à quoi ?
                je pense que faire un exec() pour lancer une commande externe, c'est pas une solution acceptable pour un shell. De meme, pour les pipes, et les redirections, bon courage.

                Il y a les droits d'acces et les ACL par exemple dans java
                ah oui, c'ets d'un plaisir a manipuler d'ailleurs...

                Quand on veut des perfs on utilise pas un script.
                mouais, enfin ya perf et perfs, la c'etait reellement ras des paquerettes, meme sur des trucs cons for (int i = 0; i<borne; i++)

                Ce serait intéressant d'argumenter cela par un exemple.
                Possibilite de tester du code java vite fait sans avoir a sortir l'artillerie lourde (console java interactive quoi), possibilite de rajouter du code java sans avoir a le compiler. Je l'avais utilise dans un outil destine a des ingenieurs qui savaient coder, mais qui avaient besoin d'un langage proche de ce qu'il connaissaient (la base du c/c++), mais plus souple au niveau syntaxique. Ca s'integre tres facilement dans un programme java qui plus est.

                Bref un bon outil dans la sphere java. Mais un shell, non, je m'insurge.
        • [^] # Re: comme dcop/dbus ? bsh , js shell, ipython

          Posté par  (site Web personnel) . Évalué à 4.

          Est-ce que Mono propose cette API ?
          Oui et non. Globalement ce qu'apporte le Power Shell, c'est l'ensemble des fonctions permettant de récupérer "rapidement" des infos du système. Bref, une tripoté de script et d'alias. Sinon pour les types sous-jacents, c'est les types du framework .NET dessous, largement implémentés par Mono.
          Donc par exemple, la méthode get-process qui retourne tous les processus n'existe pas dans Mono. Par contre la méthode get-process retourne une liste d'objet de la classe System.Diagnostics.Process, implémentée par Mono. Ses propriétés et méthodes sont identiques à celles disponible dans le power shell : Id, Kill(), etc. (cf http://msdn2.microsoft.com/fr-fr/library/system.diagnostics.(...) )
          Je me doute qu'étant donné la différence de conception entre les 2 os, il doit y avoir des incompatibilités
          Globalement le framework .NET est bien indépendant de l'OS. La contre-partie, c'est que certaines infos ne sont pas disponible. MS propose donc des extensions spécifiques à Windows (gestion IIS, ActiveDirectory, etc.). Mono de son côté a un namespace Mono.Unix ( http://www.go-mono.com/docs/monodoc.ashx?tlink=0@N%3aMono.Un(...) ) qui offre une surcouche à des fonctionnalités spécifiques de nos OS.

          Mono permet t'il réellement l'interopérabilité ?
          On peut imaginer une bonne partie des scripts "compatibles", avec des spécificités pour chaque OS forcement.
          • [^] # Re: comme dcop/dbus ? bsh , js shell, ipython

            Posté par  . Évalué à 5.

            hop, t'es partis pour nous faire un OpenPowerShell ? :)
            • [^] # Re: comme dcop/dbus ? bsh , js shell, ipython

              Posté par  . Évalué à 2.

              Je plussoie fortement pour que TImaniac nous ponde ça. :) Bien entendu, je ,e connais pas son emploi du temps et donc si il a le temps. Mais ce serait une bonne maniére pour lui de nous démontrer la puissance de mono qu'il n'arrete pas de défendre à tort ou à raison je n'ensais fichtrement rien.
  • # Je me marre ...

    Posté par  . Évalué à 9.

    En voyant les commentaires. On retrouve un schéma classique ici

    Annonce -> "machin va faire X"
    Commentaires -> "Mouah, ca va être pourri, on peut déja faire ça avec Y"
    Sortie de X -> "Mouah, c'est pourri, on peut déja faire ça avec Y, en plus il avaient annoncé Z et c'est pas sorti"

    ...

    Le temps passe -> "Cool, X sors sous Linux! on va pouvoir faire Ça Ça et Ça, ç'est super cool"


    Et ça marche avec plein de trucs, GUI potable/CLI par exemple, quoi que c'est peut être pas le bon journal pour dire ça ...

    Ici, on peut bien sûr remplacer X par un shell objet qui peut manipuler le système en entier, et Y par un shell "chaines de caractère et fichiers"

    Quoi que, on a déja des trucs dans ce sens sous linux, que ce soit des shells objets ou des trucs comme Dbus, mais faudrait intégrer et développer un peu tout ça, et que des gens s'exatasient déja de pouvoir manipuler les applis kde en ligne de commande ou dans des scripts.
    • [^] # Re: Je me marre ...

      Posté par  . Évalué à 3.

      Pour une fois que ni BeOS ni l'Amiga ne faisaient la même chose il y a 10 ou 20 ans je trouve que les travaux de Microsoft sur un shell objet sont très intéressants.

      BeOS le faisait il y a 20 ans !

    • [^] # Re: Je me marre ...

      Posté par  . Évalué à 5.

      Euh, ça fait quoi concrètement un shell « objet » à part rajouter un super buzzword à un truc simple ?

      Yth, perplexifié...
      • [^] # Re: Je me marre ...

        Posté par  (site Web personnel) . Évalué à -6.

        Ouais, c'est clair, de toutes façons, le seul vrai langage, c'est le C.

        Jean-Philippe, pas du tout ironique
      • [^] # Re: Je me marre ...

        Posté par  (site Web personnel) . Évalué à 8.

        Ca fait que tu manipules des objets typés et plus des chaînes de caractères toute bête. Prend par exemple des commandes qui manipules des dates. Dans le monde unix classique, tes commandes vont sortir sous forme de chaîne de caractère une date, d'autres vont se faire chier à les parser pour les interpréter. Y'a intérêt d'avoir des conventions. Mais j'imagine que certains vont utiliser la syntaxe ISO, d'autres vont plutôt mettre la valeur unix, enfin bref, c'est le bordel.
        Dans un shell typé, ben les commandes ont des arguments en entrée et en sortie qui sont typés. En l'occurence ils peuvent utiliser le type DateTime. Ce ne sont plus des chaînes de caractères qui transite d'un program à l'autre dans les pipes mais des objets. Pas de problème de typage, le type DateTime est en standard dans le framework, tout le monde comprend cette structure.
        Après on peut s'amuser avec tout le framework .NET, par exemple je veux le jour de la semaine d'aujourd'hui, je sais que Get-Date me retourne la date du jour de type DateTime, et je sais aussi qu'il y a la propriété DayOfWeek (qu'il m'a de toute façon proposé avec la completion possible grâce à l'introspection) :
        >(Get-Date).DayOfWeek
        Wednesday
        Plus fort, la méthode ToString par défaut de DateTime retourne une chaîne de caractère qui est localisée suivant l'environnement :
        >Get-Date
        mercredi 15 novembre 2006 17:11:59
        Hop c'est en français. Mais ca conserve le type sous-jacent, je peux mettre Get-Date dans une variable et la passer à une autre commande qui prend un DateTime en entrée.
        Y'a pleins d'autres avantages, suffit d'essayer.
        • [^] # Re: Je me marre ...

          Posté par  . Évalué à -2.

          oui d'accord, c'est clair que c'est intéressant, mais leur truc ne fonctionnera que sous windows seulement, donc cela restera inaccessible pour nous...

          Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

        • [^] # Re: Je me marre ...

          Posté par  (site Web personnel) . Évalué à 3.

          Bon, je vais pas dire que c'est de la merde, c'est clair que spa mal.

          Mais bon, soyont réaliste, le systeme unix avec ses milliers de commandes plus impressionnantes les unes que les autres et ses "tubes" restera toujours plus efficace que ca...
          • [^] # Re: Je me marre ...

            Posté par  . Évalué à 3.

            si pour toi efficace, c'est perdre son temps a batailler avec des regexp et du texte, oui, c'est efficace...
            • [^] # Re: Je me marre ...

              Posté par  (site Web personnel) . Évalué à 3.

              La plupart du temps, t'es pas obligé de batailler avec des regexp pour "parser" une commande... Y'a d'autres alternatives.

              klog:x:102:103::/home/klog:/bin/false

              Genre récupérer le home dir de klog dans cette ligne, ca se fait sans regexp et facilement, suffit de savoir compter.

              Apres, je parlais pas que de ca, je parlais de tout ce que permet de faire Unix en ligne de commande, de l'encodage audio/video à la modification d'image, à ...

              Je doute que le shell de Microsoft arrive un jour à ce niveau de puissance parce que ca n'interessera personne, tout simplement.
              • [^] # Re: Je me marre ...

                Posté par  (site Web personnel) . Évalué à 2.

                Je doute que le shell de Microsoft arrive un jour à ce niveau de puissance parce que ca n'interessera personne, tout simplement.
                Bof, ImageMagick et mencoder peuvent être lancés depuis le Power Shell de Microsoft, c'est des softs externes qui font des entrées/sorties standards, rien de bien spécifique au monde Unix :)
                • [^] # Re: Je me marre ...

                  Posté par  (site Web personnel) . Évalué à 2.

                  >rien de bien spécifique au monde Unix

                  J'ai pas dit que c'etait spécifique mais que la quantité de soft dispo est tellement élever qu'il y'a toujours réponse à ton probleme.
                  • [^] # Re: Je me marre ...

                    Posté par  . Évalué à 2.

                    L'énorme quantité de commandes est à la fois un avantage et un inconvénient.

                    Il y a plein de commandes redondantes sous Unix (genre awk vs combinaison grep, cut, ....) et il faut souvent beaucoup d'investissement (Par ex se taper un bouquin complet d'Oreilly pour maitriser pleinement sed et awk)


                    Du coup on est bien souvent obligé d'en apprendre plus que nécessaire.
                    Si l'on se retrouve à relire le code d'un autre, chacun ayant sa façon de faire, il y a toujours des subtilités qui nous font perdre un temps fou.Des fois mêm en relisant son prore code on ne comprebd pas ce que l'on a voulu faire.

                    Avec une approche typé objet, il suffit de ne connaitre que les classes de base pour être opérationnel. La complétion automatique apportée par l'introspection venant à la rescousse.
                    Et celà est en général bien suffisant pour couvrir un spectre de besoins aussi large.

                    C'est donc toujours les 2 philosophies
                    TIMTOWTDI (perl n'est il pas un shell unix amélioré)
                    versus
                    KISS
                    qui s'affrontent
                    • [^] # Re: Je me marre ...

                      Posté par  . Évalué à 2.

                      la poo placé sous KISS.
                      L'est tout poilu ton troll la.
                      • [^] # Re: Je me marre ...

                        Posté par  . Évalué à 3.

                        Tu connais Smalltalk ? Self¹ ? Io² ?

                        ¹ : http://research.sun.com/self/language.html

                        ² : http://iolanguage.com/
                        • [^] # Re: Je me marre ...

                          Posté par  (site Web personnel) . Évalué à 2.

                          Merci beaucoup pour ces liens qui m'ont fait découvrir Io ... Il semblerait que ce soit le langage que j'ai toujours cherché :) dérivé de lua, lisp, smalltalk, que du bonheur.
                          Par contre, je n'arrive pas a m'abonner à la mailing list :(
                      • [^] # Re: Je me marre ...

                        Posté par  . Évalué à 2.

                        Dans un shell objet, je pense qu'il ne faut pas placer tous les concepts de la poo.
                        Ca na pas pour but de se créer ses propres classes par héritage, juste d'utiliser les classes existantes pour effectuer un traitement simple.
                        Le polymorphisme peut être utile (lister tous les fichiers d'un répertoire et les traiter comme des fichiers, même si on a des réferences à des objets de la classe répertoire)

                        En fait je pensais plus à la philosophie de python qu'a KISS mais j'ai pas osé.
                        Un troll peut en cacher un autre ;-)
                    • [^] # Re: Je me marre ...

                      Posté par  (site Web personnel) . Évalué à 5.

                      Personnellement, je bannis awk...

                      En effet, dès que je commence à avoir de l'awk avec du sed... je considère que Perl est plus adapté et plus maintenable (et non, je programme pas comme un gorais en Perl et oui, on peut faire du Perl lisible).

                      C'est un peu l'approche de debian

                      - simple, couche base du système -> bash

                      - compliqué -> Perl

                      Il ai vrai que l'on voit aussi de plus en plus de python...

                      L'objectif d'un shell est aussi d'être interactif, de la à faire des gros programmes... Enfin, si le shell windows remplace à la fois command.exe et le vbs système, je crois que personne ne va pleurer. Sauf que malheureusement, il n'y a pas un portage minimal sur les anciens OS !
                  • [^] # Re: Je me marre ...

                    Posté par  . Évalué à 3.

                    C'est a mon avis principalement que tu ne connais pas ce que Windows peut deja faire.

                    Par exemple, l'acces HTTP en script, sous Unix t'as wget, sous Windows t'as IE, ben oui, la magie de COM, tu peux scripter a peu pres tout ce que tu veux de IE, loader des pages, ... depuis belle lurette. Meme chose avec Word, Excel, Photoshop,...

                    Bref, la "magie" d'Unix, c'est pas si magique que ca, c'est simplement fait d'une maniere differente sous Windows.

                    Et sans parler du fait que la plupart des softs Unix tournent sous Windows aussi, donc sont directement utilisables la aussi par des scripts.
                    • [^] # Re: Je me marre ...

                      Posté par  . Évalué à 3.

                      Et sous windows, tu peux aussi simplement que sous linux ajouter un disque, en faire ton disque système, sans rien réinstaller et ceci sur une simple station de travail?
                      C'est ce que j'ai fait quand j'ai acheté mon premier disque en sata.
                      J'ai juste fait la copie de quelques répertoires et, et configuré grub.
                      A la fois t'es pas le seul responsable mais ce jeu de moi j'en ai une plus grosse est ridicule. Surtout que tu peux faire tout ce que tu fais avec wget avec IE, c'est peut-être vrai, mais quand tu fais man wget, tu te rends compte qu'il risque de falloir beaucoup scripter. Quelques exemple come --debug, --force-html, --tries, --retry-connrefused, --continue....
                • [^] # Re: Je me marre ...

                  Posté par  . Évalué à 10.

                  Power Shell

                  C'est marrant, j'ai l'impression d'être dans une station service à me servir le dernier diesel ultra économique et performant !
                • [^] # Re: Je me marre ...

                  Posté par  . Évalué à 5.

                  Bin oui, pour le coup, les redirections et les pipes sont une spécificité du monde UNIX et MS n' a fait que copier. Et puis si tu te retrouve à parser la sortie de mplayer avec Power Shell, et bien au final tu fais du UNIX sous Windows.

                  Pour reprendre ton exemple un peu plus haut, tu n'as pas trés bien choisi ton exemple avec 'Get-Date', car le programme date (coreutils) peut faire tout ce que tu as dit:

                  (Get-Date).DayOfWeek

                  date +%A

                  Et alors, ça va t'étonner, comme dans PowerShell, si tu met ça dans un script, c'est automatiquement localisé suivant l'environnement :)

                  Regarde:

                  # j'enregistre la date:
                  $ MYDATE=$(date '+%D %T %Z')
                  $ echo $MYDATE
                  11/16/06 05:53:25 CET

                  # affichage de la date:
                  $ date -d "$MYDATE"
                  jeudi 16 novembre 2006, 05:53:25 (UTC+0100)

                  # affichage de la date localisé suivant l'environnement:
                  $ env LANG=C date -d "$MYDATE"
                  Thu Nov 16 05:53:25 CET 2006
                  $ env LANG=de_DE date -d "$MYDATE"
                  Do 16. Nov 05:53:25 CET 2006

                  # Jour de la semaine:
                  $ date +%A -d "$MYDATE"
                  jeudi
                  $ env LANG=C date +%A -d "$MYDATE"
                  Thursday

                  # Toujours plus fort les GNU ...
                  # le jour de la semaine, à la même date l'année prochaine
                  $ env LANG=C date +%A -d "$MYDATE next year"
                  Friday

                  # Et la veille de cette date:
                  $ env LANG=C date +%A -d "$MYDATE yesterday"
                  Wednesday

                  Il y a une quinzaine, il y a 3 ans, dans une minute et 12 seconde, demain de l'année dernière, ... Et bien sur tout ça en prenant soin d'ajuster aux heures d'été/d'hiver, année bisextile, etc...

                  Pour moi, simple scripteur du dimanche, tout se passe comme si la variable $MYDATE avait conservé le 'type' date tout au long de ces transformations.


                  P.S.
                  tapez info date pour voir toutes les choses bizarres qu'on peut faire avec.
                  • [^] # Re: Je me marre ...

                    Posté par  (site Web personnel) . Évalué à 4.

                    >avait conservé le 'type' date tout au long de ces transformations

                    Pas vraiment ;) C'est de la truande ton truc :p

                    gnumdk@flanders:~$ MYDATE=$(date '+%A %D %T %Z')
                    gnumdk@flanders:~$ echo $MYDATE
                    jeudi 11/16/06 08:22:35 CET
                    gnumdk@flanders:~$ LANG=C date +%A -d "$MYDATE next year"
                    date: invalid date `jeudi 11/16/06 08:22:35 CET next year'
                    gnumdk@flanders:~$
                  • [^] # Re: Je me marre ...

                    Posté par  (site Web personnel) . Évalué à 2.

                    Pour reprendre ton exemple un peu plus haut, tu n'as pas trés bien choisi ton exemple avec 'Get-Date', car le programme date (coreutils) peut faire tout ce que tu as dit:

                    Houlà, j'ai jamais dis que c'était pas faisable sous Unix...
                    Déjà le PowerShell apporte l'instrospection, et donc la completion automatique, le DayOfTheWeek m'a été proposé automatiquement après le ".", pas eu besoin de me taper le man de la commande date.
                    Ensuite je voulais montrer que celui qui a fait la commende Get-Date n'a rien eu à faire pour avoir la localisation : la classe System.DateTime est déjà localisée, son script doit ressembler à : System.DateTime.Now.
                    Tu vas me dire, la localisation, c'est pas forcement la "killer feature", certes, je voulais surtout montrer qu'il y a une différence entre la valeur "affichée" et la valeure manipulée : dans le powershell c'est différencié : la date est en français ou en allemand, si dessous ta commande powershell récupère ca, tu as toujours un objet DateTime. Dans nos shell classique, faut te taper la gestion de cette date à la main.

                    Pour moi, simple scripteur du dimanche, tout se passe comme si la variable $MYDATE avait conservé le 'type' date tout au long de ces transformations.
                    Oué bah regarde le boulot qu'à du faire le mec qui a fait date comment il a dû rigoler pour parser ses dates ;) Et puis comme je l'ai précisé dans un autre post, si toi tu dois choisir de faire un programme qui doit traiter des dates, ben, tu vas devoir tenter de trouver les conventions des autres programmes pour être sûr de gérer les mêmes types de date, modulo les bugs que tu vas ajouter, etc.

                    Allez, on va voir si ta variable $MYDATE contient vraiment le type pour toi scripteur...
                    Dans mon powershell si je fais :
                    $MYDATE = get-date
                    $JOUR = get-date.Today
                    maintenant je fais :
                    $HEUREDUJOUR = $MYDATE - $JOUR
                    T'optiens quoi en faisant une différence entre 2 chaînes de caractères en bash ? ;) Moi dans le powershell j'obtient un objet TimeSpan qui indique une durée.
                    • [^] # Re: Je me marre ...

                      Posté par  (site Web personnel) . Évalué à 1.

                      En général, pour la date, si je veux être portable, j'utilise deux notations :

                      - YMD

                      - timestamp

                      On obtient le second avec date %+s

                      Je crois que un des problèmes des exemples, c'est que ce sont des trucs assez classiques et qu'il existe donc déjà sous UNIX des bonnes manières pour faire vite et propre en bash.

                      Là ou le shell windows va devenir intéressant, c'est quand on va rentrer dans des choses systèmes et mélanger un peu tout cela.

                      Dans les langages de scripts, on peut faire un peu pareil avec sous Windows les modules de type Win32 (Win32:: sous Perl). Mais il faut faire le "wrapper". On peut cependant imaginer qu'avec .Net et l'introspection, il soit possible, notament avec la force de frappe de Microsoft, de mettre au point un wrapper automatique, soit lors des mises a jour des logiciels, soit avec un mécanique du type AUTOLOAD pour Perl.

                      Bref, ca manque d'un langage de script...
              • [^] # Re: Je me marre ...

                Posté par  . Évalué à 2.

                ... Sauf que c'est pas des fonctionnalités qu'on parle, c'est du principe du shell. Imagine les fonctionnalités des commandes combinées avec le shell lui même ?
                • [^] # Re: Je me marre ...

                  Posté par  (site Web personnel) . Évalué à 3.

                  Ouh Ouh, tu as lu mon premier commentaire?

                  Je parle du nouveau shell de Microsoft la?
                  Non, je parlais de la quantité de soft dispos sous Unix en ligne de commande qui rende notre vieux shell très puissant.

                  Et je me permets de douter sur l'explosion de softs en ligne de commande sous Windows du à l'arrivé de Vista.
                  • [^] # Re: Je me marre ...

                    Posté par  . Évalué à -1.

                    Ton commentaire ressemble surtout à celui d'un mec vexé qui veut pas perdre la face. "oué, ok il ont sorti un truc bien. Mais quand même". Et ça, c'est parce que c'est MS, j'en suis profondément persuadé.
                    • [^] # Re: Je me marre ...

                      Posté par  . Évalué à 0.

                      Et de renchérir : surtout quand la qualité bash/ksh/... vs cmd.exe, completion, efficacité du shell a longtemps été un sujet de raillerie de la part des linuxiens vis à vis de windows. Là sur le shell lui même ils ont pas grand chose à envier, au contraire.
                    • [^] # Re: Je me marre ...

                      Posté par  (site Web personnel) . Évalué à 2.

                      >Et ça, c'est parce que c'est MS, j'en suis profondément persuadé.
                      Exactement, je peux pas les encadrer! Surtout pbpg :p

                      Autre probleme la, je ne m'attaque pas une seconde à Pwsh, je disais juste que l'aspect ligne de commande sous Windows est mort en dehors des informaticiens (et encore, de quelques rares admins).

                      Apres, c'est plutot une bonne chose, ca marche sous Xp, c'est le genre de truc que je cherche depuis des années n'ayant ni envie de me faire chier avec les limitations de Dos ni envie d'apprendre VB.

                      Seul probleme, marche pas sous 98 et y'en a encore un paquet de ces merdes la... :(
              • [^] # Re: Je me marre ...

                Posté par  . Évalué à 1.

                ????

                qu'est ce que ca a de specifique a unix?

                un binaire qui prend des parametres en entree et qui pond un fichier en sortie, bref input/output tout ce qu'il ya de plus con quoi...
                • [^] # Re: Je me marre ...

                  Posté par  . Évalué à 2.

                  Je suis pas un historien de l'informatique, mais pour ma part, a part des unix et des OS de MS, j'ai vu ça nul part (en gros, c'est à dire ni sur des macos, ni sur des TI 99/4A :) ). Mais on peut lire un peut partout que ça viens bien d'UNIX ou peut être de MULTICS son ancêtre:

                  http://en.wikipedia.org/wiki/Standard_streams
                  http://en.wikipedia.org/wiki/Pipeline_%28Unix%29

                  «
                  History

                  The pipeline concept and the vertical-bar notation was invented by Douglas McIlroy, one of the authors of the early command shells, after he noticed that much of the time they were processing the output of one program as the input to another. The idea was eventually ported to other operating systems, such as DOS, OS/2, Windows NT, and BeOS often with the same notation.

                  The robot in the icon for Apple's Automator, which also uses pipeline concept to chain repetitive commands together, holds a pipe as recognition of the application's Unix heritage.[1]
                  »


                  A propos de Douglas McIlroy:
                  «
                  Dr. McIlroy is best known for having invented:
                      * The pipes and filters architecture of Unix as seen in the Unix pipeline implementation.
                      * The entire concept of software componentry
                      * Several Unix tools, such as spell, diff, sort, join, graph, speak, tr, etc.
                  »
                  • [^] # Re: Je me marre ...

                    Posté par  . Évalué à 0.

                    macos c'est un bsd, donc le pipe, il y est

                    sinon :
                    a part des unix et des OS de MS

                    et ya quoi sur le marche des os en dehors d'unix et de ms?

                    je parle de truc reellement utilises, hein...
              • [^] # Re: Je me marre ...

                Posté par  (site Web personnel) . Évalué à 1.

                un grep et un awk et zou :D
                • [^] # Re: Je me marre ...

                  Posté par  . Évalué à 5.

                  NON NON NON, tu vas pas faire comme ces andouilles de chez MS (qui font semblant de pas savoir pour que ça ait l'air encore plus compliqué UNIX) awk sait trés bien "matcher" des lignes avec des expressions rationelles .

                     awk '/^regex$/ { ... }'

                  (d'autant que awk est très rapide, beaucoup plus que sed par exemple)
                  • [^] # Re: Je me marre ...

                    Posté par  (site Web personnel) . Évalué à 1.

                    euh ben oui mais il avait dit sans regexp ...

                    Mais en fait ca marche pas non plus parce que grep ca utilise des motifs motifs (enfin pour moi ca ressemble beaucoup aux regexp les motifs).

                    Enfin bref, tu as raison.
          • [^] # Re: Je me marre ...

            Posté par  . Évalué à 2.

            Ca n'a rien a voir avec les fonctionnalités ou le nombre de commande, c'est simplement un moyen d'accéder à ces fonctionnalités.
          • [^] # Re: Je me marre ...

            Posté par  (site Web personnel) . Évalué à 2.

            ais bon, soyont réaliste, le systeme unix avec ses milliers de commandes plus impressionnantes les unes que les autres et ses "tubes" restera toujours plus efficace que ca...
            Pour les commandes, c'est vrai que pour l'instant, c'est pas pléthore. Mais le framework donne déjà accès à de très nombreux service, de la manipulation de service à la gestion de serveur web en passant par les regex ou la manipulation de fichiers XML. Bref c'est déjà un bon point de départ. Et gageont que les commandes vont vite s'enrichir.
            Quand aux tubes, je vois pas trop ce qu'il y a de plus efficace, dans MS Power Shell y'a aussi les tubes, mais avec des vrais objets qui passe dedans :
            exemple :
            "get-process p* | stop-process"
            Bref, ca marche comme les pipes Unix, mais en mieux.
            • [^] # Re: Je me marre ...

              Posté par  . Évalué à 2.

              Justement, puisque ce sont des objets qui sont transmis ... comment ca se passe si on envoie un objet d'un mauvais type ?
              Cad, au lieu de faire stop-process sur un objet "processus", si je le fait sur le PID du pocessus ? je me fait jeter ?

              Si oui, cela veut dire qu'il faut être hyper rigoureux et que l'on est forcé de récupérer les bons objets par les fonctions adéquates (pas moyen de construire à la mimimine ses propres valeurs).

              Si non, c'est un bon point, mais cela signifie que le "stop-process" a été codé dans ce sens, et donc qu'il faut que le programmeur ai envisagé tous les types d'objets potentiels en entrée ... ca risque de rendre long le codage de nouvelles fonctionnalités ... mais bon si M$ y mets des sous ...

              Et d'ailleurs (ch'connais pas .Net), on peut facilement recevoir des objets autres que des chaines en paramètres du main() ?
              • [^] # Re: Je me marre ...

                Posté par  . Évalué à 2.

                Tu peut construire à la mimine ta valeur, et faire un "get-process ma_valeur_construite_a_la_mimine" j'imagine ... et si le process existe pas, get-process doit te l'indiquer. (j'ai cru entendre parler d'exceptions)
                • [^] # Re: Je me marre ...

                  Posté par  . Évalué à 3.

                  ok, mais ca ne répond qu'a une partie de la problématique posée :
                  oui, on peut faire ces propre valeurs à la mimine
                  Mais faut-il systèmatiquement passer par un "get-process" (ou autre fonction renvoyant un objet processus) avant de pouvoir faire un "stop-process" ? (c'est ca que j'appelle être hyper rigoureux)

                  Le bash est pour moi un langage de bidouilles sans contraintes (avec ses inconvénients comme ses avantages) ; j'ai l'impression que celui de M$ pousse à beaucoup plus de rigueur ...
                  Ces 2 shells ne jouent peut-être pas dans la même cour ?
            • [^] # Re: Je me marre ...

              Posté par  . Évalué à 4.

              Il y a quelque chose qui me chagrine

              Pourquoi mélanger des paradigmes objets avec des concepts de shells classiques.

              Les devs vont être tentés de recréer une pléthore de commandes juste pour retrouver leurs sensations d'avec cygwin.

              Tout ca ne me parait pas "orthogonal"
              • [^] # Re: Je me marre ...

                Posté par  . Évalué à 2.

                Parce que ça peut être utile et pratique ?

                Les devs, ils deviendrons des dinausores ou ils comparerons à l'usage ce qui est le plus pratique à utiliser pour ce qu'ils ont à faire.
                Wait & see donc.
        • [^] # Re: Je me marre ...

          Posté par  . Évalué à 2.

          Ok, je vois l'intérêt.
          Mais ce genre de choses, on peut les faire en python, ou en perl, avec derrière pas mal de trucs vraiment puissants.

          Certes, ce n'est pas directement dans le shell, et on ne lance pas des commandes à exécuter immédiatement de la sorte, mais l'intérêt de passer des objets évolués d'un outil à un autre etc. c'est de faire des scripts un peu complexe, pas tellement de lancer des commandes à la main.

          En gros, si on avait un shell python, ça serait plus ou moins pareil ?


          Yth.
          • [^] # Re: Je me marre ...

            Posté par  (site Web personnel) . Évalué à 2.

            En gros, si on avait un shell python, ça serait plus ou moins pareil ?
            Oui effectivement, tu peux appliquer le même modèle à n'importe quel environnement de programmation de "haut niveau" avec un modèle de machine virtuelle offrant des possibilité d'introspection. Python est un bon exemple. Reste plus qu'à faire le shell (gestion des pipes, completion, etc.) et l'ensemble des commandes pour accéder à tous l'OS :)
            • [^] # Re: Je me marre ...

              Posté par  . Évalué à 3.

              Oki !
              Ca a l'air sympa ce bidule, ya de l'idée.
              Vais jeter un oeil à ce ipython dont parle Thomas juste en dessous...

              Yth.
          • [^] # Re: Je me marre ...

            Posté par  . Évalué à 2.

            Ça ça existe déja, c'est ipython je crois. Mais iphython ce n'est pas encore tout à fait ça: il manque notament l'accès "de base" a pleins d'objets système, applis, ... pour pouvoir scripter tout ça et accéder à pleins de trucs, de piper des objets (cf les exemples), ...
      • [^] # Re: Je me marre ...

        Posté par  . Évalué à 7.

        T'as pas lu les commentaires et les liens ?

        je précise que perso, ça va pas réxolutionner ma façon de travailler, et que je m'en fiche un peu ( je dis ça, il y a des chances que je trouve des trucs à faire après)

        Déja, le flux n'est plus un flux de caractères, c'est un flux d'objet : au lieu d'avoir une ligne texte qui représente un process, avec tout ce que ça peut comporter de merde potentielle si on utilise des grep, sed, awk, mal fichus pour récupérer les infos qu'on veut, les espaces à gérer par des escape shell, tout ça, on récupère un ensemble d'objets processus.

        Ensuite, sur cet ensemble d'objet, on peut appeler des méthodes, qui vont non seulement nous donner des infos sur le processus, mais aussi de lui envoyer des ordres. Genre t'as pas besoin de récupérer le PID du process pour faire un "kill" dessus, tu appelle la méthode "kill" de l'objet process. Comme dit plus haut, tu peux facilement récupérer l'ensemble des méthodes que tu peux appliquer à ton process, pas besoin nécessairement d'apprendre 25 000 noms de commandes. Certe il existe la commande pkill ou des trucs comme ça, mais elle marche que sur les process, il faut la connaitre, etc. Là le mécanisme est plus général et plus cohérent : tu peux utiliser la même démarche avec n'importe quel type d'objet.

        Un autre avantage du système : les objets peuvent être n'importe quoi : un process, une GUI d'appli, ... Tu peux sans doute lancer, arrêter de jouer une musique en appelant les bonnes méthodes du process correspondant, sans que le programme ait été pensé pour avec une commande spécialement codée ou une API. Tu peut accéder grosso modo à l'ensemble du système, niveau applis, ou niveaux plus bas.

        En bref, c'est un mécanisme cohérent et unifié pour faire pleins de trucs, en évitant certains éceuils d'un shell classique.
        • [^] # Re: Je me marre ...

          Posté par  . Évalué à 1.

          ouais enfin ... le shell c'est juste censé être utilisé pour faire qq scripts aussi, ce n'est pas pensé initialement pour programmer des applis métier complètes.

          C'est comme si sur une C1 (concu essentiellement pour la ville) tu t'amuse a mettre plusieurs mode de gestion du moteur dont 'grande vitesse' ou encore 'conduite hyper sportive' (vitesse maxi en 4em 157 kmh, et on ont l'atteind pas tout de suite le 150 km/h)...
          • [^] # Re: Je me marre ...

            Posté par  . Évalué à 2.

            Ben là, tu pourras toujours faire les quelques scripts, en te prenant moins la tête, et tu auras plus de possibilité pour faire tes quelques scripts.

            En quoi ce shell est pensé pour faire une appli complète ? c'est l'infrastructure .NET qui l'est.
            • [^] # Re: Je me marre ...

              Posté par  . Évalué à -1.

              sans vouloir être vexant, je préfere prendre un lgg adapté à mon probleme.
              Alors des fichiers de scripts d'une quinzaine de lignes pour gérer une compilation , np. Mais c'est du séquentiel pur la, aucun intéret de mettre de l'objet au milieu.
              Les scripts objets ont, pour moi, aucun intérêt. Je prend un vrai lgg objet si j'ai besoin de faire de faire un traitement objet. Et contrairement a ce qu'on pense, il est pas plus long de faire un programme que de faire un script shell quand le probleme commence à être complexe (cad en gros si il faut plus d'une trentaine de ligne de shell script non triviale, il existe en plus de trés bon lgg de script comme python , ou ruby (jamais essayé mais j'en ai entendu bcp de bien)).
              Ensuite l'habitude de tel ou tel lgg rentre en ligne de compte. Il m'est arrivé de faire des shell script, et de devoir cherché des infos pendant de (trés)long moments. Pour finalement me dire 'bon me fais chier, je le fais en c, ca va etre simple, je sais comment résoude ce probleme' et en 15 min c'était fait.
              Alors qu'un pro du shell script l'aurais fait en 5-10 min aussi (vu que c'était plus adapté au shell script mais bon , on ne sais pas tout).


              En quoi ce shell est pensé pour faire une appli complète ? c'est l'infrastructure .NET qui l'est.
              .Net ... c'est vraiment tout et n'importe quoi de mon point de vue. C'est pas en essayant d'etre sur tous les marché (du shell script au projet métier) qu'on va faire un beau truc partout.
              Je rapelle un peu le principe sous jacent à unix : On fait un seul truc, mais on le fait bien.
              • [^] # Re: Je me marre ...

                Posté par  . Évalué à 3.

                je le fais en c


                Tu passes du bash au C directement ? La vache. C'est complètement orthogonal du point de vue gestion des chaines de caractères, et d'un tas d'autres choses d'ailleurs. Ça explique bien des choses ;)

                Et pour ton fichier de compilation séquentiel
                Pourquoi pas un truc du genre

                a_compiler = { fichiers compilables du répertoire }

                Pour chaque fichier de a_compiler
                Si fichier.est_lisible() alors
                fichiers_objets.ajouter = fichier.compiler()
                fin si
                fin pour

                executable = fichiers_objets.lier()

                avec la gestion des erreurs, et tout ? j'adorerai faire ça ... sans avoir à gérer mon ensemble de fichier comme une chaine de caractère bash dans laquelle un espace dans le nom de fichier foutra la merde ou connaitre la manpage de "test" par coeur pour savoir si un fichier est plus récent qu'un autre ...

                Ok, c'est complètement farfelu comme exemple, c'est surement pas réalisable cash, vaut mieux faire un makefile, mais c'est pour donner une idée.
                • [^] # Re: Je me marre ...

                  Posté par  . Évalué à 6.

                  Tu passes du bash au C directement ? La vache. C'est complètement orthogonal du point de vue gestion des chaines de caractères, et d'un tas d'autres choses d'ailleurs. Ça explique bien des choses ;)
                  ca explique surtout que quand on sait se servir d'un langage, ben on sais ou chercher les infos et les librairies (ou on les connais déja).
                  Et tu sais que les chaines de caractères c'est que des données, et de base.
                  Si tu as des problemes avec les chaines de caractères en C, je comprend mieux pourquoi tu trouve ce shell tellement bien.

                  Et pour ton fichier de compilation séquentiel
                  Pourquoi pas un truc du genre

                  Peut etre parce qu'il s'agit de fichiers différents, avec des options différents, et des compilos différents (lex , yacc , et g++ par exemple).
                  Pour la compilation de tt facon je fais des Makefile.
                  C'est surtout pour faire marcher deux projets ensembles, lancer les compils kivonbien (avec des compilation imbriqués) que je me suis servis du shell, ou faire des petits tests sur les fichiers.

                  avec la gestion des erreurs, et tout ?
                  Parce que toi tu as une vrai gestion des erreur avec le truc qui te lance le gdb et l'éditeur de texte quand ca plante ?
                  ou ton truc fait comme tout le monde echo 'erreur sur le fichier machin ligne bidule'; exit;
                  sans avoir à gérer mon ensemble de fichier comme une chaine de caractère bash dans laquelle un espace dans le nom de fichier foutra la merde
                  ben ca sens surtout que tu ne sais pas utiliser le shell. Tu peux changer le séparateur par défaut si tu veux.
                  Ou simplement mettre tes fichiers entre '' et utiliser read line ou encore ...
                  C'est con hein...
                  Je pense surtout que tu as du mal a utiliser l'outil existant , et donc tu te jette a coeur perdu dans un autre outil en pensant qu'il est forcément mieux.

                  ou connaitre la manpage de "test" par coeur pour savoir si un fichier est plus récent qu'un autre ...
                  Parce que tu pense que tu connaitras de facon aisé chacune des fonctions et attributs que va t'offrir chacun des mots clés de ton shell ?
                  Tu est pas foutu de te les souvenirs dans un cas, mais dans l'autre ca sera forcément et magiquement mieux ???
                  • [^] # Re: Je me marre ...

                    Posté par  . Évalué à 5.

                    Non, je n'ai pas de problème avec les chaines de caractères en C, c'est juste particulièrement lourd à manipuler dans ce langage (Honnêtement, je crois pas connaître pire, d'après des retours que j'ai eu appliquer une regexp en C c'est d'une lourdeur totale, par exemple, pour concaténer deux chaines il faut appeler une fonction, se demander si la fonction en question alloue elle même la mémoire ou si elle attends la place nécessaire préallouée ... Alors qu'en shell, tu feras pas grand chose sans manipuler des chaines de caractères.

                    Pour la compilation : cet exemple était certe pourri, j'avais prévenu ;) Mais je déteste pas faire des trucs un peu élaboré avec un shell, ou utiliser des boucles for ou des trucs dans ce genre. Ce qui est frustant dans ce cas, c'est le nombre de tricks qu'il faut se rappeler pour faire marcher le bouzin correctement alors que c'est 5 lignes de code ... je pense perso que l'approche "une entité du SE", un fichier par exemple, est un objet, avec immédiatement et facilement accessible tout ce qu'on voudrait en savoir, comparée à l'approche "une entité est une chaîne" avec des commande à taper et des lignes de textes de descriptions accessibles à partir de commande qui prennent en paramètre l'identifiant chaine de l'entité qu'il faut parser derrière est bien meilleure.


                    Pour le séparateur par défaut, le changer, c'est du bricolage, et oui, je savais qu'on pouvait le faire. C'est de la trituration mentale de se demander à chaque fois dans quel cas ça va foirer et ce qu'il faut faire pour y remédier, mettre des quotes, utiliser $@ etc.


                    Je me jette pas à corps perdu dans cet outil, j'ai déja dit que je m'en foutais un peu. D'ailleurs j'utilise pas windows.

                    Sur les fonctions et attributs, là tu te plantes : on a déja dit que grâce à l'introspection des objets, tu pouvais connaître en ligne toutes les méthodes que tu peux leur appliquer, type shell completion, éventuellement avec la doc j'imagine. Le genre de trucs qui peuvent faciliter la vie.


                    Mais après, si "ça sert à rien, on pouvait déja faire ça avec Y" et "on pouvait faire ça en C aussi", j'ai plus rien à ajouter à mon premier post, rendez-vous dans quelques temps ;)
                    • [^] # Re: Je me marre ...

                      Posté par  . Évalué à 2.

                      Laisse tomber, face a tant de mauvaise foi ya plus rien a faire.
                      Il n'y pas plus sourd que celui qui ne veut pas entendre.

                      Quand je vois que certains proposent beanshell ou ipython face a PowerShell, je me dit que bizarrement, le soit disant fleuron de l'innovation n'a toujours pas compris quel etait l'interet de ce shell.

                      D'ici 5 a 10 ans, les libristes s'interesseront a ce genre de techno et on aura tous les coqs de la planete libre qui viendront fanfaronner avec un proof of concept d'un shell, soit disant innovation, ca marche presque, mais pas encore, bientot dans l'ubuntu unstable etc.

                      La seule chose qui me vient a l'esprit quand je vois ces echanges, c'est une citation de mission cleopatre (de tete):
                      - Le probleme avec vous amonbofis, c'est qu'on a toujours fait comme on a toujours fait...
                      - Beeeen, oui!! On a toujours fait comme ca!!!
                      • [^] # Re: Je me marre ...

                        Posté par  . Évalué à 2.

                        C'est si vrai que ca en serait triste :)
                        Ca destabilise, ce "powershell". J'avoue que si c'etait completement portable, ca pourrait etre interessant de s'y attarder.
                        M'enfin ca a quand meme un souci noté plus haut :
                        Alors pour avoir un shell, il faut avoir une vm, un framework, puis le shell ?
                        Vindiou, faut pas avoir peur. Un shell minimaliste, ca reste *essentiel*. Devoir sortir un buldozzer pour agresser une mouche, c'est pas utile. D'ou l'interet du shell UNIX je pense. Il fait une chose, mais la fait tres bien.

                        J'avoue en lisant les scripts d'exemple qu'il y a un peu de mauvaise foi de la part de microsoft (grep puis awk, grep -v grep... Utilisation intensive de ps -el alors qu'avec les bonnes options on peut arriver au meme resultat que lui mais plus simplement...) mais je trouve que la partie "exemple" coté powershell est sexy, mais l'objet a un desavantage : "punaise y'a plein de methodes sur cet objet, j'en fait quoi ? Merde, faut caster pour changer de methodes et avoir un xml au lieu d'un texte simple, du coup derriere on re liste les methodes etc." mais wait&see.
                        • [^] # Re: Je me marre ...

                          Posté par  . Évalué à 5.

                          c'est pas de la mauvaise foi.
                          C'est juste que ce n'est PAS un shell.
                          C'est un langage de script, peut etre super tip top.
                          Mais ce n'est pas pour moi un shell.
                          Un shell est juste censé être utilisé pour communiquer directement avec le systeme. Ensuite on a rajouté des trucs dessus comme la complétation (ce qui est trés pratique itou itou) mais initialement c'est juste ca!
                          Et la on veux essayer de nous faire croire qu'un langage de script (qui plus est basé sur de l'objet) est mieux que le vieux /bin/sh qu'on peut lancer quand on a une merde ?
                          Faut arrêter un peu!
                          Moi les scripts shells je les utilisent beaucoup moins que les applis, et seulement pour faire des trucs simples. D'ou l'inintérêt le plus totale de l'objet dans un shell. D'où le fait qu'il manipule grosso modo que les chaines de caractères est largement suffisant.

                          Quand au C , les chaines de caracteres sont peut etre 'horribles' , mais tu ne les utilise rarement pour manipuler les données. Tu les utilise la plupart du temps juste en e/s
                          (et petit conseil, tu te prend une fois la tête a faire une librairie qui fait toutes les fonctions qui te plaisent avec les strings. Et ensuite tu réutilise ces fonctions. Par exemple je me suis fait il y a fort longtemps une fonction getline, elle lis directement stdin, alloue la bonne longueur de chaine , et me renvoie le tout, j'ai pas a me prendre la tête)


                          Quand je vois que certains proposent beanshell ou ipython face a PowerShell, je me dit que bizarrement, le soit disant fleuron de l'innovation n'a toujours pas compris quel etait l'interet de ce shell.

                          Quand je vois que certains propose une vm pour un shell, je me dis qu'ils n'ont pas compris l'intéret d'un shell. Et que visiblement ils sont a fond dans la logique de ms 'consommons de la mémoire, aprés tout c'est l'utilisateur qui paie la ram, pas moi' (rem, il y a de mon point de vue le meme travers avec fx)


                          Pour le séparateur par défaut, le changer, c'est du bricolage, et oui, je savais qu'on pouvait le faire. C'est de la trituration mentale de se demander à chaque fois dans quel cas ça va foirer et ce qu'il faut faire pour y remédier, mettre des quotes, utiliser $@ etc.
                          Le shell script c'est la plupart du temps du bricolage. On fait ca rapidement pour automatiser simplement une tache et basta. Ca ne retire rien a son utilisation, mais ca reste du bricolage. Et le coup de 'espace dans les noms de fichiers' . Moi aussi j'ai eu ce probleme. Puis j'ai cherché, puis je me suis fait un script avec read line. Et quand j'ai un probleme je reprend ce script, je cc et voila.
                          Tu fera exactement la meme chose avec ton PowerShell quand tu te souviendras plus de la fonction. Tu regardera un truc ou tu l'a déja fait, tu reprend le nom et voila.
                          Bref l'intéret ici est pas flagrant.

                          Maintenant si PowerShell c'est un meilleur langage de script que le shell ? Sans (presque aucun) doute. Mais c'est pas ce que je demande a mon shell.
                          • [^] # Re: Je me marre ...

                            Posté par  (site Web personnel) . Évalué à -1.

                            Quand je vois que certains propose une vm pour un shell, je me dis qu'ils n'ont pas compris l'intéret d'un shell.
                            Mouarf. Et quand tu proposes un exemple de script... t'appelle un langage interprété avec un modèle de machine virtuelle dessous : Perl.

                            Mais c'est pas ce que je demande a mon shell.
                            Faut bien voir qu'on adapte aussi ses besoins aux possibilités offertes par l'outil. Faut pas croire que l'outil est juste là pour répondre à un besoin, c'est le jeu de l'émulation. Je suppose que les mecs qui codaient en binaire avec des switchs sur les premières machines de bureau, ils trouvaient que les claviers et écrans ca servait à rien, c'est pas ce qu'ils demandaient à leur engin.
                            • [^] # Re: Je me marre ...

                              Posté par  . Évalué à 4.

                              Mouarf. Et quand tu proposes un exemple de script... t'appelle un langage interprété avec un modèle de machine virtuelle dessous : Perl.
                              Mouarf visiblement tu sais pas faire la différence entre 'Shell' et 'Script' hein.

                              Faut pas croire que l'outil est juste là pour répondre à un besoin
                              A parce que un outil doit CREER un besoin ?
                              Oula on est pas dans la vente la!
                              l'outil doit REPONDRE au besoin, pas le créer. Si tu trouve .Net bien c'est parce qu'il REPOND a un de TES besoins.
                              Si il crée un besoin alors tu es sacrément influencable dans les technos, et somme toute le produit sert a rien , vu que c'est qu'un besoin virtuel.
              • [^] # Re: Je me marre ...

                Posté par  (site Web personnel) . Évalué à 1.

                .Net ... c'est vraiment tout et n'importe quoi de mon point de vue.
                C'est aussi son objectif : couvrir un grand nombre de fonctionnalités, pour avoir un ensemble cohérent et unifié. C'est ce qui a fait tout le succès de Java par exemple.

                Je rapelle un peu le principe sous jacent à unix : On fait un seul truc, mais on le fait bien.
                Oué, et on commence par utiliser le langage Unix de référence : le C, on se tape un malloc et des void *, et hop, on fait tout et n'importe quoi avec, d'un interpréteur de script à un kernel en passant par un desktop complet :-p
                Non plus sérieusement, le framework .NET c'est avant tout une VM et un modèle objet qui permet de voir autre chose que de simples adresses mémoires et des instructions pour les manipuler. Après .NET c'est aussi un ensemble conséquent de classes qui permettent à toutes les applis de partager des types en communs : un type string pour tous les programmes, un type DateTime pour tous les programmes, de l'appli graphique au pages web dynamique en passant par le shell : cohérence et interopérabilité. Tu vois, là moi je me vois déjà scripter mes classes développées dans un projet, juste parcque les 2 utilisent une infrastructure en commun et partagent les mêmes formats de données, bref toutes les applis parlent la même langues : .NET. C'est avec des exemples comme le power shell qu'on comprend mieux tout l'intérêt de proposer une infrastructure "générique" à tout faire : on peut "out-of-the-box" réutiliser tout le framework et les milliers de classes qu'elle contient, mais également les classes développées par tout le monde. Microsoft met également en valeur toutes ses technos basés sur l'introspection, depuis l'ancètre COM jusqu'aux ActiveX, toutes ces technos sont accessibles directement à travers le power shell. Comme quoi la réutilisation ventée par la technique objet n'est pas que théorique comme on l'entend souvent.
                Allez pour la route, un exemple trouvé sur wikipedia montrant l'intérêt de donner accès à tout le framework .NET d'un coup :
                PS> $rssUrl = "http://blogs.msdn.com/powershell/rss.aspx"
                PS> $blog = [xml](new-object System.Net.WebClient).DownloadString($rssUrl)
                PS> $blog.rss.channel.item | select title -first 8

                Hop ca te retourne les 8 entrées les plus récentes du blog.
                • [^] # Re: Je me marre ...

                  Posté par  . Évalué à 4.

                  Moi j'aimerai savoir un truc plus intéressant, j'ai mon serveur dans un datacenter que je contrôle via un KVM IP et j'ai toujours mon cd d'installation dedans. Si pour une raison quelle conque (logiciel), mon système ne démarre plus (kernel panic quel conque), je peux toujours démarrer mon cd d'installation et utiliser un chroot pour réparer le problème sur mon serveur de chez moi. Donc est-ce que le shell de microsoft me permet au minimum de faire ça?
                • [^] # Re: Je me marre ...

                  Posté par  . Évalué à 0.

                  Je passerais sur le troll sur le C, et me demande pourquoi Timaniac est sur linuxfr vu qu'il semble pas des masses utiliser un pingouin pour dire des trucs comme ca.

                  Non plus sérieusement, le framework .NET c'est avant tout une VM et un modèle objet qui permet de voir autre chose que de simples adresses mémoires et des instructions pour les manipuler. Après .NET c'est aussi un ensemble conséquent de classes qui permettent à toutes les applis de partager des types en communs : un type string pour tous les programmes, un type DateTime pour tous les programmes, de l'appli graphique au pages web dynamique en passant par le shell : cohérence et interopérabilité.
                  Attend deux seconde : pour communiquer avec le systeme (parce c'est ce a quoi correspond un shell) tu as besoind d'une VM, d'un framework, et d'un shell 'interopérable' ???
                  C'est au systeme d'etre intéropérable, pas au shell!
                  Si le systeme l'est, alors le shell l'est (peut l'être) aussi.
                  Et je passe sur le coup de la vm et du framework.
                  Moi je n'attend absolument pas les meme fonctionnalité du shell, du C, du C++, du lisp et du python. Mais bon si tu veux faire tes projets en shell script et tes scripts shell en c# libre à toi hein.

                  Comme quoi la réutilisation ventée par la technique objet n'est pas que théorique comme on l'entend souvent.
                  Fermer la porte, ca souffle :-D

                  Hop ca te retourne les 8 entrées les plus récentes du blog.
                  Cool et ca sert à quoi ?
                  Sachant que je lis pas les blogs, et que si j'ai envie de voir des flux rss pour une page web, j'utilise plutot ff vu qu'il me permet de cliquer directement sur le lien qui m'intéresse .
                  Et tu as beau dire 'c'est super simple' rien que ta deuxieme ligne devient difficilement lisible (alors voyons voir : une création d'objet avec utilisation direct d'une fonction sur une variable définis avant , avec cast et affectation...).
                  Si tu veux faire du code comme ca, certains ont réussis à coder decss en un nombre ridicule de caractère, arrivera tu a faire la meme chose avec ton super power shell ?
                  puis j'adore les attributs a rallonge :
                  '$blog.rss.channel.item' rien que pour ca tu passe une heure dans les specifs pour savoir quels sont chacuns des attributs si tu n'as pas l'habitude (et oui, ceux qui utilisent le shell script, c'est pas forcément qu'ils ont envie de faire 4000 lignes de code, mais simplement automatiser rapidement une tache simple)
                  • [^] # Re: Je me marre ...

                    Posté par  (site Web personnel) . Évalué à 4.

                    me demande pourquoi Timaniac est sur linuxfr vu qu'il semble pas des masses utiliser un pingouin pour dire des trucs comme ca.
                    J'ai commencé à coder en C, et j'utilise Linux au quotidien chez moi. Je voulais juste faire remarquer la pseudo philosophie du "ca fait une seule chose et ca le fait bien" est globalement bidon. On pourrait lancer des trolls emacs par exemple, célèbre pour son "fait une seule chose et la fait bien". On pourrait lancer des trolls sur Konqueror qui pareil est réputé pour respecter à donf la philosophie Unix. Globalement dans le trip Unix, on auraît du tout coder à base de pipe pour construire des supers briques logiciels de la mort. Au final, ca sert juste à faire des scripts.
                    Si le système l'est, alors le shell l'est (peut l'être) aussi.
                    Et ben t'as tout compris : .NET c'est une couche d'abstraction objet pour offrir les services du système (et plus).

                    Moi je n'attend absolument pas les meme fonctionnalité du shell, du C, du C++, du lisp et du python.
                    Et ben t'as tout compris d'une 2ème idée de .NET : on fournit un socle objet commun, et on greffe des langages dessus, chacun ayant sa pertinence suivant le contexte. D'où le fait que MS est créé un langage de script spécialement pour son powershell.

                    j'utilise plutot ff vu qu'il me permet de cliquer directement sur le lien qui m'intéresse .
                    Tiens encore une appli qui fait autre chose que ce qu'on lui demande à la base... Elle peut pas laisser ce taf à un lecteur de flux RSS qui ne fait que ca et qui le fait bien ? Elle est où la philosophie Unix ?

                    rien que pour ca tu passe une heure dans les specifs pour savoir quels sont chacuns des attributs si tu n'as pas l'habitude
                    D'où l'intérêt du powershell : la completion grâce à l'introspection. Pas besoin de te taper les specifs et toutes les pages de man en permancence comme tu aurais dû le faire avec un shell classique.

                    et oui, ceux qui utilisent le shell script, c'est pas forcément qu'ils ont envie de faire 4000 lignes de code, mais simplement automatiser rapidement une tache simple
                    D'où mon exemple justement : en 3 lignes tu récupères les 8 premières entrées d'un blog. Fait le avec wget et un parseur xml en script bash, on va voir lequel est le plus simple pour l'admin.
                    • [^] # Re: Je me marre ...

                      Posté par  . Évalué à 5.

                      D'où mon exemple justement : en 3 lignes tu récupères les 8 premières entrées d'un blog. Fait le avec wget et un parseur xml en script bash, on va voir lequel est le plus simple pour l'admin.

                      Une ligne (bon j'ai pas wget sur ma machine, donc je peux pas faire le lien avec le fichier) :
                      perl -e 'use XML::Simple; $lim = 8; $items = ${XMLin("/users/cvaraldi/priv/rss.xml")}{"item"}; foreach (@$items) { print $$_{"title"}."\n" if($lim -- > 0;}'

                      Temps de reflexion : quedalle.
                      Faut utiliser les bons outils aux bons endroits, c'est tout. Y'a pas que sed/awk/wget dans la vie.

                      Le concours du nombre de ligne ne rime a rien, ce qui importe, c'est le temps et la fiabilité que tu auras mis a developper ton script. Ce qui compte aussi, c'est la portabilité.
                      Ici, mon truc est portable. Qu'en est-il de ton script ? Tu vas cloisonner, fermer, ta solution, a la seule plateforme Windows. Jusqu'a ce que ca emmerde les gens, et que quelqu'un fasse un portage. Qu'aura-t-on gagné ? Beaucoup de sueur, pour rien.

                      Ce shell est peut etre interessant, mais ne sera jamais une solution deployable en milieu etherogene. Inutile a grande echelle. Sans compter la formation que les admins devraient faire, pour quelque chose qu'ils savent deja faire et rapidement.
                      • [^] # Re: Je me marre ...

                        Posté par  (site Web personnel) . Évalué à 1.

                        Le concours du nombre de ligne ne rime a rien, ce qui importe, c'est le temps et la fiabilité que tu auras mis a developper ton script.
                        Ben justement, c'est ce que j'ai voulu montrer : sans y connaître grand chose, la completion automatique du powershell permet de découvrir facilement les services offerts.
                        Question temps, t'es gagnant. Question fiabilité, tu manipules des données typées, c'est toujours plus fiable que non typées. Question lisibilité, on laissera chacun se faire une idée.

                        Ici, mon truc est portable. Qu'en est-il de ton script ?
                        Mouarf, tellement portable, que t'as bien précisé que t'avais pas wget sur ta machine, imagine que sur ma mache j'ai pas... perl. Super portable dis donc. L'intérêt du powershell, c'est de se baser sur le framework .NET qui propose un nombre conséquent de fonctionnalités, en standard.

                        Jusqu'a ce que ca emmerde les gens, et que quelqu'un fasse un portage.
                        Oué bah comme quelqu'un a dû faire le portage de perl & co. C'est exactement pareil. On a déjà une infrastructure .NET sous linux, il ne manque que le powershell. Le gros inconvénient c'est que c'est pas un LL, va donc commencer par falloir en faire une implémentation libre. Mais la portabilité n'a strictement rien à voir là dedans : c'est pas un problème technique mais un problème politique.
                        Après tiens ca me fait penser que Novell a passé un accord avec MS, pas que sur des questions juridiques, mais aussi pour bosser sur des technos facilitant l'administration de serveurs hétérogènes... Sachant que les technos mises en avant dans leur truc sont Samba, .NET mais aussi Mono (.NET portable), s'ils ont la même idée que moi...
                        • [^] # Re: Je me marre ...

                          Posté par  . Évalué à 4.

                          mais aussi Mono (.NET portable)
                          Mono ... projet fait pas microsoft, bien connu...
                          Sortir l'argument de .Net c'est beau , windows met en avant la portabilité PARCE QUE des benevoles se sont crever le cul pour le porter, je trouve ca fort en café.
                          • [^] # Re: Je me marre ...

                            Posté par  (site Web personnel) . Évalué à 1.

                            , windows met en avant la portabilité PARCE QUE des benevoles se sont crever le cul pour le porter, je trouve ca fort en café.
                            MS a surtout eu l'idée intelligente de concevoir son framework pour être portable : c'est une couche d'abstraction vis-à-vis du matos et de l'OS. Ils ont pondus des implémentations "shared-source" (pas libre, non-commercial uniquement toussa) pour montrer que c'est techniquement faisable. Donc .NET est portable parcque MS a décidé de le concevoir de la sorte. Commercialement ils ont préférés le garder pour leurs produits et ainsi y mettre une valeure ajoutée.
                            Mono apporte surtout le côté logiciel libre que MS ne veut évidemment pas faire.
                            Mais bon, revenons à nos moutons, et évitons de partir dans les trolls stériles.
                        • [^] # Re: Je me marre ...

                          Posté par  . Évalué à 5.

                          Mouarf, tellement portable, que t'as bien précisé que t'avais pas wget sur ta machine, imagine que sur ma mache j'ai pas... perl. Super portable dis donc.

                          A ce petit jeu, cherche pas la ptite bete avec Perl, il a des modules tres bien qui permettent de s'affranchir du wget ;0)
                          Et mon code reste largement plus portable que le tien, qui ne fonctionnera jamais ici avec les solaris, les linux, les ppc, les anciennes versions de windows... les machines type embarquees.
                          Pour tout ca, perl est installable et installé. Je peux propager mon pti script, y marchera tres bien chez tout le monde.
                          Il se trouve que j'ai pas wget, et je l'ai précisé parce que c'etait suggere plus haut d'utiliser wget et du sed/awk/grep pour dire que c'etait vachement plus compliqué, verbeux etc.

                          c'est pas un problème technique mais un problème politique.

                          C'est aussi un probleme de cout. Je suis une entreprise, je ne peux pas engager X personnes sur Y mois pour pondre un portage qui servira a faire ce qui est tout a fait faisable sans. Le cout n'est pas le meme. Ensuite, mono et .NET sont sous linux. Qu'en est-il des microsystemes et des OS plus exotiques (pour toi) comme solaris (qu'on peut trouver ici a la pelle). Il faudra en faire l'integration. Encore un surcout.
                          Ensuite, avant de faire le portage, il faut verifier si y'a pas de brevets sur certaines techniques utilisees la dessous, sinon c'est pas bon. Il faut se palucher les specs, et reinventer la roue. Perl a ete porté un jour, mais il etait libre. Beaucoup plus facile a porter !

                          -- Maintenant j'vais m'amuser a repondre aux commentaires en bas pour pas faire de doublons :D

                          MS a surtout eu l'idée intelligente de concevoir son framework pour être portable : c'est une couche d'abstraction vis-à-vis du matos et de l'OS.
                          Dire ca, et parler de Samba comme techno mise en avant, moi ca me fait tout bizarre. Samba, c'est des gars qui se sont cassé le cul a decortiquer un truc dont ils ne pouvaient pas avoir les specs. Ils ont fait du retro ing', ils ont essayé de decortiquer les traces d'E/S, pour pondre leur projet. Alors "concevoir pour etre portable"...

                          Un one-liner perl. Tu as donc meilleur temps de rajouter le shebang et de rendre ton script perl executable.
                          Et il est où le shell là dedans ?

                          C'est en substance ce que disait briaeros : y'en a pas. Mais tu sais, awk n'EST PAS le shell. sed non plus. Ce sont des utilitaires qui gravitent autour.
                          Moi ce que j'attend d'un shell, c'est d'avoir un endroit ou je peux taper des trucs dedans, et que ca me reponde un resultat suivant les instructions données. Ces instructions sont en sh. si j'invoque sed, c'est pas une fonction sh que j'utilise, c'est une execution qui est faite en dehors.
                          Ici, powerShell melange les deux notions. C'est un concept que je trouve a la fois interessant (si, je suis pas tout noir ou tout blanc hein ^_^), mais dangereux (et si je veux un shell minimaliste ?)


                          J'adore aussi le contexte qui fait que tu es obligé de te replonger dans le perldoc pour capter ce que l'autre a voulu écrire

                          Heuuuu... replonger dans perldoc pour lire mon one-line ? Hmmm... Pourtant, il est lisible (entre autres grace aux $@% que tu decries tant). XML::Simple, on se doute que ca va travailler sur du XML, et Simple, que ca va etre bateau. XMLin : baaaah, je lui donne un xml en parametre, donc in. Je m'attend a ce qu'il mache quelque chose. ${XMLin(...)}{'item'} -> cool, c'est une table de hashage ! Alors toute la structure est organisee comme ca => Facile, tu as la dtd, tu la regardes, paf paf, t'as ta table de hashage. Aucune difficulté.


                          Quant à la portabilité: pour avoir développé des scripts portables en perl je peux te dire que c'est un vain mot.

                          J'ai un prog de 11000lignes dans les mains. Il tourne sous solaris/linux sans probleme. 1h plus tard, je l'ai fait tourner sous windows (petits soucis avec les C:\ ). Ce n'est pas un vain mot.


                          Le moment que je préfère aussi c'est lorsque mon xemacs sous Windows n'arrive plus à coloriser mon script parce qu'il n'arrive plus à parser ce beau langage à la syntaxe si limpide.

                          Deja, use emacs :D Ensuite, ca c'est lié a ton editeur de texte, pas au langage en lui meme. Je peux te garantir que le powershell, dans ton xemacs, la, il va pas te le colorier joli joli :D
                          (et oui, le perl peut etre beau et limpide, comme tout autre langage)



                          Bref la courbe d'apprentissage est tellement grande que je comprend que les gourous de ce langage aient tant de mal à le quitter après tant d'investissement. Quand tu dois produire un truc rapidement sans expérience préalable Perl n'est assurément pas la bonne solution.

                          Tu sais quoi ? Passer de php a perl et inversement, ca ne devrait pas etre un investissement si enorme. Perl, je l'ai appris entre les cours, en 2 semaines. Super gros l'investissement initial. Apres, c'est vrai, j'en apprend tous les jours. C'est aussi ca qui fait que j'aime bien ce langage.

                          Et donc pour produire un truc rapidement sans experience prealable, quel langage preconises-tu ? php ? python ? ruby ?
                          Des trois, je dirais que le plus simple est peut etre ruby, mais il faut s'y faire, au debut c'est parfois un peu deroutant.


                          Ben moi quand je relis le code donné par Timaniac, je vois bien un pipe alors que je n'en vois pas dans ton exemple.

                          Y'a pas forcement besoin de pipe dans mon one-line :)
                          Et si tu en veux un, il est en tete de script avec le wget :)


                          Je n'arrive pas à lancer perl en interactif

                          perl -de 1
                          Mais j'avoue que c'est du debuggeur, c'est clairement pas aussi bon que l'invite python (exemple con : perl -de n'autorise pas les blocs en plusieurs lignes, et c'est lourd)

                          En résumé, un shell c'est un programme qui permet d'intéragir simplement avec l'utilisateur en ligne de commande avec un retour immédiat et qui en plus permet de réaliser des scripts.

                          Powershell me parait répondre à cette description.

                          Tout a fait d'accord avec toi. Et c'est pour ca que j'ai repondu a son powershell par du perl.
                          Simplement, il ne faut pas croire que powershell est la reponse a tout, c'est ce que j'essaye de dire depuis le debut d'une certaine maniere.


                          J'ai pas le temps de chercher car je dois partir au boulot, mais c'est à peu prés sur que des mongueurs perl ont en leur stock des unilines de ce type. Je vois pas trop l'exploit, on fait des trucs bien plus impressionnant que ça en uniline perl ...

                          Ca n'a strictement rien d'impressionnant, je te rassure. Voir les A++ sur paris.mongueur pour voir de jolis oneline :)
                      • [^] # Re: Je me marre ...

                        Posté par  . Évalué à 0.

                        Un one-liner perl. Tu as donc meilleur temps de rajouter le shebang et de rendre ton script perl executable.
                        Et il est où le shell là dedans ?

                        Elle est ou la puissance d'unix qui permet d'enfiler tout un tas de commandes qui ne font qu'une chose mais le font bien là ?

                        Ben non. Le shell montre ces limites alors on passe à Perl, un langage de script comme un autre mais qui reprend toutes les hérésies du shell en plus complexe.
                        Ce que je préfère, c'est les indirections et autres signes cabalistique (@$, ...). Quand tu en est a ton 3eme niveau de liste de référence de tableau et que tu passes une heure à trouver la bonne séquence de caractère.

                        J'adore aussi le contexte qui fait que tu es obligé de te replonger dans le perldoc pour capter ce que l'autre a voulu écrire

                        Quant à la portabilité: pour avoir développé des scripts portables en perl je peux te dire que c'est un vain mot.

                        Le moment que je préfère aussi c'est lorsque mon xemacs sous Windows n'arrive plus à coloriser mon script parce qu'il n'arrive plus à parser ce beau langage à la syntaxe si limpide.

                        Bref la courbe d'apprentissage est tellement grande que je comprend que les gourous de ce langage aient tant de mal à le quitter après tant d'investissement. Quand tu dois produire un truc rapidement sans expérience préalable Perl n'est assurément pas la bonne solution.
                        • [^] # Re: Je me marre ...

                          Posté par  . Évalué à 2.

                          Elle est ou la puissance d'unix qui permet d'enfiler tout un tas de commandes qui ne font qu'une chose mais le font bien là ?
                          Nulle part, elle montre juste que powershell n'est somme toute qu'un lgg de script comme un autre (perl par exemple).

                          Quant à la portabilité: pour avoir développé des scripts portables en perl je peux te dire que c'est un vain mot.
                          Et elle est ou la portabilité chez ms ? Ne me dis pas mono, mono n'est PAS un projet de ms.
                          • [^] # Re: Je me marre ...

                            Posté par  . Évalué à 4.

                            Ben moi quand je relis le code donné par Timaniac, je vois bien un pipe alors que je n'en vois pas dans ton exemple.

                            Ca montre juste que la frontière entre langage de script et shell n'est pas si claire que tu veux nous le faire croire.
                            Un shell c'est un programme basé sur un interpréteur (tiens c'est donc un VM en quelque sorte) dans lequel tu peux lancer des commandes en interactif.
                            Tout comme powershell.
                            Je n'arrive pas à lancer perl en interactif alors que python me le permet (python est il un shell ?). Mais avec python je n'arrive pas à enchainer des commandes simplement sans faire appel au librairies du système (os.popen, os.exec , ...) ce qui expliquerait pourquoi on parle de langage de script. Et là par contre Perl l'autorise.

                            Un script pour moi, c'est un programme enchainement de commandes automatisée et bizarrement les shell permettent celà. Doit-on les appeler langages de scripts ?

                            En résumé, un shell c'est un programme qui permet d'intéragir simplement avec l'utilisateur en ligne de commande avec un retour immédiat et qui en plus permet de réaliser des scripts.

                            Powershell me parait répondre à cette description.
                            • [^] # Re: Je me marre ...

                              Posté par  . Évalué à 2.

                              déja confond pas tout le monde c'est pas 'mon' exemple, je suis nul en perl ;)
                              ensuite il t'a répondu au dessus :-D

                              Ca montre juste que la frontière entre langage de script et shell n'est pas si claire que tu veux nous le faire croire.
                              Elle est extrémement claire.
                              Un shell est une interface minimaliste entre le systeme et l'utilisateur. Ensuite qu'on puisse faire des scripts avec c'est byzance, mais c'est pas le but initial d'un shell.
                              C'est d'ailleur pour ca que l'on peut le lancer directement à partir du noyau (si compilé en statique, ce qui n'est pas toujours le cas dans les distribs ) (init=/bin/sh).

                              La ce qu'on voit c'est qu'il y a certe un interfacage avec le systeme, mais par une couche d'abstraction , une vm, et ceci pour introduire une syntaxe objet . C'est intéressant , mais ce n'est pas un shell proprement dit. C'est un lgg de script issu de .net avec des facilités pour la communication avec le systeme.



                              En résumé, un shell c'est un programme qui permet d'intéragir simplement avec l'utilisateur en ligne de commande avec un retour immédiat et qui en plus permet de réaliser des scripts.
                              Un retour immédiat ? ca veux dire quoi ca ?
                              Ca veux dire qu'on peut lancer plusieurs trucs en paralléle ? C'est vrai que les systemes actuelle le permet, mais ce n'était pas forcément le cas avec les premiers shells ou autre.
                              ou ca veux dire qu'on voit forcément qqch dans le shell ? Dans ce cas c'est complétement faux (suffit d'utiliser les redirections /dev/null \o/).
                              lance fsck -yn /dev/hda1 >/dev/null 2>&1 pour voir si tu as un retour immédiat sur une partoch de 40 Go ...
                    • [^] # Re: Je me marre ...

                      Posté par  . Évalué à 2.

                      J'ai pas le temps de chercher car je dois partir au boulot, mais c'est à peu prés sur que des mongueurs perl ont en leur stock des unilines de ce type. Je vois pas trop l'exploit, on fait des trucs bien plus impressionnant que ça en uniline perl ...
                    • [^] # Re: Je me marre ...

                      Posté par  . Évalué à 2.

                      On pourrait lancer des trolls
                      Et oui personne n'est parfait que veux tu.
                      Ah si tiens pe que .Net est parfait vu qu'il n'accepte aucune critique...

                      on fournit un socle objet commun, et on greffe des langages dessus, chacun ayant sa pertinence suivant le contexte.
                      Trés pertinnent quand le type de lgg que l'on veut utiliser s'en fout royalement de l'objet (par exemple lisp , ou prolog ou encore le C ...). Ca c'est de la pertinence à l'objet pur.

                      Tiens encore une appli qui fait autre chose que ce qu'on lui demande à la base...
                      Ah bon tu es sur ?
                      On demande a cette appli de surfer sur le web cad lire les pages web , et le contenu associé (js, flash, ... et rss). La j'entend bien entendu des rss lié a une page web, comme dans ton exemple.


                      D'où mon exemple justement : en 3 lignes tu récupères les 8 premières entrées d'un blog. Fait le avec wget et un parseur xml en script bash, on va voir lequel est le plus simple pour l'admin.
                      En 3 lignes CRYPTIQUES (désolé pour moi il est pas évident que la classe System ai un attribut nommé .Net, ni que ce meme attribut ait un attribut nommé WebClient ni que cet attribut possede une fonction 'DownloadString' (pourquoi pas DownStr ou GetUrl ou ...)
                      enfin voir le commentaire de 'Clément varaldi' pour ce sujet.


                      D'où l'intérêt du powershell : la completion grâce à l'introspection.
                      Et tu la commence comment ton introspection ?
                      Et ton script tu le tape ou ? directement dans le shell, ou dans un éditeur de texte ou ... ?


                      Globalement dans le trip Unix, on auraît du tout coder à base de pipe pour construire des supers briques logiciels de la mort. Au final, ca sert juste à faire des scripts.
                      Globalement tu dis de belle connerie sans meme t'en rendre compte.
                      Encore une fois, le script shell c'est pour faire des trucs simple. Si ce n'est plus simple, on arrete le shell script et on change de langage et c'est tout.
                      Et le powershell c'est juste un lgg de plus. Alors il est peut etre génial, mais c'est pas un shell.
                      • [^] # Re: Je me marre ...

                        Posté par  (site Web personnel) . Évalué à 2.

                        Trés pertinnent quand le type de lgg que l'on veut utiliser s'en fout royalement de l'objet (par exemple lisp , ou prolog ou encore le C ...).
                        Evidemment, .NET n'est pas non plus adapté à tous les langages : c'est une plateforme multi-langages... objets.

                        Ah bon tu es sur ?
                        Tu sais la limites est flou, si tu considères qu'un navigateur web doit faire tout ce que propose le web, t'es pas rendu : tu peux faire des web-services, faire du WebDav, faire du protocole de chat, etc. Après ton navigateur peut vite devenir une usine à gaz. La limite, tu la fixes où tu veux, et c'est bien pour ca que la philosophie Unix est foireuse : si tu considère la brique élémentaire de base, tu fixes l'instruction assembleur. Ou alors tu fixes la limite là où ca t'arrange, suivant les besoins, le contexte, auquel cas la philosophie ne tient plus debout.

                        que cet attribut possede une fonction 'DownloadString' (pourquoi pas DownStr ou GetUrl ou ...)
                        D'où l'intérêt de l'autocomplétion : t'as pas à réfléchir à la syntaxe comme sous Unix ou si t'as le malheur de mettre une option "A" en minuscule "a" tu changes entièrement le comportement de la commande.

                        Et ton script tu le tape ou ? directement dans le shell, ou dans un éditeur de texte ou ... ?
                        Bah comme d'hab : dans le shell ou dans un fichier de script...

                        Globalement tu dis de belle connerie sans meme t'en rendre compte.
                        T'es gentil, mais argumente un minimum. C'était quoi pour toi la philosophie des pipes Unix à la base ?

                        Alors il est peut etre génial, mais c'est pas un shell.
                        Le powershell c'est un shell associé à un langage de script. Comme tous les shells Unix. Vois pas ce que tu cherches à démontrer. Appelle le powershell comme tu veux, le fait est que son intérêt est le même : administrer en ligne de commande, faire des petits scripts simples.
                        • [^] # Re: Je me marre ...

                          Posté par  . Évalué à 2.

                          Bah comme d'hab : dans le shell ou dans un fichier de script...
                          Et dans ton fichier de script , tu n'as pas l'autocomplétation :-P



                          Globalement dans le trip Unix, on auraît du tout coder à base de pipe pour construire des supers briques logiciels de la mort. Au final, ca sert juste à faire des scripts.
                          Globalement tu dis de belle connerie sans meme t'en rendre compte. > j'argumente :
                          le trip unix n'est en aucun cas faire que du shell script.
                          on fait un seul truc mais on le fait bien pour éviter l'usine a gaz qui fait tout mais mal.
                          Dans le trip unix comme tu dis, on aurait du tout coder dans LE LANGAGE LE PLUS ADAPTES, c'est tout. On utiliserais pas de 'pipe' si on en pas besoin.
                          On utiliserais des librairies plutot que des programmes lorsqu'on a besoin de faire des enchainement ( un minimum compliqués) entre différentes fonctions précodés toussa.
                          Le coup du shell script c'est quand meme essayer de concevoir des petites usines a gaz que l'on démentelera juste aprés l'utilisation.

                          Ca a son intéret, comme je pense que le LANGAGE power shell a son intérêt, mais ce n'est pas forcément le meme intérêt.
                          C'est un peu comme la twingo : au départ ca a été concu pour les femmes citadines. Finalement ce sont plutot les campagnard qui l'ont acheté au début parce qu'elle remplacait la 4L. Ce sont juste trompé de cible ;)
                          Alors oui le powershell pourrais etre un SHELL génial meme pour les unix mais à plusieurs conditions
                          1°) faible empreinte mémoire (be pas avoir tout .Net)
                          2°) possibilité d'être compilé en statique
                          3°) complétement rétrocompatible avec /bin/sh et les fonctions utilisée dans unix (par ex 2 qui ont énormement de mal sous win la derniere fois que j'ai regardé : chroot et mkfifo)
                          On vois ici que le 1°) et 2°) vont être vachement dur a satisfaire avec .Net.
                          • [^] # Re: Je me marre ...

                            Posté par  (site Web personnel) . Évalué à 3.

                            1°) faible empreinte mémoire (be pas avoir tout .Net)
                            C'est basé SUR .NET V2, donc impossible.
                            Ca se sent un peu au lancement, et sur ma machine (PIV 3GHz), je trouve que c'est un peu lent.

                            2°) possibilité d'être compilé en statique

                            C'est un shell script, on s'en fout de la compilation en statique. Pour ça y'a des langages compilés. Et pour les mordus de l'intégration dans le monde Microsoft (et dans .NET), y'a les langages C# like.

                            3°) complétement rétrocompatible avec /bin/sh
                            Pourquoi? tcsh est-il compatible avec sh?
                            Là c'est un nouvel outil avec son fonctionnement, sa syntaxe. Un outil de plus, pas un candidat au remplacement de sh.

                            et les fonctions utilisée dans unix (par ex 2 qui ont énormement de mal sous win la derniere fois que j'ai regardé : chroot et mkfifo)
                            Là c'est de la mauvaise foi caractéristiques. Ce sont des exécutables externes, non pas des commandes du shell lui-même. Un portage de PowerShell sous Mono/Linux serait tout à fait capable de les appeler.
                            Elles ne sont pas natives sous Windows (quoi qu'il faudrais regarder du côté des Windows For Unix Services [*]), mais le but de Microsoft n'est pas de faire de Windows un unix-like.

                            [*] http://www.microsoft.com/technet/interopmigration/unix/sfu/d(...)

                            Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

                            • [^] # Re: Je me marre ...

                              Posté par  . Évalué à 2.

                              C'est un shell script, on s'en fout de la compilation en statique.
                              Je parle du shell en lui même , pas du shell script ;)
                              Cad qu'on doit pouvoir executer le shell sans (trop de) librairie extérieure que le systeme ne sait pas forcément ou chercher toussa ;)
                              Pourquoi? tcsh est-il compatible avec sh?
                              La syntaxe de base c'est bien celle de sh.
                              Si ensuite tu veux faire un script pour tcsh , alors il faut que tcsh soit aussi installé sur ta machine.
                              Je n'ai pas maté les normes pour connaitre lequel doit etre obligatoirement , mais amha il y a de forte chance que ce soit sh.
                              Edit : c'est effectivement sh qui est définis dans posix, pour sa part rechercher tcsh ne retourne rien.

                              Là c'est un nouvel outil avec son fonctionnement, sa syntaxe. Un outil de plus, pas un candidat au remplacement de sh.
                              Au temps pour moi. Mais il semble préférable d'etre rétro compatible quand on pronne la portabilité , non ?

                              Là c'est de la mauvaise foi caractéristiques. Ce sont des exécutables externes, non pas des commandes du shell lui-même.
                              C'est meme pire que ca ... Ce sont des contraintes de l'os !
                              que fait mkfifo ? il crée une fifo.
                              Mais si on veut etre portable, il faut supporter les descripteurs et utilitaires posix ! et faire une fifo fait partie de posix, effectivement :

                              The Open Group Base Specifications Issue 6
                              IEEE Std 1003.1, 2004 Edition
                              Copyright © 2001-2004 The IEEE and The Open Group, All Rights reserved.
                              NAME

                              mkfifo - make FIFO special files

                              SYNOPSIS

                              mkfifo [-m mode] file...
                              • [^] # Re: Je me marre ...

                                Posté par  . Évalué à 2.

                                Edit : c'est effectivement sh qui est définis dans posix, pour sa part rechercher tcsh ne retourne rien.

                                8-0
                                comment tu fais pour editer tes messages?
                                • [^] # Re: Je me marre ...

                                  Posté par  . Évalué à 2.

                                  c'est un faux edit :je tape d'abord tout mon commentaire.
                                  Et je vérifie aprés, recherche de source toussa. Je rajoute juste à la fin mes découvertes quand ca entraine pas de modifications ;)

                                  (oui je sais je suis flemmard).
                                  Mais bon c'est vrai que pouvoir éditer ca serait bien.
                                  • [^] # Re: Je me marre ...

                                    Posté par  . Évalué à 1.

                                    si linuxfr.org utilisait PowerShell, yaurait juste a faire un Net.Web.Message.edit(String newMsg); et ca serait fait.

                                    'fin j'dis ca...

                                    :-D
                      • [^] # Re: Je me marre ...

                        Posté par  . Évalué à 2.

                        En 3 lignes CRYPTIQUES

                        huhu

                        perl -e 'use XML::Simple; $lim = 8; $items = ${XMLin("/users/cvaraldi/priv/rss.xml")}{"item"}; foreach (@$items) { print $$_{"title"}."\n" if($lim -- > 0;}'


                        ou

                        PS> $rssUrl = "http://blogs.msdn.com/powershell/rss.aspx"
                        PS> $blog = [xml](new-object System.Net.WebClient).DownloadString($rssUrl)
                        PS> $blog.rss.channel.item | select title -first 8


                        et c'est le deuxieme que t'appelles CRYPTIQUE.
                        c'est sur qu'imbriquer des accolades, des parenthses, utiliser $@ $$_ et autres joyeusetes, c'est super lisible et comprehensible.
                        • [^] # Re: Je me marre ...

                          Posté par  . Évalué à 3.

                          En PHP:
                          php -r '$xml=simplexml_load_file("http://blogs.msdn.com/powershell/rss.aspx"); foreach($xml->channel->item as $item){echo $item->title . "\n";}'
                        • [^] # Re: Je me marre ...

                          Posté par  . Évalué à 2.

                          Me souviens pas avoir parlé de perl...
                          Juste dis qu'un autre commentaire montrait qu'on pouvait aussi le faire en perl en 'moins de ligne' donc que l'argument 'moins de lignes' était pas forcément a prendre en compte.
        • [^] # Re: Je me marre ...

          Posté par  (site Web personnel) . Évalué à 6.

          Là le mécanisme est plus général et plus cohérent : tu peux utiliser la même démarche avec n'importe quel type d'objet.


          kernel.kill !!

          Trop bien, l'écran bleu en une ligne de commande :)
        • [^] # Re: Je me marre ...

          Posté par  . Évalué à 3.

          Ok, le power shell de Microsoft est bien dans sa conception objet. Ca simplifie pas mal de chose.

          Mais, il y a un mais...

          Ce que je regrette toujours avec les outils Microsoft, c'est qu'en gagnant de la facilité, on perd en possibilité. Les interfaces graphiques, c'est bien beau, mais ça ne permet pas de faire tout ce que l'on peut faire avec un shell : essayez de concevoir une interface pour configurer apache, je doute que vous n'arriviez à penser à tous les cas bizarres et trarabiscotés.

          Et je pense que nous aurons la même limitation avec le power shell : que faire si on veut faire quelque chose qui n'a pas été prévu ? le shell est-il assez souple pour nous permettre de tout faire même ce qui n'a pas été prévu ?

          A suivre donc.... mais je ne suis pas optimiste.
          • [^] # Re: Je me marre ...

            Posté par  . Évalué à 2.

            Si ca n'a pas ete prevu ben c'est simple, t'ecris objet pour le faire toi meme, tout comme tu ecrirais une commande unix toi-meme si elle n'existait pas...
            • [^] # Re: Je me marre ...

              Posté par  . Évalué à 2.

              Ma réflexion était plus dans le sens où en unix on peut arriver à faire presque tout avec les outils disponibles (plus ou moins facilement), mais y'a toujours une solution.
              • [^] # Re: Je me marre ...

                Posté par  (site Web personnel) . Évalué à 2.

                Ben le framework .NET a quand même été conçu pour couvrir le maximum de fonctionnalités. Après si ce qu'il y a dedans te suffit pas, tu peux aussi le faire avec des applis externes. Tiens par exemple tu récupères cygwin (version windows de la plupart des outils ligne de commande de Unix), et hop, tu les exécutes dans le powershell :)
                Je vois pas trop ce qui peut te manquer après !
                • [^] # Re: Je me marre ...

                  Posté par  . Évalué à 1.

                  et tu peut récupérer directement unixtools et les utiliser dans un shell normal
                  je vois pas ce qu'apporte PowerShell dans ce cas .
      • [^] # Re: Je me marre ...

        Posté par  . Évalué à 7.

        Un shell objet c'est :

        L'introspection qui te permet de compléter les actions quelque soit le type de l'objet et ne se contente pas de la complétion des fichiers et du nom de la première commande.C'est un peu comme si on pouvait completer tous les paramètres des commandes unix rien qu'en interprètant la syntaxe de l'aide.

        C'est le fait de ne pas être obligé de passer une demi-heure à debugguer ton script en posant des traces partout parce que les devs de la super commande que tu utilisais ont changé l'affichage en rajoutant un mot qui pourrit complétement le parsing de ton script ou parce que t'avais pas prévu que la locale affectait l'affichage des dates.
        Là, il te prévient que la signature a changé ou que la méthode n'existe plus en te lancant une exception. D'autant que tu fais moins souvent des changements de contrat que d'affichage.

        C'est la vérification qu'une information que tu passes en paramètre à une commande est du bon type plutôt qu'une chaine de caractère en évitant tous les effets de bord et trous de securité associés

        C'est le fait de ne pas être obligé d'apprendre par coeur la syntaxe de 250 commandes imbuvables qui n'adoptent pas toujours les mêmes conventions sur les paramètres pour transformer une chaine de caractère (sed, awk, grep, egrep & co) ou pour en extraire la substantifique moelle.

        C'est le fait de ne pas passer 1h à mettre au point la regexp qui va bien.

        Et je dois en oublier
        • [^] # Re: Je me marre ...

          Posté par  . Évalué à 4.

          C'est un peu comme si on pouvait completer tous les paramètres des commandes unix rien qu'en interprètant la syntaxe de l'aide.

          ZSH fait ça =) (au moins en partie du moins)
          Les commandes unix sont imbuvables, mais elles correspondent à un standard et sont énormément utilisées. On ne peut pas les changer comme ça, ça implique de refaire tous les scripts présent dans les milliers de package pour une distribution, ou d'ajouter encore un interpréteur alors que sur un système gnu/linux de base, on a déjà perl, python, bash (+sed et awk), et d'autres.
          Quand il n'y a qu'un seul outil pour faire ça, ça va, mais dans le cas d'un système unix, vu ce qui existe déjà, on risque plus de complexifier l'utilisation qu'autre chose, et je pense que c'est pour ça que personne ne s'y est intéressé.
      • [^] # Re: Je me marre ...

        Posté par  (site Web personnel) . Évalué à 1.

        Ca fait comme python en moins bien.

        L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

    • [^] # Re: Je me marre ...

      Posté par  . Évalué à 4.

      Bon ben tant mieux alors, qu'ils le sortent en opensource et facilement implémentable sans la technologie .NET qui n'intéresse pas forcément tout le monde, que cela soit complètement interopérable (qui a dit posix ?) et utilisable sur les autres OS et on en reparlera (peut etre en bien...)

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

      • [^] # Re: Je me marre ...

        Posté par  . Évalué à 1.

        Ragarde la partie "techinque" avant de crier au "c'est ms donc c'est mal ou ça va l'être".


        Ce dont je parle, c'est le principe de X, pas "X" lui même. Que ce soit MS qui ait implémenté en premier le principe de X correctement (à voir, on a pas encore trop de retour) ça veut pas dire que le principe de X est à jeter.

        Je me marre toujours autant, donc, c'est exactement ce que je voulais dire : on l'a pas encore, et c'est MS qui le fait, donc la techo est mauvaise. Si on avait eu la même chose en libre en premier, tout le monde aurait crié au génie.
        • [^] # Re: Je me marre ...

          Posté par  . Évalué à 3.

          et bien ? Je n'ai pas dit que l'idée était mauvaise. Mais s'il faut aligner les $$$ pour pouvoir implémenter l'idée sous linux (à supposer que cela soit possible et que cela en vaille la peine), ou faire des contrats de non agression avec MS parce qu'on a le poids pour (comme Novell), cela est nettement moins attractif.

          Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

          • [^] # Re: Je me marre ...

            Posté par  . Évalué à -3.

            Je te laisse à tes illusions ... Tu crois que la totalité des lignes de code de ton OS préféré a été écrite sans argent ?
      • [^] # Re: Je me marre ...

        Posté par  . Évalué à 0.

        Heureusement que tous les projets logiciels n'ont pas besoin d'etre implementable sur tous les types de technologie, interoperable avec tout et utilisables sur tous les OS pour qu'on en parle, sinon personne ne parlerait d'informatique.
  • # les commande Linux y sont reconnues

    Posté par  . Évalué à 9.


    > ls --help
    Get-ChildItem : A parameter cannot be found that matches parametre name '--help'.
    At line: 1 char:9
    * ls --help <<<
    > ls|grep Favoris
    The term 'grep' is not reconized as a cmdlet, function, operable program, or script file. Verify the term and try again.
    At line:1 char:8
    * ls|grep Favoris <<<


    PowerShellSaiNull®
    • [^] # Re: les commande Linux y sont reconnues

      Posté par  . Évalué à 2.

      en fait c'est super car cela fait les pages de man en meme temps que l'on tape les commandes !

      en particulier on voit cela ici :
      http://www.clubic.com/afficher-en-plein-ecran-400794.html

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Béh nos soirée vont devenir drôle, tiens

      Posté par  . Évalué à 3.


      > help
      The term 'help' is not recognized as a cmdlet, function, operable program, or script file. Verify the term and try again.
      At line : 1 char:1
      * help <<<
      > help.stp*
      Command list : help.stp.plz.je-ten-prie help.fuck.maintenant! help.man.function.help
      > help.man.function.help help.man.function.help
      help.man.function.help error : no manual page for help.man.function.help.
      The term help.man.function.help is not a cmdlet, function, operable program, or script file. Verify the term and try again.
      At line:1 char:8
      * help.man.function.help help.man.function.help <<<


      PowerShellSaiLeMAL
  • # Désolé, j'ai pas m'en empécher

    Posté par  . Évalué à 10.

    Le principe de ce shell, n'est pas de traiter du texte comme sous Linux, mais des objets (grosso modo du C#)


    ca serait pas plutôt "grosso mono du C#" ?
  • # performance

    Posté par  . Évalué à 0.

    cool, déjà qu'on est pas content de tel ou tel terminal qui consomme trop de CPU quand du texte défile, qu'on est outré quand zsh bouffe 10 meg de ram ... là on a droit à un shell à VM histoire de devoir acheter un pentium 3GHZ (qui accélère l'internet je le rappelle) et 1 gig de ram pour pouvoir faire un ls. on arrête pas le progrès, nous vivons une époque moderne.
  • # Faille de securite mieux exploitable

    Posté par  . Évalué à 5.

    Bon maintenant, au moins, on aura un vrai remote shell convi !

Suivre le flux des commentaires

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