Python 2.5.1 startet nicht unter Vista32bit

Probleme bei der Installation?
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

BlackJack hat geschrieben:Das einzige Programm, dass ich regelmässig benutze und das Probleme damit hat ist, LaTeX.
Gut, TeX ein unfassbar altes System das ja auch fast ungeändert seit vielen Jahren existiert. Und interessanterweise alle seine Nachfolger überlebt und verdrängt hat.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Erwin
User
Beiträge: 141
Registriert: Donnerstag 9. Juni 2005, 08:51

BlackJack hat geschrieben: Wie man sieht: Namen mit Leerzeichen sind nicht nur erlaubt, sondern werden sogar auf der ersten Diskette, die man auf dem C64 üblicherweise zu Gesicht bekommt, ausgiebig verwendet. Gross-/Kleinschreibung wird auch unterschieden.
Hm... dann bin ich wohl ständig nur mit Systemen in Kontakt geraten, die halt nur 8 Zeichen zugelassen haben?
Also bei ST kann es durchaus so sein.
Schneider-Basic ist mir nie eins aufgefallen das mehr als 8+3 Zeichen hatte. Gehörte aber ja, da es der Vorläufer von TOS war, zur gleichen Kategorie.
Commodore? Das wundert mich. Weil dort hat uns der Lehrer beigebracht, nur maximal 8 Zeichen für einen Namen zu verwenden.
Aber vielleicht hatte er es auch vorher mit was anderem zu tun gehabt?
Basic ist ja fast auf allen Computer gleich gewesen.
Unter DOS aber ist mir auch nie etwas mit mehr als 8+3 Zeichen aufgefallen.

BlackJack hat geschrieben: Unter Linux habe ich kaum Probleme mit Leerzeichen in Dateinamen. Das einzige Programm, dass ich regelmässig benutze und das Probleme damit hat ist, LaTeX.
Ich hatte damals so am Anfang eine Verknüpfung zu meinen STEEM hergestellt.
Da schrieb ich rein: 'Atari ST'.
Und das möchte er gar nicht. Die Verknüpfung tauchte erst gar nicht auf, und hernach schien sie nicht richtig anpassen zu lassen.
Als ich es ohne Leerzeichen estellte, funzte es einwandfrei.
Das komische daran: Später konnte ich in den Namen wiederum ein Leer rein machen (also dementsprechend Umändern). Das machte dann nichts mehr aus.
Und als Linux auch noch aus dem Umlaut 'ü' (Ordner Verknüpfung etc.) das Rauten-Frage-Zeichen machte ... . Vor allem wenn ich das sicherte, meckerte Linux, bzw. das Brenn-Programm immer, dass er es nicht richtig brennen könne?

Von daher kann ich mir schwer vorstellen, das Leer und Umlaute erlaubt sind.
Oder habe ich etwa ständig das Talent, seltene Fehler zu entdecken?


Kann man nun Tkinter trotzdem weiter verwenden, oder sollte man besser einen Bogen drumherum machen?
Ich mache nie einen Fehler Zweimal.
Schließlich ist die Auswahl ja groß genug.
BlackJack

@Erwin: Die Frage ist wie das 'ü' kodiert war und ob das den Einstellungen im System entsprach und falls dem nicht so war, wie Du die Datei dann erstellt hast. Die lustige Welt der Kodierungen eben.
Erwin
User
Beiträge: 141
Registriert: Donnerstag 9. Juni 2005, 08:51

BlackJack hat geschrieben:@Erwin: Die Frage ist wie das 'ü' kodiert war und ob das den Einstellungen im System entsprach und falls dem nicht so war, wie Du die Datei dann erstellt hast. Die lustige Welt der Kodierungen eben.
Kodiert?
Also ich habe mir da Gedanken gemacht, und bin zu der Ansicht gekommen, dass das Programm beim ersten Start vermutlich sich die Namen der Ordner ebenfalls (so wie auch alles andere ins Deutsche übersetzte) aus dem Translat-Textdokument (wo also Englisch und Deutsch drin steht) herausholt. Bzw. von daher die Namen für die Ordner zum erstellen nimmt.
Also habe ich drin nach Verknüpfungen und Schnappschüsse gesucht und die ü drin durch ue ersetzt.
Und sie da, es hat funktioniert: Jetzt heißen die Ordner Verknuepfungen und Schnappschuesse.
Zum Glück ging es da scheinbar so einfach.
Zumindest ist bis jetzt kein Fehler aufgetreten.
Ich mache nie einen Fehler Zweimal.
Schließlich ist die Auswahl ja groß genug.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Erwin hat geschrieben:
BlackJack hat geschrieben:@Erwin: Die Frage ist wie das 'ü' kodiert war und ob das den Einstellungen im System entsprach und falls dem nicht so war, wie Du die Datei dann erstellt hast. Die lustige Welt der Kodierungen eben.
Kodiert?
Na, [wiki=Von_Umlauten, Unicode und Encodings]kodiert[/wiki] eben. Kodierungen sind auf den ersten Blick seltsam, aber wenn man es einmal verstanden hat, ist es ganz einfach.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Erwin
User
Beiträge: 141
Registriert: Donnerstag 9. Juni 2005, 08:51

