Pourtant, quelques idées semblaient intéressantes.
Par exemple l'équivalent du "ls" retourne non pas le descriptif des fichiers sous forme de texte, mais des objet correspondant aux fichiers listés, que la console (ou l'éventuel programme dans lequel se dirige le pipe) peut afficher de la manière de son choix.
De plus il est possible dans le pipe de ne sélectionner que certains objets, grâce à des filtres portant sur leurs propriétés (ce qui serait possible sous bash, théoriquement, mais je ne crois pas que ça existe). Enfin, le shell peut transcrire les objets en xml, fichiers Excels...
Le problème, c'est que la volonté d'un shell "propre" d'un point de vue théorique a conduit ce langage à l'inexpressivité la plus totale.
Par exemple, le
ls -R dossier semble s'écrire get-childitem -Recursive -Path dossier.Il est heureusement possible d'écrire des alias, et certains sont fournis par défaut. Mais quand on doit aliaser toutes les commandes avant de pouvoir décemment les utiliser, c'est qu'il y a un problème.
Je doit reconnaître qu'il ne m'a pas été possible de le tester, cela requérant d'avoir windows, le paquet .net, un compte passeport et de s'enregistrer (pour les plus courageux, la procédure est indiquée sur le quatrième lien).
Mais j'ai quand même trouvé des scripts, qui sont censé être impressionants mais qui illustrent à mon avis l'inutilisabilité de la chose. Pour les utiliser, il vous faudra peut être changer la valeur du MSHCommandPath (14 lettres).
Le premier "FindStringsInWordDocs.msh" est un équivalent du
antiword fichiers.doc|grep mot (mais sans le support des regexp, sachant je n'arrive pas à comprendre la syntaxe pour l'invoquer, et qu'il faut avoir acheté msword pour qu'il marche).$phrase = $args[0];
$wd = new-object -activex "word.application";
$p = pwd;
if ($args.length > 1) {
$docs = $args[1];
} else {
$docs = "*.doc";
}
foreach ($a in $(get-childitem $docs -name)) {
$doc = $wd.documents.open("$p\$a");
if ($doc.content.find.execute("$phrase")) { write-host $a }
$doc.close();
}Le second change le prompt (équivalent de "PS1=" sous bash) en 17 lignes de code cryptique. C'est la réponse à la neuvième question de la FAQ.
function prompt
{
# make sure the end of the path is always visible at the prompt
$local:path = $(get-location).ToString()
$local:maxPath = [int] $MshHost.UI.RawUI.WindowSize.Width - 1
if ($local:path.length -gt $local:maxPath)
{
$local:x = [int] [System.Math].Max(0, $([int] $local:maxPath - 10))
$local:path = '...' + $local:path.Substring(($local:path.length - $local:x), $local:x )
}
$local:counter = $(get-history -count 1).Id
$local:counter += 1
# also show the path at the command windows title bar
$mshhost.UI.RawUI.WindowTitle=$('MSH - ' + $path)
#Show the prompt in blue
write-host $('MSH {0:d} {1}' -f $local:counter, $local:path) -fore Blue
'>'
}
Enfin, le troisième, MSHColorFunctions est un palliatif au manque de fonctions aussi simples que setterm.
Rappelons en effet que le nombre de programmes accessibles depuis la ligne de commande risque d'être extraordinairement limité par rapport à ce qu'on trouve sous Unix (ce qui est peut être compensé par l'accès au framework de .net).
Dans ces conditions, l'enthousiasme des utilisateurs de windows parait franchement surprenant. Peut être ai-je manqué une fonctionnalité ? Ou alors ils ne savent pas qu'un shell n'est pas forcement un langage destiné à écrire des projets d'envergure, mais simplement un truc commode au quotidien.
Un exemple parfait me semble être le fait que toutes les démonstrations de ce shell (cf google) trient des processus, les mettent dans des fichiers, affichent des dates, manipulent des chaînes de caractères... mais qu'aucune ne crée d'utilisateurs, ne redimensionne d'images, ne fait de calculs ou n'envoie d'email.
Je n'ai même pas entendu parler de la commande qui permettrais de déplacer des fichier ! Je sens déjà venir les "get-child -Path source *.txt|move-item destination".
Toujours dans cet esprit il manque à ce shell la gestion de la complétion par [tab], les options n'ont pas d'alias cours (comme -d pour --long)...
Bon, ceci dit il y a un ou deux cas où il se comporte mieux que bash (notement grâce à where). Mais il ne me convainc pas pour l'utilisation quotidienne.
Liens :
- Wiki enthousiaste sur le MSDN (source des exemples) :
http://channel9.msdn.com/wiki/default.aspx/Channel9.MSHWiki(...) - FindStringsInWordDocs :
http://channel9.msdn.com/wiki/default.aspx/Channel9.FindStringsInWo(...) - La FAQ du wiki : http://channel9.msdn.com/wiki/default.aspx/Channel9.MSHFaq(...)
- MSHColorFunctions : http://channel9.msdn.com/wiki/default.aspx/Channel9.MSHColorFunctio(...)
- Obtenir MSH : http://www.tech-recipes.com/windows_monad_msh_tips629.html(...)
- Quelques fonctions utiles de MSH : http://dolly.thinkingms.com/PermaLink,guid,b6bdc880-2c66-4d32-b635-(...)
# un autre
Posté par patrick_g (site web personnel) . Évalué à 5.
Comment comparerais MSH et Fish ? Est-ce que les quelques manques de Bash par rapport à MSH que tu évoque seront pris en compte dans une future version ou est-ce que Fish te semble plus prometteur ?
[^] # Re: un autre
Posté par un_brice (site web personnel) . Évalué à 2.
Avant toutes choses, je tient à dire que je suis un gros newbie du shell, que je parle en toute subjectivité et je sait que les gens qui conçoivent ces logiciels ont probablement pensé à des choses que je ne peut même pas imaginer.
Pour fish j'ai pas vraiment d'avis, il m'a pas l'air très utile: c'est juste une nouvelle syntaxe à peine préférable. Mais comme l'interêt du scripting bash par rapport à des langages comme python est justement que l'interpréteur est répendu, Fish me parrait pas très utile. Autant promouvoir de "vrais" langages.
Pour ce qui est d'amelliorer bash, j'essaierais peut être de faire un truc ces vacances : l'idée est qu'on peut arriver en bash au même genres de filtres qu'avec MSH, si on considère que la quasi-totalité des informations manipulées par les programes du shell sont des nom de fichiers ou du texte formaté en colonne.
L'idée serait de faire un genre de grep, qui pourrais appeler des programmes externes pour trouver les propriétés de ses arguments, et aussi parser les formats de sortie "standards" (objets séparés par des retours à la ligne, propriétés séparées par des tabulation - les trois quarts des utilitaires marchent comme ça).
Avec ça, on ferais par exemple "ps aux | filter -c -t CPU -gt 10" ( -c pour définir un critère, -t pour désigner la colonne qui a la valeur CPU à sa première ligne, les autres tests utiliseraient le format standard (man test)).
On encore "ls -R | filter -c -e du -gt 1000" pour trouver les programe de plus d'un kilo-octet grâce à un appel de "du" (find le fait, mais c'est pour illustrer).
Avec un outil comme ça, je pense on disposerais en pratique des mêmes fonctionalités, dans tout les shells et sans la lourdeur des concepts de MSH.
Et si il est en C, il pourras devenir un des outils standards, ou même titre que skill et ses copains.
(si j'y arrive je ferais aussi un programme pour standardiser la sortie des programes Unix plus abscons, voir j'essaierais de contacter leurs auteurs pour leur proposer un switch supplèmentaire)
(PS: Attention, c'est pas une promesse, vu que j'ai tendance à ne jamais finir ce que je commence. et qu'en plus je bosse jusqu'en juin. Si quelqu'un veut faire ça à ma place, ça me gêne pas -_^ (ça serait sympa de m'en parler))
# Hmm
Posté par Nong . Évalué à 4.
Les %? (? = lettre) du PS1 ne sont pas toujours portables et il faut parfois bidouiller selon les platformes ... De toute facon tu commences en concluant donc ...
[^] # Re: Hmm
Posté par un_brice (site web personnel) . Évalué à 8.
man console_codes
Alors que MSH c'est portable ?
Au moins bash existe sur plusieurs plates forme.
Rien à redire, je m'était déjà fait mon avis en commençant à rédiger.
[^] # Re: Hmm
Posté par ndv . Évalué à 2.
Mais bon, attendons de voir ce que ça vaut réellement avant...
[^] # Re: Hmm
Posté par push . Évalué à 7.
[^] # Re: Hmm
Posté par mol67 . Évalué à 1.
[^] # Re: Hmm
Posté par TImaniac (site web personnel) . Évalué à 4.
Eh oui il y a des choses que tu ne sais pas : Les dev de M$ ont gentiment aidé les dev de Mono quand ceux-ci avaient des difficultés.
[^] # Re: Hmm
Posté par mol67 . Évalué à 1.
Je veux bien te croire si tu m'en donnes.
[^] # Re: Hmm
Posté par TImaniac (site web personnel) . Évalué à 6.
Et pour reprendre ton poste précédent : .NET (la techno) EST portable. MS la prouvé avec Rotor. Après certains API sont plus difficilement portable (ou tout du moins pas adaptés), mais dans le contexte qui nous intéresse ici, un shell qui utilise les base fondamentales du framework c'est tout à fait portable.
[^] # Re: Hmm
Posté par farib . Évalué à 3.
Sans rien connaitre à MSH, je comprend presque les 17 lignes de code.
Tandis que la signification des chaines bizaroides d'un PS1 m'échappe toujours...
# Filiation bizarre...
Posté par Seazor . Évalué à 8.
On prend un shell, VBscript, on jette le tout dans un mixer et on se retrouve avec une syntaxe bidouillée pour pouvoir faire un peu des 2.
Mis à part le fait que ce sera un poil plus facile à lancer, faudra me montrer l'interet de la chose par rapport à leur vbs.
P'tet pouvoir faire comme les grands et devenir champion des one-liner :-)
[^] # Re: Filiation bizarre...
Posté par kowalsky . Évalué à 10.
Tout les jeuneot qui crois que de travailler en mode
texte fais de toi un "cyber-gouru qui tus de la mort" (au moins).
genre le mec il tape des commandes de fouuuuuuuuuuuuuuuuuuu...!
# ls -la | grep -v "lapin blanc"
Et apres il fait, ouf, j'ai reussi a penetré le system...!
[^] # Re: Filiation bizarre...
Posté par mol67 . Évalué à 10.
BERK !
[^] # Re: Filiation bizarre...
Posté par ナイコ (site web personnel) . Évalué à 6.
[^] # Re: Filiation bizarre...
Posté par Myrtille . Évalué à 5.
[^] # Re: Filiation bizarre...
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 7.
Proverbe Alien : Sauvez la terre ? Mangez des humains !
[^] # Re: Filiation bizarre...
Posté par nigaiden . Évalué à 3.
Ces jeunes, il faut tout leur expliquer...
[^] # Re: Filiation bizarre...
Posté par durandal . Évalué à 10.
Ces vieux, ils pigent rien...
# Ne pas oublier l'intégration avec l'environnement
Posté par lolop (site web personnel) . Évalué à 10.
Si on prend par exemple:
Première réaction, "c'est lourd par rapport à un ls -R". Maintenant, si WSH est bien fait, le get-childitem doit pouvoir s'appliquer à d'autres choses que des répertoires. A toute chose qui supporte la programmation objet, on peut imaginer que ça serve à traiter du XML, des informations de la registry Windows & Co.
Par le biais de ces protocoles, on peut faire pas mal de choses dans Windows, je vous renvoi vers les exemples d'utilisation de WMI (Windows Management Instrumentation) avec Python, sur http://tgolden.sc.sabren.com/python/wmi_cookbook.html(...) où l'on dépasse la simple manipulation de fichiers.
Ce que je ne comprends pas, c'est l'intérêt de redéfinir un nouveau langage de shell. Ils auraient pris un Python, ajouté iPython pour en faire un outil plus sympa au niveau shell interactif, et bien sûr l'extension win32 pour s'interfacer avec l'API windows et en particulier COM/DCOM... là ils ont fait un bâtard à leur sauce.
Python: http://www.python.org/(...)
iPython: http://ipython.scipy.org/(...)
extension win32: http://starship.python.net/crew/mhammond/(...)
Python WMI: http://tgolden.sc.sabren.com/python/wmi.html(...)
WMI: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wm(...)
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Ne pas oublier l'intégration avec l'environnement
Posté par un_brice (site web personnel) . Évalué à 3.
Le problème c'est que ces arborescences seront uniquement visibles des applications msh (à priori). Donc pas de passage par word ou par notepad ou que sais-je-encore.
De ce point de vue FuseFS, qui devrait arriver incessamment sous peu dans le noyau, est bien plus propre. En plus, il permet d'utiliser les langages de son choix (dont Python) aussi bien pour coder les systèmes de fichiers utilisateurs que pour coder les applications qui l'utilisent. (et pourtant on en fait pas tout un plat)
[^] # Re: Ne pas oublier l'intégration avec l'environnement
Posté par lolop (site web personnel) . Évalué à 1.
Pour le "tout fichier" (l'homogénéisation de l'accès aux informations - ça peut être du "tout objet" si l'on a l'infrastructure logicielle pour), sûr que sous Windows c'est pas vraiment prévu pour. Avez-vous vu passer un Hurd ou un Plan9 récemment ?
Microsoft aurait aimerais sans-doute un tout composant, mais entre l'héritage de l'existant (très lourd pour MS, voir le taux de migration à WinXP vs ce qui reste encore en Win2K), l'aspect "on change tout et on recommence" qui peut lasser voir dégouter des développeurs (Apple a beaucoup joué à ça aussi), ils sont obligés de faire avec plusieurs technologies, et là un système de shell/glue est intéressant.
Pour fuse (trouvé http://fuse.sourceforge.net/(...) ), je n'ai pas l'impression que ça puisse être utilisé sous Windows - là WSH vise un public particulier...
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Ne pas oublier l'intégration avec l'environnement
Posté par un_brice (site web personnel) . Évalué à 2.
Tu me diras, y'a probablement moyen sous windows d'intégrer au poste de travail un système distant par un protocole arbitraire (vu que GmailDS le fait).
Sauf que sous Linux ça peut se faire relativement facilement et de amnière sure, tout en étant parfaitement rétrocompatible.
Le peu que j'ai vu passer de Plan9 était trop compliqué pour moi, mais V9FS pourrait t'interesser http://v9fs.sourceforge.net/(...) .
Et je pense que Fuse peut aider à attendre le Hurd.
Mouais... y'a de la marge entre "potable compte tenu de l'inertie de leur plateforme" et "interessant". Surtout qu'ils auraient parfaitement pu fournir des facilités pour créer des systèmes de fichiers utilisateurs en tant que sous dossier dans un lecteur spècifique (disons Z:), ça n'aurais pas cassé la rétro compatibilité.
Enfin, je vais pas les accabler.
Mais le minimum aurait été de séparer la glue (comme tu dit) du shell. Et d'en profiter pour faire un shell sympa.
Non, Fuse est effectivement resérvé à Linux, mais rien n'empêcherais microsoft de tenter quelque chose du même genre.
[^] # Re: Ne pas oublier l'intégration avec l'environnement
Posté par lolop (site web personnel) . Évalué à 2.
Non, sauf erreur si l'application est scriptable les commandes de base sont toujours les mêmes. Après, si on veut demander à word d'aller faire une correction orthographique sur la deuxième phrase du troisième paragraphe de la page deux...
get orthcor(sentence two of paragraph three of page 2 of this document)
Non, là ça ressemblerait à de l'Applescript/Hypertalk. Microsoft préfère les $ et les accolades pour WSH.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Ne pas oublier l'intégration avec l'environnement
Posté par pasBill pasGates . Évalué à 1.
Sauf que sous Linux ça peut se faire relativement facilement et de amnière sure, tout en étant parfaitement rétrocompatible.
http://www.viksoe.dk/code/gmail.htm(...)
Mouais... y'a de la marge entre "potable compte tenu de l'inertie de leur plateforme" et "interessant". Surtout qu'ils auraient parfaitement pu fournir des facilités pour créer des systèmes de fichiers utilisateurs en tant que sous dossier dans un lecteur spècifique (disons Z:), ça n'aurais pas cassé la rétro compatibilité.
Ca existe deja, t'es simplement pas au courant que ca existe
[^] # Re: Ne pas oublier l'intégration avec l'environnement
Posté par un_brice (site web personnel) . Évalué à 2.
Mais je trouve que c'est plus proche de KIO que de Fuse. J'ai même l'impression que c'est moins réussi que KIO parce que l'API à l'air inchiable et que seul explorer et ses dérivés peuvent y faire appel (pas testé, extrapolé de http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sh(...) )
En tout cas, on est loin de pouvoir créer un FS en quelques lignes de python.
[^] # y'a encore du boulot !
Posté par patrick_g (site web personnel) . Évalué à 3.
Hummm....va voir sur http://lwn.net/Articles/131856/(...) et trouvera cette peu réjouissante prévision :
Until the core filesystem hackers are happy, however, FUSE is likely to have a rough path into the mainline.
# Ben...
Posté par pasBill pasGates . Évalué à 6.
Un exemple parfait me semble être le fait que toutes les démonstrations de ce shell (cf google) trient des processus, les mettent dans des fichiers, affichent des dates, manipulent des chaînes de caractères... mais qu'aucune ne crée d'utilisateurs, ne redimensionne d'images, ne fait de calculs ou n'envoie d'email.
Tout simplement car le but ici est de montrer ce que le shell lui-meme permet. Creer un utilisateur, redimensionner une image, envoyer un e-mail,... cela ne fait pas forcement partie du shell lui-meme, c'est une commande qui sera utilisee dans le shell.
Toujours dans cet esprit il manque à ce shell la gestion de la complétion par [tab], les options n'ont pas d'alias cours (comme -d pour --long)...
Perdu, les 2 sont dedans. La completion est la, et les alias aussi(cf. la video)
[^] # Re: Ben...
Posté par un_brice (site web personnel) . Évalué à 2.
C'est un peu comme si tu faisait la démo d'un nouveau langage en calculant la 321 ème décimale de Pi et une application qui écrit en boucle "toto" dans un fichier texte.
Désolé.
L'absence de complètion par [tab] C'est la manière dont j'avais compris le 13ième élément de la FAQ. Mais en lisant mieux, j'ai compris que la complétion qui n'existe pas encore et qu'ils regrettent de ne pas voir associé a [tab] est celle du "page précédente" "page suivante" et du "!".
http://channel9.msdn.com/wiki/default.aspx/Channel9.MSHFaq(...)
Pour ce qui est des alias, je pensais qu'il n'y étaient pas parce que l'imitation de man (get-help) ne les affiche pas sur la seule "capture d'écran" que j'ai vue http://www.egilh.com/blog/archive/2004/11/08/307.aspx(...) .
Ça ne justifie pas mon erreur, mais j'étais de bonne foi.
Enfin, y'a d'autres choses qui sont pas très utilisables (besoin de définir une fonction avant d'aliaser des commandes et leur arguments par exemple). C'est vrai que c'est pas structurel, mais révélateur.
[^] # Re: Ben...
Posté par briaeros007 . Évalué à -1.
plus serieusement : il a dis alias d'options. pas alias tout court. Je sais pas si tu avais dis alias dans ce sens (option) , ou juste alias normal.
[^] # Re: Ben...
Posté par pasBill pasGates . Évalué à -2.
[^] # Re: Ben...
Posté par briaeros007 . Évalué à 9.
Rectification celui qui veut lire les fichier, et qui a suffisament d'argent le peut.
De meme que celui qui a suffisament d'argent peut acheter une licence microsoft et un pc spécialement pour regarder les wmv ; ou celui qui a suffisament d'argent peut acheter un airbus.
MS ne cache pas ces specs,
Ben en les faisant payer il les cache a ceux qui ne veulent/peuvent pas payer.
Donc je maintiens ce n'est pas inter operable, car tout le monde doit pouvoir acceder aux specs sans discrimination si on veut que ce soit reelement inter operable : que tout le monde puisse les lire, et pas juste ceux qui peuvent payer (ps oui la discrimination par l'argent en est une).
[^] # Re: Ben...
Posté par Seazor . Évalué à 1.
C'est juste une reformulation de vbscript pour la ligne de commande ?
ou il y a vraiment plus ? (autre que l'autocomplete décent je veux dire ;-) )
[^] # Re: Ben...
Posté par pasBill pasGates . Évalué à 2.
# Irb
Posté par Matthieu Lemerre (site web personnel) . Évalué à 3.
exemples:
Recuperer la premiere ligne de tous les fichiers courant:
Dir.glob('*').collect {|f| File.open(f) {|io| io.readline}}
On peut meme, moyennant quelque traffics, taper directement
ses commandes shell avec irb:
def method_missing(*args)
`#{args.join(' ')}`.split("\n")
end
Et hop:
ls
=> ["src", "bin"]
ps
=> [" PID TTY TIME CMD", "5045 pts/4 00:00:00 zsh"]
Bon evidemment ca ne demande qu'a etre ameliore... Ce que je veux montrer c'est qu'on a tout ce dont on dispose pour fabriquer un outil equivalent
(un shell/langage plus evolue que le shell actuel).
En plus, Ruby est multiplateforme et on peut aussi contacter les composants Microsoft des autres appli avec.
http://l-lang.org/ - Conception du langage L
[^] # Re: Irb
Posté par lorill (site web personnel) . Évalué à 4.
c'est bon a savoir :)
# ca sert a rien?
Posté par kra . Évalué à 3.
- ben, en 5 minutes, hier.
- a y claque grave, il a un style qui claque a l'americaine, un truc de ouf.
- ouais, mais bon, c'est... franchement, ca sert a rien, c'est pas pour nous c'truc la..
- ah ouiii, la ptite one-liner, a la perl, chanme, ptite ligne vite fait, franchement bien, hein.
En meme temps, j'sais pas.. j'vois pas trop c'qu'on pourrait faire avec, c'est pas pour nous c'truc la
-Putain, c'te shell il est mortel, mais j'vois pas c'quon peut faire avec,
t'facons, c'est pas un truc pour nous, moi la d'ssus, j'verrais plus Daniel Robbins.
L'aut' jour, j'ai etudie son code d'facon analytique, ca m'echappe, il a des plans de script trop technique.
qu'il ecrit avec trop d'aisance, ca fait 15 ans qu'j'suis dans l'libre comme lui, j'voudrais coder dans un style trop d'avance,
mais bon, j'y arrive moyen, j'crois bien qu'ya pas moyen,
et putain, tu peux l'garder ton shell pourri qui sert a rien.
-il est pourri, il a bouffe d'la ketamine l'autre ou quoi encore?
- et j'dirais meme qu'y gave, avec cette fausse ligne en .net ou on sait pas c'qu'elle bave
ca s'trouve, c'est tout naze, voire pire, on s'rait pas d'accord, genre un drm de l'autre bord.
Bon qu'est ce qu'on fait, on le retravaille, ca peut peter en GPL?
- tu veux poser sur c'te shell, la disquette j'l'ai perdue,
demande aux lardu, aux objet trouvé, l'on ptetre entendu.
Ok, ca sort d'l'ordinaire, moi, c't'ordi m'fout les nerfs,
j'ai en plein le disque dur, mais ca m'donne pas le fsf d'or.
d't'facons, j'me rappelle, J'ai ete au plus vite pour faire ce shell, avec linux c'est c'quon evite, le code redmondien a la ballmer.
T'en faire un sans liberte et sans test.
Releaser ce shell, ca serait comme deposer le silence a la sacem.
...
-ca sert a rien?
comment ca, ca sert a rien?
dire ca d'un shell comme ca, mais putain, vous etes bien?
j'sais pas, vous, on dirait que vous calculez pas, mais ca au moins, bah ca sonne un peu cker-ha pour une fois..
Pourquoi se prendre la tete a cherche un gimmick bizarre?
moi, ya pas, j'veux poser sur ce shell d'batard!!
Pour qu'les gars qui m'trouvent dans les bacs,
confondent pas longhorn avec un mac,
pour qu'j'ai plus ce genre d'critiques dans les pattes.
J'te parle meme pas de garder un ton hardcore,
mais quoi, changer c'truc la contre un truc graphique, encore?!?
nan, d't'facons, virez ce shell, ya pas moyen.
pis j'parle plus avec vous les pingouins, ca sert a rien.
les amateurs de svinkels auront compris je pense ;-)
les autres, bah vous saurez quoi acheter comme cd la prochaine fois :p
[^] # Re: ca sert a rien?
Posté par gnumdk (site web personnel) . Évalué à 0.
Bel hommage à Svinkels :)
Bon, manque un bout du morceau mais sinon c'est pas mal ;)
Et effectivement, Svinkels c'est bien meme si mes morceaux préférés sont pas sur le dernier album.
[^] # Re: ca sert a rien?
Posté par kra . Évalué à 0.
une journee de taff dans un bureau ou il fait chaud :)
ca coute pas cher et c'est efficace.
sinon, comme toi, je prefere les premiers albums
[^] # Re: ca sert a rien?
Posté par gnumdk (site web personnel) . Évalué à -3.
[^] # Re: ca sert a rien?
Posté par Flavien . Évalué à 1.
Moi je connais que 2 morceaux ... fo que je pense à écouter ...
# Pourquoi ?
Posté par farib . Évalué à 5.
On détruit sans tester. Mais apres, on va aller pleurer que les logiciels MS, qui sont pas QUE nuls combinés à la machine marketing se vendent comme des petits pains.
Microsoft a du pognon, et un mec de la R&D chez MS est pas forcément plus con qu'un mec qui fait du libre.
Je fais confiance à MS pour pondre un très bon Longhorn, et faire très mal au libre, ce que je ne souhaite pas forcément.
[^] # Re: Pourquoi ?
Posté par Flavien . Évalué à 0.
de toute facon ca serra toujours mieux que CMD.exe + wscript +vbs ...
Bon en tant qu'admin microsoft (non ce n'est pas un choix ...) jui content c'est deja ca de pris.
Bon je me suis mis à fond windows car je ne trouvais pas (ou trop peu) de travail sous linux ... et j'ai trouvé des trucs très interressant chez microsoft ... par exemple WMI est vraiment très bien (ceux qui connaissent pas , critiquer pas ca sert à rien ...)
Seul ceux qui savent comprendrons ...
Et pour longcorne je pense aussi que ce sera une bonne mouture ... allez l'open source faite rentrer des os alternatifs dans l'entreprise ... eux mais pas dans des boites noires siouplé ... (checkpoint, netapp ou nokia VPN)
[^] # Re: Pourquoi ?
Posté par un_brice (site web personnel) . Évalué à 2.
Ce que je dit de manière cynique, je l'ai déduit de ce que j'ai lu, et je l'ai étayé par des exemples.
Du reste, parler de Longhorn maintenant est hors sujet.
[^] # Re: Pourquoi ?
Posté par kra . Évalué à 2.
'fin, bon, c'que j'en dis, hein, moi j'suis plutot content d'avoir enfin un shell pour windows, meme si c'est pour dans un futur lointain..
[^] # Re: Pourquoi ?
Posté par Seazor . Évalué à 3.
# Encore du code de porc
Posté par python . Évalué à -1.
Parce qu'on met des noms de variables pertinents, des noms de commandes significatives.
cd est une abbréviation de change directory
cp pour copy
mv pour move
rm pour remove
...
get-childitem ? ça veut dire quoi? Le mec était-il dans un délire quand il a décidé de pondre cette idée.
Vous pouvez m'incendier mais quand on pense vraiment, on n'a pas de doute. Suffit de voir ce qu'ils ont fait avec CMD.exe, JScript. Je trouve anormal qu'un term éxécute un virus.
Laissons à Microsoft le soin de rendre encore plus lourd, plus fonctionnel pour les ceux qui se jettent dessus et se pètent les bretelles et n'y voient que du feu derrière. La fonction première de bash est d'avoir accès au shell qui manipule directement le système de fichiers...
plus tard on va voir MS sortir un MSH version truc, qui permettra de taper du texte dans word, envoyer un e-mail, formater son pc par un virus,
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.