Journal MSH beta est disponible mais ne sert à rien

Posté par (page perso) .
Tags : aucun
0
21
juin
2005
Microsoft vient de publier une version bêta de son Shell révolutionnaire. Il semblerait que bash ait encore de beaux jours devant lui.

Pourtant, quelques idées semblaient intéressantes.
Par exemple l'équivalent du "ls" retourne non pas le descriptif des fichiers sous forme de texte, mais des objet correspondant aux fichiers listés, que la console (ou l'éventuel programme dans lequel se dirige le pipe) peut afficher de la manière de son choix.
De plus il est possible dans le pipe de ne sélectionner que certains objets, grâce à des filtres portant sur leurs propriétés (ce qui serait possible sous bash, théoriquement, mais je ne crois pas que ça existe). Enfin, le shell peut transcrire les objets en xml, fichiers Excels...

Le problème, c'est que la volonté d'un shell "propre" d'un point de vue théorique a conduit ce langage à l'inexpressivité la plus totale.
Par exemple, le ls -R dossier semble s'écrire get-childitem -Recursive -Path dossier.
Il est heureusement possible d'écrire des alias, et certains sont fournis par défaut. Mais quand on doit aliaser toutes les commandes avant de pouvoir décemment les utiliser, c'est qu'il y a un problème.

Je doit reconnaître qu'il ne m'a pas été possible de le tester, cela requérant d'avoir windows, le paquet .net, un compte passeport et de s'enregistrer (pour les plus courageux, la procédure est indiquée sur le quatrième lien).

Mais j'ai quand même trouvé des scripts, qui sont censé être impressionants mais qui illustrent à mon avis l'inutilisabilité de la chose. Pour les utiliser, il vous faudra peut être changer la valeur du MSHCommandPath (14 lettres).

Le premier "FindStringsInWordDocs.msh" est un équivalent du antiword fichiers.doc|grep mot (mais sans le support des regexp, sachant je n'arrive pas à comprendre la syntaxe pour l'invoquer, et qu'il faut avoir acheté msword pour qu'il marche).
$phrase = $args[0];
$wd = new-object -activex "word.application";
$p = pwd;
if ($args.length > 1) {
$docs = $args[1];
} else {
$docs = "*.doc";
}
foreach ($a in $(get-childitem $docs -name)) {
$doc = $wd.documents.open("$p\$a");
if ($doc.content.find.execute("$phrase")) { write-host $a }
$doc.close();
}


Le second change le prompt (équivalent de "PS1=" sous bash) en 17 lignes de code cryptique. C'est la réponse à la neuvième question de la FAQ.
function prompt
{
# make sure the end of the path is always visible at the prompt
$local:path = $(get-location).ToString()
$local:maxPath = [int] $MshHost.UI.RawUI.WindowSize.Width - 1

if ($local:path.length -gt $local:maxPath)
{
$local:x = [int] [System.Math].Max(0, $([int] $local:maxPath - 10))
$local:path = '...' + $local:path.Substring(($local:path.length - $local:x), $local:x )
}
$local:counter = $(get-history -count 1).Id
$local:counter += 1
# also show the path at the command windows title bar
$mshhost.UI.RawUI.WindowTitle=$('MSH - ' + $path)
#Show the prompt in blue
write-host $('MSH {0:d} {1}' -f $local:counter, $local:path) -fore Blue
'>'
}

