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.
Journal PowerShell: tapez rm -rf c:\Windows ! ;)
15
nov.
2006
# GNU is Not Unix
Posté par feth . Évalué à 9.
Henry Spencer, November 1987
[^] # Re: GNU is Not Unix
Posté par Fabien Engels . Évalué à 5.
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 Yth (Mastodon) . Évalué à 10.
Yth.
# Amis journalistes
Posté par plagiats . Évalué à 5.
[^] # Re: Amis journalistes
Posté par Guinns . Évalué à 5.
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 Hrundi V. Bakshi . Évalué à 8.
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 ploum (site web personnel, Mastodon) . Évalué à 6.
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.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Amis journalistes
Posté par TImaniac (site web personnel) . Évalué à 8.
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 briaeros007 . Évalué à 7.
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 Sytoka Modon (site web personnel) . Évalué à 2.
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 golum . Évalué à 3.
Désolé Ruby ca sera pour une autre fois o:)
[^] # Re: Amis journalistes
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Amis journalistes
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
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 lolop (site web personnel) . Évalué à 1.
C'est fait exprès, c'est expliqué là pourquoi (en anglais):
http://effbot.org/pyfaq/why-must-self-be-used-explicitly-in-(...)
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Amis journalistes
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
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 Pinaraf . Évalué à 2.
[^] # Re: Amis journalistes
Posté par Matthieu . Évalué à 2.
Microsoft a une solution autre que vbscript ou part-il dans le tout-framework ?
[^] # Re: Amis journalistes
Posté par Guinns . Évalué à 3.
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 golum . Évalué à 1.
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 Guinns . Évalué à 5.
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 Sytoka Modon (site web personnel) . Évalué à 4.
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 TImaniac (site web personnel) . Évalué à 5.
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 Sytoka Modon (site web personnel) . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 4.
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 kowalsky . Évalué à 10.
refaire tout ce qu'on fait deja, mais en different...!
# ya du progrès
Posté par Christophe Merlet (site web personnel) . Évalué à 10.
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 Fabien Engels . Évalué à 1.
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 Guillaume Denry (site web personnel) . Évalué à 5.
Openssh server existe sous windows et fonctionne bien.
[^] # Re: ya du progrès
Posté par lolop (site web personnel) . Évalué à 2.
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.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: ya du progrès
Posté par TImaniac (site web personnel) . Évalué à 3.
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 pasBill pasGates . Évalué à 2.
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 Christophe Merlet (site web personnel) . Évalué à 6.
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 pasBill pasGates . Évalué à 3.
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 Sytoka Modon (site web personnel) . Évalué à 4.
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 Guillaume Knispel . Évalué à 7.
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 Johann Ollivier-Lapeyre (site web personnel) . Évalué à 7.
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 free2.org . Évalué à 1.
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 golum . Évalué à 3.
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
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 free2.org . Évalué à 1.
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 hophophop . Évalué à 2.
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 free2.org . Évalué à 4.
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 hophophop . Évalué à 2.
- 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 free2.org . Évalué à 1.
D'ailleurs y'a vraiment de l'espoir que tous les shells et scripts puissent accéder facilement à la plateforme Java:
http://jakarta.apache.org/bsf/
http://groovy.codehaus.org/
[^] # Re: comme dcop/dbus ? bsh , js shell, ipython
Posté par free2.org . Évalué à 1.
http://eclipse-shell.sourceforge.net/index.html
EclipseShell allows you to use
* JRuby
* Beanshell
* JavaScript (Rhino) to script your Java classes.
Eclipse shell allows you to do this by
* providing an interactive Editor with AutoComplete and other amenities, so you don’t have to mess with ugly readline interpreters.
* automatically setting up the CLASSPATH to your classes and the libs, taken from your Workspace Project settings.
* making it easy to store and reuse the history of your interactive sessions
[^] # Re: comme dcop/dbus ? bsh , js shell, ipython
Posté par TImaniac (site web personnel) . Évalué à 4.
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 andeus . Évalué à 5.
[^] # Re: comme dcop/dbus ? bsh , js shell, ipython
Posté par el_mickey . Évalué à 2.
# Je me marre ...
Posté par Thomas Douillard . Évalué à 9.
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 dinomasque . Évalué à 3.
BeOS le faisait il y a 20 ans !
[^] # Re: Je me marre ...
Posté par Yth (Mastodon) . Évalué à 5.
Yth, perplexifié...
[^] # Re: Je me marre ...
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à -6.
Jean-Philippe, pas du tout ironique
[^] # Re: Je me marre ...
Posté par TImaniac (site web personnel) . Évalué à 8.
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 B16F4RV4RD1N . Évalué à -2.
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 gnumdk (site web personnel) . Évalué à 3.
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 hophophop . Évalué à 3.
[^] # Re: Je me marre ...
Posté par gnumdk (site web personnel) . Évalué à 3.
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 TImaniac (site web personnel) . Évalué à 2.
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 gnumdk (site web personnel) . Évalué à 2.
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 golum . Évalué à 2.
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 briaeros007 . Évalué à 2.
L'est tout poilu ton troll la.
[^] # Re: Je me marre ...
Posté par lambada . Évalué à 3.
¹ : http://research.sun.com/self/language.html
² : http://iolanguage.com/
[^] # Re: Je me marre ...
Posté par Mildred (site web personnel) . Évalué à 2.
Par contre, je n'arrive pas a m'abonner à la mailing list :(
[^] # Re: Je me marre ...
Posté par golum . Évalué à 2.
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 Sytoka Modon (site web personnel) . Évalué à 5.
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 pasBill pasGates . Évalué à 3.
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 ǝɹɹǝıd oɯɐɹʇ . Évalué à 3.
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 dguihal . Évalué à 3.
Bref j'aimerais bien que FF ou konqueror soient scriptables de la même manière. (Si quelqu'un a une solution il aura toute ma reconnaissance)
[^] # Re: Je me marre ... greasemonkey dcop
Posté par free2.org . Évalué à 1.
[^] # Re: Je me marre ... greasemonkey dcop
Posté par free2.org . Évalué à 1.
http://userscripts.org/
[^] # Re: Je me marre ... greasemonkey dcop
Posté par dguihal . Évalué à 2.
Pour moi piloter c'est faire des choses du type :
Lancer le navigateur (facile)
Aller a l'URL xxxx
remplir le champ login avec la valeur _______
remplir le champ passwd avec la valeur _______
activer le bouton "valider"
greasemonkey ne me permet pas de faire ca
pour bonobo je ne connais pas de navigateur "bonoboisé"
Pas trouvé comment faire avec DCOP (genre manipuler le DOM) de la page
et pour DBUS j'ai un (faible) espoir mais j'ai de gros doutes
Avec IE et OLE c'est facile de faire ceci a partir d'un script vbs (ou js) qu'on lance avec cscript.exe
[^] # Re: Je me marre ... greasemonkey dcop
Posté par andeus . Évalué à 5.
Aller a l'URL xxxx
dcop konqueror-X konqueror-mainwindow#X openURL xxxx
Executer du JS sur la page:
dcop konqueror-X html-widgetX evalJS "script"
[^] # Re: Je me marre ... greasemonkey dcop
Posté par dguihal . Évalué à 1.
[^] # Re: Je me marre ... greasemonkey dcop
Posté par free2.org . Évalué à 1.
et d'utiliser greasemonkey pour exécuter du JS sur cette page
[^] # Re: Je me marre ... greasemonkey dcop
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
[^] # Re: Je me marre ... greasemonkey dcop
Posté par dguihal . Évalué à 1.
http://search.cpan.org/dist/WWW-Mechanize/lib/WWW/Mechanize.(...)
cependant un petit extrait :
donc pas utilisable dans mon cas.
De plus si je comprends bien, ce module emule un navigateur, et non pas cree une instance reele de navigateur, c'est pas mal déjà mais ce n'est pas ce que je souhaite.
Enfin merci je garde en bookmark quand même ca peut servir
[^] # Re: Je me marre ... greasemonkey dcop
Posté par Jérôme FIX (site web personnel) . Évalué à 2.
[^] # Re: Je me marre ...
Posté par Matthieu . Évalué à 10.
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 gnujsa . Évalué à 5.
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 gnumdk (site web personnel) . Évalué à 4.
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 TImaniac (site web personnel) . Évalué à 2.
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 Sytoka Modon (site web personnel) . Évalué à 1.
- 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 Thomas Douillard . Évalué à 2.
[^] # Re: Je me marre ...
Posté par gnumdk (site web personnel) . Évalué à 3.
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 Thomas Douillard . Évalué à -1.
[^] # Re: Je me marre ...
Posté par Thomas Douillard . Évalué à 0.
[^] # Re: Je me marre ...
Posté par gnumdk (site web personnel) . Évalué à 2.
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 hophophop . É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 gnujsa . Évalué à 2.
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 hophophop . Évalué à 0.
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 GPH (site web personnel) . Évalué à 1.
[^] # Re: Je me marre ...
Posté par gnujsa . Évalué à 5.
awk '/^regex$/ { ... }'
(d'autant que awk est très rapide, beaucoup plus que sed par exemple)
[^] # Re: Je me marre ...
Posté par GPH (site web personnel) . Évalué à 1.
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 Thomas Douillard . Évalué à 2.
[^] # Re: Je me marre ...
Posté par TImaniac (site web personnel) . Évalué à 2.
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 Guinns . Évalué à 2.
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 Thomas Douillard . Évalué à 2.
[^] # Re: Je me marre ...
Posté par Guinns . Évalué à 3.
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 golum . Évalué à 4.
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 Thomas Douillard . Évalué à 2.
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 Yth (Mastodon) . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 2.
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 Yth (Mastodon) . Évalué à 3.
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 Thomas Douillard . Évalué à 2.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Je me marre ...
Posté par Thomas Douillard . Évalué à 7.
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 briaeros007 . Évalué à 1.
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 Thomas Douillard . Évalué à 2.
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 briaeros007 . Évalué à -1.
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 Thomas Douillard . Évalué à 3.
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 briaeros007 . Évalué à 6.
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 Thomas Douillard . Évalué à 5.
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 hophophop . Évalué à 2.
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 iznogoud . Évalué à 2.
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 briaeros007 . Évalué à 5.
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 TImaniac (site web personnel) . Évalué à -1.
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 briaeros007 . Évalué à 4.
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 TImaniac (site web personnel) . Évalué à 1.
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 ǝɹɹǝıd oɯɐɹʇ . Évalué à 4.
[^] # Re: Je me marre ...
Posté par briaeros007 . Évalué à 0.
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 TImaniac (site web personnel) . Évalué à 4.
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 iznogoud . Évalué à 5.
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 TImaniac (site web personnel) . Évalué à 1.
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 briaeros007 . Évalué à 4.
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 TImaniac (site web personnel) . Évalué à 1.
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 iznogoud . Évalué à 5.
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 golum . Évalué à 0.
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 briaeros007 . Évalué à 2.
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 golum . Évalué à 4.
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 briaeros007 . Évalué à 2.
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 gnujsa . Évalué à 2.
[^] # Re: Je me marre ...
Posté par briaeros007 . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 2.
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 briaeros007 . Évalué à 2.
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 lolop (site web personnel) . Évalué à 3.
Ca se sent un peu au lancement, et sur ma machine (PIV 3GHz), je trouve que c'est un peu lent.
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.
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.
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(...)
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Je me marre ...
Posté par briaeros007 . Évalué à 2.
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 :
[^] # Re: Je me marre ...
Posté par hophophop . Évalué à 2.
8-0
comment tu fais pour editer tes messages?
[^] # Re: Je me marre ...
Posté par briaeros007 . Évalué à 2.
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 hophophop . Évalué à 1.
'fin j'dis ca...
:-D
[^] # Re: Je me marre ...
Posté par hophophop . Évalué à 2.
huhu
ou
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 andeus . Évalué à 3.
[^] # Re: Je me marre ...
Posté par briaeros007 . Évalué à 2.
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 gnumdk (site web personnel) . Évalué à 6.
kernel.kill !!
Trop bien, l'écran bleu en une ligne de commande :)
[^] # Re: Je me marre ...
Posté par feth . Évalué à 3.
[^] # Re: Je me marre ...
Posté par Matthieu . Évalué à 3.
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 pasBill pasGates . Évalué à 2.
[^] # Re: Je me marre ...
Posté par Matthieu . Évalué à 2.
[^] # Re: Je me marre ...
Posté par TImaniac (site web personnel) . Évalué à 2.
Je vois pas trop ce qui peut te manquer après !
[^] # Re: Je me marre ...
Posté par briaeros007 . Évalué à 1.
je vois pas ce qu'apporte PowerShell dans ce cas .
[^] # Re: Je me marre ...
Posté par golum . Évalué à 7.
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 scullder . Évalué à 4.
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 Infernal Quack (site web personnel) . Évalué à 1.
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 el_mickey . Évalué à 1.
[^] # Re: Je me marre ...
Posté par B16F4RV4RD1N . Évalué à 4.
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 Thomas Douillard . Évalué à 1.
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 B16F4RV4RD1N . Évalué à 3.
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 Thomas Douillard . Évalué à -3.
[^] # Re: Je me marre ...
Posté par pasBill pasGates . Évalué à 0.
[^] # Re: Je me marre ...
Posté par lambada . Évalué à 4.
# les commande Linux y sont reconnues
Posté par andeus . Évalué à 9.
PowerShellSaiNull®
[^] # Re: les commande Linux y sont reconnues
Posté par B16F4RV4RD1N . Évalué à 2.
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 ThesmallgamerS . Évalué à 3.
PowerShellSaiLeMAL
[^] # Re: Béh nos soirée vont devenir drôle, tiens
Posté par Snarky . Évalué à 3.
# Désolé, j'ai pas m'en empécher
Posté par abc . Évalué à 10.
ca serait pas plutôt "grosso mono du C#" ?
# performance
Posté par TazForEver . Évalué à 0.
[^] # Re: performance
Posté par ThesmallgamerS . Évalué à 3.
# Faille de securite mieux exploitable
Posté par alphacc . Évalué à 5.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.