Python Skript zum Einlesen von Comdirect Wertpapierabrechnungen

[ZappBrannigan]

Hallo,

 

nachdem ich es einige Zeit versäumt habe über die Käufe, Umschichtungen und Ausschüttungen in meinem Depot Buch zu führen, habe ich mich gestern endlich mal daran gesetzt dies nachzuholen. Dazu habe ich zunächst alle Wertpapierabrechnungen und Ertragsmeldungen von Comdirect im pdf-Format heruntergeladen um dann die enthaltenen Informationen manuell in ein Spreadsheet einzutragen. Meine Geduld dabei währte ganze 15 min bis ich beschloss ein Skript zu schreiben um diese stupide Arbeit zu automatisieren. Vielleicht ist das Skript ja doch auch für den einen oder anderen nützlich.

 

Das Skript ist noch extrem rudimentär, nicht sonderlich schön geschrieben (bin eigentlich mehr C/C++ und matlab gewohnt), hat dafür aber bisher alle meine Comdirect-Wertpapierabrechnungen gelesen. Ich habe es aber auch nur mit ETF- und Anleihenabrechnungen getestet. Es kann durchaus sein, dass die Abrechnungen für andere Wertpapiere leicht anders aussehen. In diesem Fall gilt es die regulären Ausdrücke entsprechend anzupassen (die in meinem Skript zugegebenermaßen übel aussehen - ich hab die noch nie gemocht und mir entsprechend wenig Mühe gegeben).

 

Das Skript ist im übrigen in python geschrieben und benötigt neben python auch einige python-Pakete um zu funktionieren: argparse (Kommandozeilen-Schnittstelle), pdfminer (pdf in string umwandeln), xlsxwriter

 

Hier erstmal ein kleines Beispiel:

$ python parseComdirectPDF.py *.pdf -o wertpapiere.xlsx

 

Ergebnis: Wertpapierabrechnungen (Verkäufe habe ich einfach mit negativem Nenn- & Kurswert gekennzeichnet):

 

 

und hier die Ertragsmeldungen (auf zweitem Sheet in der gleichen Datei):

 

parseComdirectPDF.py.zip

[Schinzilord]

Super Idee, danke dafür!

Hatte ich noch gar nicht auf dem Radar, PDFs einzulesen.

Ich schaue mir dein Skript auf alle Fälle an.

[shadow]

Super Idee ! Ich steh vorm gleichen Problem und möchte mal wissen ob und wieviel Gewinn und Verlust ich die letzten Jahre genau gemacht habe ! Leider bekomme ich Fehler gemeldet

 

C:\Users\internet\Documents\python\parse_comdirekt>parseComdirectPDF.py 1.pdf -o

out.xls

Traceback (most recent call last):

File "C:\Users\internet\Documents\python\parse_comdirekt\parseComdirectPDF.py", line 276, in <module> text = convert_pdf_to_txt(f)

File "C:\Users\internet\Documents\python\parse_comdirekt\parseComdirectPDF.py", line 34, in convert_pdf_to_txt interpreter.process_page(pages.next())

File "C:\Python27\lib\site-packages\pdfminer-20140328-py2.7.egg\pdfminer\pdfpage.py", line 121, in get_pages doc = PDFDocument(parser, password=password, caching=caching)

File "C:\Python27\lib\site-packages\pdfminer-20140328-py2.7.egg\pdfminer\pdfdocument.py", line 315, in __init__ xref.load(parser)

File "C:\Python27\lib\site-packages\pdfminer-20140328-py2.7.egg\pdfminer\pdfdocument.py", line 175, in load (_, obj) = parser.nextobject()

File "C:\Python27\lib\site-packages\pdfminer-20140328-py2.7.egg\pdfminer\psparser.py", line 557, in nextobject (pos, token) = self.nexttoken()

File "C:\Python27\lib\site-packages\pdfminer-20140328-py2.7.egg\pdfminer\psparser.py", line 482, in nexttoken self.fillbuf()

File "C:\Python27\lib\site-packages\pdfminer-20140328-py2.7.egg\pdfminer\psparser.py", line 215, in fillbuf raise PSEOF('Unexpected EOF')

pdfminer.psparser.PSEOF: Unexpected EOF

 

Egal was ich Ihm vorwerfe ! Ich denke mal es handelt sich um ein Problem Linux/Windows !??

