Beiträge von Welm

    Der Vollständigkeit halber ... falls mal jemand hier rein googelt:


    VMware-Player-16.1 braucht den Workaround nicht mehr.


    VMware-Player-15.5.2 sollte man aber trotzdem erst dann wegwerfen, wenn der Neue funktioniert hat. Es werden ja ständig alte CPUs rausgeworfen ... mein zweiter Arbeitsplatz mit einem "AMD Athlon II X2 250" geht z.B. nur mit dem alten Vmplayer.

    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

    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.

    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
    ...

    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...

    Hmmm ...


    die Beispieldatei ist etwas unpraktisch denn Zeilen wie


    Code
    00 1
    0 1
    0 0 0
    0 01

    dürfen in beliebiger Reihenfolge ausgegeben werden. Solange erst die 100er, dann die 11er, dann die 10er, dann die 1er und dann die 0er kommen, darf alles ansonsten beliebig zufällig sortiert sein. LANG=C sollte daran nichts ändern (es war nur für das "ls" gedacht).


    "sort -nr tri_sort.txt" liefert aber definitiv was Falsches (11 kommt nach 10). Bei mir kommt es richtig raus.


    Sehen wir mal nach, welches "sort"-Programm da läuft: bei mir stammt es aus dem normalen "coreutils"-Paket.


    ... Einstellungen der Win7 VM (Virtualbox) zu ändern, und da habe ich gesehen, daß nur 3.1 der eigentlich 4 GB RAM erkannt werden.

    Gibt das "3.1" an was die virtuelle Maschine höchstens bekommt oder was die reale Maschine selbst hat?

    Mach mal in der echten Maschine

    Code
    cat /proc/meminfo

    Da siehst Du unter "MemTotal" wieviel die Maschine an RAM hat und unter "MemAvailable" wieviel für Prozesse höchstens übrig bleibt.


    Eine virtuelle Maschine ist ja nur einer der Prozesse innerhalb der realen Maschine. Sobald die Prozesse insgesamt mehr bekommen als da ist fängt die Swapperei an und die ganze Kiste wird langsam.