mikrocontroller.net

Forum: PC-Programmierung CSV-Datei teilen


Autor: Wilhelm Schürings (wilhelmdk4tj)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hallo zusammen.

Es geht um die CSV-Dateien, die WSPR als Monatsdaten bereit stellt.
Zur Info: WSPR = W(eak) S(ignal) P(ropagation) R(eporter)
Wer Genaueres wissen möchte:

http://wsprnet.org/drupal/

Hier wird u. a. unter 'Download' eine monatliche Liste aller
Verbindungen als *.zip eingestellt.

Ich habe folgendes Problem:
Nach dem Entpacken habe ich eine Riesen-CSV Datei mit ca. 2G
Mich interessieren ja erstmal nur meine eigenen Verbindungen.
Also selektieren. Aus den ..zig Millionen Datensätzen bleiben
für mich nur ein paar (..zig) tausend übrig.
Das nur zur Erklärung.
Zum Verarbeiten habe ich mir ein dBase/Clipper (Sorry, DOS-Mensch)
Programmm geschrieben, das die CSV-Datei einliest, und die für mich
wichtigen Datensätze selektiert. Hat geklappt; nachdem jedoch die
Dateigrösse in den letzten Jahren extrem angestiegen ist, steigt
mein Programm aus.
Ich denke, es liegt an der Dateigrösse.
Meine Idee: Das CSV-File in mehrere Teile spalten, die man ja dann
nach und nach verarbeiten könnte.
Wer hat eine, vielleicht auch andere, Idee?

73
Wilhelm

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

Autor: J. Fourier (Firma: Père Lachaise) (rect)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Python Skript mit Regex? Sollte relativ einfach gehen.

