CSV-Datei teilen

Nimm einfach eine aktuelle Programmiersprache wie java, python oder 
ähnliches...ließ die daten zeilenwweise und nicht als ganzes...fertig

2gb sind wirklich eine lächerliche größe 2017 ;)

Unter Unix:

unzip -p riesig.zip | grep dk4tj > dk4tj.csv

"unzip -p" schreibt den Zip-Inhalt nach STDOUT, d.H es wird nicht 
temporär eine 2GB-Datei auf die Platte geschrieben.
Das sollte auch das WinDOS unzip.exe können. Evtl. mit "unzip /p"?

"grep dk4tj" sucht daraus nur die Zeilen aus, die "dk4tj" enthalten.
-> was ähnliches bieten auch die Windows-Bordmittel. "find.exe"?

"> dk4tj.csv" schreibt alle passenden Zeilen in eine neue Datei.
Beachten: Header-Zeile fehlt, die kannst du selber leicht nachrüsten.

Thomas S. schrieb:
> ... oder awk. Das gibt es auch für Win*.
> Suche nach Gawk.

Nicht nur awk/gawk, auch die oben erwähnten unzip & grep sowie diverse 
weitere Tool:
http://gnuwin32.sourceforge.net

Wilhelm S. schrieb:

> Nach dem Entpacken habe ich eine Riesen-CSV Datei mit ca. 2G

Wenn du die Datei unter DOS noch vollständig entpacken kannst, kannst du 
sie auch unter DOS weiter verarbeiten (im Sinne von: filtern). Das 
sollte logisch ein, oder?

> Hat geklappt; nachdem jedoch die
> Dateigrösse in den letzten Jahren extrem angestiegen ist, steigt
> mein Programm aus.

Sehr wahrscheinlich deshalb, weil schon die Originaldatei nicht mehr 
vollständig entpackt werden kann, das Ergebnis als irgendwo mittendrin 
einfach aufhört, weil das DOS-Limit von 2GB Dateigröße gerissen wurde.

Es gibt also zwei Probleme:

1) Die Datei kann nicht mehr vollständig entpackt werden.

2) Dein eigenes Werk ist unfähig, mit "truncated input" korrekt 
umzugehen. Gute Software(tm) würde in diesem Fall einfach eine 
Fehlermeldung über eine illegale Datei-Struktur absondern, ansonsten 
aber alles (bis auf die letzte nur noch teilweise ausgepackte Zeile) 
korrekt verarbeiten. Du hast wohl nie gelernt, sowas zu schreiben...

> Ich denke, es liegt an der Dateigrösse.

Natürlich, die maximale Dateigröße unter DOS war schließlich zu keiner 
Zeit ein Geheimnis...

> Meine Idee: Das CSV-File in mehrere Teile spalten

Das hilft dir nicht wirklich. Das Problem tritt ja bereits bei der 
Erzeugung der Datei durch das Entpacken auf. Sie ist dann bereits 
kaputt, weil unvollständig.

Alles, was dein Ansatz bringen könnte: Die Fehler in deinem eigenen Werk 
zu umschiffen. Ich persönlich würde dann aber eher mein eigenes Werk 
nachbessern. Schon aus Gründen der Programmierer-Ehre...

Blöd bloß, dass das im konkreten Fall das Problem auch nicht wirklich 
lösen würde.  Zwar könnte dann dein Programm wenigstens den entpackten 
Teil der Datei korrekt verarbeiten, aber es würde nach wie vor die 
unvollständige Zeile fehlen und auch alles, was danach noch kommt...

Als einzige Möglichkeit unter DOS würde ich hier sehen: Von 
Dateiverarbeitung auf Streamverarbeitung umsteigen. Sprich: Entpacker 
sagen, dass er das Ergebnis nach stdout liefern soll (statt es in einer 
Datei abzulegen) und deinem eigenen Programm sagen, dass es stdin 
verarbeiten soll, statt einer Datei. Für einen auch nur halbwegs 
kompetenten Programmierer sind die nötigen Änderungen am Programm eine 
Sache von wenigen Minuten.

