TT-RSS, Ordnerstruktur

[Lyreco]

Hallo,

ich möchte gerne ein bestehendes TinyTiny-RSS um die Erweiterung MailWebsiteChanges ergänzen. Dazu habe ich mich an der Anleitung (https://wiki.natenom.de/sammelsurium/so ... itechanges) entlang gehangelt, jedoch leider mit mäßigem Erfolg. Daher wäre ich sehr dankbar, wenn mir jemand weiterhelfen könnte, da ich sonst nicht weiterkomme.

Ich besitze einen Zugang bei uberspace.de, auf deren Server python3 und lxml bereits vorinstalliert sind.
Der Punkt „2.2 Umgebung vorbereiten“ (mkdir, cd) konnte ich leider nicht so wie vorgeschlagen durchführen, da ich als normaler Benutzer keinen neuen Ordner checker in /var/www/ anlegen darf, daher habe ich den Ordner in meinem Verzeichnis (/home/meinbenutzername/checker) angelegt und anschließend mit chown –R meinbenutzername: /home/meinbenutzername/checker die Zugriffsrechte geändert. Dementsprechend habe ich bei Punkt „3.2.4 Weitere Einstellungen“ folgendes geändert: os.chdir(‘/home/meinbenutzername/checker‘) und rssfile = ‘/home/meinbenutzername/html/tt-rss/checkerfeed.xml‘.
Auch cronjob war bereits installiert, aber für mich nicht in /etc/crontab, sondern „lokal“, daher habe ich folgenden Befehl ausgeführt: 30 * * * * meinbenutzername cd /home/meinbenutzername/checker && env LC_ALL=en_GB.utf8 python3 mwc.py

Die Befehle konnte ich alle nach langem hin und her erfolgreich ausführen, doch leider tut sich nichts. Die checkerfeed.xml wird nicht generiert.

Ich vermute, dass wohl irgendwas mit der „Ordnerstruktur“ nicht stimmt bzw. irgendwo falsch verwiesen wurde.

Ich wäre super wenn mir jemand helfen könnte!

[BlackJack]

@Lyreco: Der lokale crontab-Eintrag scheint mir schon mal falsch zu sein, denn da gehört die Benutzerspalte nicht hinein. Die braucht man für die globale crontab, bei der Lokalen ist der Benutzer unter dem das ausgeführt wird eben durch den Benutzer dem die crontab gehört, bereits festgelegt.

Das man die Locale festlegen muss um Unicode-Ausnahmen zu verhindern, deutet darauf hin, dass das Programm nicht ordentlich mit Unicode umgeht, und eventuell auch darauf das der Autor das nicht richtig verstanden hat.

[Lyreco]

Vielen Dank für die Antwort!

@Lyreco: Der lokale crontab-Eintrag scheint mir schon mal falsch zu sein, denn da gehört die Benutzerspalte nicht hinein. Die braucht man für die globale crontab, bei der Lokalen ist der Benutzer unter dem das ausgeführt wird eben durch den Benutzer dem die crontab gehört, bereits festgelegt.

Ich habe die Zeile auf 30 * * * * cd /home/meinbenutzername/checker && env LC_ALL=en_GB.utf8 python3 mwc.py abgeändert

Das man die Locale festlegen muss um Unicode-Ausnahmen zu verhindern, deutet darauf hin, dass das Programm nicht ordentlich mit Unicode umgeht, und eventuell auch darauf das der Autor das nicht richtig verstanden hat.

Das verstehe ich nicht wirklich, kannst du das bitte genauer ausführen? Was heißt das für mich?

P.S.: Bin leider blutiger Anfänger (mit gutem technischen Grundverständnis)

[BlackJack]

@Lyreco: Das mit der Kodierung bedeutet für Dich konkret nur das Du die per Locale-Einstellung vorgeben musst. An der Stelle würde man erwarten das sich der Programmierer in seinem Programm da bereits drum gekümmert hätte an den entsprechenden Stellen Texte explizit zu (de)kodieren.

[Lyreco]

@Lyreco: Das mit der Kodierung bedeutet für Dich konkret nur das Du die per Locale-Einstellung vorgeben musst. An der Stelle würde man erwarten das sich der Programmierer in seinem Programm da bereits drum gekümmert hätte an den entsprechenden Stellen Texte explizit zu (de)kodieren.

Hmmmm... ok. Irgendwie kann ich trotzdem leider nicht viel damit anfangen.
Wie löse ich denn mein Problem?
Wieso wird die checkerfeed.xml nicht generiert? Stimmen die Pfade ansonsten?

[Sirius3]

@Lyreco: was passiert denn, wenn Du das Skript von der Konsole aus startest? Gibt es irgendwelche Fehlermeldungen?

[DasIch]

Das man die Lokale festlegen muss um Unicode-Ausnahmen zu verhindern, deutet darauf hin, dass das Programm nicht ordentlich mit Unicode umgeht, und eventuell auch darauf das der Autor das nicht richtig verstanden hat.

Dem würde ich in diesem Fall widersprechen. Wenn die Anwendung mit LC_ALL=C läuft nimmt Python an ganz vielen Stellen ASCII als Encoding an. Das betrifft nicht nur Stellen an denen man explizit ohne weiteres ein Encoding angeben könnte sondern auch Pfade, stdin usw. Unicode verstanden zu haben und damit richtig umzugehen, bewahrt einen nicht davor in so einer Situation auf Probleme zu stoßen.

Deswegen macht es durchaus Sinn das Locale so zu setzen dass utf-8 verwendet wird. Es gibt sogar ein PEP (538) dass vorschlägt C immer als C.utf-8 zu behandeln um diese Problematik zu beheben. Die Dokumentation zu click beschäftigt mit sich auch mit dem Thema, click geht soweit unter Python 3 eine Exception zur werfen falls LC_ALL=C ist.

[BlackJack]

@DasIch: Okay, dann ist die Schuld nicht nur beim Programmierer sondern auch bei den Python-Entwicklern zu suchen die mit diesem Unsinn die Kodierung zu raten angefangen haben und damit gegen das Zen verstossen haben. Wird doch langsam Zeit das ich mich nach einer anderen Programmiersprache umsehe…

[DasIch]

Die Kodierung die über die Umgebungsvariablen festgelegt ist zu übernehmen ist jetzt nicht wirklich raten. Ich halte es nicht für sinnvoll weil man mMn einfach immer utf-8 nehmen sollte aber vielleicht kommt das noch.

[BlackJack]

@DasIch: Ich sehe das aus sehr praktischen Gründen anders, nämlich das ich regelmässig Fälle habe bei denen die Kodierung von Dateinamen und Dateiinhalten nicht der Locale entsprechen. Da ist Locale ein nett gemeinter Hinweis und keine definitive Kodierung die man erwarten kann. Was ich auch gar nicht als Fehler ansehe, denn Dateinamen sind, zumindest auf den Systemen auf denen ich mich rumtreibe, keine Zeichen- sondern Byteketten die alles ausser Nullbytes und den Pfadtrenner enthalten dürfen und die Dateisystem-API verwendet Bytes. Und auch Dateiinhalte können alles mögliche sein, und wenn ich Unicode-Daten schreibe, dann möchte ich eigentlich immer das *alles* geschrieben werden kann, auch wenn ich das auf einem Server und/oder über SSH mache.

Im konkreten Fall (dem verlinkten Issue) geht es um Daten von Webseiten, also komplett alles was man so als Unicode erwarten kann, und eine Datei die der Programmierer mit `open()` öffnet. Wenn das abkackt weil LC_* zu ASCII führt, sehe ich das als Fehler des Programmierers. Denn selbst wenn die Locale nicht C gewesen wäre, sondern beispielsweise Latin-1, fällt das Programm dann doch bei irgendeinem Webseiteninhalt früher oder später auf die Nase.

Click-Programme kann man also nicht als Root und/oder über SSH ausführen. Interessant. Autsch. Gut zu wissen.

[Sirius3]

@BlackJack: im konkreten Fall geht es nur darum, dass die Lokale Einfluß auf des Encoding von stdout hat, und munter irgendwelche Seitentitel per print ausgegeben werden. Als normaler Programmierer hat man kaum eine Chance, Fehler bei print abzufangen, zumal an anderer Stelle automatisch etwas sinnvolles gemacht wird. Sowohl logging als auch Exceptions kommen mit jedem Ausgabeencoding klar:

Code: Alles auswählen

>>> print("Hallo \u00df!")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec cannot encode character '\xdf' in position 6: ordinal not in range(128)
>>> logging.warn(u"Hallo \u00df!")
WARNING:root:Hallo \xdf!
>>> raise AssertionError("Hallo \u00df!")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AssertionError: Hallo \xdf!

Konsequenz daraus ist, print ist kaputt, macht bei einem Programm, das als cronjob gestartet werden soll, auch wenig Sinn.

[BlackJack]

Der konkrete Fall, also der Traceback aus dem im Blog verlinkten Issue sieht mir nicht nach `print()` aus:

Code: Alles auswählen

Traceback (most recent call last):
  File "MailWebsiteChanges.py", line 270, in <module>
    pollWebsites()
  File "MailWebsiteChanges.py", line 239, in pollWebsites
    storeFileContents(site['shortname'], parseResult)
  File "MailWebsiteChanges.py", line 195, in storeFileContents
    file.write(c)
UnicodeEncodeError: 'ascii' codec can't encode character '\u2014' in position 11903: ordinal not in range(128)

Dort, bei den zu erwartenden Daten, würde ich das einfach mal als Programmierfehler ansehen das `file` nicht mit einer expliziten Kodierung geöffnet wurde die auch Unicode komplett abdeckt.

[Sirius3]

@BlackJack: der Blog scheint sich noch auf eine ältere Version zu beziehen, inzwischen sieht die Stelle so aus:

Code: Alles auswählen

    file = open(shortname + '.' + str(i) + '.txt', 'wb')
    file.write(c.encode('utf-8'))
    file.close()

Nicht schön, aber encoding-fehlerfrei.

[Lyreco]

Zum Testen habe ich in die config.py

sites = [

{'shortname': 'Spiegel Online',
'uri': 'http://www.spiegel.de/index.html',
'type': 'html',
'titlexpath': '//title'
'encoding': 'utf-8'},

]

geschrieben (bin mir nicht sicher ob das so auch stimmt) und erhalte beim Ausführen über SSH folgende Fehlermeldung:


[meinbenutzername@elnath checker]$ python3 mwc.py --dry-run="Spiegel Online" --config=config
Traceback (most recent call last):
File "mwc.py", line 337, in <module>
config = importlib.import_module(configMod)
File "/package/host/localhost/python-3/lib/python3.4/importlib/__init__.py", line 109, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "<frozen importlib._bootstrap>", line 2254, in _gcd_import
File "<frozen importlib._bootstrap>", line 2237, in _find_and_load
File "<frozen importlib._bootstrap>", line 2226, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 1200, in _load_unlocked
File "<frozen importlib._bootstrap>", line 1129, in _exec
File "<frozen importlib._bootstrap>", line 1467, in exec_module
File "<frozen importlib._bootstrap>", line 1572, in get_code
File "<frozen importlib._bootstrap>", line 1532, in source_to_code
File "<frozen importlib._bootstrap>", line 321, in _call_with_frames_removed
File "/home/rsstest/checker/config.py", line 14
'encoding': 'utf-8'},
^
SyntaxError: invalid syntax

