Le jour ou on trouvera en standard grep, awk, sed, md5sum, sha1sum, wget, wput, wc, mail, sendmail, bzip2, less, more, gzip, lzma, tar, cut, tail, head, su, sudo, at, find, zip, bc, base64, netcat, diff, patch, ln, mkfifo, cat, ssh, scp, sftp, gpg, uniq et xargs, on en reparlera, d'accord ?
Il y a boire et à manger dans cette liste, tu mélange pêle mêle, manipulation de fichiers, outils de compressions, et outils réseaux.
ça dépend de l'usage de chacun, faut pas déconner (et je suis 100% linux chez moi). Il y en a marre de se payer des outils antediluvien sous pretexte qu'ils sont "essentiels" alors que la vraie raison, c'est que des générations d'admin ont fait des scripts illisibles avec.
En plus un bash, c'est plus d'un méga en mémoire au lancement, quand on voit la faune des scripts de démarrage sous linux, et que ce mécanisme a très peu évolué, on peut se poser des questions sur les non-performances entrainées au boot.
Un système écrit sur un langage plus évolué avec une seule VMbytecode serait plus light en ressources et plus rapide.
xargs est une vaste blague, c'est une commande qui a été crée après coup pour pouvoir récupérer les argument à travers un pipe, et comme elle n'a jamais évoluée, quand tu as un espace dans tes noms de fichiers (maintenant j'utilise des espaces dans mes noms de fichiers), ça te fait planter ton beau one-liner.
Au boulot, j'utilise cygwin pour avoir des commandes unix, et comme en général, c'est pour analyser des logs, ou trouver des méthodes, mon outil numéro est "grep" (plus rapide que "rechercher" windows).
Autant j'apprécie le fait d'avoir ces commandes pour rapidement filtrer des fichiers pour trouver le problème à la main qui m'intéresse, autant si je devais automatiser une chaîne de traitement, je ne la ferais pas en sh/csh/ksh/bash (je dis ça parce que tu cites AWK, et tu ne crée pas un filtre AWK pour le plaisir par exemple)
Avec ces outils, tu te retrouves avec trop de problèmes avec les séparateurs (espace tabulation) pour faire des solutions robuste.
Si ce que je dis était faux, PERL n'aurait pas eu autant de succès, car il comble beaucoup de manque de la programmation shell où ce n'est pas intuitif (arithmétique, somme des lignes de plusieurs fichiers par exemples, collections/tableaux, ...)
Les commande unix de BASE (au sens unix d'une commande qui ne fait qu'une seule chose mais qui la fait bien), mangez en, autant il ne faut pas s'arcbouter religieusement dessus.
Maintenant la ligne de commande "dos", c'est pire, maintenant je ne connais pas le powershell.
P.S. dd est effectivement une commande essentielle de mon toolkit pour récupérer une image disk ou au contraire éclater en DUR la table des partitions rapidement.
[^] # Re: Windows est rancunier
Posté par darkleon . En réponse à la dépêche Une année sans (MS) Windows : achever la conversion d'un utilisateur de Windows. Évalué à 1.
Le jour ou on trouvera en standard grep, awk, sed, md5sum, sha1sum, wget, wput, wc, mail, sendmail, bzip2, less, more, gzip, lzma, tar, cut, tail, head, su, sudo, at, find, zip, bc, base64, netcat, diff, patch, ln, mkfifo, cat, ssh, scp, sftp, gpg, uniq et xargs, on en reparlera, d'accord ?
Il y a boire et à manger dans cette liste, tu mélange pêle mêle, manipulation de fichiers, outils de compressions, et outils réseaux.
ça dépend de l'usage de chacun, faut pas déconner (et je suis 100% linux chez moi). Il y en a marre de se payer des outils antediluvien sous pretexte qu'ils sont "essentiels" alors que la vraie raison, c'est que des générations d'admin ont fait des scripts illisibles avec.
En plus un bash, c'est plus d'un méga en mémoire au lancement, quand on voit la faune des scripts de démarrage sous linux, et que ce mécanisme a très peu évolué, on peut se poser des questions sur les non-performances entrainées au boot.
Un système écrit sur un langage plus évolué avec une seule VMbytecode serait plus light en ressources et plus rapide.
xargs est une vaste blague, c'est une commande qui a été crée après coup pour pouvoir récupérer les argument à travers un pipe, et comme elle n'a jamais évoluée, quand tu as un espace dans tes noms de fichiers (maintenant j'utilise des espaces dans mes noms de fichiers), ça te fait planter ton beau one-liner.
Au boulot, j'utilise cygwin pour avoir des commandes unix, et comme en général, c'est pour analyser des logs, ou trouver des méthodes, mon outil numéro est "grep" (plus rapide que "rechercher" windows).
Autant j'apprécie le fait d'avoir ces commandes pour rapidement filtrer des fichiers pour trouver le problème à la main qui m'intéresse, autant si je devais automatiser une chaîne de traitement, je ne la ferais pas en sh/csh/ksh/bash (je dis ça parce que tu cites AWK, et tu ne crée pas un filtre AWK pour le plaisir par exemple)
Avec ces outils, tu te retrouves avec trop de problèmes avec les séparateurs (espace tabulation) pour faire des solutions robuste.
Si ce que je dis était faux, PERL n'aurait pas eu autant de succès, car il comble beaucoup de manque de la programmation shell où ce n'est pas intuitif (arithmétique, somme des lignes de plusieurs fichiers par exemples, collections/tableaux, ...)
Les commande unix de BASE (au sens unix d'une commande qui ne fait qu'une seule chose mais qui la fait bien), mangez en, autant il ne faut pas s'arcbouter religieusement dessus.
Maintenant la ligne de commande "dos", c'est pire, maintenant je ne connais pas le powershell.
P.S. dd est effectivement une commande essentielle de mon toolkit pour récupérer une image disk ou au contraire éclater en DUR la table des partitions rapidement.