An der Kommandozeile wäre der Aufruf dann in etwa so:

entpacker quelldatei <option für "entpacke nach stdout">  | deinprogramm 
<option für "lies von stdin"> zieldatei

Das "|" ist der Trick. Das ist eine Pipe, der Entpacker füttert seine 
Ausgabe über stdout dort hinein, dein Programm hingegen bekommt es über 
stdin.

Das Schicke ist: für diese Pipe gibt es auch unter DOS keine 
Beschränkungen, sie kann unendlich lang werden. 2GB-Grenze adé...

Sprich: dein nächstes Problem würde erst auftreten, wenn der Umfang des 
Teils der Datei, welcher dich interessiert, die 2GB-Grenze 
überschreitet. Das wirst du vermutlich aber nicht mehr erleben. Ich sehr 
wahrscheinlich auch nicht...

Rufus Τ. F. schrieb:

> Das willst Du unter DOS hinbekommen?

Natürlich, oder siehst du da ein konzeptionelles Problem?

Ich jedenfalls sehe keins. Piping unter DOS habe ich vor vielen 
Jahrzehnten schon erfolgreich benutzt. OK, ich müßte sicherlich meine 
DOS-Kennntnisse ganz erheblich auffrischen, um das heute auch wieder 
machen zu können, das meiste von dem Scheiß habe ich sicherlich 
mittlerweile vergessen. Aber ich habe meine alte Papierdoku aus dieser 
Zeit noch. D.h.: ich könnte mir das sogar auf dem Klo ooder in der 
Badewanne wieder anlesen. Wenn es denn mein Problem wäre und ich deshalb 
entsprechend motiviert wäre...

Ganz sicher bin ich jedenfalls, dass es keine Limitierung der Pipelänge 
gab, denn schon einige der Anwendungen von damals(tm) rissen da locker 
die 2GB-Grenze innerhalb von Tagen und liefen dann viele Jahre am 
Stück...

> Vielleicht sollte der Threadstarter etwas mehr vom tatsächlich
> verwendeten Betriebssystem erzählen. Tatsächlich DOS?

Das könnte zumindest keinesfalls schaden...

> Oder nicht vielleicht doch nur ein DOS-Programm, das unter einem (mäßig
> aktuellen) Windows in der üblichen NTVDM läuft?

Würde meiner Meinung nach praktisch nix ändern. Höchstens, dass man das 
2GB-DOS-Limit auf das 4GB-NT-FAT-Limit ausdehnen könnte. Aber selbst 
wenn das möglich wäre, wäre es nur eine Lösung für Arme, eben für Leute, 
die nicht wirklich programmieren können und immer nur das 
zusammefrickeln, was sie halt können...

Rufus Τ. F. schrieb:
> Vielleicht sollte der Threadstarter etwas mehr vom tatsächlich
> verwendeten Betriebssystem erzählen. Tatsächlich DOS?
>
> Oder nicht vielleicht doch nur ein DOS-Programm, das unter einem (mäßig
> aktuellen) Windows in der üblichen NTVDM läuft?

Wilhelm hat im Eingangspost bereits erwähnt, dass alles unter XP 
läuft...

Rufus Τ. F. schrieb:

> Magst Du mir erklären, wie das auf einem nicht-multitaskingfähigen
> "Betriebssystem" funktionieren soll? Ist ja nicht so, daß unter DOS das
> erzeugende und das empfangende Programm gleichzeitig laufen könnte -
> also muss der Inhalt der Pipe irgendwo zwischengespeichert werden, und
> wenn DOS eins nicht hat, dann RAM.

Das ist eine intelligente Frage und ich muss zugeben, dass ich darauf im 
Moment keine Antwort weiss. Ich kann also aktuell nicht erklären, warum 
das damals so funktioniert hat, wie es funktioniert hat.

