sort zeigt etwas unerwartes für mich, warum ?

Hinweis: In dem Thema sort zeigt etwas unerwartes für mich, warum ? gibt es 18 Antworten auf 2 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Ich habe zwei Probe gemacht mit einem anderen Computer (B).

    Ergebnis -> kein Problem, und dies mit Leap 15.2 sowie mit Tumbleweed (eine Distribution ist auf Deutsch, die andere auf Französisch) .

    Ich lasse nun den zweiten Computer (B).

    ==================================================================

    Computer (A), mit dem merkwürdigen Ergebnis:


    Die drei Outputs mit Debug:


    1) ls -l /usr/bin/ | sort --debug -nrk 5 | head -n 60


    2. sort --debug -nr tri_sort.txt | head -n 60

    Quelle: tri_sort.txt

    3. LANG=C sort --debug -nr tri_sort.txt | head -n 60

    Quelle tri_sort.txt

    Übrigens: Ich habe die Datei tri_sort.txt mit cat erstellt und dann sie mit vim bearbeitet, also Zeilen hinzugefügt.

    Sie ist in UTF-8 kodiert. (Wenn ich sie mit Kate öffne, ist es UTF-8 geschrieben…)

    Einmal editiert, zuletzt von denebe ()

    Für den Inhalt des Beitrages 287473 haftet ausdrücklich der jeweilige Autor: denebe

  • Die drei Outputs mit Debug:


    1) ls -l /usr/bin/ | sort --debug -nrk 5 | head -n 60

    ...

    Das ist es! Das französische locale erlaubt augenscheinlich einzelne Blanks innerhalb der Zahlen. Man darf also die Zahl "123456" auch als "123 456" schreiben. So werden die Dateilängen und die zweistellige Tagesnummer zu einer Gesamtzahl.

    Test:

    In französisch sieht sort die Zahlen 11, 12, 21 und 111.


    Ich habe aber keine Ahnung, wie man ein locale reparieren kann...

    Für den Inhalt des Beitrages 287474 haftet ausdrücklich der jeweilige Autor: Welm

  • Hi,

    ich konnte nicht raus lesen, ob das bei euch unter Tumbleweed (coreutils 8.32, Release : 6.1) mit fr_FR.UTF-8 geklappt hat oder auch noch ein Problem gab. Bei mir liefen hier alle Versuche sauber.

    Zitat

    Ich habe aber keine Ahnung, wie man ein locale reparieren kann...

    Ich vermute, das da ist was mit sort nicht in Ordnung ist (in Verbindung mit einzelnen locales, bzw. Sonderzeichen). Wenn es in tumbleweed sauber läuft, wurde das schon gefixt (siehe https://lists.gnu.org/archive/…ils/2020-08/msg00019.html ?).


    Um das heraus zu finden, könnte man auch unter Leap 15.2 eine neuere Version von core utils einspielen. Es existieren Community-Versionen von 8.32. Ob man das einfach machen darf und das eine gute Idee ist kann ich aber nicht beurteilen. Da fehlt mir das wissen.

    Für den Inhalt des Beitrages 287477 haftet ausdrücklich der jeweilige Autor: r3z5

  • Ich vermute, das da ist was mit sort nicht in Ordnung ist...

    Das glaube ich nicht. "sort" entscheidet, wo das Feld 5 im Beitrag #1 anfängt und das locale entscheidet, wie weit die Zahl geht -- danach muss sort sich richten. Wenn im französischen locale steht, dass Leerzeichen in Zahlen stehen dürfen, dann ist die Sortierung im ersten Beitrag richtig. Dort stand:

    Code
    ...
    -rwxr-xr-x 1 root root     2496112 10 oct.  02:57 Xvnc
    -rwxr-xr-x 1 root root    22878400  2 déc.  15:13 mariabackup
    -rwxr-xr-x 1 root root     2143568 16 mai    2020 busybox-static
    ...
    -rwxr-xr-x 1 root root     1218608 15 juin   2020 kolourpaint
    -rwxr-xr-x 1 root root    12165480  9 juin   2020 gdb
    -rwxr-xr-x 1 root root     1179968 23 juil. 12:49 flatpak
    ...

    Gemäß einem locale, dass Leerzeichen in Zahlen erlaubt, ist das zu interpretieren als:

    Code
    ...
    -rwxr-xr-x 1 root root     249611210 oct.  02:57 Xvnc
    -rwxr-xr-x 1 root root     228784002 déc.  15:13 mariabackup
    -rwxr-xr-x 1 root root     214356816 mai    2020 busybox-static
    ...
    -rwxr-xr-x 1 root root     121860815 juin   2020 kolourpaint
    -rwxr-xr-x 1 root root     121654809 juin   2020 gdb
    -rwxr-xr-x 1 root root     117996823 juil. 12:49 flatpak
    ...

    Für den Inhalt des Beitrages 287480 haftet ausdrücklich der jeweilige Autor: Welm

  • ok, danke für die Erklärung. Nur um das noch mal sacken zu lassen. Was passiert bei:

    Code
    LANG=fr_FR.UTF-8 sort -nk 1,1 zz.txt

    bzw.

    Code
    LANG=fr_FR.UTF-8 ls -l /usr/bin/ | LANG=fr_FR.UTF-8 sort --debug -nrk 5 | head -n 60

    und

    Code
    LANG=fr_FR.UTF-8 ls -l /usr/bin/ | LANG=fr_FR.UTF-8 sort --debug -nrk 5,5 | head -n 60

    Der erste und letzte Befehl sollte ja klappen oder? Hier würde dann sort das Ende richtig erkennen (Leerzeichen)? Und somit kommen dann keine Leerzeichen mehr im Key vor, die vom fr-locale als Zahl interpretiert werden? Koerrekt?


    Wenn das was beim locale ist, müsste das Paket glibc-locale sein oder? Sollte man da nicht mal den Paketbetreuer anfixen?

    Code
    > rpm -qif /usr/lib/locale/fr_FR.utf8/
    Name        : glibc-locale
    Version     : 2.32
    Release     : 4.1
    Architecture: x86_64
    Install Date: Fr 25 Dez 2020 21:50:17 CET
    Group       : System/Libraries

    Steckt hier jemand noch tiefer in der Materie drin?

    Für den Inhalt des Beitrages 287481 haftet ausdrücklich der jeweilige Autor: r3z5

  • Der erste und letzte Befehl sollte ja klappen oder?

    Ja, genau, bei mir jedenfalls (nur 15.2, glibc-locale-2.26-lp152.26.3.1.x86_64)

    Wenn das was beim locale ist, müsste das Paket glibc-locale sein oder? Sollte man da nicht mal den Paketbetreuer anfixen?

    Ich hab keine Ahnung von französischen Sprachregeln. Wenn das Leerzeichen da als Tausendertrennung üblich ist, dann gehört das ja eigentlich ins locale. Auch wenn es zu Problemen führt.

    Siehe auch https://de.wikipedia.org/wiki/Zifferngruppierung


    Aber man kann das Problem ja auf die von Dir angegebene Art (d.h.: auch die Endspalte angeben) vermeiden.

    Für den Inhalt des Beitrages 287482 haftet ausdrücklich der jeweilige Autor: Welm

  • Das ist es! Das französische locale erlaubt augenscheinlich einzelne Blanks innerhalb der Zahlen. Man darf also die Zahl "123456" auch als "123 456" schreiben. So werden die Dateilängen und die zweistellige Tagesnummer zu einer Gesamtzahl.

    Ich habe auch das gedacht. Aber --debug zeigt, wenn die Tagesnummer eine einzelne Ziffer ist, dass die zum Sortieren verwendeten Felder nur das 5 ist (ohne Blanks). Siehe Bild:

    Wenn die Tagesnummer 2 Ziffern enthält, schließen die zum Sortieren verwendeten Felder das Feld 5 und das Feld 6 ein (mit Blanks).


    Ich bedanke mich sehr bei euch, es hat mir viel geholfen.

    Für den Inhalt des Beitrages 287483 haftet ausdrücklich der jeweilige Autor: denebe

  • Ich habe auch das gedacht. Aber --debug zeigt, wenn die Tagesnummer eine einzelne Ziffer ist, dass die zum Sortieren verwendeten Felder nur das 5 ist (ohne Blanks).

    Ahh. Du hast noch einen Fehler gefunden! Die Debugausgabe unterstreicht nicht genau das, was wirklich zum Sortieren benutzt wird.


    Die Reihenfolge in Beitrag #11 gibt erst "Xvnc", dann "mariabackup" und dann "busybox-static" an.

    Das passt weder zu den wirklichen Dateilängen:

    Code
     2496112
    22878400
     2143568

    noch zu den von "debug" unterstrichenen Angaben:

    Code
    249611210
     22878400
    214356816

    aber zu den Zahlen:

    Code
    249611210
    228784002
    214356816

    Für den Inhalt des Beitrages 287488 haftet ausdrücklich der jeweilige Autor: Welm