[Mr. Jones]

Na ja, EOF = end of file. Falsche Codierung?

[shadow]

Na ja, EOF = end of file. Falsche Codierung?

 

Das dachte ich auch gleich und nachdem ich die erste Zeile gelöscht hatte in der der Verweis auf (usr/bin/python) stand lief auch das Programm nur hat es jetzt scheinbar ein Problem mit der Codierung der PDFs. Wahrscheinlich kann man die Kodierung irgendwo im Pdfminer angeben !? So gut bin ich in Python (noch) nicht !

[shadow]

Also wenn ich mit Notepad++ das Pythonfile in "UTF-8" konvertiere und das als Header eintrage

 

#!C:\Python27\python.exe

# -*- coding: utf-8 -*-

 

siehe https://www.python.org/dev/peps/pep-0263/

 

C:\Users\internet\Documents\python\parse_comdirekt\ori>parseComdirectPDF.py 1.pd

f -o out.xls

Traceback (most recent call last):

File "C:\Users\internet\Documents\python\parse_comdirekt\ori\parseComdirectPDF

.py", line 280, in <module>

text = convert_pdf_to_txt(f)

File "C:\Users\internet\Documents\python\parse_comdirekt\ori\parseComdirectPDF

.py", line 38, in convert_pdf_to_txt

interpreter.process_page(pages.next())

File "C:\Python27\lib\site-packages\pdfminer-20140328-py2.7.egg\pdfminer\pdfpa

ge.py", line 121, in get_pages

doc = PDFDocument(parser, password=password, caching=caching)

File "C:\Python27\lib\site-packages\pdfminer-20140328-py2.7.egg\pdfminer\pdfdo

cument.py", line 315, in __init__

xref.load(parser)

File "C:\Python27\lib\site-packages\pdfminer-20140328-py2.7.egg\pdfminer\pdfdo

cument.py", line 175, in load

(_, obj) = parser.nextobject()

File "C:\Python27\lib\site-packages\pdfminer-20140328-py2.7.egg\pdfminer\pspar

ser.py", line 557, in nextobject

(pos, token) = self.nexttoken()

File "C:\Python27\lib\site-packages\pdfminer-20140328-py2.7.egg\pdfminer\pspar

ser.py", line 482, in nexttoken

self.fillbuf()

File "C:\Python27\lib\site-packages\pdfminer-20140328-py2.7.egg\pdfminer\pspar

ser.py", line 215, in fillbuf

raise PSEOF('Unexpected EOF')

pdfminer.psparser.PSEOF: Unexpected EOF

 

Wenn ich mein PDF mit pdf2txt.py teste geht es wunderbar also muss doch in 215 !? der Fehler liegen oder ? Da wird das xls geschrieben

for f in keys:

row+=1

if 'datum' in f:

215 worksheet.write(row, 0, f['datum'], date_format)

if 'name' in f:

??

[ZappBrannigan]

Wenn ich mein PDF mit pdf2txt.py teste geht es wunderbar also muss doch in 215 !? der Fehler liegen oder ? Da wird das xls geschrieben

for f in keys:

row+=1

if 'datum' in f:

215 worksheet.write(row, 0, f['datum'], date_format)

if 'name' in f:

??

Nein, die Zeile 215 bezieht sich auf die Datei "psparser.py", die zum Paket pdfminer gehört.

 

Der Fehler tritt beim folgenden Aufruf auf "interpreter.process_page(pages.next())". Ich weiß leider auch nicht genau, was da schief läuft. Es kann aber sein, dass du eine andere pdfminer-Version hast. Ich habe gerade das Problem, dass sich die API (Schnittstelle) nach einem Update geändert hat und ich das Skript erstmal anpassen muss - du hast aber definitiv nicht das gleiche Problem wie ich (beim neuen pdfminer gibt es gar kein PDFPage mehr).

 

Du könntest mal probieren "interpreter.process_page(pages.next())" und die Zeile davor durch folgendes zu ersetzen:

for page in PDFPage.get_pages(fp, pagenos, maxpages=maxpages, password=password,caching=caching, check_extractable=True):
interpreter.process_page(page)

Ich bin allerdings leider nicht allzu hoffnungsvoll, dass das funktioniert.

[Chartwaves]

Würde es fürs erste nicht reichen zu sagen, welche Versionen der jeweiligen Pakete man benötigt damit es läuft?

 

