Commande sort : comportement étrange !?

Version imprimable

Salut.

Voici un petit code à exécuter:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
#!/bin/bash
 
/bin/bash --version
echo
echo
 
fic='./test.txt'
 
rm $fic
 
echo 'La Mort En Ligne (2003).avi' >> $fic
echo 'LA Panthere Rose (2006).mkv' >> $fic
echo 'LA Panthere Rose 2 (2009).mkv' >> $fic
echo 'la Petite Boutique Des Horreurs (1960).mkv' >> $fic
echo 'LA Proie D Une Ombre (2021).mkv' >> $fic
echo 'la Lettre Inachevee (1960)' >> $fic
echo 'La Maison Des Damnés (1973)' >> $fic
echo 'Lamb (2021).avi' >> $fic
 
 
echo '---------- cat du fichier '$fic
cat $fic
echo "------------------------------"
echo 
echo '---------- sort du fichier '$fic
sort $fic
echo "------------------------------"

J'obtiens en sortie (comme vous ?) les lignes suivantes:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
 
GNU bash, version 5.0.17(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2019 Free Software Foundation, Inc.
Licence GPLv3+ : GNU GPL version 3 ou ultérieure <http://gnu.org/licenses/gpl.html>
 
Ceci est un logiciel libre ; vous être libre de le modifier et de le redistribuer.
AUCUNE GARANTIE n'est fournie, dans les limites permises par la loi.
 
 
---------- cat du fichier ./test.txt
La Mort En Ligne (2003).avi
LA Panthere Rose (2006).mkv
LA Panthere Rose 2 (2009).mkv
la Petite Boutique Des Horreurs (1960).mkv
LA Proie D Une Ombre (2021).mkv
la Lettre Inachevee (1960)
La Maison Des Damnés (1973)
Lamb (2021).avi
------------------------------
 
---------- sort du fichier ./test.txt
la Lettre Inachevee (1960)
La Maison Des Damnés (1973)
Lamb (2021).avi
La Mort En Ligne (2003).avi
LA Panthere Rose (2006).mkv
LA Panthere Rose 2 (2009).mkv
la Petite Boutique Des Horreurs (1960).mkv
LA Proie D Une Ombre (2021).mkv
------------------------------

C'est super bizarre !!!! Tout se passe comme si sort ne tenait aucun compte ni des espaces, ni des majuscules et minuscules !
J'utilise cette commande depuis que Linux existe (eh oui je suis plus tout jeune snif), je n'avais jamais remarqué ça.
Pour moi, ce n'est pas du tout le comportement attendu.

Qu'en pensez-vous ? Comment expliquez vous ça ? Comment rétablir un comportement "normal" de ma commande sort, le cas échéant.

09/01/2023, 19h10
N_BaH

Bonjour,

Code:

LC_COLLATE=C sort -f tonFichier

mais je ne sais plus le pourquoi du LC_COLLATE :(
quant au -f, c'est pour ne pas tenir de la casse; là, c'est toi qui voit. :)
09/01/2023, 19h21
NeoType

Si j'en crois cette page, voici ce que fait LC_COLLATE:
https://unix.stackexchange.com/quest...fore-uppercase

Autrement dit si je comprends bien ça inverse le comportement par défaut vis à vis des min et des maj.

Mais ça n'explique pas le comportement actuel de ma commande qui ne tient pas compte des espaces, et ignore complètement les min et les maj.
Ce nest pas sensé être son comportement par défaut !
09/01/2023, 20h08
NeoType

OK avec

Code:

LC_ALL=C sort -d $fic

j'ai l'impression que je retombe plus ou moins sur mes pieds, mais j'ai un peu de mal à comprendre encore ce que fait l'option -d (ordre du dico), et j'ai peur que tout ça ait des implications si je combine la sortie de sort avec une commande uniq (typiquement).

Va falloir faire des p*tains de tests, et ça me fait grmbl grmbl.

De toute façon pour moi cette histoire de LC_ALL ou LC_COLLATE est clairement un bug.
Si on veut ignorer la casse, l'option -f, --ignore-case est sensée justement servir à ça. Alors que là par défaut cette option ne sert à rien à du tout ! (sauf si la page de manuel est mensongère)

Les développeurs de bash finissent par faire n'importe quoi à force de pseudo améliorations, ce qui provoque des bugs surprise de version en version.
Chuis pas content !!! :mrgreen:

Merci à toi N_BaH de m'avoir mis sur la piste.

Je ne passe pas le sujet en [résolu] dans l'immédiat, j'attends éventuellement d'autres commentaires.
09/01/2023, 20h24
N_BaH

sort, ce n'est pas bash : c'est GNUcoreutils.

Code:

info coreutils sort
09/01/2023, 21h24
NeoType

Oui en plus, je n'avais pas réalisé qu'il s'agit de variables d'environnement.
Merci à toi.
Je me suis énervé tout seul.
10/01/2023, 12h46
Flodelarab

Bonjour :coucou:

Ce n'est pas nouveau et c'est très gênant. Quand tes lignes commencent par 2 champs numériques, il les concatène dans un tri numérique. Ce qui oblige à introduire une séparation artificielle, comme un "M" par exemple. Ce n'est effectivement pas le comportement que l'on souhaite par défaut.
10/01/2023, 17h21
NeoType

Salut à toi,

Est-ce que c'est pas plutôt parce qu'il semble ne pas tenir compte des caractères espaces comme je le signalais plus haut ?
Ou je n'ai pas compris ce que tu dis.

Apparemment ce comportement repose sur des variables de localisation qui ne sont peut-être pas bien positionnées chez moi.

PS: j'ai utilisé cette commande en toute confiance pendant des années y compris en entreprise et c'est seulement maintenant que je réalise que tous mes scripts ksh et bash étaient potentiellement foireux. Ca m'horripile ce sentiment d'insécurité.
10/01/2023, 18h16
disedorgue

Pour la locale FR_fr (et bien d'autre) la partie collate est défini dans (sur un wsl ubuntu) :
/usr/share/i18n/locales/iso14651_t1_common

Après faut comprendre les règles pour les divers parties...

Pour un sort, vaut mieux écouter le conseil du man (*** WARNING *** The locale specified by the environment affects sort order. Set LC_ALL=C to get the traditional sort order that uses native byte values.)
10/01/2023, 19h55
NeoType

Oui LC_ALL=C semble résoudre le problème (non prise en compte des espaces et non distinction maj/min) mais je trouve hallucinant que ce ne soit pas le comportement par défaut.

D'ailleurs l'existence même de l'option -f (--ignore-case) tend à prouver selon moi qu'historiquement c'était bien le comportement par défaut (au moins pour la casse).
Ou alors il faut signaler ça dans les pages de manuel ! C'est absolument pas intuitif.
Et si on en rendu là pour une commande aussi basique que sort, alors il est permis de mettre douter le comportement de l'ensemble des commandes shell. C'est légèrement problématique je trouve !!! (est-ce que ls ou mkdir font bien ce qu'ils sont sensés faire ? --> Ben j'en sais plus rien !)
10/01/2023, 20h14
disedorgue

Ton raisonnement est valable dans le monde de l'ascii mais dés que tu passes dans le monde de l'unicode, tu ne peux plus te permettre de penser comme ça. Dis toi que toi, tu as la chance de pouvoir utiliser la locale C car tu utilises un alphabet très proche de l'ascii, ce qui n'est pas le cas pour par exemple le mandarin.
Sort travail sur du texte et pas que de type latin.
Par défaut l'espace est le séparateur de mot, comment toi tu trierais 2 phrases par ordre alphabétique ? Tu verras qu'en y réfléchissant un peu, tu ferais comme sort.
10/01/2023, 21h04
NeoType

C'est le rôle des locale de permettre aux chinois mandarins d'adapter leur système au comportement par défaut, de langue anglaise. Et nous de même. Pas l'inverse.
Sinon on aboutit à une commande sort qui ne tient carrément plus compte des espaces ! (et sans offrit une option qui irait dans ce sens si on le souhaite). Où va-t-on, là ?!
Je ne te suis pas et je ne crois pas que ce soit l'explication. Peut-être que je me trompe.
10/01/2023, 21h20
disedorgue

Non, pas d'accord, montre à un enfant une lettre "a" et une lettre "B" à un enfant et demande lui quelle lettre est la première, il te dira le "a" et pourtant un sort en locale C te dira le "B"...

Pareil pour l'espace, l'enfant l'ignorera, celui ci, n'est pas pris en compte.

C'est ça un tri alphabétique. Toi tu veux un tri binaire sur de l'alphabétique.

L'espace n'existe pas dans l'alphabet, c'est juste un séparateur de mot.
10/01/2023, 23h41
NeoType

Citation:

Envoyé par disedorgue

Non, pas d'accord, montre à un enfant une lettre "a" et une lettre "B" à un enfant et demande lui quelle lettre est la première, il te dira le "a" et pourtant un sort en locale C te dira le "B"...

Pareil pour l'espace, l'enfant l'ignorera, celui ci, n'est pas pris en compte.

C'est ça un tri alphabétique. Toi tu veux un tri binaire sur de l'alphabétique.

L'espace n'existe pas dans l'alphabet, c'est juste un séparateur de mot.

Mais non, je me fiche que les maj viennent avant les min ou l'inverse. (d'ailleurs ce doit être le rôle de l'option -d de faire ça, et c'est arbitraire)
J'estime juste que la commande sort doit faire ce qu'elle est sensée faire, c'est à dire trier des chaînes en fonction des caractères et de leur position.
Or une majuscule et une minuscule, ce n'est pas la même chose et un caractère espace, bah ce n'est un pas un caractère vide !

Parce qu là c'est du grand n'importe quoi, je suis désolé. Je ne sais pas comment on peut soutenir le contraire ! Ca s'appelle de la mauvaise foi, chinois mandarins et enfants de 5 ans ou pas. Pourquoi ne pas considérer aussi que le caractère "0" compte pour du beurre désormais. C'est juste une idée. Une idée farfelue peut-être mais pourquoi pas ?
On peut très bien ajouter une option pour ça, où est le problème ? Moi je veux bien. Mais ça ne doit en aucun cas être le comportement par défaut, ce serait juste aberrant, non ? C'est pareil.
11/01/2023, 00h58
N_BaH

modération : discussion close.

te rends-tu compte que ta colère, ici, n'a pas de sens ?
ce serait plus constructif de la diriger vers les développeurs du programme.

tu peux ne pas être d'accord avec la façon dont fonctionne un moteur à explosion, ça sert à rien de t'en prendre au mécanicien qui t'explique comment il tourne.