Leonidas hat geschrieben: Na, [wiki=Von_Umlauten, Unicode und Encodings]kodiert[/wiki] eben. Kodierungen sind auf den ersten Blick seltsam, aber wenn man es einmal verstanden hat, ist es ganz einfach.
Also wenn ich das so kurz überfliege, dann bekomme ich den Eindruck, dass man dann dem Programm nur sagen muss, dass er die Ordnernamen mit einem Bestimmten Kod auslesen soll, und fertig? Dann erkennt er, den richtigen Kod angegeben vorausgesetzt, problemlos auch Ordner mit Leerzeichen?

Wobei dies jetzt wohl in dem Fall nur auf Python zutrifft, oder gilt diese Einstellung dann universell?
Also dass man überall bloß den Kod mitteilen muss, und dann funzt es, egal welches Programm und womit und wann es geschrieben wurde?
Ich mache nie einen Fehler Zweimal.
Schließlich ist die Auswahl ja groß genug.
BlackJack

Vergiss erst einmal Leerzeichen. Leerzeichen gehören zu ASCII und sind damit in allen, zumindest in allen bei uns gebräuchlichen Kodierungen, gleich, machen also keine Probleme.

Die Frage ist, wie Du die Datei mit einem 'ü' im Namen angelegt hast. Dateinamen bestehen bei Linux in der Regel nicht aus Zeichen sondern aus Bytes. Die Frage ist also welcher Bytewert für das 'ü' genommen wurde, und ob diese Kodierung der Systemkodierung entsprach. Wahrscheinlich nicht, wenn Du an anderer Stelle das Ersatzzeichen mit dem Fragezeichen gesehen hast.

Wenn Du dass dann auf CD brennen willst, gibt's Probleme wenn die Kodierung nicht mit der Systemkodierung übereinstimmt, weil die Joliet-Erweiterung zum Speichern von langen Dateinamen ISO 9660 Dateisystemen, Unicode-Zeichen kennt und da versucht wird aus den Bytes in den Dateinamen unter Annahme der Systemkodierung sinnvolle Zeichen zu machen.
Erwin
User
Beiträge: 141
Registriert: Donnerstag 9. Juni 2005, 08:51

BlackJack hat geschrieben: Die Frage ist, wie Du die Datei mit einem 'ü' im Namen angelegt hast. Dateinamen bestehen bei Linux in der Regel nicht aus Zeichen sondern aus Bytes. Die Frage ist also welcher Bytewert für das 'ü' genommen wurde, und ob diese Kodierung der Systemkodierung entsprach. Wahrscheinlich nicht, wenn Du an anderer Stelle das Ersatzzeichen mit dem Fragezeichen gesehen hast.
Mir anderen Worten, es lag vermutlich daran, weil das Programm selbst dies ohne Abstimmung mit Linux-Kernel (etc.) die Ordner angelegt hat?
Aber inzwischen egal.
Konnte es ja auch anderweitig lösen.

Was denkst Du über Tkinter?
Kann man da trotzdem noch ohne weiteres nutzen?
Oder lieber doch nicht, wo es derzeit scheinbar Probleme mit Vista macht?
Ich mache nie einen Fehler Zweimal.
Schließlich ist die Auswahl ja groß genug.
BlackJack

Vista ist mir relativ egal, also kann ich auch Tkinter benutzen. Wobei das ja wohl kein Problem ist, was sich nicht beheben lässt.
Erwin
User
Beiträge: 141
Registriert: Donnerstag 9. Juni 2005, 08:51

BlackJack hat geschrieben:Vista ist mir relativ egal, also kann ich auch Tkinter benutzen. Wobei das ja wohl kein Problem ist, was sich nicht beheben lässt.
Zum arbeiten vermutlich nicht.
Es sei denn Linux macht irgendwann den gleichen Zeug, mit den Leerzeichen.

Aber wenn ich ein Programm als Script weiter gebe?
Allerdings ist es da wohl eh besser für Win eine exe daraus zu machen. Sollte ja genau so gut dann klappen, als wenn man es als Script weiter gibt, oder?

Spielt es dann im Falle einer daraus gemachten exe eine Rolle?
Oder ist dann alles in der exe drin und kommt zugleich auch dann mit Leerzeichen im Ordner und Dateinamen klar?
Ich mache nie einen Fehler Zweimal.
Schließlich ist die Auswahl ja groß genug.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Wenn dein Python-Programm mit Leerzeichen klar kommt, gibt es auch mit dem ge-freezten Programm keine Probleme. Warum auch.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
BlackJack

Na weil auch ein ge"freeze"tes Tcl nicht plötzlich auf magische Weise Leerzeichen in Pfaden mag!?
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

BlackJack hat geschrieben:Na weil auch ein ge"freeze"tes Tcl nicht plötzlich auf magische Weise Leerzeichen in Pfaden mag!?
Und wo habe ich das behauptet?
Leonidas hat geschrieben:Wenn dein Python-Programm mit Leerzeichen klar kommt
Wenn es wegen Tkinter crasht dann kommt es logischerweise nicht mit Leerzeichen klar. Daran ändert das freezen ja nichts.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
BlackJack

