opendir(), readdir() Sortierung

Seiten des API ist keine Reihenfolge definiert. Sie hängt also vom 
Filesystem ab. Das kann bei NTFS anders aussehen als bei FAT.

Danke.

Also doch Einlesen und dann qsort ;)

Filesystem wie NTFS mit innerer Baumstruktur haben ein inhärentes 
Sortierverhalten, was aber der internen Zeichencodierung folgt, nicht 
der je nach Sprache grammatikalisch gewünschten. Andere Filesysteme wie 
FAT speichern völlig unsortiert.

Ich kompiliere wissenderweise mit einem C-Compiler. Mit C++
habe ich bis jetzt ein Projekt mit dem Gnu-Compiler durchgezogen.

Der C-Code zum Laden eines Verzeichnisses mit anschließendem
Sortieren ist auch nicht "größer" wie das C++-Bespiel.

C ist erheblich weniger Tipparbeit.

Na, das mache ich etwas kompakter ;)

Also wenn schon kompakter und nicht C, wärs dann damit: ;-)
  print join "\n", sort </home/*>;

Aber aber, Perl ist doch pöse, wegen seiner schrecklichen Syntax. :-))

Wie groß sind denn die binaries beider Varianten (also ohne daß jetzt 
wesentliche Teile in ingendwelchen dlls ausgelagert sind)?

Jörg W. schrieb:
> Aber aber, Perl ist doch pöse, wegen seiner schrecklichen Syntax. :-))

Eben. Genau wie C und C++. :-))

Dr. Sommer schrieb:

1

  copy (files.begin (), files.end (), ostream_iterator<string> (cout,  "\n"));

Ich hab immer den Eindruck, dass copy mit ostream_iterator hauptsächlich 
verwendet wird, weil es Leute irgendwie für cool halten, dass man das 
kann. In der Praxis würde ich aber einfach schreiben:

1

for (auto& file: files) cout << file << '\n';

Und ich finde auch, dass statt dem hier:

1

transform (directory_iterator ("/home"), directory_iterator (), back_inserter (files), [] (auto& e) { return e.path (); } );

das folgende vielleicht uncooler, dafür aber kürzer und lesbarer ist:

1

for (auto& e: diretory_iterator("/home")) files.push_back(e.path());

nunja aber die Vergleichsfunktion mit strcmp() hat einen blöden 
Nachteil..

strcmp() vergleicht Zeichenweise und bricht ab beim Ende der 
Zeichenkette oder bei ersten Zeichen das ungleich ist ab und liefert 
größer/kleiner zurück. Es vergleicht plump die Values und berücksichtigt 
nicht der Wertung der Zeichen.

CcAazZ usw.. unter dem Aspekt kommt nicht das gewünschte Ergebnis zu 
Stande wenn man in die ASCII Tabelle schaut...


alphasort (const void *a, const void *b)  schon ob das portable ist weiß 
ich jetzt nicht..

Die Frage ist noch nicht beantwortet :)

wollte nur darauf hinweisen das der Sachverhalt nicht so ganz einfach 
ist ;)

Dann strcoll()

https://docs.microsoft.com/de-de/cpp/c-runtime-library/reference/strcoll-wcscoll-mbscoll-strcoll-l-wcscoll-l-mbscoll-l?view=vs-2019

Goto ist aus vielerlei Hinsicht unschön... außer in der Linux Kernel 
Programmierung. Bei Treibern wird es benutzt um bei Fehlern aufzuräumen.

Außerdem gibt es kein Problem was sich nicht ohne Goto lösen lässt.

Das heißt, du willst also den Speicherverbrauch des Programms für 
Strings schlicht vervierfachen und 32-Bit Codepoints speichern. Richtig?

Oder doch lieber UTF8, UTF16BE, UTF16LE oder was anderes nutzen?

S. R. schrieb:
> Das heißt, du willst also den Speicherverbrauch des Programms für
> Strings schlicht vervierfachen und 32-Bit Codepoints speichern. Richtig?

Der Speicherverbrauch vervierfacht sich nur, wenn das Programm 
ausschließlich aus Strings besteht und weder irgendwelchen Programmcode, 
noch andere Ressourcen wie z.B. Grafiken enthält. Tatsächlich ist es in 
einigen Sprachen üblich, UCS-4 für Strings zu verwenden.

> Oder doch lieber UTF8, UTF16BE, UTF16LE oder was anderes nutzen?

Dann muss man allerdings zwischen der Länge des Strings im Bezug auf 
Speicher und im Bezug auf Anzahl Zeichen unterscheiden. Man müsste dann 
also entweder jedesmal mühsam die Zahl an Zeichen ausrechnen, wenn man 
sie braucht, oder man müsste beide Werte speichern und bei jeder 
Änderung aktualisieren. Das lohnt sich auf einem aktuellen PC nicht, nur 
um ein paar Dutzend Kilobytes RAM zu sparen.

test schrieb:
> Und der Arduino oder das Linux auf dem Toaster darf gerne weiterhin
> 8-Bit ASCII nutzen, da hat jeder Verständnis für.

Ein ordentlicher Toaster basiert auf BSD und beherrscht 
selbstverständlich moderne Zeichensätze.

Rolf M. schrieb:
>> Das heißt, du willst also den Speicherverbrauch des Programms
>> für Strings schlicht vervierfachen und 32-Bit Codepoints speichern.
>> Richtig?
>
> Der Speicherverbrauch vervierfacht sich nur, wenn das Programm
> ausschließlich aus Strings besteht und weder irgendwelchen
> Programmcode, noch andere Ressourcen wie z.B. Grafiken enthält.

Darum schrieb ich "für Strings". Muss ich sowas noch hervorheben oder 
jedesmal einen Vortrag mit allen Details ausarbeitern?

> Tatsächlich ist es in einigen Sprachen üblich,
> UCS-4 für Strings zu verwenden.

Die meisten mir bekannten Sprachen verwenden allerdings utf8.
Die JVM nutzt intern UCS16, kann also ohnehin nur die BMP (Basic 
Multilingual Plane).

test schrieb:
> Nur mal so aus Neugier... Was machst du in deinem "ein String ist
> ja nur ein Byte Array" Programm, wenn dein Nutzer z.B. eine Datei
> mit Japanischen Zeichen im Dateinamen hat?

Nix. Ich gebe die an das Betriebssystem weiter. Warum sollte ich den 
Dateinamen in einen String wandeln wollen? Solange ich da nix rumparsen 
muss, kann mir der Name doch egal sein.

> Abstürzen lassen oder eine Meldung zeigen die den Nutzer
> auffordert, derartig seltsame Sachen zu lassen?

Dazu müsste ich erstmal rauskriegen, dass der Dateiname irgendwie 
seltsam ist. Dafür zusätzlichen Code in mein Programm tun? Nee, danke.

Im Übrigen ist utf8 dafür wesentlich besser geeignet als UCS32. 
Platzsparender für fast alle relevanten Anwendungsfälle sowieso.

Dr. Sommer schrieb:
>> Solange ich da nix rumparsen
>> muss, kann mir der Name doch egal sein.
>
> Zum Sortieren muss man das aber, wofür man
> dann Unicode und UTF-XY beherrschen muss.

Stimmt, aber das überlasse ich in der Regel auch dem Betriebssystem. :-D

Dr. Sommer schrieb:
>> Stimmt, aber das überlasse ich in der Regel auch dem Betriebssystem.
> Welche Betriebssysteme haben denn nativ Unicode-Sortierfunktionen?

Wenn ich eine Dialogbox aufmache, um den Nutzer eine Datei auswählen zu 
lassen, ist mir die Sortierung relativ egal. In der Regel kann der 
Nutzer sogar selbst aussuchen, was er gern hätte.

Textprogramme bekommen ihre Dateinamen bei mir in der Regel direkt 
übergeben. Wenn dann ein open() fehlschlägt, weder mein Problem noch ein 
katastrophales Ereignis.

Dr. Sommer schrieb:
> Und sind die dann im Kernel implementiert?

Nö, aber ziemlich sicher im verwendeten Toolkit.

S. R. schrieb:
> Wenn ich eine Dialogbox aufmache, um den Nutzer eine Datei auswählen zu
> lassen, ist mir die Sortierung relativ egal.

Du hast wohl noch nie eine grosse Directory gesehen.

Dir als Entwickler glaube ich das. Testszenarien bei Entwicklern sind 
eigentlich immer schön übersichtlich. Fluchen tut ja auch nicht der 
Entwickler, sondern der Anwender.

> In der Regel kann der
> Nutzer sogar selbst aussuchen, was er gern hätte.

Glücklicherweise ja. Es gibt aber leider Software, in der das nicht 
möglich ist. Das kann recht unangenehm auffallen.

A. K. schrieb:
>> Wenn ich eine Dialogbox aufmache, um den Nutzer eine Datei auswählen zu
>> lassen, ist mir die Sortierung relativ egal.
> Du hast wohl noch nie eine grosse Directory gesehen.

Doch, aber in der Regel habe ich die selbst verursacht und kann damit 
einigermaßen umgehen. Notfalls mit "rm -rf". :-)

A. K. schrieb:
> Testszenarien bei Entwicklern sind eigentlich immer schön
> übersichtlich. Fluchen tut ja auch nicht der Entwickler,
> sondern der Anwender.

Ich frage mich gerade, welches Szenario du gerade im Hinterkopf hast. 
:-)

Wenn ich 10.000 Dateien in einem Ordner habe, wie soll meine Software es 
dem Benutzer denn einfacher machen, eine Datei auszusuchen? Der 
Standard-Dialog ist jedenfalls wesentlich besser getestet und sollte 
besser funktionieren als eine von mir zusammengefrickelte Alternative.

S. R. schrieb:
>>> Wenn ich eine Dialogbox aufmache, um den Nutzer eine Datei auswählen zu
>>> lassen, ist mir die Sortierung relativ egal.
>
> Standard-Dialog ist jedenfalls wesentlich besser getestet und sollte
> besser funktionieren als eine von mir zusammengefrickelte Alternative.

Das ist ja auch meist der richtige Ansatz. Eine chronologisch statt 
namentlich sortierte Listbox mit 50 Einträgen, wie z.B. in der VMware 
Netzwerk-Auswahl, ist der falsche.

S. R. schrieb:
> --SCHNIPP--
> Die meisten mir bekannten Sprachen verwenden allerdings utf8.
> Die JVM nutzt intern UCS16, kann also ohnehin nur die BMP (Basic
> Multilingual Plane).
> --SCHNIPP--
Surrogate-Paare. Damit kommt man auch in die anderen Bereiche rüber
===> https://de.wikipedia.org/wiki/UTF-16 Abschnitt Kodierung

Tom G. schrieb:
> Surrogate-Paare.

Oh, danke für den Hinweis.
Also die Nachteile von UTF8 und UCS-2 vereint.

Dr. Sommer schrieb:

> Außer Beschimpfungen zu meinem C-Code wurde bisher kein besserer
> gezeigt. Daher gehe ich mal davon aus, dass es doch nicht signifikant
> besser geht.

1

       #define _DEFAULT_SOURCE

2

       #include <dirent.h>

3

       #include <stdio.h>

4

       #include <stdlib.h>

5

6

       int

7

       main(void)

8

       {

9

           struct dirent **namelist;

10

           int n;

11

12

           n = scandir(".", &namelist, NULL, alphasort);

13

           if (n == -1) {

14

               perror("scandir");

15

               exit(EXIT_FAILURE);

16

           }

17

18

           while (n--) {

19

               printf("%s\n", namelist[n]->d_name);

20

               free(namelist[n]);

21

           }

22

           free(namelist);

23

24

           exit(EXIT_SUCCESS);

25

       }

Mit Fnmatch sind auch ausgefallene Sortierungen möglich.. Ob das 
poartable ist weiß ich nicht..

1

static int filter_match(const struct dirent *pDirent){

2

3

  if(fnmatch(LOG_FILENAME"*", pDirent->d_name, 0) == 0 && pDirent->d_type == DT_REG)return 1;

4

5

  return 0;

6

}

hier mal ein einfacher filter welcher mit versionsort(), mir meine 
logfiles sortiert so das ich herausfinden kann welches das ältere ist um 
dies dann zu löschen ;)

Der Platzhalter "*" Filter -> test0.log test1.log usw...

Es wird noch komplizierter ;)

scandir() hat einen blöden Nachteil..

zumindest unter Linux, wird ein doppel pointer vom type struct dirent 
erwartet.

Diese Struktur enthält nur Informationen zum namen und type.

Keine Attribute, size,Description,time etc. was aber genau so vom 
Interesse wäre wie der Name.

Also müsste man das Array mit Hilfe von qsort() und stat() erneut 
sortieren.

Ich frage mich gerade zu solchen Problemen müsste es doch Bibliotheken 
geben? Kennt jemand welche ?

Marco H. schrieb:
> Keine Attribute, size,Description,time

Weil dies unter Posix-Umgebungen Eigenschaften des jeweiligen Objektes 
sind, nicht von dessen Verzeichniseintrag. Es benötigt also in jedem 
Falle ohnehin die Indirektion, aus dem Verzeichniseintrag das Objekt zu 
ermitteln, um an dessen Eigenschaften zu gelangen.

Wozu aber benötigt man beim Sortieren der Anzeige denn die 
Objektattribute?

Marco H. schrieb:
> Diese Struktur enthält nur Informationen zum namen und type.
> Keine Attribute, size,Description,time etc. was aber genau so vom
> Interesse wäre wie der Name.

Und das hat einen soliden Grund. Viele Filesysteme unterscheiden 
zwischen der Information in der Directory und der Information zum 
eigentlichen File (Inode). Muss der opendir-API nur die Information aus 
der Directory abliefern, geht es sehr schnell. Muss er jedoch auch die 
Information aus den Inodes mitliefern, muss für jedes einzelne File ein 
eigener Disk-Zugriff auf die Inode-Information erfolgen.

Unix/Linux-Prinzip: Keep it simple. Den stat()-Aufruf für die 
Inode-Information kann der Nutzer des APIs genauso gut selber anfügen, 
wenn er sie benötigt.

Das war mir bewusst, ich wollte damit nur hinweisen das der Aufwand 
etwas steigt ;)  Aber sehr gut erklärt Danke.

Wenn funktioniert sieht das dann so aus :)

Marco H. schrieb:
> Wenn funktioniert sieht das dann so aus :)

Ich würde solche Listen ja bevorzugt case-insensitiv sortieren, also 
erst alles nach Kleinbuchstaben wandeln, dann sortieren (und die 
Originale anzeigen).

"F" vor "7" vor "t" ist eher unintuitiv.

Also ich arbeite auch viel mit readdir(). Es wurde ja schon gesagt, das 
readdir() die Namen in der Reihenfolge liefert, wie das Dateisystem sie 
gespeichert hat.

Welche zusätzlichen Daten readdir() liefert oder liefern kann, hängt vom 
Betriebssystem und von Dateisystem ab. Bei Ubuntu Linux und dem 
Dateisystem ext4 kann man z.B. aus dem vollen schöpfen. Aber auch da 
bekommt man manchmal als Ergebnis DT_UNKNOWN, nämlich bei einigen 
Netzwerkfreigaben. da muss man dann trotzdem stat() bemühen.

> Ich würde solche Listen ja bevorzugt case-insensitiv sortieren,...

Das ist zumindest unter Linux nicht die beste Idee, da das Dateisystem 
da keine Unterschiede macht. Dazu kommt dann noch, das man bei der 
Sortierung evtl. noch spezielle Eigenheiten der Sprache berücksichtigen 
möchte, damit öäüß richtig einsortiert werden.

Aber möglicherweise ist scandir() eine Alternative (wenn es auf dem 
Zielsystem verfügbar ist). Da könnte man die Sortierung beeinflussen.

Manfred M. schrieb:
>> Ich würde solche Listen ja bevorzugt case-insensitiv sortieren,...
> Das ist zumindest unter Linux nicht die beste Idee, da das
> Dateisystem da keine Unterschiede macht.

Das Dateisystem unterscheidet zwischen Groß- und Kleinschreibung, aber 
deswegen muss es die Sortierung in der Anzeige ja nicht tun. Schau mal 
in die Ausgabe von "ls", denn die sortiert (zumindest bei mir) ohne 
Berücksichtigung der Groß-/Kleinschreibung.

> Dazu kommt dann noch, das man bei der Sortierung evtl. noch
> spezielle Eigenheiten der Sprache berücksichtigen möchte,
> damit öäüß richtig einsortiert werden.

Das sowieso. Aber wenn man schon Unicode implementiert (hat), dann kann 
man auch gleich locale-aware sortieren. Zumal selbst gleiche Zeichen 
unterschiedlich sortiert werden (dt. "ö"=="o", sv. "ö"==letzter 
Buchstabe, dk/no. "ö"=="ø"==vorletzter Buchstabe).

S. R. schrieb:
> Schau mal in die Ausgabe von "ls", denn die sortiert (zumindest bei mir)
> ohne Berücksichtigung der Groß-/Kleinschreibung.

Hängt stark von der locale ab.

1

$ env LC_COLLATE=C ls

2

AbCDe   Bdda    abcde   bodec   Æbedc

3

$ env LC_COLLATE=de_DE.UTF-8 ls

4

abcde   AbCDe   Æbedc  Bdda    bodec

5

$ env LC_COLLATE=da_DK.UTF-8 ls

6

abcde   AbCDe   Bdda    bodec   Æbedc

Klassisch wurde die ASCIIbetische Sortierung auf UNIX-Systemen 
durchgeführt. Deshalb sind manche Filenamen wie z.B. Makefile oder 
README groß geschrieben - damit sie zuerst angezeigt werden.

Beim Makefile kommt noch dazu, dass "makefile" Vorrang vor "Makefile" 
hat, sodass man durch Kopieren auf die klein geschriebene Variante 
schnell eine eigene Modifikation durchführen kann.