Das mit dem begrenzten RAM ist dabei noch nichtmal das Problem, einen 
unendlichen FIFO kann man mit beliebig begrenztem RAM realisieren, 
notfalls mit einem einzigen Byte. Aber die Tatsache, dass pures DOS kein 
Multitasking-OS ist, läßt sich nicht wegdiskutieren und der beschriebene 
Ansatz funktioniert nur, wenn wenn Sender und Empfänger der Pipe 
parallel laufen können. D.h.: in meiner Erinnerung muss definitiv ein 
wichtiger Punkt bezüglich der damaligen Umgebung fehlen. Es kann 
definitiv zumindest kein pures DOS gewesen sein, soviel ist schonmal 
sicher. Andererseits bin ich sehr sicher, dass ich "unter DOS" 
programmiert habe.

Ich versuche, den offensichtlichen Widerspruch anhand der noch 
vorhandenen Unterlagen aufzuklären...

c-hater schrieb:
> Aber die Tatsache, dass pures DOS kein
> Multitasking-OS ist, läßt sich nicht wegdiskutieren und der beschriebene
> Ansatz funktioniert nur, wenn wenn Sender und Empfänger der Pipe
> parallel laufen können.

Es wird aus einer Datei gelesen und direkt in eine andere geschrieben, 
das sollte DOS gekonnt haben?

Wo kommen denn nun Pipes zum Einsatz?

1

W:\> FIND /I "DK4TJ" RIESIGMAX2GB.CSV > WINZIG.CSV

Löst das die selektions Aufgabe nicht?
-
Dass beim Entpacken u.U. die resultierende Datei nach 2GB abgewürgt wird 
ist doch eine Limitierung des Dateisystems. Also sollte es doch genügen 
die Arbeit auf einer mit fähigem Dateisystem eingerichteter Partition zu 
erledigen. Ja?

NB: dass für mit Bordmittel bewältigbare Trivialaufgaben umständlich 
eigene, kaputte Programme geschrieben werden ist schon...     "seltsam".

> PS:
> Alles läuft unter XP, bitte keinen Mecker diesbezgl.!
> Ja ich weiss, ich bin noch etwas von früher ;-)

Nein, XP (& DOS) sind für die Spätaufsteher.
Früher[TM] gab es echte Computer und echte Programmierer

Kommandozeile vor dem Frühstück für Alle! schrieb:
> Früher[TM] gab es echte Computer und echte Programmierer

Microsoft beschäftigt auch noch echte Programmierer.

https://www.bleepingcomputer.com/news/microsoft/microsoft-appears-to-have-lost-the-source-code-of-an-office-component/

Hut ab!

Wilhelm S. schrieb:
> PS:
> @C-Hater
> Ist dein Name Programm?

Oh ja. Davon kannst du ausgehen.

Wilhelm S. schrieb:
> Hallo zusammen,
>
> da habe ich ja eine Lawine losgetreten, oje.

Nicht doch, dies ist ein harmloser Verlauf.
Nicht zuletzt dank Deiner gleich im Eröffnungspost ziemlich umfassenden 
Beschreibung. Schlicht mustergültig.





> Die Lösung ist 'Find' mit Umleitung in eine andere Datei.
> Von da komme ich schon weiter.
> Das *.zip-File wird ordentlich entpackt -> ca. 2,4G
> 'Find' hat dann auch nicht gemeckert, das Suchen hat aber einige
> Zeit gebraucht.

Do schau her, von wegen Tamtam um Pipes...   :-)


> Bzgl. Programmieren:
> Ich bin zwar kein Profi, aber

Ich gratuliere!
Es freut mich sehr hie und da auch unter Anwendern welchen zu begegnen, 
die EDV als "El. Datenverarbeitung" begreifen UND umsetzen - entgegen 
dem Volkstrend "Ende Der Vernunft" welcher leider auch unter Profis 
grassiert!


  -  -  -
> Noch zur allgemeinen Info:
> Alles läuft in der DOS-Box von XP. Ich bleibe bei XP, weil
> man da noch einen Vollbildschirm im DOS-Fenster bekommt.

