Journal la puissance du bash sous windows ?

Posté par  . Licence CC By‑SA.
Étiquettes :
-4
10
mai
2011

Bonjour ,

Travaillant parfois en environnement hostile par contrainte (Windows Vista ) , et pestant contre l'architecture logiciel de ce système non Unix (et donc non souple ) , je me mis à la recherche d'un shell sous windows porté de notre environnement libre préféré , alors bien entendu la première idée qui m'est venu à l'esprit est cygwin, mais le fait qu'il manque un kernel semble limité la puissance du shell (dont la vitesse d'exécution s'en fait ressentir assez lourdement ) . J'ai vue le projet colinux (faire tourné un kernel linux sous windows ) qui m'a l'air sympathique , mais un peu complexe et j'aurais aimé avoir des retours d'expérience sur colinux en environnement de production . Mes seuls besoin se limite à du shell , pas besoin de X , Kde , gnome etc ...(j'ai lu la faq qui de toute façon parlait d'instabilité des couches supérieurs dont le serveur graphique et son )

Sinon sauriez vous s'il existe d'autre projet que j'aurais loupé et qui permettent d'avoir un vrai shell GNU/Linux sous windows ?

  • # Euh?

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

    Tant qu'a etre sous Windows, autant utiliser powershell...

    Je dis ca, je m'y suis toujours pas mis, j'essaye de faire un maximum sous Linux: les outils openldap pour modifier l'AD, des montages vers le serveur Krosoft pour les modifs acls, ...

    Mais après, ca reste très limité, je te rappel quand meme que bash sous Windows, ca veut dire bash avec les commandes externes windows, tu vas vite te faire chier...

    Regarde la liste des commandes internes, y'en a pas des tonnes:
    http://tldp.org/LDP/abs/html/x9529.html

    La puissance du shell unix, c'est surtout la foultitude de commande existantes...

    Powershell lui passe par l'infrastructure windows pour fonctionner... Et oui, Windows n'est pas Unix, ce sont deux philosophies bien différentes.

    • [^] # Re: Euh?

      Posté par  . Évalué à 5.

      Sinon peut être que iPython peut faire l'affaire ? (faut savoir utiliser python à la place de bash)

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

    • [^] # Re: Euh?

      Posté par  . Évalué à 1.

      Ça me fait peut-être un peu mal de le dire, mais j'approuve !

      Pour être réellement efficace, autant utiliser les outils conçus et adaptés pour l'utilisation cible, surtout que cette fois-ci Microsoft nous a pondu un produit qui me semble plutôt bien fait et puissant (je ne l'ai, il est vrai, que très peu utilisé).
      PowerShell permet d'accéder à tout l'API .Net et donc à l'ensemble de la configuration du système. Il demande bien sûr une période d'apprentissage, mais je pense que les administrateurs Windows ont maintenant (enfin) un vrai outil efficace à leur disposition (il ne reste plus qu'à les convaincre que "programmer" [écrire des scripts] n'est pas sale et réservé à des admins barbus du millénaire dernier. Et c'est certainement la tâche la plus compliquée, tant ça n'entre pas dans leur mode de fonctionner).

      Évidemment, si ton objectif n'est pas de faire de l'administration, tu dois pouvoir te contenter d'un bash mais, comme l'a fait remarquer Gnumdk, il n'est pas certain que le bash seul te suffise. Dans ce cas, installe cygwin en choisissant les paquets dont tu as besoin (grep, awk, sed, sort, ...) : l'interface d'installation te permettra de faire ça facilement.

      A+
      JJD

    • [^] # Re: Euh?

      Posté par  . Évalué à 2.

      Moui, powershell, c'est pas trop mal. J'ai eu des scripts à faire avec et j'ai pas trouvé ça trop déplaisant. Sur ce, c'est quand même pas aussi agréable que Bash ou ksh. Tu retrouveras pas mal de chose de ces shells dans PS. Après, faut aimer le vbs pour vraiment en profiter.

      Pour ce qui est du Batch, il ne faut pas que regarder les commandes internes, il y'a une multitude de commande externes au batch (les commandes net notamment...). Le répertoire winntsystem32 contien des centaines d'EXE pouvant être utilisés comme commandes dans des scripts (manipulation de partition, de systèmes de fichiers, gestion des services WIN...). Bien sur, cela reste souple comme du béton, mais en bricolant, y'a moyen de faire des choses.

      • [^] # Re: Euh?

        Posté par  . Évalué à 1.

        Après, faut aimer le vbs pour vraiment en profiter.

        Par VBS, tu veux dire VBscript? PS a son propre langage de script, et tu peux ecrire des commandes (Cmdlets) en n'importe quel langage .Net, mais c'est pas du VBS.

        manipulation de partition, de systèmes de fichiers, gestion des services WIN

        Sachant que dans la majorite des cas, c'est soit expose par l'API powershell, soit dispo dans le framework .Net (et donc utilisable directement depuis un script), faut vraiment avoir envie de se compliquer la vie pour vouloir appeler directement un utilitaire en ligne de commande et s'amuser a parser la sortie. C'est certainement necessaire dans certains cas, mais pas pour tous les exemples que tu cites.

        • [^] # Re: Euh?

          Posté par  . Évalué à 1.

          Bah, VBScript, VB, VBS, pour moi, c'est du pareil au même : j'aime pas (ATTENTION, J'AI PAS DIT QUE C’ÉTAIT NULLE). C'est une question de gout.

          Pour la suite, je suis d'accord, sauf que ces utilitaires en question sont inclus dans Windows, ce qui n'est pas le cas de PS. Ensuite, c'est pas plus compliqué qu'en VBScript et c'est le même type d'intégration que ls ou ps sous linux... Bon, ok, c'est beaucoup plus mal foutu, mais ça marche quand même!

          Je t'invite à te renseigner sur la commande sc, qui va bien plus loin que l'interface de gestion des services Windows, ou encore diskpart... Ces commandes sont plus puissantes et ne nécessitent pas de travailler en VBS. Ces commandes supportent le pipe et la redirection.

          Maintenant, pour faire un script rapide d’arrêt relance de service, je ferais ça en batch...

  • # Services For Unix

    Posté par  . Évalué à 7.

    De Microsoft, il y a Services For Unix (SFU), qui a l’air de fournir un environnement compatible POSIX assez complet (sans bash, mais avec ksh, csh et « plus de 350 commandes et utilitaires Unix usuels », dixit Microsoft).

    Disclaimer : je ne l’ai jamais utilisé, je ne sais pas ce que ça vaut.

    • [^] # Re: Services For Unix

      Posté par  . Évalué à 2.

      il marche très bien, est plus rapide que Cygwin, et d'ailleurs un rm -rf ne sortira plus

      'rm' n'est pas reconnu en tant que commande interne ou externe, un programme exécutable ou un fichier de commandes.

      maintenant il faut se demander quel est la pérennité de ce truc, il semble s'être fossilisé en 2004/Windows Server 2003, ce qui fait 7 ans déjà

      • [^] # Re: Services For Unix

        Posté par  (Mastodon) . Évalué à 7.

        Il a été renommé en SUA pour Vista, 7 et W2K8 et est intégré comme composant donc plus téléchargeable en standalone. Il propose d’étendre le schéma AD pour renseigner des trucs tous cons comme le shell par défaut, le répertoire Home et les uid, gid… Informations qui peuvent être récupérées par samba et winbind (indispensable en environnement hétérogène…).
        Il y a un vrai cron (ce qui n’est pas un mal…)
        Il semble même y avoir une communauté qui intègre des packages : http://www.suacommunity.com/tool_warehouse.aspx

        Je pense que c’est la première option à regarder pour faire tourner du shell « Unix » sous Windows.

  • # MSYS ?

    Posté par  . Évalué à 2.

    Bon, c'est plus une question de forum que de journal, mais bon.

    MSYS fournit un terminal et un shell sans toute la pile CYGWIN, donc ça doit te correspondre.

    http://www.mingw.org/wiki/msys

  • # de haut de ma montagne

    Posté par  . Évalué à 5.

    De mon expérience, c'est cygwin qui reste la meilleur option. J'ai cependant quelques points noirs, mais qui sont je le crains du pour certain au système de base (au moins sous XP) :
    - le cache fichier (deux grep -R à la suite sur un bon volume de donnée pour se rendre compte que celui sous *nux est plus performant dans ce cas précis.
    - les chemins; si la majorité des softs sont capable de comprendre c:/plop/ningo.xml, la quasi totalité fournira un c:plopningo.xml foutant la merde dans les copier coller (cygpath -m '' est ton ami)
    - les chemins traditionnels avec des espaces ou maintenant parenthèse; le $HOME ou ~ peut poser pas mal de problème à cause de ces *$£{@¤ d'espaces
    - les installes de cygwin pas toujours identique : pour certain / = c: pour d'autre / = c:/cygwin-b20/... parfois les disques sont accessible dans /cygdrive/d d'autre fois ce sera /d/
    - la gestion des fin de ligne ( parfois rn d'autre juste n ) les scripts bash se plantent si la terminaison est pas la bonne.
    - globalement tout ce qui est intégration (par exemple faire fonctionner le emacs win32 avec une installe de cygwin demande pas mal de custo)
    - les disque réseau se comportent différemment selon les utilitaires : ls -R va passer alors qu'un /bin/find va planter (j'ai toujours pas compris pourquoi d'ailleurs)

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

    • [^] # Re: de haut de ma montagne

      Posté par  . Évalué à -2.

      • pas de 64 bits, ce qui est gênant pour intéragir un problème compiler en 64 bits.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: de haut de ma montagne

        Posté par  . Évalué à 4.

        Je voulais plutôt dire:

        • pas de 64 bits, ce qui est gênant pour utiliser des bibliothèques compilés en 64 bits.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: de haut de ma montagne

      Posté par  . Évalué à 3.

      je n'utilise pas beaucoup windows, et pas beaucoup cygwin, mais pour l'avoir testé sous xp et seven, je n'ai pas trouvé les différences de comportement que tu cites.

      Cygwin, c'est vraiment la meilleure option possible quand on est sous windows.

      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

  • # Zsh

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

    Tant qu'à faire, autant utiliser un vrai shell d'homme, le Z shell…

    • [^] # Re: Zsh

      Posté par  . Évalué à 10.

      C'est quoi ce shell discriminatoire ?!?

    • [^] # Re: Zsh

      Posté par  . Évalué à 1.

      C'est vrai, zsh c'est le bien, mais perso j'ai jamais réussi à le faire marcher sous cygwin...

  • # Performances

    Posté par  . Évalué à 2.

    mais le fait qu'il manque un kernel semble limité la puissance du shell (dont la vitesse d'exécution s'en fait ressentir assez lourdement )

    Ca n'a rien a voir avec le noyau et beaucoup plus avec les choix technologiques effectues (il y a des trucs plus lents sous Windows, d'autres plus rapides). Si tu essayes d'exploiter a fond certaines particularites d'Unix et que tu gardes exactement le meme code en ajoutant juste une couche d'abstraction, tu te retrouves avec un truc extremement lent sous Windows.

    C'est d'autant plus vrai avec Cygwin et MSYS que le code est prevu pour tourner sur plein de versions de Windows (tres bien en soit), mais ne prend souvent pas en compte les nouvelles API et fait des trucs completement cons (au lieu d'utiliser les soft/hard-links quand c'est necessaire, il y a encore du code qui fait un copie des fichiers, meme sur les versions de Windows qui ont l'API qui va bien).

    Un exemple pathologique, c'est le portage de git pour Windows. A la base c'est optimise pour Linux, les choix technos sont parfois tres mauvais pour Windows (nombreux petits fichiers, NTFS est pas forcement tres bon la dessus) et c'est pas prevu pour etre portable et ca se voit. Par dessus, tu rajoutes la couche d'abstraction Windows de qualite tres inegale, les programmeurs qui font le portage qui considerent que les utilisateurs et programmeurs Windows sont majoritairement des gros cons, une meconnaissance du systeme et des attentes minimales des utilisateurs (certains devs n'ont meme pas de systeme Windows pour tester) et tu arrives a transformer du code C optimise en truc qui tourne plus lentement que du Python dans une VM. Le plus rigolo, c'est qu'ils se plaignent qu'aucun des ces cretins de programmeurs Windows ne veulent les aider (on se demande pourquoi).

    • [^] # Re: Performances

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

      Un exemple pathologique, c'est le portage de git pour Windows.

      C'est amusant, parce que c'est très proche du comportement que j'adopte moi-même quand je code de petits trucs, et que j'adopterais également si je codais de gros trucs. À savoir :

      • je code sous Unix, je ne connais pas Windows et je m'en moque éperdument ;
      • je ne fais pas volontairement du code non portable, au contraire j'essaie de coder de façon raisonnablement portable bien que je ne m'y connaisse pas assez pour garantir quoi que ce soit question portabilité ;
      • si quelqu'un veut porter mon logiciel, tant mieux, sinon tant pis, encore une fois je m'en moque.
      • [^] # Re: Performances

        Posté par  . Évalué à 3.

        si quelqu'un veut porter mon logiciel, tant mieux, sinon tant pis, encore une fois je m'en moque

        Je parle des mecs qui font le portage la, que Linus et les mainteneurs de git s'en contrefichent de Windows, tant mieux pour eux, il n'y a rien a leur reprocher.

        A moins que:
        1. tu consideres que tes utilisateurs sont des cretins
        2. que pour tous les bugs que tu ne peux pas reproduire (ou que tu n'as pas envie de corriger) ta reponse soit systematiquement un lapidaire "telecharges les sources et fait un patch"
        3. que tu prennes pour des insultes un rapport de bug qui dit qu'un bug est majeur et que par consequent, il devrait etre corrige en priorite (genre une perte de perfs de 500% qui affecte 30 a 40% de tes utilisateurs).
        4. que tu te plaignes tout le temps que personne ne veut t'aider a faire le portage ou te financer (surement a cause tu point 1)

        Non, tu n'adoptes probablement pas le meme comportement.

        • [^] # Re: Performances

          Posté par  . Évalué à 5.

          C'est un logiciel libre, dans la licence il y a écrit explicitement les mots suivants :

          This software is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY;

          Donc tu fais pas chier et tu utilises du proprio, ou tu paies une boite de service, ou tu codes toi-même dessus, si t'es pas content. Les auteurs de git ne doivent rien à personne.

          • [^] # Re: Performances

            Posté par  . Évalué à 3.

            Donc tu fais pas chier et tu utilises du proprio, ou tu paies une boite de service, ou tu codes toi-même dessus, si t'es pas content. Les auteurs de git ne doivent rien à personne.

            En effet, ils ne doivent rien a personne. Et je me reserve le droit de commenter leurs actions quand meme. Si t'es pas content, t'as qu'a faire un patch.

            • [^] # Re: Performances

              Posté par  . Évalué à 3.

              Et pour preciser quand meme: lorsque tu distribues un logiciel et sollicite activement des retours et contributions de tes utilisateurs, les renvoyer chier systematiquement, ca passe quand meme tres mal (et c'est en contradiction totale avec le desir d'avoir des rapport de bug et de l'aide pour les patchs).

              Que les utilisateurs dont la seule contribution est "votre logiciel c'est de la merde! Je veux une correction pour demain bande de branleurs" soit ignores, c'est une chose [1], mais quand tu as des gens qui prennent le temps de faire un rapport complet, isolent la cause du probleme, trouvent un workaround et te donnent les etapes pour reproduire ou tester le probleme, choisir de les envoyer chier parce qu'ils n'ont pas aussi fait un patch, ca va forcement avoir un impact sur le projet. Se plaindre ensuite que les programmeurs Windows sont des nuls en general et que personne avec de l'experience sur cet OS ne veut contribuer a ton projet est legerement contradictoire.

              Tu peux pas avoir tout a la fois, soit tu fait ton projet dans ton coin et n'offre aucun support (garanti ou pas), soit tu veux des contributeurs et des retours utilisateurs et il faut accepter de corriger des bugs qui ne t'impactent pas directement et que la qualite des retours soit inegale, tout le monde ne pouvant pas faire un patch (si le rapport est complet avec de quoi reproduire, c'est deja bien).

              [1] La facon de le faire se discute aussi, etre systematiquement grossier semble etre le modus operandi de certains projets, mais sur le long terme ca impacte forcement aussi les contributeurs potentiels qui n'ont pas forcement envie de bosser avec toi si tu te comportes en malotru. Etre pro dans ses reponses meme a des emmerdeurs, ca a aussi plein d'avantages en terme d'image.

            • [^] # Re: Performances

              Posté par  . Évalué à 1.

              Quand aura-t-on enfin une licence GPL-EJTMSTPC?

              La licence GPL avec l'extra Et Je T'eMmerde Si T'es Pas Content

              Paragraphe annexe:
              En utilisant ce logiciel, l'utilisateur accepte et comprend que l'auteur de ce logiciel n'a aucun devoir particulier envers lui de corriger les bugs, ajouter des fonctionnalités, ou passer du temps à écouter ses suggestions, et que l'auteur n'a jamais exprimé le désir d'avoir le moindre retour utilisateur.
              Par conséquent l'utilisateur s'engage à classer du mieux possible tous ses retours vers l'auteur en deux catégories:
              - les retours positifs par mail
              - les retours négatifs, requêtes, suggestions par /dev/null

      • [^] # Re: Performances

        Posté par  . Évalué à 5.

        Lennart Poettering ?

  • # pas coLinux

    Posté par  . Évalué à 5.

    coLinux n'a pas grand chose à voir avec ta problématique, c'est (quasi) de la virtualisation comme VMWare ou VirtualBox

    donc en gros un shell qui tournerait dedans ne verrait pas tes disques Windows mais son disque (virtuel) à lui. donc pas tes fichiers.

  • # Français

    Posté par  . Évalué à 6.

    Des efforts sur le français serait un plus, ce journal pique un peu les yeux.

  • # Forum général.cherche-logiciel

    Posté par  . Évalué à 3.

    unxutils.sf.net (y'a zsh dedans, +les commandes standards)
    ou gnuwin32.sf.net (packagings autour)

    • [^] # Re: Forum général.cherche-logiciel

      Posté par  . Évalué à 3.

      http://mx.gw.com/pipermail/tcsh/2006-January/003521.html

      J'avais utilisé tcsh sous Windows 2000 de façon bluffante pour Windows ( comprendre assez proche du minimum qu'on pouvait en obtenir sous FreeBSD ).

      Apparemment il va ressortir pour Windows Sept. ( Et non pas Windows Cévennes ).

      Sinon, Il existe aussi WinZsh. http://zsh-nt.sourceforge.net/index.html

      Puis comme dit plus haut, PowerShell , mais qui oblige à apprendre un autre langage de script ( plus proche des habitudes de nommage des fonctions & procédures des langages soutenus par Microsoft ).

      Sedullus dux et princeps Lemovicum occiditur

  • # la faiblesse du bash sur windows?

    Posté par  . Évalué à 3.

    oui c'est la limite du troll, mais moi je penche sérieusement pour Perl voire peut-etre python pour les scripts d'exploit sur windows ET Unix.

    Il manque encore quelques librairies propres pour s'approcher de la simplicité du shell, mais j'apprécie la simplicité et la précision de ces langages.

  • # Ça me fait penser ...

    Posté par  . Évalué à 10.

    Je vous copypasta cette petite histoire, également disponible sur la toile, mais ce sera plus lisible comme ça:

    I've been attending the USENIX NT and LISA NT (Large Installation Systems
    Administration for NT) conference in downtown Seattle this week.

    One of those magical Microsoft moments(tm) happened yesterday and I
    thought that I'd share. Non-geeks may not find this funny at all, but
    those in geekdom (particularly UNIX geekdom) will appreciate it.

    Greg Sullivan, a Microsoft product manager (henceforth MPM), was holding
    forth on a forthcoming product that will provide Unix style scripting and
    shell services on NT for compatibility and to leverage UNIX expertise that
    moves to the NT platform. The product suite includes the MKS (Mortise
    Kern Systems) windowing Korn shell, a windowing PERL, and lots of goodies
    like awk, sed and grep. It actually fills a nice niche for which other
    products (like the MKS suite) have either been too highly priced or not
    well enough integrated.

    An older man, probably mid-50s, stands up in the back of the room and
    asserts that Microsoft could have done better with their choice of Korn
    shell. He asks if they had considered others that are more compatible
    with existing UNIX versions of KSH.

    The MPM said that the MKS shell was pretty compatible and should be able
    to run all UNIX scripts.

    The questioner again asserted that the MKS shell was not very compatible
    and didn't do a lot of things right that are defined in the KSH language
    spec.

    The MPM asserted again that the shell was pretty compatible and should
    work quite well.

    This assertion and counter assertion went back and forth for a bit, when
    another fellow member of the audience announced to the MPM that the
    questioner was, in fact David Korn of AT&T (now Lucent) Bell Labs. (David
    Korn is the author of the Korn shell)

    Uproarious laughter burst forth from the audience, and it was one of the
    only times that I have seen a (by then pink cheeked) MPM lost for words
    or momentarily lacking the usual unflappable confidence. So, what's a body
    to do when Microsoft reality collides with everyone elses?

Suivre le flux des commentaires

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