Also:

Python Version soundso

argparse Version soundso

pdfminer Version soundso

xlsxwriter Version soundso.

[ZappBrannigan]

Würde es fürs erste nicht reichen zu sagen, welche Versionen der jeweiligen Pakete man benötigt damit es läuft?

Bei PDFMiner (welches gerade das Problem ist), ist das gar nicht so einfach, da es keine Versionsnummern gibt (ist ein sehr kleines Projekt). Ich gehe stark davon aus, dass die Version, die funktioniert, folgende ist (siehe hier):

• 2013/10/22: Sudden resurge of interests. API changes. Incorporated a lot of patches and robust handling of broken PDFs.

Ältere Versionen scheinen das beschriebene Problem zu haben, bei neueren Versionen gibt es weitere API-Änderungen, für die ich das Skript erst einmal anpassen muss. Das werde ich auch machen und ich kann das Skript dann auch gerne hier wieder online stellen - allerdings wird es dann ziemlich sicher nur noch mit der aktuellsten PDFMiner-Version funktionieren.

[shadow]

Also meine Versionen sind

C:\Users\internet\Documents\python\parse_comdirekt\ori>pip freeze

QSTK==0.2.6

matplotlib==1.1.1

numpy==1.6.1

pandas==0.11.0

pdf2text==1.0.0

pdfminer==20140328

python-dateutil==1.5

pytz==2014.10

scikit-learn==0.13

scipy==0.11.0

statsmodels==0.4.3

xlsxwriter==0.6.6

 

Ich finde das Problem sieht so danach aus das irgendwo bei Windows mal wieder ein UTF-8 Problem ist. Wahrscheinlich im String der aus dem Pdf eingelesen wird !?

Wie z.B. sowas ?

 

http://stackoverflow.com/questions/6870214/python-special-characters-giving-me-problems-from-pdfminer/6873578#6873578

 

aber hatte keinen Erfolg !

[ZappBrannigan]

Ich habe das Skript gerade überarbeitet. Es verwendet jetzt das Paket 'slate', welches das Handling mit pdfMiner um einiges vereinfacht, und daher hoffentlich auch etwas versionunabhängiger ist. Du müsstet allerdings evtl. noch slate nachinstallieren (evtl. einfach mit 'pip install slate', falls pip installiert ist).

 

Hier mal die von mir verwendeten Paketversionen:

 

python: 2.7.8

argparse 1.2.1

xslxwriter: 0.5.2

slate: 0.3

pdfminer: 20110515 (wird allerdings gar nicht mehr direkt importiert, sondern von slate gewrapped)

 

Sieht für mich so aus, als könnte die bei dir sehr neue pdfminer-Version das Problem sein. Hoffentlich klappt das mit slate besser - hier wird wirklich nur eine einzige Zeile zum Einlesen des PDFs benötigt, API Änderungen sollten sich daher kaum auswirken (solange slate und pdfminer miteinander zurecht kommen).

[shadow]

Nur mal als Hinweis. Das passiert nach

#pip install slate

C:\Users\internet\Documents\python\parse_comdirekt>parseComdirectPDF_slate.py 1.pdf -o out.xls

File "C:\Users\internet\Documents\python\parse_comdirekt\parseComdirectPDF_slate.py", line 67

SyntaxError: Non-ASCII character '\xc3' in file C:\Users\internet\Documents\python\parse_comdirekt\parseComdirectPDF_slate.py on line 67, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details

 

nach löschen in der ersten Zeile alles bis auf (davor stehen irgendwelche komischen Zeichen .. wahrscheinlich UTF-8 BOM von Linux!?)

#!/usr/bin/env python

 

 

C:\Users\internet\Documents\python\parse_comdirekt>parseComdirectPDF_slate.py 1.pdf -o out.xls

Traceback (most recent call last):

File "C:\Users\internet\Documents\python\parse_comdirekt\parseComdirectPDF_slate.py", line 257, in <module>

text = convert_pdf_to_txt(f)

File "C:\Users\internet\Documents\python\parse_comdirekt\parseComdirectPDF_slate.py", line 19, in convert_pdf_to_txt

import slate

File "C:\Python27\lib\site-packages\slate\__init__.py", line 48, in <module>

from slate import PDF

File "C:\Python27\lib\site-packages\slate\slate.py", line 3, in <module>