Wenn Du "so Einer" bist, lass Dir empfehlen in bash & GNU-tools zu 
schnuppern. M.M.n. wird es Dir gefallen.
Migrationsstrategie:
- erstmal unter XP mit CygWin starten (mit bloß dem Grundstock an core 
Pakete)
- danach doch auf ein Linuxsystem wechseln (Zweitrechner m. *buntu), 
Terminal und/oder per [strg][alt][Fx] die Textkonsole nutzen.
Bei "Heimweh" einfach das Paket dosbox einrichten: damit dürften auch 
die alten dBase/Clipper unter Linux laufen (meine Einschätzung vom 
Schiff aus, hab keine eigene handfeste Erfahrung mit dosbox)
Ja, etwas Umgewöhnunsaufwand ist zu leisten.
Mein Bauchgefühl gibt mir die Überzeugung dass dies VIEL Potential hat 
Dir zu gefallen; jedenfalls besser als irgendein Krampf per "modernem" 
WindowsXY.

Wilhelm S. schrieb:
> Noch zur allgemeinen Info:
> Alles läuft in der DOS-Box von XP. Ich bleibe bei XP, weil
> man da noch einen Vollbildschirm im DOS-Fenster bekommt.

Dann probier mal folgendes: Lösung für Win7 (und wahrscheinlich auch 
höher):

Win+R drücken -> im Fenster 'Ausführen' "cmd" eingeben -> Enter

Rechtsklick auf die obere 'Rahmenleiste' (in der sich auch das Kreuz zum 
Schliessen befindet) -> 'Eigenschaften' anklicken

Reiter Schriftart bzw Reiter Layout: Werte anpassen... vielleicht 
hilft's Dir ja irgendwie... ;-)


Meine Einstellungen:

Bildschirm-Auflösung: 1600 x 1200

Eigenschaften v. cmd.exe:

Layout
Fenstergrösse: Breite = 130 & Höhe = 68

Schriftart
Grösse = 12 x 16

Kommandozeile vor dem Frühstück für Alle! schrieb:
> Wenn Du "so Einer" bist, lass Dir empfehlen in bash & GNU-tools zu
> schnuppern. M.M.n. wird es Dir gefallen.

Ist mir genauso gegangen, bin seit Jahren Linux-Fan, am liebsten auf der 
Konsole. Habe aber manchmal noch ein W2k und ein WXP in der VM laufen. 
Auch auf SBC bin ich jetzt "angesprungen", z.B. RaspberryPi bzw. noch 
lieber OrangePi. Meine Lieblingssprache ist jetzt Python.

Falls Du bei Windows bleiben willst und eine vernünftige Konsole 
brauchst, probier mal ConEmu, die kann u.a. auch die schönen alten 
ANSI-Sequenzen (jaja ich weiss, W10 kann die auch wieder, aber wer will 
schon W10, wenn er Linux hat).

damit der Wilhelm DK4tj noch mehr Lust auf bash/GNU-tools/Linux bekommen 
soll:
(dieser Thread hat meine Neugierde auf WSPRNET angestachelt :-)

1

$ ## 2017-12-06  HB9ocq

2

$ 

3

$ ## auf  http://wsprnet.org/archive/  Stichprobedateien ausgesucht

4

$ ## Kriterium: Datenmenge --> ca. 5/40/200/580 MB als Ziparchive

5

$ 

6

$ echo "http://wsprnet.org/archive/wsprspots-2008-04.csv.zip" > urls.list

7

$ echo "http://wsprnet.org/archive/wsprspots-2012-07.csv.zip" >> urls.list

8

$ echo "http://wsprnet.org/archive/wsprspots-2016-01.csv.zip" >> urls.list

9

$ echo "http://wsprnet.org/archive/wsprspots-2017-10.csv.zip" >> urls.list

10

$

11

$ ## die 4 ausgesuchten Archive runterladen

12

$ cat urls.test | while read fn

13

> do  curl -O "$fn"

14

> done

15

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current

16

                                 Dload  Upload   Total   Spent    Left  Speed

17

100 4324k  100 4324k    0     0   665k      0  0:00:06  0:00:06 --:--:-- 1008k

18

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current

19

                                 Dload  Upload   Total   Spent    Left  Speed

20

100 36.2M  100 36.2M    0     0   931k      0  0:00:39  0:00:39 --:--:--  631k

21

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current

