https://github.com/PowerShell/PowerShell/
PowerShell intègre un interface en ligne de commande, le langage de script PowerShell ainsi qu'un kit de développement. Il est inclus depuis Windows 7 et s'appuie sur le framework Microsoft .NET.
Après avoir libéré le Framework .NET, Microsoft vient de faire la même chose pour son Shell en le rendant disponible sous Linux et OSX.
Pas pu tester pour le moment car il ne fonctionne pas sous ArchLinux. Mais je suis curieux de voir comment Microsoft va intégrer cela avec notre OS. En effet, Powershell se base sur des couches d'abstractions pour communiquer avec le système, lui permettant de renvoyer des données formatées et donc d'éviter certaines galères communes aux Shell Unix comme:
$ ip addr | grep 'state UP' -A2 | tail -n1 | awk '{print $2}' | cut -f1 -d'/'
vs
>Get-NetIPAddress –AddressFamily IPv4
Merci de ne pas poster votre version plus courte pour obtenir l'ip courante, j'ai juste copié collé le premier résultat depuis Google
Bref, à suivre.
# Grilled
Posté par gnumdk (site web personnel) . Évalué à 8.
https://linuxfr.org/users/dcp/journaux/powershell-sur-linux
# Héhé
Posté par barmic . Évalué à 7.
Comme tu t'es fais griller, je me permet parce que ça ne devrait pas trop polluer la discussion.
Moi j'aime bien cette solution :
pas plus courte, mais elle montre toutes les adresses et sur quelle interface :
Car le plus simple reste encore :
netstat -ie | awk '/inet /{print substr($2, 5)}';)Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Héhé
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
Pour trier déjà sur les IPv4 et sur les interfaces actives, autant le demander à
ip:[^] # Re: Héhé
Posté par barmic . Évalué à 4.
Je ne connaissais pas, merci. Mais comme tu fais de toute manière un filtre ça ne change pas grand chose. Par contre pour faire plus simple que le
/inet /!d;tu peux faire :Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Héhé
Posté par esdeem . Évalué à 2.
Mouais, mais ça donne le même résultat uniquement si tu n'as qu'une interface avec une ip.
Exemple chez moi :
192.168.1.65 → juste
Mais:
192.168.148.1 → faux !
Par contre :
192.168.1.65 → juste
--
Mes 2 ¢
0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
[^] # Re: Héhé
Posté par Benoît Sibaud (site web personnel) . Évalué à 4. Dernière modification le 19 août 2016 à 11:56.
Je dirais que le souci vient plutôt du fait que je n'ai pas géré la diversité des cas. Par exemple :
inet 192.xx.xx.xx/24 brd 192.xx.xx.xx scope global eth2et
inet 90.xx.xx.xx peer 193.xx.xx.xx/32 scope global ppp0donc il ne faut pas utiliser le '/' du '/24' pour délimiter l'IP.
[^] # Re: Héhé
Posté par Benjamin Henrion (site web personnel) . Évalué à 2.
Une pétition aux auteurs de la commande ip (et ifconfig aussi tant qu'on y est) pour ajouter ce genre de fonctionnalité dont les sysadmins ont besoin?
[^] # Re: Héhé
Posté par claudex . Évalué à 4.
On appelle ça un rapport de bug
Vu le nombre d’année que c’est deprecated, on ne va pas forcer.
Quelle fonctionnalité ont-ils besoin ? Parce que par défaut, dans le commentaire auquel tu réponds, il y a déjà les IP sur une ligne.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Héhé
Posté par flan (site web personnel) . Évalué à 6.
Gros inconvénient de ce genre de manip : on peut avoir de mauvaises surprises vu qu'on compte sur un format de sortie qui n'a aucune garantie de stabilité (par exemple quand l'OS est en français). À ce niveau, PowerShell a un gros avantage.
[^] # Re: Héhé
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
J'ai du mal à voir l'intérêt de choisir la dernière IP, si on ne contrôle pas quelle est la dernière interface. A priori il y a déjà un souci dans la requête initiale. Soit on veut une interface portant tel nom (une eth3 ou un ppp0 par exemple), soit on cherche une IP ayant telle forme (un 192.168.42.xx par exemple).
Exemple : deviner quelle sera la dernière interface listée entre eth1 ou eth3 :
[^] # Re: Héhé
Posté par David Marec . Évalué à 3.
Sous Windows 7, PowerShell répond en français:
[^] # Re: Héhé
Posté par barmic . Évalué à 4.
Oui mais tu manipule des objets .Net pas une sortie texte.
Après dans un script tu nettoie ton environnement pour que les commandes te sortent du français et en cli tu t'en fout c'est de la commande que tu n'utilisera pas plus de quelques jours grand maximum.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Héhé
Posté par David Marec . Évalué à 5.
Quel rapport ? Il s'agit pour l'auteur de comparer deux commandes "shell".
D'un coté, il fournit une commande Linux honteusement compliquée, alors qu'un
hostname -Isuffit.De l'autre, il fournit un équivalent Windows qui n'existe pas sous Windows 7, OS mentionné dans l'article.
[^] # Re: Héhé
Posté par barmic . Évalué à 3.
Je croyais que ce qui te gênait c'était qu'il réponde en français.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Héhé
Posté par gouttegd . Évalué à 10.
Petite précision, la commande
hostnamefournie par le projet net-tools ne reconnaît pas d’option-I. Cette option est une invention de l’implémentation propre à Debian.Toutes les distributions n’ont pas repris cette implémentation et fournissent à la place la commande
hostnamed’origine du projet net-tools (sans l’option-I, donc).[^] # Re: Héhé
Posté par Frank-N-Furter . Évalué à 6. Dernière modification le 19 août 2016 à 15:54.
$ hostname -ihostname: illegal option -- i
usage: hostname [-fs] [name-of-host]
grilled…
Depending on the time of day, the French go either way.
[^] # Re: Héhé
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Ben justement, je ne suis pas sur que cela soit toujours une bonne idée !
Avec le shell UNIX et en pensant à faire un LANG=C, les scripts sont relativement robuste dans le temps. Si les versions changent, c'est du texte, on met à jour mais tout cela reste des chaînes de caractères immutable.
C'est assez lispsien comme approche. Dans la construction de Perl6, ils expliquent bien pourquoi ils ne font pas du tout objet.
Tes objets, ils ont plein de méthodes et tu joues au final avec un nombre fini de méthode. Avec l'approche ASCII, on fait du traitement de chaîne en terme de flux. Chacun peut imaginer tout ce qu'il veut, c'est un monde très ouvert et très souple. Avec le temps, les arbres de classes ont tendance a se rigidifier et à se scléroser. Il devient paradoxalement très compliqué de modifier certain schéma interne.
Alors certes, l'approche ASCII n'est pas performante mais on n'est pas là pour faire toujours du HPC ;-)
[^] # Re: Héhé
Posté par barmic . Évalué à 7.
Ce n'est pas vraiment une question de performance (le shell surpasse tous les langages qui existant), c'est plus de la fiabilité et de la simplicité.
Je trouve l'idée assez bonne, mais l'implémentation pas terrible personnellement. Ce n'est peut être qu'un effet de bord ou peut être que j'ai un biais de pensé, mais le shell est un langage que je parle véritablement couramment. Pour des raisons que j'ai du mal à expliquer mes tentatives avec PowerShell n'ont rien donné de très concluant (et je suis ouvert, je suis entrain d'essayer de passer à ipython comme login shell).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Héhé
Posté par flan (site web personnel) . Évalué à 3.
je n'ai pas beaucoup regardé Powershell (je n'utilise pas Windows), mais j'ai la même impression. Je suis assez fan du concept mais la syntaxe me semble peu amène. Après, s'il y a une autocomplétion (un peu comme iPython), ça peut aider.
Faudrait que j'essaie iPython par défaut, tiens. Pour l'instant, je suis resté à zsh.
[^] # Re: Héhé
Posté par El Titi . Évalué à 10.
ipython, c'est dépassé.
La nouvelle tuerie c'est xon.sh.
Cf; presentation au pycon
https://www.youtube.com/watch?v=uaje5I22kgE
[^] # Re: Héhé
Posté par El Titi . Évalué à 2. Dernière modification le 19 août 2016 à 19:20.
houps doublon à supprimer SVP si un modo passe par là
[^] # Re: Héhé
Posté par gnumdk (site web personnel) . Évalué à 5.
C'est de la mauvaise fois ça, avec Unix aussi tu joues au final avec un nombre fini d'option par commande au lieu d'un nombre fini de méthode par objet.
[^] # Re: Héhé
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
Pas tout à fait vrai. Tu travailles en shell sur un pipe ASCII. En gros sur un texte qui se fait transformer. C'est assez proche du langage avec des possibilités très large. Ainsi, il y a plus d'une manière de faire une chose comme on le vois régulièrement dans les réponses sur le forum. TimTowTdi - There Is More Than One Way To Do It. Rare sont les langages objets a inscrire cela dans leur cœur. C'est à mon avis un gage de pérennité, de souplesse.
De plus, tu peux écrire une nouvelle commande dans le langage que tu veux, comme tu veux. Tout s'interface juste par traitement de texte. L'API imposé est hyper simple et très souple.
[^] # Re: Héhé
Posté par Zenitram (site web personnel) . Évalué à -1.
Tu es sérieux dans le fait de trouver ca "robuste"?
"on met à jour", c'est tout, tu le crois vraiment? (genre tu sais que ton script ne tourne que sur une distro précise avec une version précise)
et du coup on se retrouve avec des scripts Perl incompréhensibles (plein de "formules magiques") même par son auteur.
toi, tu dois regretter SysV qui faisait ton bonheur à coup de maintenance complexe mais il a été remplacé (les salauds!) par systemd pour justement éviter le "bonheur" dont tu parles (tout le monde n'a pas le temps l'envie de jouer à "si le texte change on met à jour", certains travaillent)
[^] # Re: Héhé
Posté par GG (site web personnel) . Évalué à 0.
Bonjour,
depuis que j'ai systemd ma vie d'administrateur système est plus compliquée.
Quand je lance un service j'ai rarement un retour. Parfois j'ai pour retour : ça marche pas, va regarder le journal pour savoir pourquoi.
Quand je n'ai aucun retour, c'est pire parce que je dois vérifier si ke service tourne.
Je suis donc obligé d'avoir un terminal de plus ouvert pour afficher les journaux de systemd.
Systemd apporte bien plus de complexité. Avant, c'était simple. On avait le retour directement.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Héhé
Posté par gnumdk (site web personnel) . Évalué à 6.
Si tu n'a pas de retour, c'est que le service fonctionne… Avec Sysinit, tu avais juste un echo "Starting toto"… J'appelle pas ça un retour…
[^] # Re: Héhé
Posté par needs . Évalué à 3.
D'expérience ce n'est pas toujours le cas. J'ai eu plusieurs fois aucun retour pour le service
fcgiwrapoufcgiwrap.socket, alors même que le service ne s'était pas lancé correctement.[^] # Re: Héhé
Posté par GnunuX (site web personnel) . Évalué à 3.
Il y avait le même genre de problème avec sysinit.
[^] # Re: Héhé
Posté par rewind (Mastodon) . Évalué à 4.
J'adore ce genre de réponse. Avant on nous vendait systemd comme un sysinit killer qui allait tout mieux faire, bien proprement et qu'on était vraiment des dinosaures à vouloir encore rester avec sysinit. Là, on est passé à un stade où on doit accepter d'avoir les mêmes bugs (parce que c'est un bug) que sysinit. Tout changer pour que rien ne change. D'autant plus que la réponse ne correspond pas à la question. On s'en fout qu'il y ait les mêmes problèmes avec sysinit. On l'a enterré sysinit (ou presque), le problème là il est bien dans systemd.
[^] # Re: Héhé
Posté par barmic . Évalué à 7.
Ben quand la remarque c'est « avant j'avais pas de problème avec sysvinit », c'est normal de faire la comparaison.
Et justement c'est un problème de compréhension.
En soit savoir qu'un deamon fonctionne est un problème bien plus complexe (et bien trop complexe pour un système d'init). La seule façon fiable consiste à faire du monitoring. Ici on est plus sur une question d’expérience utilisateur. C'est rassurant d'avoir ta commande qui te dis « ça va » que si elle ne te dis rien (même si ça a la même signification).
La solution probablement très complexe pour l'administrateur système consisterais à se créer une fonction :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Héhé
Posté par flan (site web personnel) . Évalué à 7.
Je trouve que c'est bien plus simple de débugguer avec systemd.
J'ai eu un souci récemment avec ElasticSearch dont le paquet officiel se lance encore avec sysvinit.
Le service ne se lançait pas, et aucun log nulle part.
J'aurais bien aimé lancer la commande à la main, mais retrouver la commande réellement exécutée est particulièrement pénible vu la taille du script sysvinit.
Au contraire, avec systemd on a 4 lignes qui donnent l'utilisateur, le dossier, la ligne de commande et l'environnement. Du coup, c'est très facile de le lancer directement (et en l'occurrence de se rendre compte que java n'avait pas été installé).
[^] # Re: Héhé
Posté par Moonz . Évalué à 7.
bash -x /etc/init.d/elasticsearch start[^] # Re: Héhé
Posté par Kerro . Évalué à 3.
Pourquoi pas directement « /etc/init.d/elasticsearch start » ?
[^] # Re: Héhé
Posté par Moonz . Évalué à 10. Dernière modification le 22 août 2016 à 17:47.
Pour pouvoir passer l’option
-xqui demande à bash de logguer les commandes lancées par le script, ce qui répond à la problématique initiale (comment savoir quelle commande lance réellement le script d’init ?).[^] # Re: Héhé
Posté par GG (site web personnel) . Évalué à 1.
Bonjour,
Quand je relance nginx, s'il y a une erreur, avec systemd j'ai uniquement l'information comme quoi il y a eu une erreur, et je dois regarder le journal pour avoir les détails. Très chiant.
Avec sysvinit, j'avais directement les informations sur l'erreur.
Il y a clairement une régression avec systemd.
Concernant les retours vides avec sysvinit je regarderai en détail.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Héhé
Posté par wismerhill . Évalué à 4.
Et si ça se passe au démarrage du système ça va être perdu dans tous les messages de démarrage sans moyen d'aller le retrouver, alors qu'avec systemd ce sera quand même dans le journal et tu pourra retrouver l'information.
En plus, un systemctl status t'affiche les dernières lignes du journal pour l'unité concernée.
[^] # Re: Héhé
Posté par GG (site web personnel) . Évalué à 2.
Mais pourquoi systemd ne laisse pas l'information lorsque je relance le service manuellement? Pour m'obliger à lire son journal. Donc à effectuer une operation de plus…
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Héhé
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 1.
En même temps, je ne vois pas trop comment systemd pourrait déterminer le moment opportun pour afficher le log ?
Imaginons, que ce soit dès que le processus est lancé: tu verras dans le log des lignes du genres "Starting service…." et tu ne verras pas qu'un peu plus tard le service n'arrive pas à atteindre certains fichiers. Là tu auras l'impression que systemd a menti car il a indiqué le status "OK", alors qu'en réalité le service a échoué.
En fait, le seul cas que je vois pour que systemd puisse t'afficher un retour est le cas où le processus ne peut pas être exécuté (lanceur introuvable par systemd par exemple) ou la configuration du service ne suit pas les attentes de systemd. Il me semble que dans ce cas, systemd renvoie bien des erreurs.
[^] # Re: Héhé
Posté par GG (site web personnel) . Évalué à -3.
le retour que j'ai (quand il y a une erreur) c'est qu'il ya eu une erreur sans les détails. c'est une importante régression par rapport à sysvinit.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Héhé
Posté par xcomcmdr . Évalué à 2.
Ah ? Y'avait les détails dans SysVInit au démarrage ? (première nouvelle)
Y'a des cas où journalctl ne donne pas le détail ? (deuxième nouvelle)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Héhé
Posté par GG (site web personnel) . Évalué à 1.
Depuis le début je ne parle pas du démarrage du serveur.
Je parle des cas où je change la configuration et que je regarde si le service se lance bien ensuite.
journalctl va donner les détails, mais autant les avoir directement à la commande de relance du service, non? plutôt que de devoir lancer une autre commande pour avoir les détails.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Héhé
Posté par GnunuX (site web personnel) . Évalué à 4.
Ben non tu ne lis pas le journal quand tu fais : "systemctl status nginx"
[^] # Re: Héhé
Posté par xcomcmdr . Évalué à 4.
Difficile à croire, mais ok…
WUT ?!
Toi apprendre systemd, et revenir ensuite. Sérieusement !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Héhé
Posté par GG (site web personnel) . Évalué à 3.
J'ai eu ce cas.
Peut être un script mal foutu.
Je sais me servir des comandes de bases de systemd, et c'est devenu plus compliqué. En particulier parce qu'on a pas le retour complet en cas d'erreurs. Il faut lire le journal. Avant on avait directement les erreurs. Certes c'est plus difficile à parser éventuellement par d'autres scripts, et encore.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Héhé
Posté par gnumdk (site web personnel) . Évalué à 5.
Ce qui a l'air compliqué en 2016, c'est le fonctionnement d'Unix… Si tu veux les messages directement, il y'a plein de façon de faire sous Linux. Ça m'a pris 5 minutes…
[root@adm-cb bellegardec]# systemctl start sshd
-- Logs begin at ven. 2016-03-11 20:58:24 CET, end at jeu. 2016-08-25 09:27:07 CEST.
août 25 09:27:07 adm-cb systemd[1]: Started OpenSSH Daemon.
août 25 09:27:07 adm-cb sshd[1925]: /etc/ssh/sshd_config: line 5: Bad configuration o
août 25 09:27:07 adm-cb sshd[1925]: /etc/ssh/sshd_config: terminating, 1 bad configur
août 25 09:27:07 adm-cb systemd[1]: sshd.service: Main process exited, code=exited, s
août 25 09:27:07 adm-cb systemd[1]: sshd.service: Unit entered failed state.
août 25 09:27:07 adm-cb systemd[1]: sshd.service: Failed with result 'exit-code'.
[^] # Re: Héhé
Posté par flan (site web personnel) . Évalué à 8.
Mais en PowerShell tu n'as normalement pas besoin de parser le message d'erreur. Tu regardes le type de l'exception (CommandNotFoundException) et tu te moques royalement que le message d'erreur soit en klingon ou en anglais.
Au contraire, le shell t'oblige à parser en permanence et le moindre petit changement de syntaxe peut amener des bugs aussi imprévisibles que pénibles à détecter.
[^] # Re: Héhé
Posté par Marotte ⛧ . Évalué à 1.
Les utilitaires UNIX modernes comme GNU find ou encore ls ont des options comme
--format=commaou-printf "…"qui permettent de s’assurer que ça ne va pas casser dans le futur… disons que ça en réduit la probabilité…Déterminer un format pour l’option -printf de la commande find ou choisir parmi les membres d’un objet PowerShell je ne vois pas trop la différence, c’est de l’objet dans les deux cas.
[^] # Re: Héhé
Posté par flan (site web personnel) . Évalué à 5.
Oui, peut-être pour find. Et pour les 9 999 autres commandes utilisables en shell ?
Accessoirement, il faut quand même parser la sortie (ce qui est vite pénible quand elle ne se présente pas exactement sous la bonne forme).
[^] # Re: Héhé
Posté par Marotte ⛧ . Évalué à 2.
On utilise pas 9 999 commandes en shell… Surtout si on se limite aux commandes qui produisent une information en sortie (donc exit cut, awk, sed, tr, …)
Mais bon. J’ai rien contre PowerShell hein. Il m’arrive de l’utiliser. Dernièrement je m’étais penché sur la bonne manière de mesurer une charge CPU, c’est à dire en faisant plusieurs mesures et en calculant une moyenne, en prenant en compte le nombre de cœurs. Je l’ai fait pour AIX et Linux et par curiosité j’ai cherché comment faire de même sous Windows. La solution que j’ai trouvé en PowerShell est tout aussi simple que les solutions pour AIX ou Linux qui utilisent awk.
[^] # Re: Héhé
Posté par flagos . Évalué à 4.
Pour les codes d'erreur Unix, ils sont à peu près standardisés dans sysexit.h. Pour les commandes de base, ça me semble assez bien suivi, j'irai pas dire comme tu le dis qu'il est nécessaire de parser en permanence.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2. Dernière modification le 21 août 2016 à 00:39.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Héhé
Posté par gnumdk (site web personnel) . Évalué à 0.
Le rapport? C'est pas ça qui va te dire que ton expr précédent n'a pas matché le bon truc parce que la sortie de la commande a changé…
[^] # Re: Héhé
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
D'abords, les sorties des commandes ne changent pas si souvent (bien penser à se mettre en LANG=C), ensuite coté réseau, les choses ont tant évolué en 20 ans qu'il est normal que cela change. Avec de l'objet, cela serait pareil.
Exemple, de nos jours, on peut répondre sur la même interface que la demande, même si c'est pas la route définit… Il faut bien un moyen d'avoir un retour. http://unix.stackexchange.com/questions/4420/reply-on-same-interface-as-incoming
[^] # Re: Héhé
Posté par Moonz . Évalué à 10. Dernière modification le 19 août 2016 à 12:08.
Sinon
hostname -Iça marche bien aussi.Mais je comprend aussi très bien la devise Shadock : pourquoi faire simple quand on peut faire compliqué ? :)
[^] # Re: Héhé
Posté par Michel H . Évalué à 1.
Ouf Merci …
[^] # Re: Héhé
Posté par gnumdk (site web personnel) . Évalué à 2.
hostname -I lit le fichier /etc/hosts pour te dire à quel point c'est limité: ne marche pas pour tout ce qui n'est pas serveur…
[^] # Re: Héhé
Posté par Moonz . Évalué à 5. Dernière modification le 19 août 2016 à 16:36.
Heu… non.
(si tu fais un strace complet tu peux voir qu’il interroge directement le kernel via netlink)
[^] # Re: Héhé
Posté par gnumdk (site web personnel) . Évalué à 2.
Ben ici cela ne fonctionne pas… Il me renvoie 127.0.0.1
# Pour qui?
Posté par Le Gab . Évalué à 5.
Il ne reste que des developpeurs .JS de nos jours. :P
[^] # Re: Pour qui?
Posté par Le Gab . Évalué à 0.
Et plutôt que de libérer des choses qui existent déja et en mieux, pourquoi ne pas libérer ce qui manque réellement, je sais pas moi, DirectX par exemple. :)
[^] # Re: Pour qui?
Posté par Anthony Jaguenaud . Évalué à 2.
Si les gamers ne sont plus tenu par les c……s, la perte de part de marché risque de se sentir.
[^] # Re: Pour qui?
Posté par pasBill pasGates . Évalué à -5.
Ah ca c'est sur, si Linux reste à 1% sur le desktop c'est parce que les gamers sont tenus par les couilles sous Windows…
Ah tiens, on me répond que les gamers ne sont pas 99% de la population desktop, et que les non-gamers n'en ont rien à battre de Linux non plus.
[^] # Re: Pour qui?
Posté par Zenitram (site web personnel) . Évalué à -10.
Ils iront sur Mac alors, certainement pas Linux… Ou resteront sous Windows.
Question idiote : pourquoi donc plein de non utilisateurs de DirectX (majoritaires sous Windows) sont toujours sous Windows?
Je parie qu'on va trouver une raison "c'est la faute aux autres" et pas "ouais, on est pas bons", toujours reporter sur les autres ses (ou ici de sa "communauté") échecs plutôt que de se regarder en face.
[^] # Re: Pour qui?
Posté par n0wic . Évalué à -9.
Ils iront là où on leur dira d'aller pour la majorité : par exemple sur SteamOS.
Les gamers se fouttent de la plateforme tant qu'ils ont leur dix icones et leur copains sur quakenet, je voulais dire Facebook pardon.
Après il y a des mecs qui veulent faire des taffes de portage comme ce qu'a fait loki il fut un temp (ex : postal plus) mais ils étaient solides en terme de compétences.
Bioware a créer un moteur qui utilise Opengl et DirectX et certains jeux fonctionnent sous Windows et sous Linux ca doit représenter un travail fou à déveloper tout en double.
Et je ne parle pas des mecs qui continuent à retourner le passé dans FreeDos et Cedega.
[^] # Re: Pour qui?
Posté par xcomcmdr . Évalué à 0.
LOL!!1!one
1000 jeux (pour la plupart bogués/injouables) sous Steam Linux / SteamOS, environ 7400 pour Steam sous Windows.
Essaie encore…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pour qui?
Posté par Psychofox (Mastodon) . Évalué à 4.
Je pense qu'un grosse part tiens du fait qu'en dehors de windows on n'ai aucune assurance que les périphériques que l'on possède ou achètera dans le futur sera compatible. En dehors des imprimantes, même les Maceux se limitent souvent à l'écosystème brandé Apple pour tout ce qui est réseau et périfs car ils ont peur des incompatibilités.
D'après une sondage dans mon entourage, c'est parce qu'ils ne veulent pas prendre le temps de réapprendre autre chose que ce qu'ils utilisent au bureau. Un exemple con: ma compagne admet que openoffice répondrait à son besoin d'utilisation bureautique à la maison mais les menus sont pas tout à fait présentés pareils ete elle ne l'utilisera jamais assez à la maison pour justifier la courbe d'apprentissage. Aussi, dans l'hypothétique cas où elle devrait envoyer un document à quelqu'un (ça n'est à ma connaissance jamais arrivé, elle ne bosse pas à la maison) ayant office elle aurait besoin de faire vérifier chaque document aavant envoir final sur un pc avec MS office. Donc au final autant avoir office directement.
Vue que de nos jours l'utilisation d'un ordinateur à la maison se résume de plus en plus à n'ouvrir qu'une seule application, un navigateur, je comprends aussi que personne ne soit intéressé à apprendre l'utilisation d'un OS différent, quelque soit la facilité/difficulté de la période d'apprentissage.
[^] # Re: Pour qui?
Posté par Tonton Th (Mastodon) . Évalué à 4.
http://www.clubic.com/windows-os/windows-10/actualite-814102-webcam-windows-10-anniversaire.html
[^] # Re: Pour qui?
Posté par dyno partouzeur du centre . Évalué à 5.
Sous Linux, les périphériques nouveaux ne marchent pas toujours par manque de support de la part des constructeurs qui ne se font pas chier à écrire un pilote pour un nombre d'utilisateurs assez réduit. Malheureusement c'est un cercle vicieux : pas de support pour les périphériques => faible adoption => marché de niche => pas de support pour les périphériques.
A contrario, sous Window, les périphériques anciens ne marchent pas toujours par manque de support de la part des constructeurs qui ne se font pas chier à écrire un pilote pour un produit qui n'est plus sous garantie. Malheureusement ça conforte les fabricants dans leur choix puisque la réaction naturelle du client est de remplacer le produit par un plus plus récent.
[^] # Re: Pour qui?
Posté par Firwen (site web personnel) . Évalué à 2. Dernière modification le 21 août 2016 à 19:38.
[mode vendredi]
Ne leur donne pas d'idée malheureux !
Ou on va se retrouver avec une sortie JSON sur tous les coreutils sous peu.
Et un shell nodeJS à la place de bash.
[/mode vendredi]
[^] # Re: Pour qui?
Posté par MalMok . Évalué à 2.
Déjà fait : https://juniper.github.io/libxo/libxo-manual.html
[^] # Re: Pour qui?
Posté par Firwen (site web personnel) . Évalué à 5. Dernière modification le 22 août 2016 à 00:04.
Que le dieu du Pipe et de la stderr du grand Nord nous protège, je vois déja le NPM-marcheur-blanc et son armée de zombie codé en JS nous envahir.
(désolé)
# Tu vends du rêve
Posté par kna . Évalué à 6.
Bref, c'est l'équivalent de
ip -4 asous Linux.Pour afficher uniquement l'IP, je dois faire :
Je dois cependant reconnaitre que :
Par contre, la commande ne fonctionne pas avec powershell sous linux. Vu qu'il y a seulement le shell mais pas l'écosystème en dessous, beaucoup de choses ne doivent pas être fonctionnels.
En revanche, ça peut être intéressant pour récupérer des infos/métriques de machines windows depuis une machine linux. A voir à l'usage si c'est plus pratique/complet/intéressant que SNMP/NRPE ou que faire tourner munin/collectd sous windows.
[^] # Re: Tu vends du rêve
Posté par Kerro . Évalué à 3.
Si cette ligne de commande est la bonne, alors 102 % des arguments pro-PowerShell tombent à l'eau.
J'ai trouvé des lignes de commande similaires. Quelqu'un a plus simple/court ?
[^] # Re: Tu vends du rêve
Posté par theor . Évalué à 4.
Get-NetIPAddress | select ipaddress
Mais ces exemples sont un peu vains, le PowerShell est un langage orienté objets et plus haut niveau que Bash, avec une syntaxe plus clean.
A noter l'autocomplétion très bien foutue du PowerShell sous Windows 10, avec un équivalent ncurse proposant les différentes options et arguments. Faites ctrl-espace pour l'essayer, le menu est ensuite navigable au clavier.
Mieux, l'autocomplétion Intellisense. Par exemple :
$svc = get-service
$[svc]. < tab >
Et hop, toutes les méthodes et propriétés applicables aux objets de la variable s'affichent, ici des services.
Autre truc sympa, certaines méthodes de sysadmin. Exemple, supprimer tous les programmes contenant "runtime" :
$apps = Get-WmiObject win32_product | where name -match "runtime"
$apps | %{ $_.uninstall}
Dans cet exemple PS voit que $apps est de type array, juste l'invoquer va donc envoyer les entrées de l'array dans un pipe, dont la sortie sera énumérée par une boucle foreach (%).
$_ est la sortie du pipe, que l'on peut réutiliser autant que l'on souhaite.
Evidemment, on pourrait autant faire un
for i in $(rpm -qa | grep runtime); do rpm -e $i; done
Mais au niveau syntaxe, c'est autrement moins bien foutu.
Autre truc sympa en PS, le typage statique :
[int]$i = 42
$test = $42.tostring() + 2
$test
422
$test.GetType()
String
Et pour ne rien oublier, il y a aussi la longue liste d'alias linux. Faites un man ps pour le fun. :-)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4. Dernière modification le 21 août 2016 à 00:29.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tu vends du rêve
Posté par Kerro . Évalué à 4.
Ça donne ce résulat :
Donc il faut ajouter autre chose. Toujours pas terrible par rapport à un bête Bash pour obtenir une information basique du système.
[^] # Re: Tu vends du rêve
Posté par theor . Évalué à 0.
C'est le ipaddress qui te gêne ? Tu peux rajouter -expandproperty après select pour sortir le texte brut, sans les métadonnées de l'objet.
[^] # Re: Tu vends du rêve
Posté par kna . Évalué à 3.
Je crois que ce qui le gêne, c'est qu'il liste toutes les IP.
C'est équivalent à :
On peut même faire plus court en powershell :
Du coup j'explicite ma commande précédente :
Get-NetIPAddressaffiche les infos sur les interfaces réseaux–AddressFamily IPv4affiche uniquement les IP IPv4-AddressState Preferredaffiche uniquement les interfaces actives (exclu le ethernet non branché qui a quand même reçu une adresse APIPA)Dans mon example, j'obtiens donc 2 interfaces :
- l'interface loopback
- l'interface réseau active
Pour exclure loopback, je pipe le résultat avec
Where-Object { $_.InterfaceAlias -ne 'Loopback Pseudo-Interface 1' }J'obtiens alors uniquement l'interface active. Il ne reste plus qu'à extraire uniquement l'IP avec
().IpAddress(ou| Select IPAddress)La commande est alors celle que j'ai donné :
Le lecteur attentif remarquera que :
(« ? » est un alias pour Where-Object)
[^] # Re: Tu vends du rêve
Posté par Kerro . Évalué à 4.
On arrive à un degré d'illisibilité de la ligne tout à fait équivalent à celui de Bash.
Donc l'argument comme quoi PowerShell est bien plus lisible/facile/etc car plus haut niveau, je ne suis pas convaincu.
J'ai écrit 3 « programmes » en PowerShell d'une vingtaine de lignes utiles chaque, ils sont meilleurs qu'en Bash car ils permettent de gérer les exceptions, et ça c'est vraiment un énorme plus. Pour le reste, c'est kif-kif.
[^] # Re: Tu vends du rêve
Posté par pasBill pasGates . Évalué à 6.
Pour moi c'est pas vraiment la longueur de la ligne qui serait un avantage pour Powershell (bash serait probablement plus court), mais le fait que le coté objet donne une assurance que ce qu'un élèment veut recevoir du pipe est vraiment ce qu'il recevra, et pas la colonne d'avant - d'après parce que le format a changé ou que le texte avait un tab dedans qui a merdé le formattage, etc…
Ca fait des lignes plus longues à lire oui, mais plus claires et plus solides.
[^] # Re: Tu vends du rêve
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
Parles pour toi. Perso, je trouve cela imbitable… En plus il y a un mélange de CamelCase et de non camel case.
Dans la philosophie shell bash, tu passes effectivement par du traitement de texte dont dans 99% des cas, une commande sors du texte que tu vas traiter avec : sed, grep, awk, cut… Bref, cela revient toujours à faire a peu près la même chose. Pas besoin de connaitre un arbre de classe et de méthode, on travaille sur une analyse de texte.
Ensuite, l'objectif est de rester sur du script shell donc on ne fait pas un programme de 20000 lignes ;-) Quand tu commences à vectoriser les variables en bash (en gros simuler un dictionnaire), c'est qu'on va un peu loin…
[^] # Re: Tu vends du rêve
Posté par pasBill pasGates . Évalué à 2.
Question d'habitude.
Ben euh… tu sais qu'il y a la completion en PowerShell hein ?
Mais sinon, le problème de nouveau c'est pas le nombre de commandes ou le nombre d'options, c'est la fragilité du bousin à cause du formattage en texte plutôt qu'avec un format solide qui assure que tu ne lis pas la mauvaise colonne 3 mois plus tard à cause d'un tab ou espace mal placé.
[^] # Re: Tu vends du rêve
Posté par gnumdk (site web personnel) . Évalué à 2.
Oui, mais laisse tombé, c'est juste de la mauvaise fois… Un script shell(init de distro, installeur de soft proprio, …) qui se vautre à cause de la raison que tu énonces, j'en vois au moins un par an…
[^] # Re: Tu vends du rêve
Posté par barmic . Évalué à 6.
Le vrai problème c'est que des outils qui sérialisent des objets .Net sur stdout pour pouvoir les manipuler en powershell j'en vois pas (et j'ai pas l'impression que ça se soit beaucoup exporté hors de soft écris par MS…). Et awk/perl (pour moi) reste imbattable lorsque je dois traiter du texte (un jour j'aimerais me mettre à emacs pour ça…). Du coup hors des actions de base du système et peut être de la suite Office, il faut aller les chercher les utilitaires pour faire à peu prêt tout et n'importe quoi.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Tu vends du rêve
Posté par xcomcmdr . Évalué à 4.
Je préfère justement Ruby pour traiter du texte à Bash.
De ce que je comprends, Ruby est très proche de Perl. Du coup, je suis curieux de savoir ce qui te gêne dans Perl spécifiquement pour traiter du texte ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Tu vends du rêve
Posté par barmic . Évalué à 6.
Je ne connais pas très bien ruby, mais perl est vraiment bon pour ça. En fait c'est simple :
Je n'utilise pas perl en cli (sauf cas particulier) parce qu'il n'est pas très pratique je trouve (il est plus verbeux qu'un awk pour faire la même chose - même s'il a des idiomes très intéressant).
Globalement je fais bien plus de code glue que du traitement de texte donc je sors finalement rarement du shell (j'aimerais bien un peu plus me servir de perl - j'ai pas encore touché à perl6 -)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Tu vends du rêve
Posté par Frank-N-Furter . Évalué à 3.
Depending on the time of day, the French go either way.
[^] # Perl vs AWK
Posté par Arthur Accroc . Évalué à 2.
Tu as des exemples où perl serait nettement plus verbeux ?
À mon avis, man perlrun
Notamment les options -n -l -a -F (-p aussi, mais plutôt pour remplacer sed).
Alors OK, souvent, j’arrive à un résultat un poil plus long avec perl qu’avec awk (de quelques caractères seulement)… jusqu’à ce que j’aie besoin d’une fonctionnalité qu’awk n’a pas, et là…
Je me demande toujours pourquoi, à part contrainte de portabilité, des gens utilisent encore awk voire sed, alors qu’ils sont beaucoup plus limités que perl et pas plus faciles.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Perl vs AWK
Posté par GG (site web personnel) . Évalué à 2.
Je connais Awk, je ne connais pas Perl.
Donc j'ai quand même une nette tendance à choisir un langage que je connais.
Je ne suis pas contre d'apprendre un autre langage cela dit.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Perl vs AWK
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
On passe facilement d'Awk à Perl car Awk est une des bases d'inspiration de Perl ;-)
[^] # Re: Tu vends du rêve
Posté par Kerro . Évalué à 4.
Pour ma part les script PowerShell que j'ai vu, je les ai justement vus car ils se vautrent. Et pas seulement une fois par an.
Les Bash qui se vautrent, j'en ai vu dans les trucs proprios ou pas, mais pas dans les init des distributions (Ça arrivera forcément un jour, mais pour l'instant aucun qui ne se plante à cause de l'entrée qui aurait magiquement changée).
Voilà, c'est exactement ça :-)
[^] # Re: Tu vends du rêve
Posté par Sytoka Modon (site web personnel) . Évalué à 6. Dernière modification le 23 août 2016 à 12:03.
Oui ;-)
awk gère pas mal les espaces variables ;-)
Comment je fais un programme Fortran qui s'intègre bien dans PowerShell, comment je connecte tout cela avec mes scripts Perl ou OCamel ? Le paradigme du shell (Bash) et très simple : une entrée standard, deux sorties et un code entier de retour. C'est pas top top mais c'est universel. On enchaîne alors du traitement de texte pour faire de la glu sur tout cela. C'est pas objet, c'est pas typé mais c'est souple comme un langage humain et ça marche pas si mal depuis des dizaines d'année (pour certaines tâches précises).
Pour d'autres tâches, un langage plus typé est mieux. C'est pas pour rien que Larry Wall a crée Perl qui a donné un boom énorme ensuite à tous les langages de script.
Bref, je n'ai pas dis que PowerShell est de la merdiasse. Je dis juste que l'approche texte du shell Bash qui est orthogonale au langage de programmation "classique" est aussi très intéressante et assez universelle pour ce qu'on lui demande de faire ;-)
[^] # Re: Tu vends du rêve
Posté par fearan . Évalué à 4.
J'ai tendance à lui préférer read pour les cas simple quitte à changer l'IFS pour la commande :)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Tu vends du rêve
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Surtout que c'est une commande intégrée à Bash ;-)
[^] # Re: Tu vends du rêve
Posté par barmic . Évalué à 3.
Ça c'est si tu fais des scripts shell. Il m'arrive régulièrement d'avoir comme shabang
#!/bin/axk -f:)Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Tu vends du rêve
Posté par pasBill pasGates . Évalué à 1.
Ben le truc est qu'en Powershell tu peux faire les 2… objet, ou texte que tu parses. L'un n'empêche pas l'autre.
[^] # Re: Tu vends du rêve
Posté par Flavien . Évalué à 2.
[^] # Re: Tu vends du rêve
Posté par Flavien . Évalué à 1.
ConvertFrom-String
Le paper qui a servit à l'implémentation :
FlashExtract: A Framework for Data Extraction by Examples
Un tuto :
Using the ConvertFrom-String cmdlet to parse structured text
[^] # Re: Tu vends du rêve
Posté par Flavien . Évalué à 2.
"There are also a set of investments that we know we need to drive moving forward in this area. These include: Writing Cmdlets in Python and other languages"
Source : Windows PowerShell Blog - PowerShell on Linux and Open Source
[^] # Re: Tu vends du rêve
Posté par groumly . Évalué à 7.
Non pas que je pense que c'est un bon design, mais bon.
Les tabulations, formatage etc font partie de l'api publique d'un outil en ligne de commande. Le changer, c'est Peter cette api, et les auteurs le savent. Tout comme les mecs de chez ms ne vont pas changer le nom d'un champs public, les mecs de ps ne vont pas changer leur format de sortie. En tout cas, je l'espère.
Après, on peut discuter de la pertinence d'un format plain text comme api publique en 2016, du manque de typage, de la résistance au changement en prétendant qu'un awk des bois est mieux qu'une api de haut niveau, et du temps gâché à maintenir les tabulations et tout en plaçe, et t'aurais pas tord, mais risque de peter sur une mise à jour est pas vraiment un argument valable.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Tu vends du rêve
Posté par pasBill pasGates . Évalué à 1. Dernière modification le 24 août 2016 à 09:03.
Je ne parles pas d'un changement dans la sortie de l'application, mais le parsage de texte est super fragile car la séparation entre champs est très fragile.
Combien de ces softs te sortent des colonnes basées soit sur un espace ou un tab ? Imagine que le contenu d'une des colonnes contienne un tab ou un espace, pas ta prochaine commande dans le pipe va pas faire la diffèrence et verra une colonne de plus sur cette ligne…
Voila, c'est tout ce qu'il faut pour pêter le pipe, et c'est purement dû au fait que le formattage texte empêche une séparation forte entre les champs.
Et je ne parles pas du bordel que c'est de gèrer les nombres et faire du tri avec le formattage texte…
[^] # Re: Tu vends du rêve
Posté par fearan . Évalué à 2.
sort -n ?
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Tu vends du rêve
Posté par pasBill pasGates . Évalué à 0.
0xaef
[^] # Re: Tu vends du rêve
Posté par fearan . Évalué à 3.
sort -g ?
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Tu vends du rêve
Posté par pasBill pasGates . Évalué à 1.
Ben non… cf. cet exemple et la valeur 20400001000
```
ubuntu@ip-172-31-1-133:~$ cat val3.txt
400000000 _crt0
400000039 __newr0
400001C14 get_new_task_id
400001385 output_str_j1
200000020 reg1
200000038 reg4
20400001000 status
400001E0C t1
400001E70 t2
400001D14 taskid_to_ec_range
ubuntu@ip-172-31-1-133:~$ cat val3.txt |sort -k1 -g
400001C14 get_new_task_id
400001D14 task_id_to_ec_range
400001E0C t1
200000020 reg1
200000038 reg4
400000000 _crt0
400000039 _newr0
400001385 outputstrj1
20400001000 status
400001E70 t2
```
[^] # Re: Tu vends du rêve
Posté par fearan . Évalué à 2.
faut arrêter un minimum la mauvaise foi, pas que je critique ta religion, j'ai aussi tendance à la pratiquer, mais tu as demandé explicitement 0xaef, notation hexadécimale facilement reconnaissable; dans l'exemple que tu donnes.
Rajoute un 0x en début de chaque ligne tu auras le résultat escompté.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Tu vends du rêve
Posté par pasBill pasGates . Évalué à 1.
Ben tu commences à comprendre la problématique. J'ai filé des exemples de base pour montrer à quel point cela devient le bordel si le format change un tout petit peu. Tu remarqueras que dans le monde réel, c'est fréquemment plus compliqué que juste une colonne dont toutes les valeurs ont le même format.
Tu as un type de donnée (un entier), et selon sa représentation textuelle, il faut utiliser 32 méthodes diffèrentes pour le traiter : utiliser des options diffèrentes, utiliser des commandes diffèrentes,…
Rappelons la problématique : traitement de données arbitraire.
Les données, elles pourraient être une colonne d'entiers en base 10, ça pourrait aussi être 5 colonnes dont la 3ême est la colonne de chiffres avec des colonnes séparées par des espaces ou tabs, mais pas de bol, les 2 premières colonnes sont des colonnes de texte, avec potentiellement des tabs-espaces dans le contenu. Et là ben tu vas t'amuser à rajouter ton 0x ou sortir la 3ème colonne pour la mettre en 1er
Les données, tu contrôles par forcèment leur format, tu dois vivre avec. Alors oui, c'est "possible" de tout faire avec bash, mais mon dieu quel bordel et douleur pour le faire hors des cas simples.
[^] # Re: Tu vends du rêve
Posté par barmic . Évalué à 1.
Puis
Hum hum… Dans la vraie vie donc…
Dans la vraie vie on a soit pas le problème (on s'appuie sur des formats stables ou maîtrisé comme un log par exemple), soit on ne fait pas de traitement de données (le shell c'est d'abord de la glue) soit on est déjà dans un langage largement mieux que n'importe quel shell.
Donc dans la vraie vie, ça sert à quoi ? Une application concrète, hein ? Pas du big data non structuré.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Tu vends du rêve
Posté par pasBill pasGates . Évalué à 1.
Mais tu assumes que tu connais les données à l'avance, ce qui n'est évidemment pas le cas.
Là cette semaine, je m'amuses à devoir traiter des données qui sont le résultat d'opérations sur un fichier reçu d'une boite externe histoire de sortir des stats.
J'ai pas choisi le format, j'ai pas choisi quelles infos extraire, … J'ai essayé de le faire avec une ligne de pipes dans bash (le processus en question tourne sous Linux), j'ai perdu des cheveux et assez vite abandonné.
[^] # Re: Tu vends du rêve
Posté par barmic . Évalué à 4.
Si tu essaie de me faire dire que le shell n'est pas fait pour tout, ben oui et ?
Parser un fichier dont tu ne maitrise pas le contenu sera pas trivial quelque soit le langage. Le principal avantage d'autres langages sera qu'ils valident plus facilement les données (tu peut toujours valider en shell unix avec une expression régulière si tu veux avoir quelque chose plus fiable) et te remontent une erreur plus claire.
Comment aurait-tu fait en powershell pour l'exemple que tu donne ? Une étape de déserialisation de chaque ligne dans un objet ? Cette désrialisation s'appuie sur quoi pour faire de l'arbitraire ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Tu vends du rêve
Posté par pasBill pasGates . Évalué à 2.
Pas seulement, les autres langages ont aussi l'avantage que la déserialisation et conversion texte -> chiffre n'est à faire qu'une fois, au début.
Tout à fait, et évidemment cette étape initiale peut être plus ou moins complexe selon les données, mais une fois faite, je peux avoir 32 stages à mon pipe, et je n'ai plus à faire de conversion ou autres, c'est bien plus simple.
Et oui évidemment tu peux faire ça en python très bien, c'est ce que j'ai fait au final (flemme de passer le fichier sur Windows).
[^] # Re: Tu vends du rêve
Posté par fearan . Évalué à 1. Dernière modification le 26 août 2016 à 09:42.
quand je fais du shell, je connais le format à l'avance, c'est généralement un enchainement de commandes; si c'est pour traiter des fichiers textes, j'aurais tendance à utiliser perl ou python; pour ton exemple simple, le shell suffit.
tu n'es vraiment pas allé cherché loin.
et comment fais-tu la différence entre un nombre en octal/décimal/binaire/hexadécimal?
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Tu vends du rêve
Posté par pasBill pasGates . Évalué à 2.
La question n'est pas si je suis allé chercher loin. Bash est turing complet, au final tu peux écrire un browser web complet en bash si tu veux. C'était simplement de démontrer à quel point bash peut être douloureux à cause du traitement en texte de tout ce qui passe, à chaque étape
Si il n'a aucune indication, ca va être impossible évidemment, mais t'as typiquemment un préfixe. Et pour n'importe quel traitement un peu complexe tu fais simplement une première passe ou tu déserialise les données et les convertit pour les tourner en objet, et ensuite tu peux faire les traitement que tu veux de manière simple et sûre, là ou en bash tu es forcé de traiter du texte à chaque stage de ton pipe et te retaper de maudites conversion - parsing à chaque étape.
[^] # Re: Tu vends du rêve
Posté par fearan . Évalué à 2.
Oui enfin là on attends toujours ton exemple de comment faire en PS; comme il semblerai que tu ais agrégé des sources hors contrôle, je doute que tu puisse t'affranchir du parsing du texte pour le convertir en objet comme tu dis avec le risque de te planter lors de la rédaction de la desserialisation ou sérialisation; j'ajouterai que si pour trier un bête fichier texte sur une clé hexa, je dois écrire 5 lignes, c'est qu'il y a une couille quelque part.
Qu'entends tu par simple et sure? Pour prendre exemple sur le c++ ou le java c'est pas le fait qu'un langage soit objet à typage fort qui le rend simple ou sûr; à moins de blinder ton parseur, il est très probable que l'on trouve des solutions pour l'envoyer dans les choux, et là on se heurte au premier problème, si ça devient trop gros/compliqué, on passe par du perl/c/c++/python/ruby…
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Tu vends du rêve
Posté par pasBill pasGates . Évalué à 1.
Tout a fait, il faut faire ton parsing avec n'importe quel langage utilisé
En powershell, la ligne pour du hex serait :
Get-Content val.txt | sort {[convert]::toint64($_.split()[0],16)}
Je te dirais que c'est bien plus lisible et comprehensible, la function te lance une erreur si la conversion ne fonctionne pas, il est explicite dans la ligne que c'est de l'hex, tu n'as pas à devoir rajouter un '0x' en texte et risquer un problème si par hasard il y en a déjà un, la fonction supporte 0x 0X ou même pas de préfixe.
[^] # Re: Tu vends du rêve
Posté par fearan . Évalué à 3.
oh un truc comme ça alors :
ou si tu veux en perl (je pense qu'il y a moyen de faire plus simple, mais j'ai la flemme de chercher)
selon la version de perl il faudra potentiellement utiliser les bigint
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Tu vends du rêve
Posté par pasBill pasGates . Évalué à 0.
Ben oui bien sur que c'est faisable, je ne doutes pas de la faisabilité.
Mais regarde ta version bash, tu trouves ça pratique et simple?
[^] # Re: Tu vends du rêve
Posté par xcomcmdr . Évalué à 2.
Clairement, non.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Tu vends du rêve
Posté par fearan . Évalué à 3.
Pratique non, simple oui.
(sinon pour ceux que ça intéresse, y a encore une autre solution mixant perl et bash :
trouvé ici (en même temps que la question originale ) http://ask.systutorials.com/813/how-sort-file-hexadecimal-numbers-linux-using-sort-command (Mai 2014)
Manque encore une réponse python et awk, qui s'y colle.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Tu vends du rêve
Posté par barmic . Évalué à 5.
D'ailleurs ça n'a rien de spécifique au shell.
Tu as des données → tu les valides → tu les normalise → tu fais ton calcul dessus.
Je veux dire, même dans le plus puissant des langages si tu as une entrée tu va soit normaliser soit valider (soit les deux).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Tu vends du rêve
Posté par xcomcmdr . Évalué à 4.
Et encore, quand tu dois traiter / faire des tests sur des valeurs numériques, la manière de faire en script shell est à pleurer (première raison pour laquelle j'utilise Ruby à la place)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Tu vends du rêve
Posté par barmic . Évalué à 10.
Faut surtout arrêter le délire. les shell (que ce soit bash, zsh ou PowerShell) sont là pour faire du glue code.
Ça fait 30 ou 40 ans que le shell POSIX existe et on a une myriades de langages qui sont largement capable de faire tous les traitements que tu peux imaginer des dizaines de fois plus efficacement. La majorité des unix arrivent de base avec un perl et un python, hein ?
De la même manière PowerShell arrive avec .Net ce qui permet de faire du VB.Net et c'est tant mieux parce que la quantité de logiciels qui peuvent vraiment discuter en powershell est assez faible (encore une fois je n'en connais pas hors outils de base de windows et outils spécifiques) et il est impossible si tu n'a pas fait le choix à l'origine d'un langage compatible…
Bref les capacités de traitements de texte d'un shell servent la majorité du temps à manipuler du log. C'est un cas ou powershell est inefficace (du moins tant qu'il n'y a pas quelque chose comme Lumberjack qui se démocratise) et où tu as un format à peu près stable (pour une sortie donnée).
Bref tu peux troller comme tu veux, mais :
Bref c'est cool que PowerShell arrive sur linux, ça simplifie un peu le portage Windows → Linux, mais ça s'arrête là il est très loin de pouvoir changer quoi que ce soit à la donne des langages utilisés sur unix (ou linux).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Tu vends du rêve
Posté par pasBill pasGates . Évalué à 2.
Tu as raté un élément très important de Powershell :
il peut utiliser n'importe quel objet COM de manière naturelle, sans que l'application ait été prévue pour Powershell.
Et les interfaces COM dans les softs sous Windows sont super-répandues pour permettre l'administration, et cela depuis des siècles.
cf. Citrix par exemple : https://www.citrix.com/blogs/2008/07/25/powershell-and-mfcom-lets-get-started/
[^] # Re: Tu vends du rêve
Posté par barmic . Évalué à 3.
J'ai aussi vu que vmware expose une api powershell. C'est cool :-)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Tu vends du rêve
Posté par zurvan . Évalué à 7.
bah, j'imagine que Red Hat a mis Lennart Poettring pour travailler activement dessus, et d'ici 4-5 ans c'est powershell qui va remplacer bash sur toutes les distributions.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Tu vends du rêve
Posté par Sytoka Modon (site web personnel) . Évalué à 0.
Aucune chance, le CamelCase est vraiment dégueu !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.