from pdfminer.pdfparser import PDFParser, PDFDocument

ImportError: cannot import name PDFDocument

 

Auch ein zusätzliches konvert mit notepad++ in Windows (CRLF) und UTF8 hilft nicht.

Das sieht wohl eher nach einer falschen dependencie aus !? pdfminer zu neu bei mir von 201403 ?

 

import argparse

import sys

import re

import xlsxwriter

from datetime import datetime

print sys.stdout.encoding

 

Das ergibt "cp850" https://wiki.python.org/moin/PrintFails

 

??

 

 

[ZappBrannigan]

Oder ist es wirklich das Encoding. Evtl. hilft es aus den strings, die die regulären Ausdrücke definieren, unicode-strings zu machen.

 

Vermutlich stand in der Zeile 67 bei dir folgendes (Zeile gegenüber meiner leicht verschoben, da du ja die ersten Zeilen gelöscht hast):

a = re.search('Geschäftstag[ ]*: (\d{2}\.\d{2}\.\d{4})',text)

 

Setz da mal ein u vor den String:

 

a = re.search(u'Geschäftstag[ ]*: (\d{2}\.\d{2}\.\d{4})',text)

 

Eigentlich sollte die Zeile

# -*- coding: utf-8 -*-

 

am Beginn der Datei, dies überflüssig machen. Vielleicht funktioniert das unter Windows aber nicht (da hab ich wirklich Null Erfahrung mit).

[shadow]

ok .

mit u' im search

und folgendem

pip freeze

pip uninstall pdfminer

pip install --upgrade --ignore-installed slate==0.3 pdfminer==20110515

pip freeze

 

Also downgrade auf 20110515 sagte es mir jetzt das meine Datei nicht kennt ... sollte es aber jetzt probier ich nochmal ohne u' .. ne Wertpapierkauf erkennt es nicht !?

[shadow]

for f in args.pdf:

text = convert_pdf_to_txt(f)

print "Text",text

if text.find(u'Gutschrift fälliger Wertpapier-Erträge')>0:

gutschrift.append(parse_gutschrift(text))

elif text.find(u'GESCHÄFTSABRECHNUNG VOM ')>0:

abrechnung.append(parse_abrechnung(text))

else:

print 'kenne die datei nicht'

 

 

C:\Users\internet\Documents\python\parse_comdirekt>parseComdirectPDF_slate.py "G

utschrift_thesaurierend_50000_St._WKN_DBX0AL_(DB_X-TR.II-IB.GL.IN.-L.1C)_vom_31.

12.2014540244.pdf" -o out.xls

cp850

Text 25449Quickborn♀

kenne die datei nicht

 

Muss der String noch konvertiert werden ? Da Fehlt ja viel !

[Chartwaves]

Eigentlich sollte die Zeile

# -*- coding: utf-8 -*-

 

am Beginn der Datei, dies überflüssig machen. Vielleicht funktioniert das unter Windows aber nicht (da hab ich wirklich Null Erfahrung mit).

 

In der Thememeröffnung war allerdings nicht die Rede davon, dass das Skript ausschließlich unter Linux funktioniert. Als gewöhnlicher Benutzer nimmt man ja erstmal an, dass es unter Windows tun sollte. Und womit? Mit Recht.

[ZappBrannigan]

C:\Users\internet\Documents\python\parse_comdirekt>parseComdirectPDF_slate.py "G

utschrift_thesaurierend_50000_St._WKN_DBX0AL_(DB_X-TR.II-IB.GL.IN.-L.1C)_vom_31.

12.2014540244.pdf" -o out.xls

cp850

Text 25449Quickborn♀

kenne die datei nicht

 

Muss der String noch konvertiert werden ? Da Fehlt ja viel !

Sind die entsprechenden Strings, nach denen gesucht wird, denn in der Datei vorhanden (also 'Gutschrift...' bzw. 'GESCHÄFTSABRECHNUNG'...)? Wenn ja, dann liegt vermutlich immer noch ein unicode-Problem vor. Wenn nein, dann ist mir bisher solch ein PDF noch nicht unter gekommen, d.h. die Suchstrings müssten entsprechend angepasst werden. Gleiches gilt evtl. auch für die regulären Ausdrücke in parse_gutschrift bzw. parse_abrechnung.

 