[Sirius3]

@Lyreco: ein Wörterbuch darf auch pro Eintrag nur einen Doppelpunkt haben:

Code: Alles auswählen

>>> {"A": "B": "C"}
  File "<stdin>", line 1
    {"A": "B": "C"}
             ^
SyntaxError: invalid syntax

Der Grund ist meist ein fehlendes Komma in der Zeile davor.

[Lyreco]

Danke für den Hinweis, blöder Fehler
Nach der , Korrektur erhalte ich nun:


[meinbenutzername@elnath checker]$ python3 mwc.py --dry-run="Spiegel Online" --config=config
{'titles': ['SPIEGEL ONLINE - Aktuelle Nachrichten'], 'warning': None, 'contents': ['<title>SPIEGEL ONLINE - Aktuelle Nachrichten</title>\n']}


Sieht eigentlich ganz gut aus, oder?
checkerfeed.xml wird aber trotzdem nicht angelegt...

[Sirius3]

@Lyreco: würde ich bei einem dry-run auch nicht erwarten.

[Lyreco]

Ok, wie krieg ich denn das Ding jetzt dann zum Laufen?

[BlackJack]

@Lyreco: Na eben keinen ``--dry-run`` machen‽

[Lyreco]

Haha, Tatsache, vielen Dank
checkerfeed.xml wird jetzt auch angelegt
Aber irgendwie kann ich die Datei von außen nicht aufrufen?!

EDIT: Hat sich erledigt


EDIT2: VIELEN DANK FÜR DIE HILFE!