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 gnumdk (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 barmic . É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 JJD . É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 Olorim . É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 Littleboy . Évalué à 1.
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.
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 Olorim . É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...
[^] # Re: Euh?
Posté par claudex . Évalué à 2.
PowerShell est par défaut dans Windows 7. http://en.wikipedia.org/wiki/Windows_PowerShell#PowerShell_2.0
« 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
# Services For Unix
Posté par gouttegd (site web personnel) . É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 Gniarf . Évalué à 2.
il marche très bien, est plus rapide que Cygwin, et d'ailleurs un rm -rf ne sortira plus
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 Hobgoblins Master (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 Tristramg . É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 fearan . É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 claudex . Évalué à -2.
« 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 claudex . Évalué à 4.
Je voulais plutôt dire:
« 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 B16F4RV4RD1N . É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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Tant qu'à faire, autant utiliser un vrai shell d'homme, le Z shell…
[^] # Re: Zsh
Posté par flagos . Évalué à 10.
C'est quoi ce shell discriminatoire ?!?
[^] # Re: Zsh
Posté par Shuba . Évalué à 1.
C'est vrai, zsh c'est le bien, mais perso j'ai jamais réussi à le faire marcher sous cygwin...
[^] # Re: Zsh
Posté par Damien Thébault . Évalué à -3.
Moi j'ai déjà réussi je crois.
# Performances
Posté par Littleboy . Évalué à 2.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
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 :
[^] # Re: Performances
Posté par Littleboy . Évalué à 3.
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 moules . Évalué à 5.
C'est un logiciel libre, dans la licence il y a écrit explicitement les mots suivants :
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 Littleboy . Évalué à 3.
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 Littleboy . É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 Maclag . É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 Romeo . Évalué à 5.
Lennart Poettering ?
# pas coLinux
Posté par Gniarf . É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 suJeSelS . É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 vpinon . É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 houra . É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 nomorsad . É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 boq . Évalué à 10.
Je vous copypasta cette petite histoire, également disponible sur la toile, mais ce sera plus lisible comme ça:
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.