Es tut mir wirklich Leid, dass du mit sovielen Schwierigkeiten zu kämpfen hast. Hoffentlich finden wir da noch eine Lösung. Wenn du viele Abrechnungen auswerten möchtest, sollte sich die hier eingesetzte Zeit aber lohnen. Die Abrechnungen und Gutschriften der letzten zwei Jahre sind bei mir mit dem Skript in 2 min konvertiert (130 Dateien).

 

In der Thememeröffnung war allerdings nicht die Rede davon, dass das Skript ausschließlich unter Linux funktioniert. Als gewöhnlicher Benutzer nimmt man ja erstmal an, dass es unter Windows tun sollte. Und womit? Mit Recht.

Sorry, aber ich habe das Skript hier in der Hoffnung hingestellt das es auch anderen nützlich ist. Ich bin gerne bereit Hilfe zu leisten wenn jemand so wie shadow höflich fragt und konstruktiv mitarbeitet. Ich habe auch ziemlich deutlich gesagt, dass ich es an einem nachmittag geschrieben habe und es ziemlich unausgereift ist. Wie du also mit Recht erwarten kannst, dass es auf Anhieb unter einem anderen Betriebssystem und mit anderen python-Paketversionen laufen sollte, ist mir nicht ganz klar. Das hat gar nichts mit Windows vs. Linux zu tun.

 

 

edit: Das mit dem 'u' im regulären Ausdrück war übrigens Blödsinn. Damit werden bei mir die Ausdrücke auch nicht mehr erkannt. Also wieder raus damit.

[Chartwaves]

Sorry, aber ich habe das Skript hier in der Hoffnung hingestellt das es auch anderen nützlich ist. Ich bin gerne bereit Hilfe zu leisten wenn jemand so wie shadow höflich fragt und konstruktiv mitarbeitet. Ich habe auch ziemlich deutlich gesagt, dass ich es an einem nachmittag geschrieben habe und es ziemlich unausgereift ist. Wie du also mit Recht erwarten kannst, dass es auf Anhieb unter einem anderen Betriebssystem und mit anderen python-Paketversionen laufen sollte, ist mir nicht ganz klar. Das hat gar nichts mit Windows vs. Linux zu tun.

 

Sag mal, rede ich irgendwie Chinesisch oder was?

 

Du stellst hier ein Skript rein. Es fehlt in der Themeneröffnung jegliche Information darüber, 1.) unter welchem Betriebssystem es entwickelt wurde und 2.) welche Pakete man in welcher Version braucht, damit es läuft.

 

Jeder normale Mensch würde dann zunächst einmal erwarten, dass es in einer Standardkonfiguration läuft, wenn nichts anderes angegeben ist. Standard für PCs ist aber nun mal Windows und nicht Linux. Ist das wirklich so schwer zu verstehen? Zumal Python-Code an sich nicht betriebssystemabhängig ist.

[ZappBrannigan]

Jeder normale Mensch würde dann zunächst einmal erwarten, dass es in einer Standardkonfiguration läuft, wenn nichts anderes angegeben ist. Standard für PCs ist aber nun mal Windows und nicht Linux. Ist das wirklich so schwer zu verstehen? Zumal Python-Code an sich nicht betriebssystemabhängig ist.

Eben letzeres hatte ich eben auch erwartet. Leider gibt es dann aber eben doch einige Paketabhängigkeiten etc. (deren Versionen ich hier mittlerweile auch gepostet habe). Gerade von PDFMiner scheinen einige Versionen im Umlauf zu sein, deren APIs sich alle deutlich unterscheiden. Ist eben auch nur ein sehr kleines OS-Projekt.

 

Warum du hier so einen aggressiven Ton anschlägst ist mir allerdings echt unbegreiflich. Wenn du kein Interesse an dem Skript hast und nichts konstruktives beizutragen hast dann ist mir nicht ganz klar was du hier willst.

[ZappBrannigan]

So, ich habe gerade mal die Datei von allen Unicode-Strings befreit, d.h. jetzt functioniert es auch ohne 'magic encoding comment' am Anfang. Wenn das nicht funktioniert, dann weiß ich auch nicht weiter.

parseComdirectPDF.py.zip

[StBa]

Hallo ZappBrannigan,

 

vielen Dank für Dein wahnsinnig hilfreiches Script.

 

Ich habe das neue Script noch nicht ausprobiert, aber das alte tat bei mir unter windows, nachdem ich