Du hast es nicht explizit behauptet, aber im Kontext, dass es hier in den letzten Beiträgen darum ging, ob man Tkinter wegen Vista nicht benutzen sollte und ob man mit einem ge"freeze"ten Programm "sicher" ist, könnte man das da rauslesen.
Erwin
User
Beiträge: 141
Registriert: Donnerstag 9. Juni 2005, 08:51

Leonidas hat geschrieben: Wenn es wegen Tkinter crasht dann kommt es logischerweise nicht mit Leerzeichen klar. Daran ändert das freezen ja nichts.
Darum geht es mir ja.
Soll das jetzt heißen, da dies nun mal unter Vista crasht, dass dies mit dem gefreeztem Programm dann genau so passiert?
Also die exe-Erstellung nichts daran ändert?
Dass halt leider auch der Teil der exe, der für die GUI dann zuständig ist, nicht mit Leerzeichen klar kommt?
Eben weil diese genau so wie das ursprüngliche Tcl selbst in exe verpackt keine Leerzeichen verkraftet?
Ich mache nie einen Fehler Zweimal.
Schließlich ist die Auswahl ja groß genug.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

BlackJack hat geschrieben:aber im Kontext, dass es hier in den letzten Beiträgen darum ging, ob man Tkinter wegen Vista nicht benutzen sollte und ob man mit einem ge"freeze"ten Programm "sicher" ist, könnte man das da rauslesen.
Echt? Naja, jedenfalls habe ich das so nicht gemeint.

Also nochmal zur Klarstellung: Wenn ein Python-Programm mit Leerzeichen im Pfad klarkommt, dann funktioniert ein gefreeztes Programm auch. Wenn es das nicht tut, weil was auch immer kaputt ist (ob das nun Tkinter ist oder etwas anderes), dann funktioniert eine gefreezre Version auch nicht. Das freezen hat auch die Leerzeichenbehandlung gar keinen Einfluss da Tools wie py2exe ja nur den Python-Interpreter und einige Libs in eine EXE packen und sich sonst nichts ändert.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Erwin
User
Beiträge: 141
Registriert: Donnerstag 9. Juni 2005, 08:51

Leonidas hat geschrieben: Also nochmal zur Klarstellung: Wenn ein Python-Programm mit Leerzeichen im Pfad klarkommt, dann funktioniert ein gefreeztes Programm auch. Wenn es das nicht tut, weil was auch immer kaputt ist (ob das nun Tkinter ist oder etwas anderes), dann funktioniert eine gefreezre Version auch nicht. Das freezen hat auch die Leerzeichenbehandlung gar keinen Einfluss da Tools wie py2exe ja nur den Python-Interpreter und einige Libs in eine EXE packen und sich sonst nichts ändert.
Oha.
Bedeutet dass dann auch, dass man bei einem gefreeztem Programm (welches Tcl als GUI nutzt) Tcl mitschicken müsste, falls der Anwender es nicht bereits installiert hat?
Ich mache nie einen Fehler Zweimal.
Schließlich ist die Auswahl ja groß genug.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Erwin hat geschrieben:Bedeutet dass dann auch, dass man bei einem gefreeztem Programm (welches Tcl als GUI nutzt) Tcl mitschicken müsste, falls der Anwender es nicht bereits installiert hat?
Ja, man braucht eben alles was zur Ausführung nötig ist. Aber py2exe kümmert sich schon darum, alles nötige beizupacken. Wird dann nur eben recht groß.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Erwin
User
Beiträge: 141
Registriert: Donnerstag 9. Juni 2005, 08:51

Leonidas hat geschrieben: Ja, man braucht eben alles was zur Ausführung nötig ist. Aber py2exe kümmert sich schon darum, alles nötige beizupacken. Wird dann nur eben recht groß.
Und dann wird es auf den Windows ausgepackt?
Aber leider halt nach den Regeln, wie es sonst auch (also Tcl allein) ausgepackt wird?
Somit funktioniert es dann wohl genau so, als wenn man es extern/extra installiert hätte?
Tja, dann ist es vollkommen logisch, dass dann Tcl auch nach dem freezem Ärger macht.
Dann müsste man in dem Fall den Benutzer also anweisen, er soll den Tcl-Teil in Ordner installieren, die kein Leer enthalten?
Das will mir alles nicht gefallen.
Ich mache nie einen Fehler Zweimal.
Schließlich ist die Auswahl ja groß genug.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Erwin hat geschrieben:Somit funktioniert es dann wohl genau so, als wenn man es extern/extra installiert hätte?
Natürlich. Der Vorgang heißt ja "freezen" und nicht "bugfixen" ;)
Erwin hat geschrieben:Dann müsste man in dem Fall den Benutzer also anweisen, er soll den Tcl-Teil in Ordner installieren, die kein Leer enthalten?
Das will mir alles nicht gefallen.
Dann warte entweder auf eine korrigierte Version, korrigiere es selbst oder steige auf ein Toolkit aus diesem Jahrzehnt um :)
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Antworten