shell sort numérique [Résolu]

[jack-ft]

Bonjour et au secours,

je cherche depuis plusieurs heures et n'arrive pas à trouver comment faire un tri numérique

Je voudrais trier par ordre croissant les entiers des 2 premières colonnes (séparées par des virgules):

Code :

1
2
3
4
5
6
7
8
9
10
11
# cat toto
1,1
1,4
1,2
1,3
1,5
1,6
1,8
1,10
1,9
2,2

Code :

1
2
3
4
5
6
7
8
9
10
11
# cat toto | sort --field-separator=',' -n -k 1,2
1,1
1,2
1,3
1,4
1,5
1,6
1,8
1,9
2,2
1,10

Je voudrais notamment sortir "1,10" avant "2,2" !!!

Oumgourje?

J'utilise une version assez ancienne (RedHat 3), sans particularité linguistique:

Code :

1
2
3
4
5
6
7
8
9
 
# sort --version
sort (coreutils) 4.5.3
Written by Mike Haertel and Paul Eggert.
 
Copyright (C) 2002 Free Software Foundation, Inc.
 
# env | fgrep --color=auto LC | wc -l
      0

Merci d'avance

)jack(

[frp31]

c'est parce que tu trie l'ensemble des colonnes 1 et 2 que le résultat est bizare.

Code :

sort --field-separator="," -n k 1,1 fichier

sort bien le 1,10 avant 2,2

Code :

1
2
3
4
5
 
1,10
1,2
2,2
2,3

vires ton cat inutile pour voir si c'est pas lui qui provoque un problème d'interprétation ...

[Alek-C]

Il faut définir les 2 clés séparément :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
$ cat toto.sort
1,1
1,4
1,2
1,3
1,5
1,6
1,8
1,10
1,9
2,2
$ sort -t',' -n -k1,1 -k2,2 toto.sort
1,1
1,2
1,3
1,4
1,5
1,6
1,8
1,9
1,10
2,2

(première clé = premier champ, deuxième clé = deuxième champ)

Edit : pour être précis, si tu fais -k1, alors il prend la clé de la position 1 jusqu'à la fin de la ligne, si tu fais -k1,2 alors la clé contient les positions 1 et 2 ensemble, et j'ai l'impression qu'avec -n sort ignore tout simplement les caractères non numériques : 2,2 devient 22 et 1,7 devient 17 etc comme on le voit ici :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ cat toto.sort
1,1
1,a
19
1,8
1,10
17
2,2
$ sort -t',' -nk1 toto.sort
1,a
1,1
17
1,8
19
2,2
1,10

[jack-ft]

Bon, ben déjà, merci d'avoir répondu aussi rapidement!

Envoyé par frp31

c'est parce que tu trie l'ensemble des colonnes 1 et 2 que le résultat est bizarre.

Mais, c'est précisément ce que je veux!

Je veux un tri majeur sur la première colonne et, lorsque la première ne discrimine pas, c'est-à-dire lorsque les valeurs de la première colonne sont identiques, je veux un tri sur la 2ème colonne.

Code :

sort --field-separator="," -n k 1,1 fichier

sort bien le 1,10 avant 2,2

Code :

Ben, j'aimerais ben, mais ça l'fait point!

Code :

1
2
3
4
5
6
7
8
9
10
11
# sort -n -k 1,1 toto
1,1
1,2
1,3
1,4
1,5
1,6
1,8
1,9
2,2
1,10

vires ton cat inutile pour voir si c'est pas lui qui provoque un problème d'interprétation ...

Désolé, mais je ne peux même pas imaginer que cela fasse la moindre différence!

Code :

1
2
3
4
5
6
# man sort
SYNOPSIS
       sort [OPTION]... [FILE]...
 
DESCRIPTION
       Write sorted concatenation of all FILE(s) to standard output.

D'après le man, les fichiers sont bien optionnels et probablement concaténés avant le tri.

Et, en plus, dans mon code, ce ne serait pas bienvenu car le pseudo fichier "toto" est la sortie d'un pipe que je veux justement trier en mémoire avant de le stocker dans un fichier (bon, d'accord, ce ne serait pas un gros fichier et je pourrais le supprimer ensuite (mais, de toute façon, ça ne change rien au résultat!)).

Entre-temps, j'ai continué mes investigations et penche plutôt pour un problème linguistique, car si je remplace la virgule par un autre séparateur, comme une virgule suivie d'une espace ou un simple point-virgule, ça marche enfin!

Code :

1
2
3
4
5
6
7
8
9
10
11
# cat toto | sed -e 's:,:;:' | sort --field-separator=';' -n -k 1 -n -k 2 | sed -e 's:;:,:'
1,1
1,2
1,3
1,4
1,5
1,6
1,8
1,9
1,10
2,2

Et pourtant, je n'ai aucune variable LC positionnée, ni rien qui pourrait faire penser à un environnement français!?!

