En faite, beaucoup d’outils similaires existent non pas dans Batch, mais dans Powershell.

curl peut trouver un équivalent dans invoke-RestMethod, unzip dans expand-archive…

Du peu que je connais, PowerShell est très puissant et ne semble pas avoir tant que ça à envier à bash/shell.



Au passage, un point intéressant de PowerShell, c’est la convention des noms des commandes, elles sont faites pour être lisible, elle commence toujours par un verbe.

Tu peux faire des pipelines en powershell. Ensuite, effectivement, les commandes dans powershell sont longues, justement car elles respectent une convention d’écriture. (voici par exemple laliste des verbes) Cependant, il existe des alias de base(tu peux l’obtenir avec “Get-Alias”).

Mais personnellement, ce qui fait que j’ai encore pas mal de difficulté avec PowerShell, c’est tout d’abord, je peux largement m’en passer, je n’ai jamais eu l’absolu nécessité au point de devoir m’y intéresser. C’est aussi parce que je reste encore loin d’avoir acquis l’essence du langage, trop éloigné d’un bach ou d’un shell. Mais bon, la doc existe et est vraiment bien foutu.

yvan a écrit :



Je pense que la cible c’est plutôt mac os.

Nombre d’unixiens utilisent mac os en OS client parce que c’est mieux foutu fonctionnellement que linux, il y a tous les outils unix dessus et les portables mac sont mortels niveau finition/ergonomie.



Si windows veut garder cette population experte tech qui est assez prescriptrice pour le grand public dans son giron il faut que tout l’outillage unix soit aussi géré sous windows, et avec des commandes natives parce que comme dit plus haut personne n’a envie d’apprendre powershell s’il sait déjà tout faire via de l’unix classique.







Tu as aussi la possibilité d’installer le sous système linux qui permet d’utiliser un shell ubuntu ou suze comme dit dans l’article.

Et je viens de voir ça, tu peux même faire l’inverse, installer Powershell sur ta distrib préférée, c’est opensource (dépôt github).







33A20158-2813-4F0D-9D4A-FD05E2C42E48 a écrit :



La concision… Pour écrire un script que tu devras maintenir longtemps, les conventions verbeuses c’est sans doute bien, mais pour taper une ligne de commande à usage unique, Get-Disk-Usage vs du, bof. Et on me dira qu’il y a des alias, certes, mais ça fait deux noms de commande à retenir.



Tiens, et si un jour cmd.exe pouvait comprendre que si ma ligne commence par ./ je veux exécuter un batch local au lieu de me dire “.” is not a valid command…





comme dit plus haut, il y a l’auto-complétion. Mais surtout, c’est justement la force de la convention d’écriture, les noms des commandes sont logique, tu connais les verbes, tu vas facilement retrouver la commande que tu souhaites utiliser. Le shell nécessite d’apprendre par cœur les noms des commandes (et de se souvenir comment les utiliser). Après, c’est sûr que si tu passes 10h par jour à ne faire que ça, tu connais tes commandes et taper 3 lettres est mieux (et là encore, tu peux faire tes alias, et puis voila), mais bon, quand comme moi, on n’utilise le shell que de temps en temps, un truc logique, c’est bien plus rapide pour s’y replonger.

Perso, “pwd” ça m’évoque plus une abréviation de “password” que de “print working directory ” (sa réelle signification) où “Get-Location” est quand même bien plus parlant (mais pwd est un alias pour dans powershell).





Même si on ne parle pas de Batch ici, en ayant utiliser Batch pour faire des script 3 fois dans ma vie, je dirais que comme l’on est sous un environnement DOS, as-tu essayé “.\” (avec l’anti-slash au lieu d’un slash), sinon, il me semble que sans, ça fonctionne très bien sans, Batch recherche si mes souvenirs sont bon d’abord dans le dossier courant puis dans les dossiers du %PATH%.







wagaf a écrit :



Il faut dire aussi que PowerShell est archi-lourd, prend plusieurs secondes à se lancer même sur une bonne machine, alors qu’au contraire un environnement shell/bash c’est ce qui se fait de plus léger comme interpréteur.



Pour du plus haut niveau autant aller vers une console Python3 (type IPython), avec tous les toolkit scientifiques et autre de dispo et un language cross-platforme.





Il démarre instantanément chez moi et PowerShell ISE (l’environnement de développement) mets 2s à démarrer, je n’ai pas non plus une brut de PC. Après, peut-être parce que j’utilise Chocolatey (et plus exactement le GUI) qui utilise powershell, ce dernier est “rafraichi” régulièrement.

(souvent le “temps” de démarrage est plombé parce que l’outil n’étant jamais lancé, il nécessite de faire vérification et ses mises à jours. Ainsi, j’avais vu ici une fois une critique comme quoi l’outil pour lister/désinstaller les programmes dans l’interface ModernUI étant plus lent que celui dans le panneau de configuration vient du fait que les 2 outils semblent partager exactement le même index pour lister les programmes, sauf que la personne a dû lancer celui de l’interface ModernUI en premier il a dû mettre à jour l’index en se lançant, ce qui n’était donc plus nécessaire lorsqu’il à lancer celui dans le panneau de configuration).



Oui et ASM est de bas niveau… je ne comprend pas ton problème, qu’est ce que python viens faire ici. Tu administres ton PC avec Python ? Si s’est pour la légèreté, un interpréteur Shell n’a pas a être léger (non, sérieusement, qui s’en soucis vraiment aujourd’hui ? parce que niveau “légèreté” une instance de powershell me bouffe 26Mo, alors qu’à coté j’ai firefox qui me bouffe 2749Mo), il doit juste servir d’interface entre toi et l’OS. Sous Windows, de manière général, l’administration de l’OS passe à très très très large majorité au travers d’interface graphique (qui est autrement plus lourd que n’importe quelle shell).

Bon, ben pour toi, je prendrais ton exemple à l’inverse, va taper dans un shell linux le nom de ton script sans le “./” (ça m’arrive encore souvent, je trouve même ça très logique), il t’engueule allégrement.