en même temps, y a tellement d'outils pour faire ça que c'est jamais vraiment une galère. cut et awk (éventuellement aidés de head ou tail) répondent à la majorité des besoins en la matière. Ensuite, des regex relativement simple permettent de régler la quasi totalité des problèmes restant à coup de sed et de grep. Il faut un peu de temps pour se familiariser à ces outils polyvalents, mais ensuite, tout coule de source
Je concois tres bien que c'est faisable, le probleme c'est le boulot necessaire pour le faire et comment verifier que tu ne laisses pas passer plus qu'il faut a travers ton filtre ou moins qu'il faut. Avoir un stream texte t'oblige forcement a ecrire un petit parser a l'aide de cut, tail et autres, effort sujet a erreurs et tests par l'essai. Passer par des methodes fait que tu sais que tu as la donnee demandee et rien d'autre, c'est direct.
Ce que tu appelles inefficacité ne correspondrait-il pas plutôt à un certain manque d'aisance en la matière (ce qui, entendons nous bien, n'est absolument pas un reproche) ?
Pas vraiment non, je connais mieux bash que powershell :+)
Simplement d'un point de vue conceptuel l'un amene un traitement structure des donnees alors que l'autre laisse cet effort a l'utilisateur.
En te lisant, ma première réaction, c'était de me dire "mince, c'est vrai ça". Du coup, je me suis mis à chercher des exemples de commandes pour lesquelles l'internationalisation pourrait poser problème ... et en fait, je ne trouve pas ... A dire vrai, ce sont souvent les messages d'erreurs qui sont internationalisés, ce qui ne pose aucun problème dans un script.
Ben tu prends la commande ls par exemple, l'affichage de la date de modif tu fichier quand tu fais un 'ls -l' depend de la locale.
C'est pas par hasard que ls est dote de 234 options pour specifier le format de date a afficher, les colonnes, l'ordre, etc... C'est pour compenser les faiblesses du systeme de pipe et permettre d'ecrire des scripts, mais c'est super lourd, bonne chance pour te souvenir de toutes ces options et je suis pret a te parier que l'admin moyen n'y fait pas attention.
Disclaimer, je ne connais pas du tout Powershell. Cependant, a priori, il me semble que fonctionner avec des objets et des méthodes, ça demande autant de mémoire que de retenir les options des différentes commandes Unix. Je me trompe ?
Les commandes sont plus simples car il n'y a pas d'options pour cacher telle ou telle colonne, trier, utiliser des tabs plutot que des espaces, etc... dans chaque commande(cf. ls). Options qui sont la uniquement dans le but de faciliter l'ecriture de scripts, alors qu'avec Powershell il y a une commande de tri qui peut trier sur n'importe quel attribut de la donnee et l'equivalent de ls est bien plus simple.
[^] # Re: Ce n'est pas tout
Posté par pasBill pasGates . En réponse au journal Microsoft donne 100000 dollars à la fondation Apache. Évalué à 2.
Je concois tres bien que c'est faisable, le probleme c'est le boulot necessaire pour le faire et comment verifier que tu ne laisses pas passer plus qu'il faut a travers ton filtre ou moins qu'il faut. Avoir un stream texte t'oblige forcement a ecrire un petit parser a l'aide de cut, tail et autres, effort sujet a erreurs et tests par l'essai. Passer par des methodes fait que tu sais que tu as la donnee demandee et rien d'autre, c'est direct.
Ce que tu appelles inefficacité ne correspondrait-il pas plutôt à un certain manque d'aisance en la matière (ce qui, entendons nous bien, n'est absolument pas un reproche) ?
Pas vraiment non, je connais mieux bash que powershell :+)
Simplement d'un point de vue conceptuel l'un amene un traitement structure des donnees alors que l'autre laisse cet effort a l'utilisateur.
En te lisant, ma première réaction, c'était de me dire "mince, c'est vrai ça". Du coup, je me suis mis à chercher des exemples de commandes pour lesquelles l'internationalisation pourrait poser problème ... et en fait, je ne trouve pas ... A dire vrai, ce sont souvent les messages d'erreurs qui sont internationalisés, ce qui ne pose aucun problème dans un script.
Ben tu prends la commande ls par exemple, l'affichage de la date de modif tu fichier quand tu fais un 'ls -l' depend de la locale.
C'est pas par hasard que ls est dote de 234 options pour specifier le format de date a afficher, les colonnes, l'ordre, etc... C'est pour compenser les faiblesses du systeme de pipe et permettre d'ecrire des scripts, mais c'est super lourd, bonne chance pour te souvenir de toutes ces options et je suis pret a te parier que l'admin moyen n'y fait pas attention.
Disclaimer, je ne connais pas du tout Powershell. Cependant, a priori, il me semble que fonctionner avec des objets et des méthodes, ça demande autant de mémoire que de retenir les options des différentes commandes Unix. Je me trompe ?
Les commandes sont plus simples car il n'y a pas d'options pour cacher telle ou telle colonne, trier, utiliser des tabs plutot que des espaces, etc... dans chaque commande(cf. ls). Options qui sont la uniquement dans le but de faciliter l'ecriture de scripts, alors qu'avec Powershell il y a une commande de tri qui peut trier sur n'importe quel attribut de la donnee et l'equivalent de ls est bien plus simple.
Petit exemple pris sur microsoft.com :
Get-ChildItem c:\scripts | Sort-Object extension,length
Te liste le repertoire, et trie par extension, puis par taille.
Get-EventLog system -newest 5 | Sort-Object eventid
Te liste les 5 evenements du log systeme les plus recents et les trie par event ID.
Sous Linux, selon ce que tu veux chaque commande a ses propres options de tri, etc... et c'est vite le bordel.