22

                                 Dload  Upload   Total   Spent    Left  Speed

23

100  197M  100  197M    0     0   967k      0  0:03:29  0:03:29 --:--:--  856k

24

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current

25

                                 Dload  Upload   Total   Spent    Left  Speed

26

100  580M  100  580M    0     0  1121k      0  0:08:50  0:08:50 --:--:-- 1216k

27

$ 

28

$ ## --> Download hat insges. 13..14 Minuten gedauert - da muss man durch.

29

$ 

30

$

31

$ ## wieviele Datensaetze in jedem Archiv vorhanden und wielange dauert die Zaehlung?  (beachte die Zeilen "real    MmSS.SSSs")

32

$ for fn in wsprspots-20*zip

33

> do

34

>    echo -n "## ${fn} : "

35

>    time  unzip -p "$fn" "${fn%%.zip}" | wc -l

36

> done

37

## wsprspots-2008-04.csv.zip : 362417

38

39

real  0m0.200s

40

user  0m0.192s

41

sys  0m0.024s

42

## wsprspots-2012-07.csv.zip : 2260108

43

44

real  0m1.481s

45

user  0m1.476s

46

sys  0m0.112s

47

## wsprspots-2016-01.csv.zip : 10462998

48

49

real  0m7.057s

50

user  0m7.084s

51

sys  0m0.548s

52

## wsprspots-2017-10.csv.zip : 32064173

53

54

real  0m20.869s

55

user  0m20.652s

56

sys  0m1.896s

57

$

58

$ ## --> letzlich werden 0.36/2.2/10/32 Mio Zeilen innert 0.2/1.5/7/21s entpackt und gezaehlt  

59

$ 

60

$

61

$ ## die Zeilen mit Bezug auf DK4tj selektionieren

62

$ for fn in wsprspots-20*zip

63

> do

64

>    WILHELMFILE="${fn%%.csv.zip}_DK4tj.csv"

65

>    echo -n "##  $WILHELMFILE "

66

>    time  unzip -p "$fn" "${fn%%.zip}" | grep --ignore-case 'DK4tj' > $WILHELMFILE

67

> done

68

##  wsprspots-2008-04_DK4tj.csv 

69

real  0m0.207s

70

user  0m0.268s

71

sys  0m0.016s

72

##  wsprspots-2012-07_DK4tj.csv 

73

real  0m1.498s

74

user  0m1.948s

75

sys  0m0.084s

76

##  wsprspots-2016-01_DK4tj.csv 

77

real  0m7.353s

78

user  0m9.164s

79

sys  0m0.548s

80

##  wsprspots-2017-10_DK4tj.csv 

81

real  0m21.252s

82

user  0m27.448s

83

sys  0m1.532s

84

$ 

85

$ ## HINWEIS!

86

$ ## das Zeichenmuster wonach mit  grep  selektiert wurde,

87

$ ## erfasst Zeilen welche irgendwie "DK4tj" (bel.Gr./Kl.Schreibung) enthalten!

88

$ ## ALSO AUCH Z.B. "DK4tja", "DK4tj6", "DK4tj/P", uvm.

89

$ ## Das ist ggfs. zu verschaerfen! --> Man lerne Mustersuche mit grep!

90

$ 

91

$

92

$ ##  und wieviele Eintraege nennen nun Wilhelm? Was dauert das Zaehlen?

93

$ time  wc -l wsprspots-20*DK4tj.csv

94

      0 wsprspots-2008-04_DK4tj.csv

95

   3653 wsprspots-2012-07_DK4tj.csv

96

  21151 wsprspots-2016-01_DK4tj.csv

97

  32529 wsprspots-2017-10_DK4tj.csv

98

  57333 total

99

100

real  0m0.010s

101

user  0m0.000s

102

sys  0m0.004s

103

$

104

$ ## wow: innert 10ms wurden knapp 60k Zeilen in 4 Dateien mit "DK4tj" gezaehlt!

105

$ 

106

$ 

107

$ ## Die Maschine hier:  ein betagter Laptop  HP 6730b, rund 10 J. alt.

108

$ ## Details

109