Enfin, le troisième, MSHColorFunctions est un palliatif au manque de fonctions aussi simples que setterm.
Rappelons en effet que le nombre de programmes accessibles depuis la ligne de commande risque d'être extraordinairement limité par rapport à ce qu'on trouve sous Unix (ce qui est peut être compensé par l'accès au framework de .net).

Dans ces conditions, l'enthousiasme des utilisateurs de windows parait franchement surprenant. Peut être ai-je manqué une fonctionnalité ? Ou alors ils ne savent pas qu'un shell n'est pas forcement un langage destiné à écrire des projets d'envergure, mais simplement un truc commode au quotidien.

Un exemple parfait me semble être le fait que toutes les démonstrations de ce shell (cf google) trient des processus, les mettent dans des fichiers, affichent des dates, manipulent des chaînes de caractères... mais qu'aucune ne crée d'utilisateurs, ne redimensionne d'images, ne fait de calculs ou n'envoie d'email.
Je n'ai même pas entendu parler de la commande qui permettrais de déplacer des fichier ! Je sens déjà venir les "get-child -Path source *.txt|move-item destination".
Toujours dans cet esprit il manque à ce shell la gestion de la complétion par [tab], les options n'ont pas d'alias cours (comme -d pour --long)...

Bon, ceci dit il y a un ou deux cas où il se comporte mieux que bash (notement grâce à where). Mais il ne me convainc pas pour l'utilisation quotidienne.

Liens :
  • # un autre

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

    t'avais vu ce journal http://linuxfr.org/~patrick_g/18270.html(...) ?
    Comment comparerais MSH et Fish ? Est-ce que les quelques manques de Bash par rapport à MSH que tu évoque seront pris en compte dans une future version ou est-ce que Fish te semble plus prometteur ?
    • [^] # Re: un autre

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

      Comment comparerais MSH et Fish ?
      Pour le peu que j'en ai vu, Fish-le-shell c'est presque un shell Unix traditionnel.

      Est-ce que les quelques manques de Bash par rapport à MSH que tu évoque seront pris en compte dans une future version ou est-ce que Fish te semble plus prometteur ?
      Avant toutes choses, je tient à dire que je suis un gros newbie du shell, que je parle en toute subjectivité et je sait que les gens qui conçoivent ces logiciels ont probablement pensé à des choses que je ne peut même pas imaginer.

      Pour fish j'ai pas vraiment d'avis, il m'a pas l'air très utile: c'est juste une nouvelle syntaxe à peine préférable. Mais comme l'interêt du scripting bash par rapport à des langages comme python est justement que l'interpréteur est répendu, Fish me parrait pas très utile. Autant promouvoir de "vrais" langages.

      Pour ce qui est d'amelliorer bash, j'essaierais peut être de faire un truc ces vacances : l'idée est qu'on peut arriver en bash au même genres de filtres qu'avec MSH, si on considère que la quasi-totalité des informations manipulées par les programes du shell sont des nom de fichiers ou du texte formaté en colonne.
      L'idée serait de faire un genre de grep, qui pourrais appeler des programmes externes pour trouver les propriétés de ses arguments, et aussi parser les formats de sortie "standards" (objets séparés par des retours à la ligne, propriétés séparées par des tabulation - les trois quarts des utilitaires marchent comme ça).
      Avec ça, on ferais par exemple "ps aux | filter -c -t CPU -gt 10" ( -c pour définir un critère, -t pour désigner la colonne qui a la valeur CPU à sa première ligne, les autres tests utiliseraient le format standard (man test)).
      On encore "ls -R | filter -c -e du -gt 1000" pour trouver les programe de plus d'un kilo-octet grâce à un appel de "du" (find le fait, mais c'est pour illustrer).
      Avec un outil comme ça, je pense on disposerais en pratique des mêmes fonctionalités, dans tout les shells et sans la lourdeur des concepts de MSH.
      Et si il est en C, il pourras devenir un des outils standards, ou même titre que skill et ses copains.

      (si j'y arrive je ferais aussi un programme pour standardiser la sortie des programes Unix plus abscons, voir j'essaierais de contacter leurs auteurs pour leur proposer un switch supplèmentaire)
      (PS: Attention, c'est pas une promesse, vu que j'ai tendance à ne jamais finir ce que je commence. et qu'en plus je bosse jusqu'en juin. Si quelqu'un veut faire ça à ma place, ça me gêne pas -_^ (ça serait sympa de m'en parler))
  • # Hmm

    Posté par . Évalué à 4.

    Les comparaisons sont peu objectives qd meme je n'ai pas teste. Mais tu compare ps1 au script qui change la fenetre du terminal y mets des couleurs. Ok c'est possible sur unix depuis longtemps mais avec des caracteres d'echapements qui sont pas toujours facile a recuperer.

    Les %? (? = lettre) du PS1 ne sont pas toujours portables et il faut parfois bidouiller selon les platformes ... De toute facon tu commences en concluant donc ...
    • [^] # Re: Hmm

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

      Les comparaisons sont peu objectives qd meme je n'ai pas teste.
      Je te le consède. Ceci dit, j'ai réellement pris les premiers codes qui me sont tombés sous la main.

      Ok c'est possible sur unix depuis longtemps mais avec des caracteres d'echapements qui sont pas toujours facile a recuperer.
      man console_codes

      Les %? (? = lettre) du PS1 ne sont pas toujours portables et il faut parfois bidouiller selon les platformes ...
      Alors que MSH c'est portable ?
      Au moins bash existe sur plusieurs plates forme.

      De toute facon tu commences en concluant donc ...
      Rien à redire, je m'était déjà fait mon avis en commençant à rédiger.
      • [^] # Re: Hmm

        Posté par . Évalué à 2.

        MSH peut être potentiellement porté sur Unix. D'après de vieilles lectures, il est basé sur le .NET Framework, qui lui a été porté sur Linux, Osx et bien d'autres (grace à des projets tels que Mono et DotGnu).

        Mais bon, attendons de voir ce que ça vaut réellement avant...
        • [^] # Re: Hmm

          Posté par . Évalué à 7.

          c'est clair qu'on va tous utiliser mono pour pouvoir utiliser cette merde
        • [^] # Re: Hmm

          Posté par . Évalué à 1.

          Ce qui fait bien rire c'est quand M$ dit lui même que .Net est multi plateforme aux conférences alors que selon moi ce n'est pas le cas... Que je sache les dev de M$ n'ont pas aidé dans le projet Mono/DotGNU.
          • [^] # Re: Hmm

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

            Que je sache les dev de M$ n'ont pas aidé dans le projet Mono/DotGNU.
            Eh oui il y a des choses que tu ne sais pas : Les dev de M$ ont gentiment aidé les dev de Mono quand ceux-ci avaient des difficultés.
            • [^] # Re: Hmm

              Posté par . Évalué à 1.

              Tu as des sources ?
              Je veux bien te croire si tu m'en donnes.
    • [^] # Re: Hmm

      Posté par . Évalué à 3.

      Pas mieux.

      Sans rien connaitre à MSH, je comprend presque les 17 lignes de code.
      Tandis que la signification des chaines bizaroides d'un PS1 m'échappe toujours...
  • # Filiation bizarre...

    Posté par . Évalué à 8.

    L'impression que ca me donne :
    On prend un shell, VBscript, on jette le tout dans un mixer et on se retrouve avec une syntaxe bidouillée pour pouvoir faire un peu des 2.

    Mis à part le fait que ce sera un poil plus facile à lancer, faudra me montrer l'interet de la chose par rapport à leur vbs.

    P'tet pouvoir faire comme les grands et devenir champion des one-liner :-)
  • # Ne pas oublier l'intégration avec l'environnement

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

    J'ai vu de nombreux posts critiquer le côté "les applications Windows ne sont pas pilotables en ligne de commande". Attention à ne pas oublier que le pilotage d'applications à la mode microsoft ne passe pas par la ligne de commande, les options et les pipes, mais par le côté scriptable des applications, les COM/DCOM, les composants ActiveX...

    Si on prend par exemple:
    get-childitem -Recursive -Path dossier

    Première réaction, "c'est lourd par rapport à un ls -R". Maintenant, si WSH est bien fait, le get-childitem doit pouvoir s'appliquer à d'autres choses que des répertoires. A toute chose qui supporte la programmation objet, on peut imaginer que ça serve à traiter du XML, des informations de la registry Windows & Co.

    Par le biais de ces protocoles, on peut faire pas mal de choses dans Windows, je vous renvoi vers les exemples d'utilisation de WMI (Windows Management Instrumentation) avec Python, sur http://tgolden.sc.sabren.com/python/wmi_cookbook.html(...) où l'on dépasse la simple manipulation de fichiers.

    Ce que je ne comprends pas, c'est l'intérêt de redéfinir un nouveau langage de shell. Ils auraient pris un Python, ajouté iPython pour en faire un outil plus sympa au niveau shell interactif, et bien sûr l'extension win32 pour s'interfacer avec l'API windows et en particulier COM/DCOM... là ils ont fait un bâtard à leur sauce.

    Python: http://www.python.org/(...)
    iPython: http://ipython.scipy.org/(...)
    extension win32: http://starship.python.net/crew/mhammond/(...)
    Python WMI: http://tgolden.sc.sabren.com/python/wmi.html(...)
    WMI: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wm(...)

    Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

    • [^] # Re: Ne pas oublier l'intégration avec l'environnement

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

      Première réaction, "c'est lourd par rapport à un ls -R". Maintenant, si WSH est bien fait, le get-childitem doit pouvoir s'appliquer à d'autres choses que des répertoires. A toute chose qui supporte la programmation objet, on peut imaginer que ça serve à traiter du XML, des informations de la registry Windows & Co.
      On peut, certaines commandes créent de nouvelles arborescences virtuelles (genre Registry: à la place de C:).
      Le problème c'est que ces arborescences seront uniquement visibles des applications msh (à priori). Donc pas de passage par word ou par notepad ou que sais-je-encore.
      De ce point de vue FuseFS, qui devrait arriver incessamment sous peu dans le noyau, est bien plus propre. En plus, il permet d'utiliser les langages de son choix (dont Python) aussi bien pour coder les systèmes de fichiers utilisateurs que pour coder les applications qui l'utilisent. (et pourtant on en fait pas tout un plat)
      • [^] # Re: Ne pas oublier l'intégration avec l'environnement

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

        Pour moi Word et Notepad (surtout Notepad), c'est pour éditer du texte (et accessoirement faire de la mise en page). Si tu veux échanger des données avec ces applications, tu peux avoir un script qui se charge de faire des copier/coller pilotés.

        Pour le "tout fichier" (l'homogénéisation de l'accès aux informations - ça peut être du "tout objet" si l'on a l'infrastructure logicielle pour), sûr que sous Windows c'est pas vraiment prévu pour. Avez-vous vu passer un Hurd ou un Plan9 récemment ?

        Microsoft aurait aimerais sans-doute un tout composant, mais entre l'héritage de l'existant (très lourd pour MS, voir le taux de migration à WinXP vs ce qui reste encore en Win2K), l'aspect "on change tout et on recommence" qui peut lasser voir dégouter des développeurs (Apple a beaucoup joué à ça aussi), ils sont obligés de faire avec plusieurs technologies, et là un système de shell/glue est intéressant.

        Pour fuse (trouvé http://fuse.sourceforge.net/(...) ), je n'ai pas l'impression que ça puisse être utilisé sous Windows - là WSH vise un public particulier...

        Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

        • [^] # Re: Ne pas oublier l'intégration avec l'environnement

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

          Pour moi Word et Notepad (surtout Notepad), c'est pour éditer du texte (et accessoirement faire de la mise en page). Si tu veux échanger des données avec ces applications, tu peux avoir un script qui se charge de faire des copier/coller pilotés.
          Evidement; mais c'est laid (le script serait particulier à chaque logiciel), et ça ne s'applique pas à tout les cas (imagine que tu veuille une abstraction pour un protocole réseau de telle manière à pouvoir afficher une vidéo distante avec un player local).
          Tu me diras, y'a probablement moyen sous windows d'intégrer au poste de travail un système distant par un protocole arbitraire (vu que GmailDS le fait).
          Sauf que sous Linux ça peut se faire relativement facilement et de amnière sure, tout en étant parfaitement rétrocompatible.

          Avez-vous vu passer un Hurd ou un Plan9 récemment ?
          Le peu que j'ai vu passer de Plan9 était trop compliqué pour moi, mais V9FS pourrait t'interesser http://v9fs.sourceforge.net/(...) .
          Et je pense que Fuse peut aider à attendre le Hurd.

          Microsoft aurait aimerais sans-doute un tout composant, mais entre l'héritage de l'existant (très lourd pour MS, voir le taux de migration à WinXP vs ce qui reste encore en Win2K), l'aspect "on change tout et on recommence" qui peut lasser voir dégouter des développeurs (Apple a beaucoup joué à ça aussi), ils sont obligés de faire avec plusieurs technologies, et là un système de shell/glue est intéressant.
          Mouais... y'a de la marge entre "potable compte tenu de l'inertie de leur plateforme" et "interessant". Surtout qu'ils auraient parfaitement pu fournir des facilités pour créer des systèmes de fichiers utilisateurs en tant que sous dossier dans un lecteur spècifique (disons Z:), ça n'aurais pas cassé la rétro compatibilité.
          Enfin, je vais pas les accabler.
          Mais le minimum aurait été de séparer la glue (comme tu dit) du shell. Et d'en profiter pour faire un shell sympa.

          Pour fuse (trouvé http://fuse.sourceforge.net/(...)(...) ), je n'ai pas l'impression que ça puisse être utilisé sous Windows
          Non, Fuse est effectivement resérvé à Linux, mais rien n'empêcherais microsoft de tenter quelque chose du même genre.
          • [^] # Re: Ne pas oublier l'intégration avec l'environnement

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

            le script serait particulier à chaque logiciel

            Non, sauf erreur si l'application est scriptable les commandes de base sont toujours les mêmes. Après, si on veut demander à word d'aller faire une correction orthographique sur la deuxième phrase du troisième paragraphe de la page deux...

            get orthcor(sentence two of paragraph three of page 2 of this document)

            Non, là ça ressemblerait à de l'Applescript/Hypertalk. Microsoft préfère les $ et les accolades pour WSH.

            Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

          • [^] # Re: Ne pas oublier l'intégration avec l'environnement

            Posté par . Évalué à 1.

            Tu me diras, y'a probablement moyen sous windows d'intégrer au poste de travail un système distant par un protocole arbitraire (vu que GmailDS le fait).
            Sauf que sous Linux ça peut se faire relativement facilement et de amnière sure, tout en étant parfaitement rétrocompatible.


            http://www.viksoe.dk/code/gmail.htm(...)

            Mouais... y'a de la marge entre "potable compte tenu de l'inertie de leur plateforme" et "interessant". Surtout qu'ils auraient parfaitement pu fournir des facilités pour créer des systèmes de fichiers utilisateurs en tant que sous dossier dans un lecteur spècifique (disons Z:), ça n'aurais pas cassé la rétro compatibilité.

            Ca existe deja, t'es simplement pas au courant que ca existe
      • [^] # y'a encore du boulot !

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

        >> FuseFS, qui devrait arriver incessamment sous peu dans le noyau

        Hummm....va voir sur http://lwn.net/Articles/131856/(...) et trouvera cette peu réjouissante prévision :
        Until the core filesystem hackers are happy, however, FUSE is likely to have a rough path into the mainline.
  • # Ben...

    Posté par . Évalué à 6.

    Je te propose d'aller jeter un oeil a la video sur http://channel9.msdn.com/ShowPost.aspx?PostID=25915(...) pour avoir une meilleure idee de ce qu'il peut faire.

    Un exemple parfait me semble être le fait que toutes les démonstrations de ce shell (cf google) trient des processus, les mettent dans des fichiers, affichent des dates, manipulent des chaînes de caractères... mais qu'aucune ne crée d'utilisateurs, ne redimensionne d'images, ne fait de calculs ou n'envoie d'email.

    Tout simplement car le but ici est de montrer ce que le shell lui-meme permet. Creer un utilisateur, redimensionner une image, envoyer un e-mail,... cela ne fait pas forcement partie du shell lui-meme, c'est une commande qui sera utilisee dans le shell.

    Toujours dans cet esprit il manque à ce shell la gestion de la complétion par [tab], les options n'ont pas d'alias cours (comme -d pour --long)...

    Perdu, les 2 sont dedans. La completion est la, et les alias aussi(cf. la video)
    • [^] # Re: Ben...

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

      Tout simplement car le but ici est de montrer ce que le shell lui-meme permet. Creer un utilisateur, redimensionner une image, envoyer un e-mail,... cela ne fait pas forcement partie du shell lui-meme, c'est une commande qui sera utilisee dans le shell.
      Je pense bien, mais c'est dans l'optique de l'utilisation de ce genre d'outil qu'aurais du être conçu le shell.
      C'est un peu comme si tu faisait la démo d'un nouveau langage en calculant la 321 ème décimale de Pi et une application qui écrit en boucle "toto" dans un fichier texte.

      Perdu, les 2 sont dedans. La completion est la, et les alias aussi(cf. la video)
      Désolé.
      L'absence de complètion par [tab] C'est la manière dont j'avais compris le 13ième élément de la FAQ. Mais en lisant mieux, j'ai compris que la complétion qui n'existe pas encore et qu'ils regrettent de ne pas voir associé a [tab] est celle du "page précédente" "page suivante" et du "!".
      http://channel9.msdn.com/wiki/default.aspx/Channel9.MSHFaq(...)
      Pour ce qui est des alias, je pensais qu'il n'y étaient pas parce que l'imitation de man (get-help) ne les affiche pas sur la seule "capture d'écran" que j'ai vue http://www.egilh.com/blog/archive/2004/11/08/307.aspx(...) .
      Ça ne justifie pas mon erreur, mais j'étais de bonne foi.
      Enfin, y'a d'autres choses qui sont pas très utilisables (besoin de définir une fonction avant d'aliaser des commandes et leur arguments par exemple). C'est vrai que c'est pas structurel, mais révélateur.
    • [^] # Re: Ben...

      Posté par . Évalué à -1.

      vais faire mon chieur mais comme windows est pour l'interoperabilite tu nous donnes des videos dont les specs des codec sont libres?

      plus serieusement : il a dis alias d'options. pas alias tout court. Je sais pas si tu avais dis alias dans ce sens (option) , ou juste alias normal.
      • [^] # Re: Ben...

        Posté par . Évalué à -2.

        Pas besoin d'etre libre pour etre interoperable. Les specs de Windows Media sont dispo(contre remuneration), donc qui veut lire ces fichiers le peut, MS ne cache pas ces specs, et d'ailleurs des boites genre TurboLinux en ont deja fait usage.
        • [^] # Re: Ben...

          Posté par . Évalué à 9.

          (contre remuneration), donc qui veut lire ces fichiers le peut,
          Rectification celui qui veut lire les fichier, et qui a suffisament d'argent le peut.
          De meme que celui qui a suffisament d'argent peut acheter une licence microsoft et un pc spécialement pour regarder les wmv ; ou celui qui a suffisament d'argent peut acheter un airbus.
          MS ne cache pas ces specs,
          Ben en les faisant payer il les cache a ceux qui ne veulent/peuvent pas payer.

          Donc je maintiens ce n'est pas inter operable, car tout le monde doit pouvoir acceder aux specs sans discrimination si on veut que ce soit reelement inter operable : que tout le monde puisse les lire, et pas juste ceux qui peuvent payer (ps oui la discrimination par l'argent en est une).
    • [^] # Re: Ben...

      Posté par . Évalué à 1.

      Je peux pas voir la video ici, verrai ce soir à la maison, mais j'aimerais ta réponse face à la chose deja relevée + haut.
      C'est juste une reformulation de vbscript pour la ligne de commande ?
      ou il y a vraiment plus ? (autre que l'autocomplete décent je veux dire ;-) )
      • [^] # Re: Ben...

        Posté par . Évalué à 2.

        C'est bien mieux et plus puissant que vbscript, le shell permet de faire des trucs qui aurait ete sacrement compliques a faire precedemment en quelque lignes
  • # Irb

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

    Faut pas avoir peur les gens, on a deja des fonctionnalites largement equivalentes avec ruby et Irb (interactive ruby):


    exemples:

    Recuperer la premiere ligne de tous les fichiers courant:
    Dir.glob('*').collect {|f| File.open(f) {|io| io.readline}}


    On peut meme, moyennant quelque traffics, taper directement
    ses commandes shell avec irb:

    def method_missing(*args)
    `#{args.join(' ')}`.split("\n")
    end

    Et hop:

    ls
    => ["src", "bin"]

    ps
    => [" PID TTY TIME CMD", "5045 pts/4 00:00:00 zsh"]

    Bon evidemment ca ne demande qu'a etre ameliore... Ce que je veux montrer c'est qu'on a tout ce dont on dispose pour fabriquer un outil equivalent
    (un shell/langage plus evolue que le shell actuel).

    En plus, Ruby est multiplateforme et on peut aussi contacter les composants Microsoft des autres appli avec.

    http://l-lang.org/ - Conception du langage L

    • [^] # Re: Irb

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

      on a tout ce dont on dispose

      c'est bon a savoir :)
  • # ca sert a rien?

    Posté par . Évalué à 3.

    - aaah ouiiii!! attends, c'est quoi, c'est un shell de ouf! tu l'as fait quand?
    - ben, en 5 minutes, hier.
    - a y claque grave, il a un style qui claque a l'americaine, un truc de ouf.
    - ouais, mais bon, c'est... franchement, ca sert a rien, c'est pas pour nous c'truc la..
    - ah ouiii, la ptite one-liner, a la perl, chanme, ptite ligne vite fait, franchement bien, hein.
    En meme temps, j'sais pas.. j'vois pas trop c'qu'on pourrait faire avec, c'est pas pour nous c'truc la

    -Putain, c'te shell il est mortel, mais j'vois pas c'quon peut faire avec,
    t'facons, c'est pas un truc pour nous, moi la d'ssus, j'verrais plus Daniel Robbins.
    L'aut' jour, j'ai etudie son code d'facon analytique, ca m'echappe, il a des plans de script trop technique.
    qu'il ecrit avec trop d'aisance, ca fait 15 ans qu'j'suis dans l'libre comme lui, j'voudrais coder dans un style trop d'avance,
    mais bon, j'y arrive moyen, j'crois bien qu'ya pas moyen,
    et putain, tu peux l'garder ton shell pourri qui sert a rien.

    -il est pourri, il a bouffe d'la ketamine l'autre ou quoi encore?

    - et j'dirais meme qu'y gave, avec cette fausse ligne en .net ou on sait pas c'qu'elle bave
    ca s'trouve, c'est tout naze, voire pire, on s'rait pas d'accord, genre un drm de l'autre bord.
    Bon qu'est ce qu'on fait, on le retravaille, ca peut peter en GPL?

    - tu veux poser sur c'te shell, la disquette j'l'ai perdue,
    demande aux lardu, aux objet trouvé, l'on ptetre entendu.
    Ok, ca sort d'l'ordinaire, moi, c't'ordi m'fout les nerfs,
    j'ai en plein le disque dur, mais ca m'donne pas le fsf d'or.
    d't'facons, j'me rappelle, J'ai ete au plus vite pour faire ce shell, avec linux c'est c'quon evite, le code redmondien a la ballmer.
    T'en faire un sans liberte et sans test.
    Releaser ce shell, ca serait comme deposer le silence a la sacem.

    ...

    -ca sert a rien?
    comment ca, ca sert a rien?
    dire ca d'un shell comme ca, mais putain, vous etes bien?
    j'sais pas, vous, on dirait que vous calculez pas, mais ca au moins, bah ca sonne un peu cker-ha pour une fois..
    Pourquoi se prendre la tete a cherche un gimmick bizarre?
    moi, ya pas, j'veux poser sur ce shell d'batard!!
    Pour qu'les gars qui m'trouvent dans les bacs,
    confondent pas longhorn avec un mac,
    pour qu'j'ai plus ce genre d'critiques dans les pattes.
    J'te parle meme pas de garder un ton hardcore,
    mais quoi, changer c'truc la contre un truc graphique, encore?!?
    nan, d't'facons, virez ce shell, ya pas moyen.
    pis j'parle plus avec vous les pingouins, ca sert a rien.

    les amateurs de svinkels auront compris je pense ;-)
    les autres, bah vous saurez quoi acheter comme cd la prochaine fois :p
    • [^] # Re: ca sert a rien?

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

      Ptain, t'as pris quoi toi?

      Bel hommage à Svinkels :)

      Bon, manque un bout du morceau mais sinon c'est pas mal ;)

      Et effectivement, Svinkels c'est bien meme si mes morceaux préférés sont pas sur le dernier album.
      • [^] # Re: ca sert a rien?

        Posté par . Évalué à 0.

        Ptain, t'as pris quoi toi?
        une journee de taff dans un bureau ou il fait chaud :)
        ca coute pas cher et c'est efficace.

        sinon, comme toi, je prefere les premiers albums
    • [^] # Re: ca sert a rien?

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

      Toi qui est derriere ton ecran, c'est pas parce que tu comprends pas le poste ci dessus et que ta culture musicale s'arrete à Tryo et Kyo qu'il faut "moinsser" sauvagement le monsieur...
      • [^] # Re: ca sert a rien?

        Posté par . Évalué à 1.

        Bah viendez à soliday toi qui venait voir Jenifer tu pourras faire un detour, ya Svikels dans la place ...

        Moi je connais que 2 morceaux ... fo que je pense à écouter ...
  • # Pourquoi ?

    Posté par . Évalué à 5.

    Je trouve ça ridicule cette façon de descendre en fleche toutes les idées de Microsoft.

    On détruit sans tester. Mais apres, on va aller pleurer que les logiciels MS, qui sont pas QUE nuls combinés à la machine marketing se vendent comme des petits pains.

    Microsoft a du pognon, et un mec de la R&D chez MS est pas forcément plus con qu'un mec qui fait du libre.

    Je fais confiance à MS pour pondre un très bon Longhorn, et faire très mal au libre, ce que je ne souhaite pas forcément.
    • [^] # Re: Pourquoi ?

      Posté par . Évalué à 0.

      flinguer c'est à la mode ...

      de toute facon ca serra toujours mieux que CMD.exe + wscript +vbs ...
      Bon en tant qu'admin microsoft (non ce n'est pas un choix ...) jui content c'est deja ca de pris.

      Bon je me suis mis à fond windows car je ne trouvais pas (ou trop peu) de travail sous linux ... et j'ai trouvé des trucs très interressant chez microsoft ... par exemple WMI est vraiment très bien (ceux qui connaissent pas , critiquer pas ca sert à rien ...)

      Seul ceux qui savent comprendrons ...

      Et pour longcorne je pense aussi que ce sera une bonne mouture ... allez l'open source faite rentrer des os alternatifs dans l'entreprise ... eux mais pas dans des boites noires siouplé ... (checkpoint, netapp ou nokia VPN)
    • [^] # Re: Pourquoi ?

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

      Microsoft a du pognon, et un mec de la R&D chez MS est pas forcément plus con qu'un mec qui fait du libre.
      Les geeks ont un cerveau et un geek qui critique une technologie n'est pas pas nécessairement plus idiot que le type qui la propose, même payé cher.
      Ce que je dit de manière cynique, je l'ai déduit de ce que j'ai lu, et je l'ai étayé par des exemples.

      Du reste, parler de Longhorn maintenant est hors sujet.
      • [^] # Re: Pourquoi ?

        Posté par . Évalué à 2.

        oui, enfin les geeks ont aussi des emotions, et quand ils parlent de technologie, ils ne sont pas forcement capables de les controler, ces emotions..

        'fin, bon, c'que j'en dis, hein, moi j'suis plutot content d'avoir enfin un shell pour windows, meme si c'est pour dans un futur lointain..
        • [^] # Re: Pourquoi ?

          Posté par . Évalué à 3.

          C'est vrai que les affaires ne laissent pas de place aux sentiments...
  • # Encore du code de porc

    Posté par . Évalué à -1.

    Vous savez pourquoi Unix et Linux sont solides comme du béton...

    Parce qu'on met des noms de variables pertinents, des noms de commandes significatives.

    cd est une abbréviation de change directory
    cp pour copy
    mv pour move
    rm pour remove
    ...

    get-childitem ? ça veut dire quoi? Le mec était-il dans un délire quand il a décidé de pondre cette idée.

    Vous pouvez m'incendier mais quand on pense vraiment, on n'a pas de doute. Suffit de voir ce qu'ils ont fait avec CMD.exe, JScript. Je trouve anormal qu'un term éxécute un virus.

    Laissons à Microsoft le soin de rendre encore plus lourd, plus fonctionnel pour les ceux qui se jettent dessus et se pètent les bretelles et n'y voient que du feu derrière. La fonction première de bash est d'avoir accès au shell qui manipule directement le système de fichiers...

    plus tard on va voir MS sortir un MSH version truc, qui permettra de taper du texte dans word, envoyer un e-mail, formater son pc par un virus,

Suivre le flux des commentaires

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