Autor: TestX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: Schwarzseher (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Thomas Sch. (doschi_)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
... oder awk. Das gibt es auch für Win*.
Suche nach Gawk.
Siehe z.B. Beitrag "Frage zu AWK"

: Bearbeitet durch User
Autor: guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Das Filtern der CSV-Datei geht auch mit Windows-Bordmitteln, dazu muss 
man keine *nix-Kommandozeilentools installieren.
findstr /c:"blabla" riesig.csv > gefiltert.csv

gibt alle in riesig.csv enthaltenen Zeilen, die "blabla" enthalten, in 
gefiltert.csv aus.


Das setzt natürlich voraus, daß die interessierenden Einträge so leicht 
zu identifizieren sind.

findstr kennt aber auch reguläre Ausdrücke ("regex"), so daß sich damit 
auch komplexere Filterkriterien konstruieren lassen.

https://technet.microsoft.com/en-us/library/bb490907.aspx

Autor: c-hater (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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...

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> 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.

Das willst Du unter DOS hinbekommen?

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?

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Ganz sicher bin ich jedenfalls, dass es keine Limitierung der Pipelänge
> gab,

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.

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tom schrieb:
> dass alles unter XP läuft...

Hab' ich dann wohl übersehen, bzw. wurde von "Clipper" und DOS 
überblendet.

Nun, wenn Wilhelm sich hier noch mal meldet, dann kann er ja vielleicht 
mehr über die benötigte Art der Filterung seiner CSV-Datei erzählen.


Das ist ja inhaltlich etwas knapp:

Wilhelm S. schrieb:
> Mich interessieren ja erstmal nur meine eigenen Verbindungen.
> Also selektieren.

Eventuell genügt einer der genannten Kommandozeilenansätze (sei es mit 
grep, findstr oder was auch immer).

Autor: Kolja L. (kolja82)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Das ist ja inhaltlich etwas knapp:

Könnte es so aussehen: http://wsprnet.org/drupal/wsprnet/spots
Timestamp  Call  MHz  SNR  Drift  Grid  Pwr  Reporter  RGrid  km  az
 2017-12-05 19:30    DL3NDR    0.475727    -27    0    JN59no    0.1    EA5DOM-1    IM98xn    1514    220 
 2017-12-05 19:30    DH5RAE    0.475766    -12    0    JN68qv    0.5    EA5DOM-1    IM98xn    1571    228 
 2017-12-05 19:30    EA3IW    0.475756    -18    0    JN11bj    0.001    EA5DOM-1    IM98xn    365    211 

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Kolja L. (kolja82)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oder so: Testing was carried out on Windows 8 Pro. CSV Splitter is also 
available for Windows 7, Vista & XP.

https://www.erdconcepts.com/dbtoolbox.html

Autor: Manfred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Manfred schrieb:
> Es wird aus einer Datei gelesen und direkt in eine andere geschrieben

Nein, eine Pipe ist was anderes.

Es geht nicht um
programm1 bla.txt > fusel.txt

sondern um
programm1 bla.txt | programm2

Die Ausgabe von Programm1 wird durch die Pipe (|) an Programm2 
übergeben.

("bla.txt" sei hier generischer Platzhalter für irgendwelche 
Kommandozeilenargumente für "programm1")

Beitrag #5234122 wurde von einem Moderator gelöscht.
Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In MS-DOS sind Pipes über temporäre Dateien implementiert, deswegen
nennt man sie auch Fake-Pipes

Aber der TE hat ja Windows XP, da sollte es auch echte Pipes geben. Ob
die |-Syntax in der Eingabeaufforderung diese tatsächlich nutzt, oder ob
dort aus Kompatibilitätsgründen immer noch temporäre Dateien verwendet
werden, weiß ich allerdings nicht.

Autor: Kommandozeile vor dem Frühstück für Alle! (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo kommen denn nun Pipes zum Einsatz?
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".

Autor: Kommandozeile vor dem Frühstück für Alle! (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
> 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

Autor: Schwarzseher (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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/mi...

Hut ab!

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kommandozeile vor dem Frühstück für Alle! schrieb:
> Wo kommen denn nun Pipes zum Einsatz?

Lies doch einfach mal das, was "c-hater" vorgeschlagen hat.

> Dass beim Entpacken u.U. die resultierende Datei nach 2GB abgewürgt wird
> ist doch eine Limitierung des Dateisystems.

Genau das würde seine Lösung nämlich umgehen, vorausgesetzt, daß beide 
Prozesse an den Enden der Pipe tatsächlich gleichzeitig arbeiten können.

Um es zusammenzufassen:
unzip monster.zip | find /i "blabla" > redux.csv

(vorausgesetzt, daß "unzip" auf diese Art und Weise aufgerufen auf 
stdout ausgibt)

Beitrag #5234394 wurde vom Autor gelöscht.
Autor: Wilhelm Schürings (wilhelmdk4tj)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hallo zusammen,

da habe ich ja eine Lawine losgetreten, oje.

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.

Ja, so sieht es aus:
> Timestamp  Call  MHz  SNR  Drift  Grid  Pwr  Reporter  RGrid  km  az
> 2017-12-05 19:30    DL3NDR    0.475727    -27    0    JN59no    0.1
> EA5DOM-1    IM98xn    1514    220
> 2017-12-05 19:30    DH5RAE    0.475766    -12    0    JN68qv    0.5
> EA5DOM-1    IM98xn    1571    228

Datum und Zeit liegen jedoch im Unix-Format als ein Item vor und
müssen noch entsprechend aufgebröselt werden; das ist aber kein
Problem.

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. Macht nix, als 'Rentier' habe ich ja Zeit genug.

Bzgl. Programmieren:
Ich bin zwar kein Profi, aber auch als Laie kann man ordentliche
Arbeit abliefern. Für meine Apotheke habe ich in dBase/Clipper
vor Jahren eine Anwendung geschrieben, die das Wichtigste für
den Apothekenalltag erledigte, nämlich in einer Liste nachsehen zu
können und Rezepte zu bedrucken. Mit diesem Programm ist 7 Jahre ohne
Fehler und Mecker Geld verdient worden. Es waren am Schluss
fast 400.000 Datensätze. Ca. 250.000 Zeichen Quellcode.
Also so ganz unbedarft bin ich nicht. Was andere mit Excel erledigen,
mache ich heute noch mit dBase im Handbetrieb. Geht auch.

Ich danke euch allen für eure Tips; mein Problem ist damit gelöst.

73
Wilhelm

PS:
@C-Hater
Ist dein Name Programm?

: Bearbeitet durch User
Autor: nicht"Gast" (Gast)
Datum:

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

Oh ja. Davon kannst du ausgehen.

Autor: Kommandozeile vor dem Frühstück für Alle! (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: usuru (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Stephan (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
damit der Wilhelm DK4tj noch mehr Lust auf bash/GNU-tools/Linux bekommen 
soll:
(dieser Thread hat meine Neugierde auf WSPRNET angestachelt :-)
$ ## 2017-12-06  HB9ocq
$ 
$ ## auf  http://wsprnet.org/archive/  Stichprobedateien ausgesucht
$ ## Kriterium: Datenmenge --> ca. 5/40/200/580 MB als Ziparchive
$ 
$ echo "http://wsprnet.org/archive/wsprspots-2008-04.csv.zip" > urls.list
$ echo "http://wsprnet.org/archive/wsprspots-2012-07.csv.zip" >> urls.list
$ echo "http://wsprnet.org/archive/wsprspots-2016-01.csv.zip" >> urls.list
$ echo "http://wsprnet.org/archive/wsprspots-2017-10.csv.zip" >> urls.list
$
$ ## die 4 ausgesuchten Archive runterladen
$ cat urls.test | while read fn
> do  curl -O "$fn"
> done
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 4324k  100 4324k    0     0   665k      0  0:00:06  0:00:06 --:--:-- 1008k
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 36.2M  100 36.2M    0     0   931k      0  0:00:39  0:00:39 --:--:--  631k
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  197M  100  197M    0     0   967k      0  0:03:29  0:03:29 --:--:--  856k
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  580M  100  580M    0     0  1121k      0  0:08:50  0:08:50 --:--:-- 1216k
$ 
$ ## --> Download hat insges. 13..14 Minuten gedauert - da muss man durch.
$ 
$
$ ## wieviele Datensaetze in jedem Archiv vorhanden und wielange dauert die Zaehlung?  (beachte die Zeilen "real    MmSS.SSSs")
$ for fn in wsprspots-20*zip
> do
>    echo -n "## ${fn} : "
>    time  unzip -p "$fn" "${fn%%.zip}" | wc -l
> done
## wsprspots-2008-04.csv.zip : 362417

real  0m0.200s
user  0m0.192s
sys  0m0.024s
## wsprspots-2012-07.csv.zip : 2260108

real  0m1.481s
user  0m1.476s
sys  0m0.112s
## wsprspots-2016-01.csv.zip : 10462998

real  0m7.057s
user  0m7.084s
sys  0m0.548s
## wsprspots-2017-10.csv.zip : 32064173

real  0m20.869s
user  0m20.652s
sys  0m1.896s
$
$ ## --> letzlich werden 0.36/2.2/10/32 Mio Zeilen innert 0.2/1.5/7/21s entpackt und gezaehlt  
$ 
$
$ ## die Zeilen mit Bezug auf DK4tj selektionieren
$ for fn in wsprspots-20*zip
> do
>    WILHELMFILE="${fn%%.csv.zip}_DK4tj.csv"
>    echo -n "##  $WILHELMFILE "
>    time  unzip -p "$fn" "${fn%%.zip}" | grep --ignore-case 'DK4tj' > $WILHELMFILE
> done
##  wsprspots-2008-04_DK4tj.csv 
real  0m0.207s
user  0m0.268s
sys  0m0.016s
##  wsprspots-2012-07_DK4tj.csv 
real  0m1.498s
user  0m1.948s
sys  0m0.084s
##  wsprspots-2016-01_DK4tj.csv 
real  0m7.353s
user  0m9.164s
sys  0m0.548s
##  wsprspots-2017-10_DK4tj.csv 
real  0m21.252s
user  0m27.448s
sys  0m1.532s
$ 
$ ## HINWEIS!
$ ## das Zeichenmuster wonach mit  grep  selektiert wurde,
$ ## erfasst Zeilen welche irgendwie "DK4tj" (bel.Gr./Kl.Schreibung) enthalten!
$ ## ALSO AUCH Z.B. "DK4tja", "DK4tj6", "DK4tj/P", uvm.
$ ## Das ist ggfs. zu verschaerfen! --> Man lerne Mustersuche mit grep!
$ 
$
$ ##  und wieviele Eintraege nennen nun Wilhelm? Was dauert das Zaehlen?
$ time  wc -l wsprspots-20*DK4tj.csv
      0 wsprspots-2008-04_DK4tj.csv
   3653 wsprspots-2012-07_DK4tj.csv
  21151 wsprspots-2016-01_DK4tj.csv
  32529 wsprspots-2017-10_DK4tj.csv
  57333 total

real  0m0.010s
user  0m0.000s
sys  0m0.004s
$
$ ## wow: innert 10ms wurden knapp 60k Zeilen in 4 Dateien mit "DK4tj" gezaehlt!
$ 
$ 
$ ## Die Maschine hier:  ein betagter Laptop  HP 6730b, rund 10 J. alt.
$ ## Details
$ cat /proc/cpuinfo | grep -i intel
vendor_id  : GenuineIntel
model name  : Intel(R) Core(TM)2 Duo CPU     P8800  @ 2.66GHz
vendor_id  : GenuineIntel
model name  : Intel(R) Core(TM)2 Duo CPU     P8800  @ 2.66GHz
$
$ cat /proc/meminfo | grep -i ^Mem
MemTotal:        3944540 kB
MemFree:          492944 kB
MemAvailable:    1488728 kB
$
$ ## NB:
$ ## das aktuell genutze Arbeitsverzeichnis ($PWD) liegt quer durch's LAN auf dem anderen Rechner,
$ ## ist hier per sshfs eingebunden. Auf der HD d. Laptops hier ist das System installiert.
$ ## KEINE SSD-Tricks.
$ 

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

Autor: Stephan (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Noch ein Hinweis fuer die Interpretation der mit time ermittelten 
Zeiten.
Von oben genommen:
:
real  0m7.353s
user  0m9.164s
sys  0m0.548s
:

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

Autor: Kommandozeile vor dem Frühstück für Alle! (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
> 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)

Autor: c-hater (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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...

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die sachliche und fundierte Rückmeldung.

Verschiedene dieser DOS-Multitasker hab' ich mir auch mal angesehen, es 
wurde dann für ein Projekt dann doch Windows 3.0 (auf einem 386). Das 
hatte den Vorteil der netten graphischen Oberfläche und schon damals 
recht weiten Unterstützung für Bildschirmtreiber.
In meinem Fall musste eh' nur eine DOS-Task parallel zu einem 
Windows-Programm laufen, und die Kommunikation zwischen der DOS-Task und 
dem Windows-Programm lief über einen DOS-Devicetreiber (so ziemlich dem 
einzigen x86-Assemblerprogramm, das ich jemals geschrieben habe). 
Immerhin, der Kram(pf) funktionierte.

Gott, was bin ich froh, das alles hinter mir zu haben.

Aber ich schweife ab ...

Autor: Stephan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
J. F. schrieb:
> Python Skript mit Regex? Sollte relativ einfach gehen.

...damit diese konditionale Aussage nicht alleine im Raum stehen bleibt:
#!/usr/bin/env python

import sys, zipfile, re

def selectCallFromWSPRNET(ziparchive, reo):
    with zipfile.ZipFile(ziparchive, 'r') as za:
        for ln in za.open(ziparchive[:-4]):
            if reo.search(ln):
                print(ln.strip())

if (3 == len(sys.argv)):
    callreo = re.compile(call, flags=re.IGNORECASE)
    selectCallFromWSPRNET(sys.argv[1], callreo)
    sys.exit(0)
else:
    print("usage: %s <wsprspots-20xx-xx.csv.zip> <call>" % sys.argv[0])
    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.
$ 
$ time  ./selectCallFromWSPRNET.py wsprspots-2008-04.csv.zip DK4tj > wsprspots-2008-04_DK4tj.py.csv

real  0m1.372s
user  0m1.152s
sys  0m0.004s
$ time  ./selectCallFromWSPRNET.py wsprspots-2012-07.csv.zip DK4tj > wsprspots-2012-07_DK4tj.py.csv

real  0m7.623s
user  0m7.424s
sys  0m0.036s
$ time  ./selectCallFromWSPRNET.py wsprspots-2016-01.csv.zip DK4tj > wsprspots-2016-01_DK4tj.py.csv

real  0m37.233s
user  0m36.392s
sys  0m0.236s
$ time  ./selectCallFromWSPRNET.py wsprspots-2017-10.csv.zip DK4tj > wsprspots-2017-10_DK4tj.py.csv

real  1m45.992s
user  1m43.948s
sys  0m0.556s
$ 

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

Autor: Oliver S. (oliverso)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: Foristenversteher (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.