$ cat /proc/cpuinfo | grep -i intel

110

vendor_id  : GenuineIntel

111

model name  : Intel(R) Core(TM)2 Duo CPU     P8800  @ 2.66GHz

112

vendor_id  : GenuineIntel

113

model name  : Intel(R) Core(TM)2 Duo CPU     P8800  @ 2.66GHz

114

$

115

$ cat /proc/meminfo | grep -i ^Mem

116

MemTotal:        3944540 kB

117

MemFree:          492944 kB

118

MemAvailable:    1488728 kB

119

$

120

$ ## NB:

121

$ ## das aktuell genutze Arbeitsverzeichnis ($PWD) liegt quer durch's LAN auf dem anderen Rechner,

122

$ ## ist hier per sshfs eingebunden. Auf der HD d. Laptops hier ist das System installiert.

123

$ ## KEINE SSD-Tricks.

124

$

Der Vorteil: ausser des Diskplatzes fuer die geholten Datenarchive und 
die wenigen extrahierten Datensaetze welche konkret interessieren wurde 
dank Pipes kein weiterer Diskplatz verwendet.

Der Nachteil: das geht mit aus dem Ärmel geschuettelten Befehle 
dermassen schnell, dass jedes 'Rentier' in Stress kommt! Nix mer mit hab 
ja Zeit
;-)

73 de Stephan HB9ocq

Noch ein Hinweis fuer die Interpretation der mit time ermittelten 
Zeiten.
Von oben genommen:

1

:

2

real  0m7.353s

3

user  0m9.164s

4

sys  0m0.548s

5

:

Diese Maschine hat ein C2D Prozessor (Core2Duo), also 2 Physische 
Rechenkerne mit je HT (Hyperthreading) Faehigkeit was unter optimalen 
Umstaende auf 4 Kerne rauskommt.

real zeigt die "an der Wanduhr" verstrichene Zeit bis der Befehl durch 
ist

user zeigt die Zeit welche Prozesse im Namen d. Users werkelten, vulgo 
Numbercrunching

system zeigt die Zeit welche mit Systemaufrufe verbracht wurde, hier 
typ. Dateioperationen


F: Warum ist nun user groesser als real (Wanduhrzeit)? Das kann doch 
gar nicht sein, oder?
A: In der Zeit als Die "Wanduhrzeit" verstrich, wurden auf diversen 
Kerne Arbeiten gleichzeitig parallel abgearbeitet. Voila!

73 de Stephan HB9ocq

> Dann probier mal folgendes: Lösung für Win7 (und wahrscheinlich auch
> höher):

Stimmt zwar, aber das bringt noch nicht bash + GNU-tools daher.
(das zeigt nur in grösser wie eingeschränkt/mangelhaft CMD.EXE ist)

Mit "wahrscheinlich auch" liegst richtig: es sind solche "nebensächliche 
Kleinigkeiten" welche von Win- zu Win-Varianten vom Hersteller allzuoft 
und unnötigerweise verändert werden. Solches vergrault einem die Lust 
am Umsteigen jedes verdammte Mal !! (bei mir letztlich zum 
Totalboykott)

Nix gegen Neues und Änderungen: aber bitte im Kernbereich meiner 
Aufgaben UND mit deutlich ergiebigen Vorteilen.
Nicht bei Pillepallekram der zu Stolpersteine/Ostersuche/Zeitfresser 
mutiert; das hat einfach wie gewohnt zu funktionieren.
(nein, ich werde nicht Müde auf solchem herumzureiten)

c-hater schrieb:

> Ich versuche, den offensichtlichen Widerspruch anhand der noch
> vorhandenen Unterlagen aufzuklären...

Ich bin fündig geworden. Die Sache lief damals unter "Novell-DOS". Eine 
Art Multitasker-Aufsatz für MSDOS. War wohl sowas wie ein kastriertes 
Abfallprodukt der Novell "Netware"-Entwicklung für den kleinen 
Geldbeutel.