Au moins, j'ai un contournement qui marche! si personne ne trouve mieux...

)jack(

[jack-ft]

Envoyé par Alek-C

Il faut définir les 2 clés séparément :

Code :

(première clé = premier champ, deuxième clé = deuxième champ)

Ah! D'accord! Je demande une première clé qui commence au premier champ et finit au premier champ (-k1,1), bref qui contient juste le premier champ, puis une deuxième clé qui commence au deuxième champ et finit au deuxième champ (-k2,2). Capico!

Et ça marche!

Merci beaucoup!

J'ai cru que j'allais devenir chèvre, si ce n'était déjà fait...

)jack(

[frp31]

le cat faut le virer de toute façon, non pas parce que ca perturbe mais parce que c'est inutile et que l'pipe abusif .... etc...Etc.... on va pas revenir sur l'UUoC

[jack-ft]

Envoyé par frp31

le cat faut le virer de toute façon, non pas parce que ca perturbe mais parce que c'est inutile et que l'pipe abusif .... etc...Etc.... on va pas revenir sur l'UUoC

Euh... je crois que je n'ai pas été assez clair pour me faire comprendre, désolé.

Le "cat" que j'ai mis ici, c'était juste pour un exemple.

[frp31]

Envoyé par jack-ft

Le "cat" que j'ai mis ici, c'était juste pour un exemple.

même dans ton exemple il sert à rien j'ai bien dit à rien !

Code :

sed -e 's:,:;:' fichier_d_exemple | sort --field-separator=';' -n -k 1 -n -k 2 | sed -e 's:;:,:'

ça suffit

[jack-ft]

[HS]Oops!!! Les joies de Windows ! Je n'ai pas pu finir mon post précédent car j'avais perdu mon clavier, mais pas ma souris! A chaque appui d'une touche, le PC ne faisait qu'un petit bip (un peu comme lorsqu'on fait C-s (Xoff) sous unix et qu'on remplit le buffer d'input). Bref, le temps que je sauve mes fichiers sous emacs (à la souris, quand on n'a pas l'habitude, c'est pas rapide!), que je reboote, que je relance tout le bazar, me revoili...[/HS]

[TROLL UUoC]

Envoyé par frp31

même dans ton exemple il sert à rien j'ai bien dit à rien !

Code :

sed -e 's:,:;:' fichier_d_exemple | sort --field-separator=';' -n -k 1 -n -k 2 | sed -e 's:;:,:'

ça suffit

Je ne veux pas relancer un troll uuoc... (quoique...).

J'ai bien entendu que tu as bien dit "à rien"! Du point de vue strictement informatique, je suis complètement d'accord avec toi que le "cat" ne sert à rien, mais (car il y a un "mais"), du point de vue interaction entre l'ordinateur et celui qui tape (ou qui lit) le programme (moi, en l'occurrence), il en va tout autrement: le "cat" m'est réellement utile (à moi-même, en personne (et peut-être à d'autres)).

En effet, il me permet d'avoir un code plus lisible (pour moi) et plus pratique à remanier.

Par exemple, si je veux transformer:

Code :

sort --field-separator=';' -n -k 1 -n -k 2 fichier_d_exemple  | sed -e 's:;:,:'

en intercalant un "sed" au début:

Code :

sed -e 's:,:;:' fichier_d_exemple | sort --field-separator=';' -n -k 1 -n -k 2 | sed -e 's:;:,:'

je trouve que c'est plus facile/rapide/lisible si j'ai mis un (inutile) "cat" dès le départ, auquel cas je transforme:

Code :

1
2
3
4
 
cat fichier_d_exemple  \
    | sort --field-separator=';' -n -k 1 -n -k 2 \
    | sed -e 's:;:,:'

en insérant juste une ligne:

Code :

1
2
3
4
cat fichier_d_exemple  \
    | sed -e 's:,:;:' \
    | sort --field-separator=';' -n -k 1 -n -k 2 \
    | sed -e 's:;:,:'

J'imagine qu'il doit y avoir un petit coût (dû au lancement du "cat"), mais je crois en retirer plus de bénéfice. J'imagine la tête d'un anti-uuoc à la lecture de mon code, car je crois bien que je n'utilise jamais sed sort etc. non précédé d'un (inutile (pour certains)) "cat" !

Cela dit, dans le bout de code que j'essayais de mettre au point (dont voici une partie), il n'y a pas de "cat", mais juste un pipe. Il s'agit d'une dizaine de cartes produisant en continu, de manière à peu près synchrone, des données qu'on souhaite regrouper triées dans une seule ligne:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
tail -f ${MMCA_RAW_FILE} | \
  (while [ 1 ] ; do
    NUM_L=0
    while [ $NUM_L -lt $NB_BOARDS ] ; do
	# Read 1 line for each board
	NUM_L=$(expr ${NUM_L} + 1)
	read line
	# put it on the stdout
	echo $line
	# and sort them, join them in one single line,
	# remove the last separator and remove empty lines
    done \
	| sort -t"${SEP}" -n -k1,1 -k2,2	\
	| (tr "\n" "${SEP}" ; echo '')		\
	| sed -e "s:${SEP}\$::"			\
	| egrep -v '^$'
  done) \
  > ${MMCA_SORT_FILE} &

[/TROLL UUoC]

BTW, l'inconvénient de ce style d'écriture (avec backslash + return), c'est que je n'arrive pas à mettre de commentaires entre les lignes :-( si quelqu'un a une solution, ça m'intéresse!

En tout cas, merci à tous pour le coup de main!

)jack(

[N_BaH]

BTW, l'inconvénient de ce style d'écriture (avec backslash + return), c'est que je n'arrive pas à mettre de commentaires entre les lignes :-( si quelqu'un a une solution, ça m'intéresse!

ce n'est pas possible : tu es toujours sur la même ligne ! Or, sur une ligne tout ce qui est après la marque de commentaire (#) est ...un commentaire

[jack-ft]

Envoyé par N_BaH

ce n'est pas possible : tu es toujours sur la même ligne ! Or, sur une ligne tout ce qui est après la marque de commentaire (#) est ...un commentaire

...et un commentaire se termine avec la marque de fin de ligne.

Je ne cherchais plus vraiment, mais, au moins, maintenant, c'est clair: je sais que je peux arrêter de chercher définitivement...

à moins qu'on nous introduise un commentaire qui ne finit pas par une fin de ligne, par exemple #< ceci est un commentaire de sept mots >#, sous réserve que quelqu'un s'amuse à modifier le shell en conséquence...

Merci N_BaH

)jack(