Bonjour,
Ce forum m'a bien aidé jusque là dans ma découverte du shell mais là je bloque.
Je suis nouvellement admin réseau et j'ai 2 fichiers .csv que je veux fusionner.
identifiants2015.csv
$cat identifiants2015.csv
CLASSE,NOM,PRENOM,IDENTIFIANT,M.de P.
c601,A,antoine,antoine.a,4f56yg
c504,B,micheline,micheline.b,654pgh
identifiants2016.csv
$cat identifiants2016.csv
CLASSE,NOM,PRENOM,LOGIN,MOT DE PASSE
c601,Z,bob,bob.z,t954fd
c502,A,antoine,antoine.a,(déjà attribué)
c404,B,micheline,micheline.b,(déjà attribué)
Et je voudrais obtenir ceci en remplaçant "(déjà attribué)" par le mot de passe 2015.
logins2016_maj2016.csv
$cat logins_maj2016.csv
CLASSE,NOM,PRENOM,LOGIN,MOT DE PASSE
c601,Z,bob,bob.z,t954fd
c502,A,antoine,antoine.a,4f56yg
c404,B,micheline,micheline.b,654pgh
Je me doute qu'il y a quelque chose à faire avec awk mais je n'y arrive pas. La lecture dans les deux fichiers simultanément me pose problème.
Avez-vous une solution pour moi ?
Merci d'avance
# .
Posté par guppy . Évalué à 3.
Une solution possible :
Ca te convient ?
[^] # Re: .
Posté par Cam . Évalué à 2.
Testé et approuvé.
C'est parfait merci beaucoup guppy !
[^] # Re: .
Posté par Cam . Évalué à 2.
EDIT : j'ai parlé trop vite…et en même temps la question n'était pas posé correctement.
Dans le cas où mon fichier ne serait pas trié ou lorsque j'ai une classe qui a disparu en 2016 par rapport à 2015, cela ne marche pas.
identifiants2015.csv
$cat identifiants2015.csv
CLASSE,NOM,PRENOM,IDENTIFIANT,M.de P.
c303,X,john,john.x,6821ff
c601,A,antoine,antoine.a,4f56yg
c504,B,micheline,micheline.b,654pgh
identifiants2016.csv
CLASSE,NOM,PRENOM,LOGIN,MOT DE PASSE
c601,Z,bob,bob.z,t954fd
c502,A,antoine,antoine.a,(déjà attribué)
c404,B,micheline,micheline.b,(déjà attribué)
$grep -v '(déjà attribué)' class2016.csv | cat - <(join -t',' <(tail -n +2 class2016.csv | sort) <(tail -n +2 Id2015.csv | sort) -j 2 -o 1.1,1.2,1.3,1.4,2.5) >logins_maj2016.csv
join: /dev/fd/62:2 : n'est pas trié : c504,B,micheline,micheline.b,654pgh
[^] # Re: .
Posté par guppy . Évalué à 3.
Pour le tri :
Pour la classe il faut que tu précises. Si tu as ça :
Tu es censé avoir quoi en sortie ?
[^] # Re: .
Posté par Cam . Évalué à 2.
Ce grep convient mieux à ce que je veux faire malheureusement il y a encore des ajustements : j'ai des doublons (triplons, quadru-,etc.) incompréhensibles dans mon fichier original. Je commence à 1600 lignes et je finis avec plus de 7500 lignes.
Je galère à interpréter la ligne entière de la commande. Il faut que je me plonge dans les man…
J'explique ce que je veux.
En fait, normalement, si j'ai une entrée pour bob.z en 2015, j'ai forcément un "(déjà attribué)" en 2016.
$ cat 2015.csv
c000,Z,bob,bob.z,000000
$ cat 2016.csv
c999,Z,bob,bob.z,(déjà attribué)
En sortie, je dois avoir
c999,Z,bob,bob.z,000000
[^] # Re: .
Posté par guppy . Évalué à 2.
Pour l'exemple :
Le
tail -n +2fait disparaître la première ligne. Si l'entête est présente, il est nécessaire.Petite correction par rapport à mon message précédent, j'ai compris que l'identifiant de la ligne est le champ 4 (
bob.z). Dans mon précédent message j'avais supposé qu'il était composite (champs 2 à 4). Ça me paraissait pas clair, certainement parce qu'en SQL on a l'habitude de le faire figurer en premier.Donc si on considère que tes 2 fichiers ont une entête d'une ligne et que l'identifiant d'une ligne est le champ 4, pour l'exemple précédent ça donne :
Tu as un exemple ?
sortpermet d'enlever les doublons (uniqaussi d'ailleurs)[^] # Re: .
Posté par remico . Évalué à 1. Dernière modification le 11 mars 2017 à 16:39.
Grep permet de lister les lignes qui contiennent l'expression (déjà attribué) mais aussi de lister les lignes qui ne la contienne pas avec l'option -v.
A priori on a plus besoin des lignes (déjà attribué) sauf pour le changement de classe.
grep "(déjà attribué)" identifiants2016.csv > déjàattribué.csv
grep -v "(déjà attribué)" identifiants2016.csv > filtré.csv
Faut enlever l'en-tête du fichier filtré :
cat filtré.csv | sed "1 d" > filtré2.csv
Et l'ajouter au fichier 2015 :
cat identifiants2015.csv filtré2.csv > logins2016_maj2016.csv
Il ne reste plus qu'à actualiser les classes du fichier final à partir du fichier contenant les lignes déjà attribué.
Trouvé ici : http://bconnelly.net/working-with-csvs-on-the-command-line/
Pour virer les doublons éventuels avec awk :
awk '!a[$0]++' logins2016_maj2016.csv > final.csv
# avec awk
Posté par totof2000 . Évalué à 4. Dernière modification le 09 mars 2017 à 00:02.
Chez moi :
Après si tu veux être sur de l'ensemble des champs, tu peux les comparer un à un et logger les erreurs dans un fichier. Mais à ce stade c'est peut-être plus simple de le faire en ruby par exemple.
# Quand on n'a qu'un marteau tout ressemble à un clou
Posté par arnaudus . Évalué à 7.
Honnêtement, à part pour un exercice, je ne vois pas vraiment l'intérêt de tripatouiller des fichiers csv avec bash/awk/grep. Tous les langages interprétés un peu avancés ont des bibliothèques capables d'importer du csv, de stocker le contenu dans des variables adéquates, de les manipuler, et de réécrire les fichiers.
D'expérience, quand on commence à tripoter à l'arrache le contenu de fichiers, on a très rapidement des problèmes majeurs (notamment, aucune assurance sur la conformité du fichier après modification), et on va avoir des algos de plus en plus complexes pour faire des opérations triviales (additionner deux colonnes, transposer un tableau par exemple).Du coup, perl, ruby, python, R, on s'en fout un peu, mais à mon avis il faut changer d'outil.
[^] # Re: Quand on n'a qu'un marteau tout ressemble à un clou
Posté par totof2000 . Évalué à 1.
Une installation qui ne dispose pas de ces fameux "langages avancés" par exemple (ya pas que Redhat/Centos dans la vie, et ya pas que des distributions Linux).
[^] # Re: Quand on n'a qu'un marteau tout ressemble à un clou
Posté par arnaudus . Évalué à 5.
Et tu manipulerais des fichiers .csv (pour t'interfacer avec un tableur?) sur des systèmes qui n'ont pas perl ou python?
On pourrait le faire en assembleur, aussi.
[^] # Re: Quand on n'a qu'un marteau tout ressemble à un clou
Posté par totof2000 . Évalué à 2.
Ben oui, c'est bien plus courant que tu ne le crois. T'as juste à déposer les fichiers (via ssh, ou ce que tu veux).
Non, ton assembleur serait différent selon l'architecture cible. L'avantage de script shell, s'il est bien écrit, c'est que tu peux l'exécuter sur des infras hétérogènes (tant du Linux que de l'AIX, du Solaris, ou un truc un peu plus exotique n'ayant pas de langage avancé installé). Au pire tu as quelques adaptations à faire selon ton environnement, mais ça reste parfois plus simple que de passer du temps à faire installer et maintenir une version de python sur l'ensemble d'un parc hétérogène.
[^] # Re: Quand on n'a qu'un marteau tout ressemble à un clou
Posté par Michaël (site web personnel) . Évalué à 1.
Donc du coup, les solutions vaporware qui n'existent pas sont mieux que celles proposées?
Quelqu'un qui connaît bien awk s'est donné la peine de prendre 5 minutes pour écrire une solution qui marche et qui tient sur 4 lignes, j'ai un peu du mal à y voir une preuve de l'inadéquation de awk pour faire ce traitement.
[^] # Re: Quand on n'a qu'un marteau tout ressemble à un clou
Posté par mathle . Évalué à 7.
C'est certainement utile de connaître awk mais dans le cas présent, la solution donnée répond à un exemple très simple (quelques lignes à traiter) mais ne m'apparaît ni réutilisable ni compréhensible par un non-expert. D'ailleurs des problèmes semblent arriver à plus grande échelle.
La solution tient sur 4 lignes, la belle affaire ! Si c'est pour le challenge, très bien, je suis impressionné (par la maîtrise que certains ont de ces outils). Mais bon, si c'est pour mettre à jour une liste de mots de passe …
[^] # Re: Quand on n'a qu'un marteau tout ressemble à un clou
Posté par Michaël (site web personnel) . Évalué à 2.
L'idée que la solution doit être réutilisable et utilisée sur d'autres fichiers que les deux montrés est inventée par toi.
C'est pas un challenge, c'est une mesure de simplicité.
Encore une fois, ce qu'on peut voir c'est un visiteur paisible et constructif qui a proposé une solution plausible en awk et deux autres visiteurs qui préfèrent pontifier sur ce qu'il faudrait beaucoup mieux utiliser un langage de plus haut niveau, que ce na doit pas bien être compliqué, mais qui se gardent bien de joindre le geste à la parole.
[^] # Re: Quand on n'a qu'un marteau tout ressemble à un clou
Posté par mathle . Évalué à 2.
Alors là, je rigole !!
Tiens, d'ailleurs l'auteur indique :
Simplicité … il faut quand même que ça réponde au besoin. Or, le jeu de données (4 lignes) est extrêmement réduit par rapport aux fichiers réels (1600 lignes) et on apprend par la suite qu'il y avait d'autres choses à connaître (sans qu'elles ne soient initialement exprimées).
L'auteur n'a d'ailleurs pas répondu aux questions de guppy qui avait présenté son aide … et où on voyait au passage que ça n'était pas si simple que tu ne veux le voir. Et il faut évoquer le fait qu'il veut merger des centaines de mots de passe, perso à sa place je ne prendrais pas ça à la légère.
Pour terminer, je n'incrimine pas l'utilisateur qui a posté un exemple en awk, l'auteur de la question initiale a d'ailleurs orienté là-dessus (même si à mon avis en partant de l'outil a priori approprié sans le connaître vraiment, au lieu de partir de données plus complètes et des besoins et contraintes), c'est juste que de mon point de vue, ce genre de solution convient plus pour dépanner, et que pour le besoin en question, ça n'est pas adapté (même si ça serait sans doute faisable, tout comme certains font des applis énormes avec Excel).
[^] # Re: Quand on n'a qu'un marteau tout ressemble à un clou
Posté par Michaël (site web personnel) . Évalué à 2.
Un jour où on rit est une belle journée, non? :)
Simplicité veut dire beaucoup de choses, dans mon propos c'est “simple” comme dans “pas beaucoup d'instructions”. Et puis ça n'a aucune intérêt de pinailler là-dessus, je continue de voir une seule solution plausible postée elle est en awk et elle est courte. C'est tout ce que je veux dire et c'est un simple constat.
Ce n'est pas une raison pour en tirer des déductions hasardeuses!
Qui parle de prendre ça à la légère? Ce n'est pas parcequ'une solution utilise un langage plus puissant qu'elle est intrinsèquement meilleure: il y a plein de gens qui n'écrivent pas leurs programmes en OCaml et je peux concevoir qu'ils aient leurs raisons.
Encore une fois, tout ce dont il est question ici, c'est de faire un traitement bien déterminé une fois sur deux fichiers bien déterminés. On peut appeler ça dépanner ou pas, ça ne change rien à l'affaire. Dans cette situation il est parfaitement légitime d'utiliser “le plus petit programme” qui fait le travail (pas maintenable, pas débogable, pas extensible ne sont ici pas des inconvénients).
Je ne suis le premier à privilégier une solution bien structurée et généralisable si elle semble nécessaire, mais utiliser sed et awk (ou ce qu'on veut d'autre) pour effectuer des traitement uniques sur des fichiers c'est le pain quotidien de l'utilisateur d'Unix que je suis, et je n'ai pas la place dans mon salon pour encadrer et afficher toutes les descriptions de traitement!
[^] # Re: Quand on n'a qu'un marteau tout ressemble à un clou
Posté par arnaudus . Évalué à 4.
Oui, parce que les solutions proposées sont indéboggables et ne relèvent que de bricolages «quick & dirty», le genre de choses que tu utilises quand tu n'as besoin que de faire quelque chose une fois et oublier à jamais. Et encore, il ne faut pas que ça soit quelque chose d'important.
Ce que le PO souhaite faire, importer deux fichiers csv qui contiennent des données partiellement chevauchantes, chercher un certain pattern dans le deuxième fichier, et remplacer ce pattern sous certaines conditions avec des données du premier fichier. Enfin, il souhaite écrire un csv valide. Tu as vu la quantité de trucs nouveaux qui arrivent à chaque question? «Ah oui, c'est possible que des IDs soient dupliqués», «il est possible que certains ne correspondent pas», etc. Clairement, il faut quelques dizaines de lignes de code dans un vrai langage de script, qui importe les deux fichiers, vérifie s'ils sont valides (bon nombre de colonnes, bons types de données, etc), retire, gère, ou fait quelque chose pour les ID dupliqués ou manquants, éventuellement balance des warnings "Ligne 3251 ID invalide", fait les remplacements souhaités, et génère le fichier valide en sortie.
Après, on peut discuter éternellement sur l'adéquation d'un outil à faire quelque chose. Si l'argument c'est simplement que c'est possible, alors oui, mais c'est aussi possible en Brainfuck. Si ça doit tenir sur 4 lignes incompréhensibles et illisibles, alors oui, c'est possible, mais il faut faire confiance et c'est du code jetable (c'est peut-être ce qui était demandé, hein). Ça n'est pas comme ça que je ferais, mais j'admet tout à fait que c'est une culture qui existe en info et il faut vivre avec.
La question, c'est un peu la même que si tu appelles un plombier pour une fuite. Tu as peut-être des mecs qui te collent un chewing-gum sur la fuite, qui foutent un coup de scotch autour et qui scellent au briquet en t'expliquant que ça polymérise le chewing-gum et que tu vois, ça ne fuit plus. En 5 minutes il a fini, et peut-être qu'en effet, ça va tenir 20 ans. Mais il n'y a pas besoin d'être un gourou de la plomberie pour voir que ça n'est pas comme ça qu'on devrait faire. C'est sûr que de couper l'eau, faire des soudures, des tests, en profiter pour changer les joints et consolider au cas où les autres endroits où ça pourrait fuir dans les années qui viennent, ça prend plus de temps et ça coûte plus cher.
[^] # Re: Quand on n'a qu'un marteau tout ressemble à un clou
Posté par Michaël (site web personnel) . Évalué à 3.
Et qu'est-ce qui te laisse penser que ce n'est pas le cas? L'OP parle de deux fichiers et d'un traitement, rien de plus.
Oui mais personne n'a publié de solution ni en Brainfuck (ça ne suffisait pas l'assembleur) ni en Python ou autre chose et quelqu'un a publié quelque chose qui résout le problème posé, et tient en 4 lignes de awk. Après évidemment qu'un langage de plus haut niveau permet de déboguer ou de faire évoluer le programme. Rien dans le contexte ne laisse penser que ça peut avoir une importance ici, pourtant tu décides de lui en donner.
La question c'est une personne qui a une fois besoin de faire un traitement sur deux fichiers bien précis.
[^] # Re: Quand on n'a qu'un marteau tout ressemble à un clou
Posté par totof2000 . Évalué à 6.
Ben la solution que je propose n'est pas moins indeboggable pour qui connait awk que ne le serait une solution en python pour quelqu'un qui connait python. Si tu veux débogger, apprends à utiliser awk. Maintenant, il est vrai que j'aurais pu présenter ça sur plusieurs lignes pour rendre la solution plus lisible. Ca pourrait donner ça :
Initialement j'ai fait un truc simple en 4 lignes parce que le PI ne précise pas si c'est du one shot ou un truc à maintenir dans la durée, mais il y a moyen de mettre tout ça dans un fichier texte lisible qui sera interprêté par awk. Pour faire un truc plus générique, on peut variabiliser le nom du fichier de l'année précédente :
On passe ensuite les variables via l'option -v de awk (je ne me rappelle plus exactement la forme exacte, ça doit être un truc du genre -v var=value et on peut en mettre plusieurs mais je sais plus comment). Et pour l'utilisateur, on peut encapsuler ça dans un script sh qui masquera les appels à awk. Pour quelqu'un qui connait awk, c'est très lisible. En tout cas plus lisible que les solutions à base de cut, join et sed.
Je pourrais également m'arranger pour que le séparateur de champ en sortie soit le même que le séparateur de champ en entrée (en faisant un truc du genre OFS=FS mais je ne me rappelle plus exactement quelle est la bonne variable, un man awk pourrait répondre). Comme indiqué on pourrait aussi faire des vérifications plus poussées sur les divers champs et logger des erreurs sur stdout ou vers un autre fichier, tout en restant très lisible.
Dans l'absolu, awk est assez simple : il faut juste savoir comment il fonctionne : juste à comprendre les blocs BEGIN, END, et la façon dont awk parse chaque ligne. Ensuite ya qu'a lire la doc pour savoir comment utiliser les fonctions interne (ou écrire ses propres fonctions).
Pour info, j'ai déjà mis ce genre de truc en place sur un parc hétérogène, géré par des entités différentes, qui pouvaient pour certains avoir du python d'installé, pour d'autres du Perl, pour d'autres aucun des deux (et c'était imposé par la politique de sécurité de la boite). Les versions de Python ou Perl étaient différentes, et le seul dénominateur commun était les commandes standards du shell (et encore avec awk faut se méfier car les diverses implémentations peuvent avoir des comportements différents).
Sinon, si tu as lu ma proposition jusqu'au bout, tu remarqueras que j'ai invité le PI à une autre approche s'il s'aperçoit que son problème est plus compliqué.
# et après...portabilité et création de cartes
Posté par Cam . Évalué à 1.
Merci à guppy et à totof pour le temps passé.
Ce que j'utilise est la solution de totof qui est simple précise et qui suffit à faire ce que je veux.
Merci guppy je comprend mieux le shell grâce aux commandes proposées.
Pour le débat c'est intéressant mais je n'ai pas le temps de lire, je trouve ça un peu stérile. J'ai eu une solution tout à fait correct qui fait parfaitement ce que je veux POINT Mon objectif est de faire des scripts simples à l'utilisation et à la modification pour les personnes qui me remplaceront.
Si arnaudus a la solution en mieux (portable sur windows par exemple je suis preneur), je planche dessus.
Je planche aussi sur la manière de créer des fichiers "imprimables"- type carte d'identité - à partir de mon nouveau .csv avec des solutions natives des 2 OS (ou au max avec un petit logiciel open source).
Mise en page :
NOM : Z PRENOM : Bob CLASSE : c999
IDENTIFIANT : bob.z MOT DE PASSE : 000000
Avec plusieurs profils par A4 tant qu'à faire.
Un petit peu d'aide serait encore la bienvenue.
[^] # Re: et après...portabilité et création de cartes
Posté par totof2000 . Évalué à 2. Dernière modification le 11 mars 2017 à 01:23.
Ma solution awk devrait fonctionner avec un environnement cygwin, peut être avecun git shell. Par contre pourle reste, la solution awk risque de devenir très compliquée. Il va tefalloir de l'artillerie lourde.
Je ne suis pas un fan de XML à tout va. La seule excepton va a SVG qui est un format que je trouve très bien fait et qui pourrait t'aider dans ce cas : tu crées un template SVG, ensuite tu passes ton template et ton fichier csv dans une moulinette qui te génèrera les feuilles A4 dont tu as besoin en positionnant et remplissant ton template autant de fois que tu le veux sur tafeuille A4. Par contre, manipuler du XML avec awk, ce serait possible mais il y a des outils mieux adaptés. Et dans ce cas je rejoins Arnaudus : Autant CSV est un format très simple à parser avec des outils plus ou moins basique comme awk, autant le XML avec awk risque d'être plus laborieux (mais tu as lancé un défi qui pourrait m'intéresser). je vais voir si je trouve un peu de temps ce week-end pour tenter quelque chose.
Ma suggestion : créer un template svg avec un utilitaire tel que inkskape, puis manipuler le template avec un langage de script (exemple ruby) qui permettrait de parcourir l'arbre XML pour changer les champs que tu auras générés par les informations de ton CSV
[^] # Re: et après...portabilité et création de cartes
Posté par GuieA_7 (site web personnel) . Évalué à 2.
Autant je suis fan de Inkscape et SVG (ma page perso parle pour moi), autant je serai plutôt parti vers du PDF.
Après je ne sais pas dans quelle mesure ça serait compatible avec la contrainte assez floue "des solutions natives des 2 OS".
[^] # Re: et après...portabilité et création de cartes
Posté par totof2000 . Évalué à 2.
L'avantage de SVG, c'est que certains langages contiennent de quoi traiter du XML dans leur bibliothèque standard (exemple : https://ruby-doc.org/stdlib-2.4.0/libdoc/rexml/rdoc/index.html). Pour du PDF, il faudra passer par une installation complémentaire (genre pip), ce qui n'est pas forcément simple sous Windows par exemple.
J'essaierai de poster quelque chose ce soir …
[^] # Re: et après...portabilité et création de cartes
Posté par GuieA_7 (site web personnel) . Évalué à 2.
Oui tout à fait (c'est le cas de Python également, même si ce qui est dans la lib standard n'est pas le mieux).
D'un autre côté, Python n'est pas non plus installé de base sous Windows (ni dans toutes les distro Linux). Si on a droit d'installer Python sous Linux, il se trouve que sous Ubuntu, reportlab est packagé aussi (donc je ne sais pas ce qui, pour l'auteur du message initial, est 'natif' là dedans). Et sous Windows l'utilisateur devrait installer Python (ou Ruby/Perl/Cygwin/…) ; et dans ce cas on doit pouvoir packager son programme, en embarquant reportlab, avec py2exe, ce qui au final revient à installer un seul programme simple également (mais ça demande un petit travail de packaging, alors que l'installeur Python pour Windows est déjà fait—mais 'pip' nécessaire pour reportlab comme tu le soulignes) ; du coup là non plus je ne sais pas ce qui est "acceptable".
Bon courage.
[^] # Re: et après...portabilité et création de cartes
Posté par Cam . Évalué à 1.
Ok, je vois que je vais encore en apprendre pas mal.
Je me lance.
Merci je vous tiens au courant.
[^] # Re: et après...portabilité et création de cartes
Posté par remico . Évalué à 1.
J'aurai pensé à la fonction publipostage de libreoffice qui est bien multiplatforme mais pas petit logiciel, au cas où il y a un tuto ici :
https://forum.openoffice.org/fr/forum/viewtopic.php?p=218303#p218303
En petit logiciel mais pas multiplatforme Glabels :
https://laurdbayrone.wordpress.com/2015/11/22/glabels-le-publipostage-facile/
[^] # Re: et après...portabilité et création de cartes
Posté par totof2000 . Évalué à 3.
Bon: finalement le SVG c'est faisable, mais il faudra passer par un convertisseur intermédiaire pour générer les images (sinon on va imprimer un texte balisé qui ne sera pas exploitable). Sous Linux c'est pas trop un problème. Sous Windows ça peut le devenir.
Je continue à regarder.
[^] # Re: et après...portabilité et création de cartes
Posté par NeoX . Évalué à 2.
le mot clef pour ce que tu veux faire s'appelle un publipostage
à partir d'un tableau CSV/XLS vers une feuille de traitement de texte (ODS ou DOC)
tu trouveras plein de tuto sur internet à ce sujet, c'est user friendly, puisque c'est en interface graphique (word/excel ou libreoffice)
# Work in progress
Posté par Cam . Évalué à 1.
Donc pour résumer :
[^] # Re: Work in progress
Posté par totof2000 . Évalué à 2. Dernière modification le 12 mars 2017 à 10:49.
Pour windows tu peux installer cygwin qui peut te permettre d'exécuter la commande awk. sinon pour le publipostage LibreOfficen tu dois pouvoir scripter quelque chose (mais je sais pas comment).
[^] # Re: Work in progress
Posté par NeoX . Évalué à 2.
comme signaler, tu peux installer cygwin pour avoir ensuite un bash et awk pour executer ton script.
sinon tu peux aussi redevelopper ton script en python qui doit ensuite etre portable sur pas mal de plateforme qui inclue python.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.