Features: Keinerlei Netzwerk-Funktionalität, aber preemptives 
Multitasking für DOS-Prozesse und relativ unkomplizierte Nutzung von 
Speicher jenseits der damaligen DOS-Grenzen (ohne manuelle 
Konfigurationsorgien in config.sys und autoexec.bat.)

Und, im Kontext dieses Threads, das Wesentliche: Tatsächlich echte 
Pipes...

J. F. schrieb:
> Python Skript mit Regex? Sollte relativ einfach gehen.

...damit diese konditionale Aussage nicht alleine im Raum stehen bleibt:

1

#!/usr/bin/env python

2

3

import sys, zipfile, re

4

5

def selectCallFromWSPRNET(ziparchive, reo):

6

    with zipfile.ZipFile(ziparchive, 'r') as za:

7

        for ln in za.open(ziparchive[:-4]):

8

            if reo.search(ln):

9

                print(ln.strip())

10

11

if (3 == len(sys.argv)):

12

    callreo = re.compile(call, flags=re.IGNORECASE)

13

    selectCallFromWSPRNET(sys.argv[1], callreo)

14

    sys.exit(0)

15

else:

16

    print("usage: %s <wsprspots-20xx-xx.csv.zip> <call>" % sys.argv[0])

17

    sys.exit(1)

Ob dies nun ein Memory-Hog ist beim durchstoebern von monströs grossen 
Ziparchive habe ich genausowenig überprueft wie ob es in Pipe-losen 
Umgebungen funktioniert (habe keine).

Ich setzte blind auf Python: das gibt es auch fuer alte Windowsen und 
die verwendeten Module sys zipfile und re gibt es alle seit Py2 also 
duerften da keine Hindernisse im Wege stehen.

Hier bei mir gezeugt und vollzogen unter Py2.7 auf Lubuntu 16.04.3 LTS.
Python3 will diesen Code allerdings nicht: irgendwas mit 
"reo.search(..)" passt ihm nicht. Ich mag dem jetzt nicht nachgehen, man 
verzeihe mir.

1

$ 

2

$ time  ./selectCallFromWSPRNET.py wsprspots-2008-04.csv.zip DK4tj > wsprspots-2008-04_DK4tj.py.csv

3

4

real  0m1.372s

5

user  0m1.152s

6

sys  0m0.004s

7

$ time  ./selectCallFromWSPRNET.py wsprspots-2012-07.csv.zip DK4tj > wsprspots-2012-07_DK4tj.py.csv

8

9

real  0m7.623s

10

user  0m7.424s

11

sys  0m0.036s

12

$ time  ./selectCallFromWSPRNET.py wsprspots-2016-01.csv.zip DK4tj > wsprspots-2016-01_DK4tj.py.csv

13

14

real  0m37.233s

15

user  0m36.392s

16

sys  0m0.236s

17

$ time  ./selectCallFromWSPRNET.py wsprspots-2017-10.csv.zip DK4tj > wsprspots-2017-10_DK4tj.py.csv

18

19

real  1m45.992s

20

user  1m43.948s

21

sys  0m0.556s

22

$

Die Ergebnisdateien sind md5sum nach bitidentisch mit denen oben per 
shell erzeugten.

Vergleicht man die Laufzeiten, sieht man dass ein guter 
S(c)h(n)ellschuss durchaus Geschwindigkeitsvorteile haben kann - 
"komplexe" Pipes hin oder her.

Es darf sich gerne jeder sportlich herausgefordert fuehlen, das kurze 
Pythonscript weiter zu beschleunigen oder Loesungen in anderen Sprachen 
ins Rennen zu schicken (diese sollten aber ebenfalls "auf einen 
Bierdeckel passen").


73 de Stephan

Oliver S. schrieb:
> usuru schrieb:
>> ANSI-Sequenzen (jaja ich weiss, W10 kann die auch wieder, aber wer will
>> schon W10, wenn er Linux hat).
>
> Da Windows10 inzwischen auch Linux kann, zumindest auf der
> Kommandozeile, müsste der Spruch eher umgekehrt lauten.
>
> Oliver

[  ] Bravo!

Kaufst wohl auch 'ne ganze Zaunfabrik, um allen zu mehr Freiheit zu 
verhelfen...