Probleme beim Übertragen eines Skriptes via Mail-Anhang

[oliver1974]

Guten Morgen zusammen,

Ich hab hier folgendes Problem, ich entwickle ein kleines Python Skript auf 2 verschiedenen Rechnern, das Skript schicke ich mir dann immer per Email zu.

(Konkret, ich arbeite nach Feierabend zu Hause noch etwas weiter).

Der eine Rechner ist eine Windows-Kiste mit Outlook als Mailclient, der andere eine Linux Kiste (Kubuntu 6.0.6) unt mit KMail.

Ich bekomme immer irgendwelche Probleme, wenn ich die frisch zugestellen Skripte ausführen will, auf der Windows - Kiste zerhauts die Umlaute, auf der Linux Kiste will das Skript erst überhaupt nicht (schwer zu beschreiben, ich bekomme da Fehlermeldung wie ": Command not found, vor dem Doppelpunkt steht aber nie was"), da muss ich per copy/paste erst das ganze Skript erst in ein neues leeres Textfile übertragen und neu speichern, dann geht es wieder.

Liegt ja nahe, dass es irgendwie am Encoding hängt, ich hatte bei beiden Editoren erst iso-8859-15, dann utf-8. Keine Änderung.

Also vermutlich das Encoding des Mailanhangs...

Wie geht ihr denn da vor?

[jens]

Ich nutzte einen SVN Server und verwalte da meine Skripte. Dann kann ich von überall her die neusten Versionen abrufen, bearbeiten und zurück schicken.
Ich hab auch mal angefragt, ob Interesse an einem "SVN Server für alle" besteht, siehe http://www.python-forum.de/topic-7961.html

Als Alternative, nutzte einen Paste Service wie http://paste.pocoo.org Oder schiebe die Daten irgendwo per FTP hin...

[oliver1974]

Ja gut, dass mit FTP und SVN oder CVS habe ich mir auch schon gedacht.. nur, es muss doch auch irgendwie so gehen?

Könnte doch in der Praxis sein, dass ich "mal eben" jemanden via Mail ein Python-Skript schicke, was denn?

[kbrust]

Wie wär's mit dem guten, alten Zipformat um jegliche Plaintext-Anhänge einzupacken?

[oliver1974]

Tja, das hatte ich vergessen zu erwähnen, aber das hatte ich eigentlich auch schon versucht.. Eigentlich denn ich grübele gerade darüber nach, ob ich das vielleicht nur "one-way" versucht habe... hmmmm.

Die Idee mit dem Einpacken in eine Archivdatei kam mir natürlich auch gleich zu Anfang, um unabhängig zu sein vom Encoding des MailClients.

Hmmmm, ich spiel das nochmal heute durch!

[jens]

Das ist IMHO ehr ein Problem Windows <-> Linux... Du solltest am besten als Zeilenenden nur "\n" nutzten, auch unter Windows. Dann muß das Zeichencodierung auf beiden Plattformen gehen... Ich nehme utf-8, wobei es bei mir auch schon mal vorkommt, das Umlaute defekt sind. Aber die kommen eigentlich eh nur in DocStrings vor

[oliver1974]

Hmm, du meinst "\r\n" wirkt sich auf das Encoding selber aus?

Würde mich jetzt überraschen, aber möglich ist ja alles.

utf-8 hatte ich auch schon probiert, keine Besserung, aber wie geschrieben, ich vermute das Problem eher bei den MailClients.

Und zu den Umlauten... Also, die kommen doch genug vor, was ist mit den ganzen Menüeinträgen, Buttons usw. die man bei einer deutschsprachigen GUI halt so baut?

[EnTeQuAk]

Na Windows erkennt die Zeilenumbrüche von Linux net an. Umgehert glaub ich auch.

Windows: \r\n
Linux: \n

daran liegt das Problem meißtens. Komisch nur, das es bei mir Ubuntu 6.10 --> Windows XP keine Probleme gibt. Könnte daran liegen, das mein FTP-Client das ganze automatisch korrigiert


Aber daran könnte es scheitern. Am Encoding von UTF-8 usw. liegt es eigentlich net (eigene Erfahrung). (Klappt zumindest bei mir meißtens gut )


MfG EnTeQuAk

[jens]

Nein, zumindest umgekehrt geht es... Also Python Skripte die nur "\n" benutzen, laufen unter Windows auch.

[Rebecca]

Bei mir unter Linux laufen auch die Wiin-Scripte mit "\n\r", sogar mit utf-8-codierten Umlauten. Die Zeilenumbrueche stoeren erst, wenn man die Datei editieren will. Aber dafuer gibt es ja dos2unix und unix2dos...

Bzgl. encodings: Hast du denn *ueberall* das gleiche encoding engestellt? D.h. im Win-Editor, im Win-Mail-Client, im Linux-Mail-Client und im Linux-Editor?

[BlackJack]

Bei mir unter Linux laufen auch die Wiin-Scripte mit "\n\r", sogar mit utf-8-codierten Umlauten. Die Zeilenumbrueche stoeren erst, wenn man die Datei editieren will.

Das stimmt so nicht ganz. Das Windowszeilenende ist '\r\n' und das '\r' stört in Skripten an einer ganz empfindlichen Stelle unter Linux, nämlich in der She-Bang-Zeile. Wenn die wie folgt aussieht: '#!/usr/bin/env python\r\n', dann sucht die Shell nach einem Programm mit dem Namen 'python\r' und findet das natürlich nicht.

Das erklärt wahrscheinlich die Fehlermeldung vom Fragesteller. Vor dem Doppelpunkt steht nichts, weil das '\r' natürlich ausgegeben wurde und der Rest der Fehlermeldung den Programmnamen überschreibt.

Du scheinst die Skripte mit Windowszeilenenden also nicht über die Shell zu starten.

[jens]

CGI Skripte laufen im Übrigen i.d.R. auch nicht, wenn die Zeilenenden nicht Linux-like sind

[Rebecca]

Du scheinst die Skripte mit Windowszeilenenden also nicht über die Shell zu starten.

Ach menno. Erwischt. Ich habe sie aus der Shell mit python meinscript.py gestartet. Jedanfalls scheinen die "\r" den Python-Interpreter nicht zu stoeren.

[Y0Gi]

Unter Windows benutze ich ausschließlich UNIX-Zeilenenden und die Scripte funktionieren alle wunderbar.

[oliver1974]

Das mit den Windows-Zeilenenden scheint das eine Phänomen zu erklären... hätte ich auch von selbst drauf kommen können, verdammt!!!!

Mit dem anderen Phänomen schau ich noch mal, ich vermute das ist gegessen wenn ich mir die Datei gepackt zuschicke (Linux->Windows), denn das ist dann doch eher ein Encoding Problem, würde ich vermuten.