Et l'option -I de xargs, par exemple, permet de faire la même chose que le {} du -exec de find.
Hum.. je me trompe si je dis que ce que tu dis n'est valable que pour l'option {} si l'on utilise \; et non \+ en fin de commande?
===== ===== ===== ===== ===== =====
Sinon, vu que tu as l'air de toucher ta bille (en plus d'expliquer bien, je veux dire), permets-moi de profiter de ce sujet pour te demander comment tu ferais pour appliquer un traitement à chaque champ d'un fichier tabulé?
Awm permets des merveilles (je l'ai découvert récemment) mais moi, j'ai (j'avais en fait, car j'ai "réussi", mais je pense que le code qui résulte de mes tentatives est dégueu, et je ne supporte pas ça) besoin de miracles :)
Je veux dire, awk nécessite d'incorporer un nouveau langage dans une chaîne d'appel, et moi, je t'avoue que je tente de garder le code que je génère maintenable. C'est à dire que j'essaies d'utiliser le moins de langages possibles (et quand je dois en combiner plusieurs, j'essaie de les isoler dans des fichiers de code source différents ), car pour moi multiplier les langages, c'est encore pire que de multiplier les chemins d'exécution (parce que c'est toujours un humain, qui se farcit les évolutions).
Basiquement, je réceptionne un fichier tabulé (csv, pour être exact, pas toujours tabulé mais ça se gère) pouvant contenir des string.
Comment ferais-tu pour transformer les string en question en 'string', en imaginant que i puisse être un espace (mais pas une tabulation).
Au début, j'ai pensé à printf, qui est censé déprécier echo, et il s'agit d'une fonction pour laquelle j'ai... un certain amour, étant d'origine un développeur C recyclé en C++ (mais je n'ai jamais pu me résoudre à abandonner scanf/printf... rien, strictement rien en C++ n'ofre leur puissance et leur efficience (des regex dans un lecteur d'entrée C++, de façon aussi simple que scanf? J'attend...), ou alors c'est hors standard, donc hors de question puisqu'un standard fait la même.).
Sauf que le printf de sh considère les espaces comme des 0,円 des séparateurs de champs. Je pense que j'ai raté quelque chose, mais quoi?
Du coups j'utilise régulièrement awk comme un workaround à printf, mais on ne peut pas piper les commandes aussi aisément... par exemple si l'on veut virer les espaces non significatifs.
J'ai un peu lu au sujet de IFS, mais il semble que cette variable ne s'applique qu'a la fonction read, les autres outils utilisant indiféremment -f, -F, ou rien du tout (le plus souvent?).
Dans l'idéal, j'essaie de restreindre mes scripts à l'usage du standard (que ce soit POSIX ou ISO, malgré que je ne soit pas un expert, pour moi une non-conformité non-voulue ou inutile au standards du moment est un bug), même si je dois perdre 10 minutes de plus pour ça (je gagnerai 2H dans 3 ans, après tout). Je pense que seule la conformité aux standards permets de rendre un code portable, et rendre un code portable est une façon de le rendre maintenable (si c'est portable, c'est supporté par plus de langages, donc compris par plus de développeurs/admins, donc plus maintenable).
Saurais-tu comment résoudre élégamment le cas la transformation de fichiers tabulés, aux champs contenant potentiellement des espaces, en, par exemple, requêtes d'insertion sql? (peut importe le type du champ de destination, admettons que tout soit casté automatiquement)
Si utiliser perl est la seule option... peut-être que je me motiverais à l'apprendre sérieusement.
[^] # Au sujet des séparateurs shell
Posté par freem . En réponse au sondage Les fonctions de bureau social, sémantique, indexation automatique des fichiers. Évalué à 2.
Merci pour cette explication!
Hum.. je me trompe si je dis que ce que tu dis n'est valable que pour l'option {} si l'on utilise \; et non \+ en fin de commande?
===== ===== ===== ===== ===== =====
Sinon, vu que tu as l'air de toucher ta bille (en plus d'expliquer bien, je veux dire), permets-moi de profiter de ce sujet pour te demander comment tu ferais pour appliquer un traitement à chaque champ d'un fichier tabulé?
Awm permets des merveilles (je l'ai découvert récemment) mais moi, j'ai (j'avais en fait, car j'ai "réussi", mais je pense que le code qui résulte de mes tentatives est dégueu, et je ne supporte pas ça) besoin de miracles :)
Je veux dire, awk nécessite d'incorporer un nouveau langage dans une chaîne d'appel, et moi, je t'avoue que je tente de garder le code que je génère maintenable. C'est à dire que j'essaies d'utiliser le moins de langages possibles (et quand je dois en combiner plusieurs, j'essaie de les isoler dans des fichiers de code source différents ), car pour moi multiplier les langages, c'est encore pire que de multiplier les chemins d'exécution (parce que c'est toujours un humain, qui se farcit les évolutions).
Basiquement, je réceptionne un fichier tabulé (csv, pour être exact, pas toujours tabulé mais ça se gère) pouvant contenir des string.
Comment ferais-tu pour transformer les string en question en 'string', en imaginant que i puisse être un espace (mais pas une tabulation).
Au début, j'ai pensé à printf, qui est censé déprécier echo, et il s'agit d'une fonction pour laquelle j'ai... un certain amour, étant d'origine un développeur C recyclé en C++ (mais je n'ai jamais pu me résoudre à abandonner scanf/printf... rien, strictement rien en C++ n'ofre leur puissance et leur efficience (des regex dans un lecteur d'entrée C++, de façon aussi simple que scanf? J'attend...), ou alors c'est hors standard, donc hors de question puisqu'un standard fait la même.).
Sauf que le printf de sh considère les espaces comme des 0,円 des séparateurs de champs. Je pense que j'ai raté quelque chose, mais quoi?
Du coups j'utilise régulièrement awk comme un workaround à printf, mais on ne peut pas piper les commandes aussi aisément... par exemple si l'on veut virer les espaces non significatifs.
J'ai un peu lu au sujet de IFS, mais il semble que cette variable ne s'applique qu'a la fonction read, les autres outils utilisant indiféremment -f, -F, ou rien du tout (le plus souvent?).
Dans l'idéal, j'essaie de restreindre mes scripts à l'usage du standard (que ce soit POSIX ou ISO, malgré que je ne soit pas un expert, pour moi une non-conformité non-voulue ou inutile au standards du moment est un bug), même si je dois perdre 10 minutes de plus pour ça (je gagnerai 2H dans 3 ans, après tout). Je pense que seule la conformité aux standards permets de rendre un code portable, et rendre un code portable est une façon de le rendre maintenable (si c'est portable, c'est supporté par plus de langages, donc compris par plus de développeurs/admins, donc plus maintenable).
Saurais-tu comment résoudre élégamment le cas la transformation de fichiers tabulés, aux champs contenant potentiellement des espaces, en, par exemple, requêtes d'insertion sql? (peut importe le type du champ de destination, admettons que tout soit casté automatiquement)
Si utiliser perl est la seule option... peut-être que je me motiverais à l'apprendre sérieusement.