- von hier den pdfminer installiert habe http://www.unixuser.org/~euske/python/pdfminer/#download

- und das hier: 'r' durch 'rb' ersetzt habe

parser.add_argument('pdf',metavar='pdf',nargs='*',type=argparse.FileType('rb'),help='Comdirect\

 

Ob nicht allein das 2. zum Erfolg führte... wer weiß :-)

 

Noch 2 vielleicht hilfreiche Tipps für irgendwen

a) Regex propbiere ich immer hier aus http://regexr.com/ , finde ich ne tolle Seite (aber Deine Regex sind eh tausendmal ausgefuchster als meine...)

b) unter Windows wird *.pdf im Aufruf nicht funktionieren (man sieht ja schon an Deiner Kommandozeile, dass Du nicht unter Win entwickelt hast)

da behelfe ich mir so:

@echo off & SETLOCAL EnableDelayedExpansion
for /F %%a in ('dir /B *.pdf') do (
set bb=!aa!
set aa=%%a !bb!
)
python  parseComdirectPDF.py -o test.xlsx !aa!

 

und noch zur Kritik:

Wenn mir ein Kunde mit solch einer Kritik zu einem kostenlos bereitgestellten Script kommt, dann bekommt der Vorgesetzte einen Anruf. Da wird dann geklärt, welche Leistung man ohne Bezahlung erwarten kann, und ob der Ton einer partnerschaftlichen Zusammenarbeit angemessen ist. Testen (auch gar plattformabhängigkeiten) und Doku kosten Zeit ;-)

Ein Script ist eben auch nicht für jeden gedacht, manche brauchen mehr Führung und für die muss es halt richtige Software sein...

 

Nochmals vielen vielen Dank, denn Du hast bestimmt auch Besseres zu tun, als ein für Dich funktionierendes Script für andere anzupassen.

 

Viele Grüße,

StBa

 

(edit: überflüssige Codezeilen entfernt)

[shadow]

So, ich habe gerade mal die Datei von allen Unicode-Strings befreit, d.h. jetzt functioniert es auch ohne 'magic encoding comment' am Anfang. Wenn das nicht funktioniert, dann weiß ich auch nicht weiter.

 

Also ich verstehe dich und möchte mich explizit für den Code bedanken ! Ich sollte eigentlich auch ein Betriebssystem benutzen und nicht Windows

[shadow]

Heureka !

 

Im Libreoffice Calc musste ich nur die direkte Formatierung wegnehmen !? Da muss ich nochmal schauen aber ansonsten war es wohl "rb" anstatt "r" !!:)

parseComdirectPDF.zip

[ZappBrannigan]

Heureka !

 

Im Libreoffice Calc musste ich nur die direkte Formatierung wegnehmen !? Da muss ich nochmal schauen aber ansonsten war es wohl "rb" anstatt "r" !!:)

Sehr schön, freut mich das es funktioniert! Und danke für deine netten Worte. Aber was genau meinst du mit 'direkter Konvertierung'?

 

und noch zur Kritik:

Wenn mir ein Kunde mit solch einer Kritik zu einem kostenlos bereitgestellten Script kommt, dann bekommt der Vorgesetzte einen Anruf. Da wird dann geklärt, welche Leistung man ohne Bezahlung erwarten kann, und ob der Ton einer partnerschaftlichen Zusammenarbeit angemessen ist. Testen (auch gar plattformabhängigkeiten) und Doku kosten Zeit ;-)

Ein Script ist eben auch nicht für jeden gedacht, manche brauchen mehr Führung und für die muss es halt richtige Software sein...

Ja, offenbar hätte ich davor warnen sollen. Ich dachte eigentlich, dass 'unausgereiftes Python Skript' schon genug Warnung war.

 

Dein Hinweis mit dem Filemodus 'rb' statt 'r' war ja wohl ein Volltreffer . Dein kleines Shell-Skript scheint mir auch ganz vielversprechend zu sein. Eine andere Möglichkeit wäre es evtl. cygwin zu installieren. Die cygwin-bash sollte sich eigentlich wie unter Linux verhalten und damit '*.pdf' auch direkt auflösen und durch die entsprechenden Dateinamen ersetzen können (käme auf einen Versuch an). Aber so geht's ja auch.

[shadow]

Hier nochmal mit Logging und "-p" für Path aber immer noch prepre beta !

parseComdirectPDF.zip