Ich habe wirklich seltsames Verhalten beim Lesen von Dateien aus / proc Wenn ich / proc / pid / stat träge mit preludes readFile lese - funktioniert das aber nicht so, wie ich es möchte. Das Umschalten auf strict reading mit Data.ByteString.readFile gibt mir eine leere Zeichenfolge.
Ich muss hier genau lesen, um die Ergebnisse zweier Lesevorgänge innerhalb eines kurzen Intervalls vergleichen zu können.
So funktioniert die Verwendung von System.IO.readFile zum Lesen von / proc / pid / stat einfach nicht. Es gibt mir das gleiche Ergebnis innerhalb von 0,5 Sekunden. Ich denke, das liegt an der Faulheit und dem halb geschlossenen Griff oder etwas ... Das Öffnen und Schließen des Dateihandle funktioniert explizit.
%Vor%Aber warum tun Sie das oben, wenn wir das bytestring strenge Lesen haben. Richtig?
Hier bin ich steckengeblieben.
%Vor%Dies gibt immer eine leere Zeichenfolge zurück. Auch in GHCI getestet. Irgendwelche Vorschläge. Danke.
--- AKTUALISIEREN ---
Danke Daniel für Vorschläge.
Das muss ich eigentlich tun. Dies könnte helfen, mein Dilemma vollständig zu zeigen und allgemeinere Vorschläge zu bringen.
Ich muss Prozessstatistiken berechnen. Hier ist ein Teil des Codes (nur die CPU-Nutzung) als Beispiel.
%Vor%Das einzige, was in dieser Situation funktioniert, ist das explizite Öffnen und Schließen von Handles mit hGetLine im obigen Code-Snippet. Aber das ist nicht gut genug, da einige proc-Dateien mehr als eine Zeile wie / proc / meminfo sind.
Also brauche ich eine Funktion, die die ganze Datei strikt lesen würde. Etwas wie hGetContents aber streng.
Ich habe versucht, dies zu tun:
%Vor%In der Hoffnung, dass Zeilen die Datei vollständig lesen würden. Kein Glück. Immer noch eine leere Liste.
Jede Hilfe, Vorschlag wird sehr geschätzt.
Der ByteString
Code ist
Aber /proc/whatever
ist keine echte Datei, sie wird bei Bedarf generiert, wenn Sie stat
sie erhalten, um die Dateigröße zu erhalten, erhalten Sie 0. So ByteString
s readFile
liest erfolgreich 0 Bytes.