[RESOLU] Quel caractère de séparation est le plus pertinent

philoeil · Le 28/01/2021, à 19:07

Bonjour,
Existe-t-il un caractère pertinent qui ne risque pas de se retrouver dans les chemins de dossiers, fichiers ?

Je m'explique un peu :

Dans un script réalisé sur le traitement de sauvegardes et recherche de doublons j'ai utilisé
dans des substitutions de paramètres traitant des chemins de dossier avec sed le caractère de séparation @
dans des fichiers resultats j'ai séparé les résultats par le caractère §.

Jusqu'à présent je n'ai pas détecté de problèmes mais je sens bien que ce n'est pas parfait
puisque ces 2 caractères ne sont pas interdits et peuvent se retrouver das des noms de répertoires ou fichier (même si sans doute peu fréquent)

J'ai trouvé | et !
mais pour une mauvaise expérience avec *
je préfère demander ....

Merci

Dernière modification par philoeil (Le 06/02/2021, à 16:14)

Watael · Le 28/01/2021, à 19:15

autant que je sache, sur Linux, (parce que ce n'est pas vrai pour certains UNIX) seul le caractère NULL (\0) n'est pas autorisé.

Zakhar · Le 28/01/2021, à 20:04

Réponse courte : ça dépend !

Détails :
.... du filesystem !

Regarde là : https://en.wikipedia.org/wiki/Compariso … le_systems

Par exemple, en ext4 (standard Linux) tout est autorisé dans un nom de fichier sauf zéro binaire et / réservé aux séparations de répertoire.

Mais il y a tout un tas d'autres filesystems qui ont bien d'autres restrictions.

Après, ça peut être très exotique mais expliqué. Par exemple j'ai écrit un "filesystem" pour le service de stockage 1fichier.com, ça se trouve ici :
[1fichier] "Montez" votre stockage 1fichier en une commande simple !

De façon "normale", le montage "raw" expose les limitations de jeu de caractères imposées par la solution de stockage, c'est à dire en plus des classiques \0 et /, interdit $ < > / et `, avec en plus ' et " pour les répertoires. Pas moyen de faire autrement puisque 1fichier.com interdit cela dans les noms de fichier/répertoire.
Le mode par défaut fait une "traduction" pour l'utilisateur puisse utiliser l'ensemble des caractères "standard linux" (tout sauf / et \0) au détriment de la longueur maximale du nom.

Donc en fait, tu peux considérer que (hélas !) tous les caractères sont autorisés !... sauf / et \0... mais ça ne va pas beaucoup t'aider pour ton "sed" !..

Dernière modification par Zakhar (Le 28/01/2021, à 20:06)

Hizoka · Le 29/01/2021, à 09:36

Salut,

Pour éviter ce genre de problème avec sed, je fais ce genre de chose :

ma_variable="bla bla bla § bla bla"

# On change le caractère qui sert à sed par -~@~- ou tout autre de suite improbable sans impacte sur ce qu'on demande à sed
ma_variable="${ma_variable//§/-~@~-}" 

# On fait le traitement sed en utilisant § comme séparateur
retour_sed=$(sed ...)

# On remet le caractère spécial
retour_sed="${retour_sed//-~@~-/§}"

Watael · Le 29/01/2021, à 13:28

pas besoin de transcrire, puis retranscrire.
il suffit de protéger, dans la variable, le caractère de séparation choisi :

$ maVar='/chemin/fichier'
$ sed 's/'"${maVar//\//\\/}"'/remplacement/' fichier

Hizoka · Le 29/01/2021, à 22:12

Encore mieux ! Merci

philoeil · Le 30/01/2021, à 07:33

Bonjour,
Merci Hizoka
Merci Zakhar pas encore eu le temps de tout lire pour comprendre

Merci Watael, je n'arrive pas à mettre en œuvre correctement ton conseil ou est mon erreur ?

Le fichier CheminProjet :

$ cat ProjetT6_Racine 
TailleMax=1000000
NombreFichiersMax=1000
FAD=ActionDoublons.txt
Info1=/home/phil/Documents/JeCodeShell/TrouvDoublons/JournalT6SavTestSauvegarde/11111.SauvegardeInfo1.txt

le script test

#/!bin/bash
# parametres
CheminProjet="./ProjetT6_Racine"
TitreParam="Info1="
TmpVarParam="/home/phil/Documents/JeCodeShell/TrouvDoublons/JournalT6SavTestSauvegarde/OOOOO.SauvegardeInfo1.txt"

 sed -i "s@^$TitreParam.*@$TitreParam$TmpVarParam@" "$CheminProjet"
 cat "$CheminProjet"
TmpVarParam="/home/phil/Documents/JeCodeShell/TrouvDoublons/JournalT6SavTestSauvegarde/XXXXX.SauvegardeInfo1.txt"
 sed 's/'"${^$TitreParam.*//\//\\/}"'$TitreParam$TmpVarParam' "$CheminProjet"
 cat "$CheminProjet"

L'erreur

./ExtractLignes1.sh: ligne 10: ${^$TitreParam.*//\//\\/} : mauvaise substitution

Merci

Hizoka · Le 30/01/2021, à 12:48

Ta commande ${^$TitreParam.*//\//\\/} est mauvaise.

Il y a un $ de trop: ${^$TitreParam.*//\//\\/}
A quoi sert le ^ ? ${^$TitreParam.*//\//\\/}
A quoi sert le .* ? ${^$TitreParam.*//\//\\/}

en bash tu ne peux faire qu'une action à la fois :
${TitreParam//\//\\/} : remplacement de caractéres
${TitreParam^} : Mise en majuscule de la 1ere lettre
Impossible de combiner les 2.

philoeil · Le 30/01/2021, à 17:03

Bonjour Hizoka,
J'ai essayé de mutiples combinaisons sans succès avec ou sans le $ et en déplaçant ^ et .* toujours en echec pour comprendre le message de Watael

Hizoka a écrit :

A quoi sert le ^ ? ${^$TitreParam.*//\//\\/}

A essayer de reproduire ce qui est fait ici

sed -i "s@^$TitreParam.*@$TitreParam$TmpVarParam@" "$CheminProjet"

c'est à dire chercher dans le fichier $CheminProjet la chaine $TitreParam en début de ligne

Hizoka a écrit :

A quoi sert le .* ? ${^$TitreParam.*//\//\\/}

A essayer de reproduire ce qui est fait ici

sed -i "s@^$TitreParam.*@$TitreParam$TmpVarParam@" "$CheminProjet"

c'est à dire chercher dans le fichier $CheminProjet la chaine $TitreParam suivi d'une suite de caractères quelconque

Pour mieux illustrer par un exemple
Le $CheminProjet de départ

TailleMax=1000000
NombreFichiersMax=1000
FAD=ActionDoublons.txt
Info1=/home/phil/Documents/JeCodeShell/TrouvDoublons/JournalT6SavTestSauvegarde/ZZZZZZZ.SauvegardeInfo1.txt

Le résultat du script avec l'erreur

$ ./ExtractLignes1.sh 
TailleMax=1000000
NombreFichiersMax=1000
FAD=ActionDoublons.txt
Info1=/home/phil/Documents/JeCodeShell/TrouvDoublons/JournalT6SavTestSauvegarde/OOOOO.SauvegardeInfo1.txt

sed: -e expression n°1, caractère 13: option inconnue pour « s »
TailleMax=1000000
NombreFichiersMax=1000
FAD=ActionDoublons.txt
Info1=/home/phil/Documents/JeCodeShell/TrouvDoublons/JournalT6SavTestSauvegarde/OOOOO.SauvegardeInfo1.txt

phil@phil-G750JH:~/Documents/JeCodeShell/TestSED$

La 1ere commande marche

sed -i "s@^$TitreParam.*@$TitreParam$TmpVarParam@" "$CheminProjet"

et l'essai de la seconde échoue

 sed "s/^{$TitreParam//\//\\/}.*/$TitreParam$TmpVarParam/" "$CheminProjet"

sed: -e expression n°1, caractère 13: option inconnue pour « s »

Hizoka · Le 30/01/2021, à 18:23

Presque :

sed "s/^${TitreParam//\//\\/}.*/${TitreParam//\//\\/}$TmpVarParam/" "$CheminProjet"

Attention à ne pas confondre la variable (${TitreParam//\//\\/}) et ce que l'expression régulière (^ et .*).

Et il faut bien remplacer tes caractères dans les 2 parties de ton sed.

C'est un chouille plus clair visuellement avec des arobases je trouve.

sed "s@^${TitreParam//@/\\@}.*@${TitreParam//@/\\@}$TmpVarParam@" "$CheminProjet"

Dernière modification par Hizoka (Le 30/01/2021, à 18:28)

philoeil · Le 30/01/2021, à 18:38

Bonjour Hizoka

Hizoka a écrit :

# On fait le traitement sed en utilisant § comme séparateur
retour_sed=$(sed ...)

Chez moi cela ne marche pas

Si dessous des tests avec différents caractères de séparation certains marchent § echoue

Mais le quel choisir ?
@ non trop présent
§ me semblait bien mais echec
! ou | je me demande si peu poser un problème ?

#/!bin/bash
# parametres
CheminProjet="./ProjetT6_Racine"
TitreParam="Info1="
TmpVarParam="/home/phil/Documents/JeCodeShell/TrouvDoublons/JournalT6SavTestSauvegarde/OOOOO.SauvegardeInfo1.txt"

 sed -i "s@^$TitreParam.*@$TitreParam$TmpVarParam@" "$CheminProjet"
 echo -e "\n resultat de l'opération sed delimitateur @ :"
 cat "$CheminProjet"
TmpVarParam="/home/phil/Documents/JeCodeShell/TrouvDoublons/JournalT6SavTestSauvegarde/XXXXX.SauvegardeInfo1.txt"

 sed -i "s|^$TitreParam.*|$TitreParam$TmpVarParam|" "$CheminProjet"
 echo -e "\n resultat de l'opération sed :delimitateur |"

cat "$CheminProjet"
TmpVarParam="/home/phil/Documents/JeCodeShell/TrouvDoublons/JournalT6SavTestSauvegarde/33333333.SauvegardeInfo1.txt"

 sed -i "s"!"^$TitreParam.*"!"$TitreParam$TmpVarParam"!"" "$CheminProjet"
  echo -e "\n resultat de l'opération sed delimitateur ! :"

cat "$CheminProjet"
TmpVarParam="/home/phil/Documents/JeCodeShell/TrouvDoublons/JournalT6SavTestSauvegarde/4444444.SauvegardeInfo1.txt"

 sed -i "s§^$TitreParam.*§$TitreParam$TmpVarParam§" "$CheminProjet"
  echo -e "\n resultat de l'opération sed  delimitateur §:"

cat "$CheminProjet"

Resultat avec l'erreur sur le te § :

$ ./SED§ErrV1.sh 

 resultat de l'opération sed delimitateur @ :
TailleMax=1000000
NombreFichiersMax=1000
FAD=ActionDoublons.txt
Info1=/home/phil/Documents/JeCodeShell/TrouvDoublons/JournalT6SavTestSauvegarde/OOOOO.SauvegardeInfo1.txt


 resultat de l'opération sed :delimitateur |
TailleMax=1000000
NombreFichiersMax=1000
FAD=ActionDoublons.txt
Info1=/home/phil/Documents/JeCodeShell/TrouvDoublons/JournalT6SavTestSauvegarde/XXXXX.SauvegardeInfo1.txt


 resultat de l'opération sed delimitateur ! :
TailleMax=1000000
NombreFichiersMax=1000
FAD=ActionDoublons.txt
Info1=/home/phil/Documents/JeCodeShell/TrouvDoublons/JournalT6SavTestSauvegarde/33333333.SauvegardeInfo1.txt

sed: -e expression n°1, caractère 2: delimiter character is not a single-byte character

 resultat de l'opération sed  delimitateur §:
TailleMax=1000000
NombreFichiersMax=1000
FAD=ActionDoublons.txt
Info1=/home/phil/Documents/JeCodeShell/TrouvDoublons/JournalT6SavTestSauvegarde/33333333.SauvegardeInfo1.txt

Zakhar · Le 30/01/2021, à 21:24

@Hizoka, je ne pense pas que vous arriverez avec sed à un truc à 100%. Même en remplaçant le caractère par -~@~- quid si cette séquence existe déjà dans un nom de fichier !

@Wattael, oui, ça a l'air de fonctionner effectivement !
Inconvénient 1, c'est un "bashism"
Inconvénient 2, on refait la substitution à chaque application de sed.

Donc en fait, la solution "simple" et non bashism ne serait-elle pas simplement d'écrire :

$ maVar='\/chemin\/fichier'

$ subst='/chemin/fichier=abcd'
$ echo "$subst" | sed "s/${maVar}/foobar/"
foobar=abcd

A moins que $maVar soit effectivement aussi une variable (lue dans un fichier, en paramètre d'entrée, etc...), auquel cas, pour éviter le "bashism", on peut la transformer une première fois avec un sed dans une variable "escapée".

Dernière modification par Zakhar (Le 30/01/2021, à 21:26)

Watael · Le 30/01/2021, à 21:33

inconvénient1: et alors ? il est interdit d'utiliser bash ? c'est pas comme les accolades inutiles.
inconvénient2 : SI on utilise plusieurs fois la variable

var='/bla/bla'
varSed="${var//\//\\/}"
sed 's/'"$varSed"'/remplacement/' fichier

et au pire

varSed=$(echo "$var" | sed 's@/@\\/@g')

Dernière modification par Watael (Le 30/01/2021, à 21:34)

philoeil · Le 30/01/2021, à 22:04

Bonjour,

Cela avance mais ce n'est pas encore bon

Je Cherche l'erreur ....
Le script test

#/!bin/bash
# parametres
CheminProjet="./ProjetT6_Racine"
TitreParam="Info1="
TmpVarParam="/home/phil/Documents/JeCodeShell/TrouvDoublons/JournalT6SavTestSauvegarde/OOOOO.SauvegardeInfo1.txt"

 sed -i "s@^$TitreParam.*@$TitreParam$TmpVarParam@" "$CheminProjet"
 echo "result substitution 00000"
 cat "$CheminProjet"

 TmpVarParam="/home/phil/Documents/JeCodeShell/TrouvDoublons/JournalT6SavTestSauvegarde/XXXXX.SauvegardeInfo1.txt"
# sed "s/^{$TitreParam//\//\\/}.*/$TitreParam$TmpVarParam/" "$CheminProjet"
sed "s/^${TitreParam//\//\\/}.*/${TitreParam//\//\\/}$TmpVarParam/" "$CheminProjet"
echo "result substitution XXXXXXX"
cat "$CheminProjet"

TmpVarParam="/home/phil/Documents/JeCodeShell/TrouvDoublons/JournalT6SavTestSauvegarde/333333.SauvegardeInfo1.txt"
# sed "s/^{$TitreParam//\//\\/}.*/$TitreParam$TmpVarParam/" "$CheminProjet"
sed "s@^${TitreParam//@/\\@}.*@${TitreParam//@/\\@}$TmpVarParam@" "$CheminProjet"
echo "result substitution 3333333"

cat "$CheminProjet"

Le resultat

$ ./ExtractLignes1.sh 
result substitution 00000
TailleMax=1000000
NombreFichiersMax=1000
FAD=ActionDoublons.txt
Info1=/home/phil/Documents/JeCodeShell/TrouvDoublons/JournalT6SavTestSauvegarde/OOOOO.SauvegardeInfo1.txt

sed: -e expression n°1, caractère 20: option inconnue pour « s »
result substitution XXXXXXX
TailleMax=1000000
NombreFichiersMax=1000
FAD=ActionDoublons.txt
Info1=/home/phil/Documents/JeCodeShell/TrouvDoublons/JournalT6SavTestSauvegarde/OOOOO.SauvegardeInfo1.txt

TailleMax=1000000
NombreFichiersMax=1000
FAD=ActionDoublons.txt
Info1=/home/phil/Documents/JeCodeShell/TrouvDoublons/JournalT6SavTestSauvegarde/333333.SauvegardeInfo1.txt

result substitution 3333333
TailleMax=1000000
NombreFichiersMax=1000
FAD=ActionDoublons.txt
Info1=/home/phil/Documents/JeCodeShell/TrouvDoublons/JournalT6SavTestSauvegarde/OOOOO.SauvegardeInfo1.txt

Merci

Watael · Le 30/01/2021, à 22:37

d'abord, {$ ???
ensuite, fais attention à la variable que tu modifies et qui contient (ou non) le caractère à protéger.

philoeil, ouvre les yeux : un seul œil semble ne pas suffire.

Dernière modification par Watael (Le 31/01/2021, à 13:50)

Zakhar · Le 31/01/2021, à 10:03

Watael a écrit :

inconvénient1: et alors ? il est interdit d'utiliser bash ?

Non, ce n'est pas interdit bien sûr, encore que le shell par défaut d'Ubuntu ne soit plus bash depuis des lustres, mais dash.
Il y quand même un différence de performance nettement mesurable au profit de dash sur des "gros" scripts. Je te laisse faire le test !..
Par contre là où tu comprends ta douleur d'utiliser des "bahism" c'est quand tu n'as pas la possibilité d'utiliser bash, comme c'était le cas quand j'ai tenté de porter des scripts sur mon Synology (qui utilise ash et ne dispose pas de bash !)
Là tu te dis : "si seulement j'avais écrit en shell portable ! (POSIX)"
Depuis que j'ai eu à faire cet "exercice" de portage sur Synology, j'évite autant que faire ce peut les "bashism". Certains n'ont cependant pas d'équivalent comme le process substitution, et cette "feature" peut effectivement rendre possible des choses qui autrement nécessitent de faire "les pieds au mur" !..

Donc je fais en sorte que tous mes scripts (dans la mesure du possible/raisonnable) commencent pas :

#! /bin/sh

Watael a écrit :

varSed=$(echo "$var" | sed 's@/@\\/@g')

Oui, ça c'est portable, et ce n'est guère plus long à écrire que la ligne de conversion de la variable brute en "bashism" !

Dernière modification par Zakhar (Le 31/01/2021, à 10:12)

Watael · Le 31/01/2021, à 13:55

soit, mais quand le posteur utilise bash, tu t'astreins tout de même à la stricte observance de la norme POSIX ?

Zakhar · Le 31/01/2021, à 14:26

Le posteur a visiblement envie d'apprendre ce qui est parfait. Il utilise sans doute bash "par défaut".

Quand ce n'est pas plus compliqué (une ligne sed au lieu d'une substitution "bashism"), autant utiliser la version portable non ?

Bien sûr dans les cas où un "process substitution" est indiqué, là comme c'est unique, ça fait du sens de limite la compatibilité.

Regarde par exemple un script que j'avais fait il y a 10 ans... pour traiter le format "XtremSplit" qui était utilisé à l'époque sur certains forums, et évidemment sans outil Linux (encore que l'exécutable fonctionnait sous Wine). Le script en question fonctionnait en fait 2 fois plus vite que l'original, merci les pipe/tee, etc...

Et il était qualifié avec tout un tas de NAS lesquels ne possédaient pas bash !..

Par contre les utilitaires GNU sont quand même bien indispensables car le "hack" pour le faire fonctionner avec la version simplifié de busybox est quand même bien affreux !

Bon, tout ça est de l'histoire ancienne (2010 !) je crois bien que plus personne n'utilise Xtremsplit, et heureusement !

Watael · Le 31/01/2021, à 14:38

quand je n'utilise pas de bashisme, je mets un /bin/sh en shebang,
mais ça ne dure jamais très longtemps.

Zakhar · Le 31/01/2021, à 14:45

Si c'est un petit truc juste pour toi et juste pour ta machine sans idée de portage ailleurs, c'est toi qui vois, ça ne fait guère de différence et n'a guère d'importance !

Sur les "gros" scripts, notamment avec beaucoup de boucles, dash fait une différence notable en performance.

Et toutes les commandes que tu passes sur ton terminal, sont en fait exécutées par bash qui est le défaut pour le terminal (même si dash est le shell par défaut).

Dernière modification par Zakhar (Le 31/01/2021, à 14:46)

Hizoka · Le 31/01/2021, à 18:15

sh limite plein de trucs quand même...
Ca t'oblige à utiliser echo + pipe :

varSed=$(echo "$var" | sed 's@/@\\/@g')

alors qu'on peut faire

varSed=$(sed 's@/@\\/@g' <<< "$var")

en bash.

Ça dépend vraiment de ce que tu veux faire, un truc portable ou limité à bash... mais comme tu le signales les terminaux utilises bash par défaut sur ubuntu... donc ça pousse à l'utiliser.

Oui, ça c'est portable, et ce n'est guère plus long à écrire que la ligne de conversion de la variable brute en "bashism" !

Ouais mais c'est pas la même rapidité d’exécution :

test="Super texte"
time for ((x=1; x<1000; x++))
do
    resultat=$(echo "$test" | sed "s/Super/Petit/")
done
# ~ 3s

time for ((x=1; x<1000; x++))
do
    resultat="${test//Super/Petit}"
done
# ~ 0.01sec

Et comme l'expliquer Watael dans un topic du forum, le but de dash est d'acceler le démarrage, une fois fait, plus de gros intérêt à l'utiliser s'il permet moins de chose (même si on pert en portabilité) en fonction du but recherché.
Si on veut quelques chose de portable, il faut le signaler dans la demande, à mon sens

Dernière modification par Hizoka (Le 31/01/2021, à 18:23)

Watael · Le 31/01/2021, à 19:20

alors qu'un peut faire

eh ben non ! on utilise le Remplacement de paramètre !

Hizoka · Le 31/01/2021, à 21:19

Oui bien sur mais pas dans le cas d'un sed plus poussé.

philoeil · Le 04/02/2021, à 19:15

Bonjour,

Pour le moment mon script fonctionne avec la ligne

sed -i "s|^$TitreParam.*|$TitreParam$TmpVarParam|" "$CheminProjet"

Je n'ai vraiment pas compris comment mettre en oeuvre le message de Watael

Je suis curieux de voir la solution fonctionner, je ne la trouve pas

watael a écrit :

pas besoin de transcrire, puis retranscrire.
il suffit de protéger, dans la variable, le caractère de séparation choisi :
$ maVar='/chemin/fichier'
$ sed 's/'"${maVar//\//\\/}"'/remplacement/' fichier

Merci

Hizoka · Le 04/02/2021, à 19:53

Bah, je te l'ai donné en message 10 :

sed -i "s|^${TitreParam//|/\\|}.*|${TitreParam//|/\\|}$TmpVarParam|" "$CheminProjet"

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 28/01/2021, à 19:07

[RESOLU] Quel caractère de séparation est le plus pertinent

#2 Le 28/01/2021, à 19:15

Re : [RESOLU] Quel caractère de séparation est le plus pertinent

#3 Le 28/01/2021, à 20:04

Re : [RESOLU] Quel caractère de séparation est le plus pertinent

#4 Le 29/01/2021, à 09:36

Re : [RESOLU] Quel caractère de séparation est le plus pertinent

#5 Le 29/01/2021, à 13:28

Re : [RESOLU] Quel caractère de séparation est le plus pertinent

#6 Le 29/01/2021, à 22:12

Re : [RESOLU] Quel caractère de séparation est le plus pertinent

#7 Le 30/01/2021, à 07:33

Re : [RESOLU] Quel caractère de séparation est le plus pertinent

#8 Le 30/01/2021, à 12:48

Re : [RESOLU] Quel caractère de séparation est le plus pertinent

#9 Le 30/01/2021, à 17:03

Re : [RESOLU] Quel caractère de séparation est le plus pertinent

#10 Le 30/01/2021, à 18:23

Re : [RESOLU] Quel caractère de séparation est le plus pertinent

#11 Le 30/01/2021, à 18:38

Re : [RESOLU] Quel caractère de séparation est le plus pertinent

#12 Le 30/01/2021, à 21:24

Re : [RESOLU] Quel caractère de séparation est le plus pertinent

#13 Le 30/01/2021, à 21:33

Re : [RESOLU] Quel caractère de séparation est le plus pertinent

#14 Le 30/01/2021, à 22:04

Re : [RESOLU] Quel caractère de séparation est le plus pertinent

#15 Le 30/01/2021, à 22:37

Re : [RESOLU] Quel caractère de séparation est le plus pertinent

#16 Le 31/01/2021, à 10:03

Re : [RESOLU] Quel caractère de séparation est le plus pertinent

#17 Le 31/01/2021, à 13:55

Re : [RESOLU] Quel caractère de séparation est le plus pertinent

#18 Le 31/01/2021, à 14:26

Re : [RESOLU] Quel caractère de séparation est le plus pertinent

#19 Le 31/01/2021, à 14:38

Re : [RESOLU] Quel caractère de séparation est le plus pertinent

#20 Le 31/01/2021, à 14:45

Re : [RESOLU] Quel caractère de séparation est le plus pertinent

#21 Le 31/01/2021, à 18:15

Re : [RESOLU] Quel caractère de séparation est le plus pertinent

#22 Le 31/01/2021, à 19:20

Re : [RESOLU] Quel caractère de séparation est le plus pertinent

#23 Le 31/01/2021, à 21:19

Re : [RESOLU] Quel caractère de séparation est le plus pertinent

#24 Le 04/02/2021, à 19:15

Re : [RESOLU] Quel caractère de séparation est le plus pertinent

#25 Le 04/02/2021, à 19:53

Re : [RESOLU] Quel caractère de séparation est le plus pertinent

Pied de page des forums