Python 2.5.1 startet nicht unter Vista32bit

[BlackJack]

@Erwin: Natürlich gibt es Leerzeichen in Dateinamen, und auch andere Sonderzeichen. Da wird nichts "getrickst", da steht einfach ein entsprechender Bytewert für's Leerzeichen, genau wie für jeden anderen Buchstaben auch.

Unter Windows ist das bei NTFS sogar ein wenig besser gelöst als unter Linux, weil bei NTFS die Zeichenkodierung festgelegt ist und die Namen vom Betriebssystem als richtige Zeichenketten behandelt werden können und nicht einfach nur Byteketten sind, wie unter Linux.

[Erwin]

Da muss ich widersprechen. Wer sauber programmiert, programmiert so, dass Leerzeichen kein Problem sind. Am Leerzeichen ist nicht Microsoft schuld. Das hat sich eingebürgert, um Worte voneinander zu trennen.

Also so weit ich weiß, wurden die Leerzeichen in Ordnern und Dateien vor allem von MS 'eingebürgert'.
Vorher gab es so was nicht bei Dateien und Ordner.
Ist erst mit Win95 aufgekommen.
Jedenfalls hatte ich zuvor damit keinen Kontakt. Und auch sonst hieß es vorher überall, dass man keine Leerzeichen in Dateien und Ordner verwenden soll/kann.

@Erwin: Natürlich gibt es Leerzeichen in Dateinamen, und auch andere Sonderzeichen. Da wird nichts "getrickst", da steht einfach ein entsprechender Bytewert für's Leerzeichen, genau wie für jeden anderen Buchstaben auch.

Und wieso konnte ich dann keine Leerzeichen für Dateien auf meinen alten Amstrad verwenden?
Und wieso haben dann andere Programme (wie z.B. Tcl) dann mit Leerzeichen Probleme, wenn es sich dabei um ganz übliche Zeichen handelt, die man angebliche nicht extra Berücksichtigen muss?

Und wieso scheint MS selbst keine Dateien und Ordner mit Leerzeichen zu verwenden?
Außer jene für User halt.

[Leonidas]

'$HOME' ??
Du benutzt Linux?

Ja, wie die meisten Regulars in diesem Forum. Aber meine Aussage war nicht Linux-spezifisch. Weder unter Windows noch unter Linux sollten Leerzeichen in Pfaden den Programmen Probleme machen.

Genau da bin ich zum ersten mal über das Leerzeichen-Problem gestolpert, als ich einer Verknüpfung beim Erstellen ein Leerzeichen mit reinverpaßt hatte.

Ja, hat ja niemand gesagt, dass es unter Linux das Problem nicht gibt. Es gibt sicherlich hunderte kaputter bash-Skripte auf jedem System, weil die die Variablen nicht richtig quoten und die Bash sie am Leerzeichen trennen würde. Nur kommen die zum glück nicht mit Leerzeichen in Berührung.

[BlackJack]

@Erwin: Der alte Amstrad mag keine Leerzeichen in Dateinamen!? Also mein alter C64 hat keine Probleme mit Leerzeichen in Dateinamen und die sind dort auch durchaus üblich. Man trifft sogar teilweise auf Steuercodes für Farben und PETSCII-Grafiken. (Das C64-Äquivalent zu ANSI-Art)

Und Unix ist auch schon recht alt. Dort sind die Einschränkungen für Dateinamen allgemein: '/' darf nicht vorkommen, weil das zum Trennen von Pfadkomponenten verwendet wird, und das Nullbyte markiert das Ende einer Zeichenkette, kann also auch nicht innherhalb einer Pfadangabe vorkommen. Einzelne Dateisysteme können noch weitere Einschränkungen für gültige Namen machen, aber grundsätzlich hat jedes (Linux-)Programm was mit solchen Namen Probleme hat IMHO einen Bug.

Bei Windows gibt's noch ein paar mehr Zeichen die Tabu sind, aber auch hier halte ich jedes Programm für fehlerbehaftet, das mit Dateinamen nicht zurecht kommt, die gültige (lange) Namen für FAT32- oder NTFS-Dateisysteme sind. Und bei beiden sind Leerzeichen eindeutig erlaubt.

Es gibt Programme und Dateisysteme, die nicht damit klar kommen, was ein Grund sein kann auf Leerzeichen in selbst vergebenen Namen zu verzichten. Aber neue bzw. gepflegte Programme sollten solche Namen verarbeiten können. Leerzeichen in Dateinamen sind nichts besonderes oder "getrickstes", sondern Programme die damit Probleme haben sind etwas "besonderes".

[Erwin]

Da ich unter Basic (Commodore und Schneider-Basic) nie in Dateien ein Leerzeichen gemacht habe (in Informatikkurs wurde uns dies auch untersagt), weiß ich jetzt natürlich nicht, ob dies nicht doch ginge. Aber aufgefallen sind mir solche Dateien (also mit Leerzeichen) noch nie.

Unter Atari ST, und das weiß ich bestimmt, geht das jedenfalls nicht.
Dort wird, wenn man einen Ordner erstellen will, Leerzeichen nicht mal angenommen. Also man kann bei der Namensvergabe bei einem Ordner nicht mal ein Leerzeichen eingeben - die Eingabe wird ignoriert.

Insgesamt bin ich jetzt verwirrt.
Kann mir das Ganze jetzt nur noch so erklären, dass also im späterem Verlauf in der Computersprache mehr Zeichen auch zur Vergabe von Ordner und Dateien möglich waren.
Erweiterter ASCII-Code?

Das neue gepflegte Programme damit klar kommen, leuchtet ein.
Anderseits bedeutet das Ganze doch auch, dass die neuen BS nicht abwärtskompatibel sind.
So wie Vista. Und das scheinbar nur deshalb, weil die ein Leerzeichen hernehmen mussten, statt einen Bindestrich. Was wäre da für MS so groß dabei gewesen, für mehr Abwärts-Kompatibilität zu sorgen?

Und was ich auch nicht verstehe:
Wieso machen den alte Programme Schwierigkeiten, wenn es darum geht, dass diese in Ordner mit Leerzeichen ausgeführt werden sollen?
Und wieso sind diese Probleme nicht anfangs massenhaft aufgetreten?

Müssen manche etwa dermaßen auf andere Ordner und Dateien zugreifen, welche sich dann ärgerlicher Weise in Ordner mir Leerzeichen befinden?
Führt dies dann etwa zu den Fehlern, weil das Programm selbst wo die Pfade reinschreibt (für andere verstreute Programmteile), aber wegen dem Leer diese Pfade nicht richtig lesen und somit nicht richtig in eigene Pfaddatei reinschreiben kann?

Das finde ich alles so verwirrend und Sinnlos.

[sma]

Wieso machen den alte Programme Schwierigkeiten, wenn es darum geht, dass diese in Ordner mit Leerzeichen ausgeführt werden sollen?

Weil alte Programmierer das nie gelernt haben oder sogar ablehnen? :)

Es war eine Design-Entscheidung von CP/M (du erwähntest den Schneider CPC, dessen Disk-Operation-System war CP/M) und DOS (was auch vom Atari benutzt wurde), keine Lehrzeichen zuzulassen - wahrscheinlich weil man sich eh nur 8+3 Zeichen gönnte und Platz sparen wollte. Annekdote am Rande: Die Sprache FORTH heißt so, weil das Dateisystem leider nicht FOURTH - die vierte - erlaubte. Unix hatte eigentlich von Anfang der 70er keine Probleme mit beliebigen Zeichen außer "/" im Dateinamen. Als 1984 der Mac erschien, unterstütze dessen Dateisystem bereits Leerzeichen.

Irgendwann hat dann auch Microsoft verstanden, dass es eine Zumutung ist, dem Anwender Leerzeichen in den Namen zu untersagen oder die Länge auf nur wenige Zeichen zu beschränken.

Leerzeichen sind keine Problem, wenn man im wesentlichen etwas anklickt. "Profis" raten gerne von Leerzeichen ab, weil ihre geliebten Kommandozeilen-Werkzeuge hier mehr Probleme haben, gilt das Leerzeichen doch traditionell als Trenner der Argumente. Und mittels " die Namen mit Leerzeichen zusammenzufassen (oder mit \ zu maskieren) wird nicht nur als umständlich wahrgenommen oder aber es wird befürchtet, dass der Profi-Kollege, der das Kommandozeilenwerkzeug gebaut hat, ebenfalls nicht mit Leerzeichen korrekt umgehen konnte.

Übrigens, VFAT von Windows 9x hat tatsächlich neben den "neuen" Namen immer noch eine Variante im 8+3-Format mit gepflegt. NTFS hat diesem Krampf ein Ende bereitet.

Stefan

[Erwin]

Es war eine Design-Entscheidung von CP/M (du erwähntest den Schneider CPC, dessen Disk-Operation-System war CP/M) und DOS (was auch vom Atari benutzt wurde), keine Lehrzeichen zuzulassen - wahrscheinlich weil man sich eh nur 8+3 Zeichen gönnte und Platz sparen wollte. ...

Atari ST's TOS soll von DOS abstammen?
Höre ich zum ersten mal:
'TOS ist aus CP/M-68K (Digital Research) hervorgegangen und wurde durch eine Mac-ähnliche grafische Benutzeroberfläche namens GEM ergänzt. Die Schnittstellen vieler Systemaufrufe entsprachen denen von DOS, auch das Diskettenformat der Systeme stimmte mit Ausnahme eines Details überein.'

Was die 8 Zeichen betrifft, so weit ich weiß, soll dies an dem 8-Bit gelegen haben. Es war einfach nicht mehr drin.
Erst mit 16-Bit sollen dann 256 Zeichen Möglich gewesen sein.

Und interessanter weise ist keine Groß-und Kleinschreibung möglich.
Jedenfalls wird dies nicht unterschieden.

Irgendwann hat dann auch Microsoft verstanden, dass es eine Zumutung ist, dem Anwender Leerzeichen in den Namen zu untersagen oder die Länge auf nur wenige Zeichen zu beschränken.

Ansichtsache.
Seit ich keine Leerzeichen mehr nutze, ist bei mir vieles Übersichtlicher geworden.

[Leonidas]

Also ich für meinen Teil finde es besser einen Dateinamen wie "The Mars Volta - A Plague Upon Your Hissing.ogg" zu lesen als "The_Mars_Volta_-_A_Plague_Upon_Your_Hissing.ogg" oder "TheMarsVolta-APlagueUponYourHissing.ogg". Findest du nicht? Trotzdem erwarte ich, dass alle diese Dateinamen korrekt verarbeitet werden.

[Erwin]

Also ich für meinen Teil finde es besser einen Dateinamen wie "The Mars Volta - A Plague Upon Your Hissing.ogg" zu lesen als "The_Mars_Volta_-_A_Plague_Upon_Your_Hissing.ogg" oder "TheMarsVolta-APlagueUponYourHissing.ogg". Findest du nicht? Trotzdem erwarte ich, dass alle diese Dateinamen korrekt verarbeitet werden.

Ok, bei Bücher und dergleichen hast Du recht.
Aber damit gab es meist auch keine Probleme.
Zumindest wüsste ich nichts davon.

Aber selbst, zum Arbeiten, finde ich es besser, dass ich mich eher auf Knappe Beschreibungen konzentriere, und auch sonst vieles zusammen füge.
So würde ich z.B., wenn ich das Buch schreiben würde, in der Arbeitsphase einfach nur 'Mars-Volta-X' (X für Nummer) nennen.
Ist kürzer und geht auch nicht über mehre Zeilen.

Früher hatten alle meine Dateien schon im Titel einen halben Roman.
Und besser durchblickt habe ich dadurch auch nicht unbedingt.
Und vor allem musste ich erst halben Roman lesen, bis ich wusste, was da drin steht.

Aber vielleicht bin ich einfach noch zu sehr der Zeit hinter her.
Früher stand auf den Disketten was drauf ist (bzw. an Daten innerhalb der Diskette). Und das ausführende Programm selbst hieß je nach dem 'go', 'start', oder dergleichen.
Aber bei der immensem Ordner und Dateienflut ... werde ich mich wohl doch mit dem Gedanken anfreunden müssen, wenn ich mal was weitergeben will, diese doch etwas ausführlicher zu benennen.

Gefallen will mir das trotzdem nicht so recht.
Vor allem auch deshalb, weil manches damit nicht klar kommt.
Vor allem LInux nicht, was ich mal so höre (Und 1-mal erlebt habe).
Und gerade letzteres nutze ich sehr gerne.

Und Windows selbst scheint ja auch keine Leerzeichen für Ihre Programmdateien zu nutzen. Im Win-Sys-Ordner und so.
Aber da muss ich mal wieder nachsehen. Allerdings einfallen tut mir da derzeit keins.

Aber insgesamt glaube ich, wächst mir das Ganze über den Kopf, weil es nichts wirklich Einheitliches gibt.
Immer muss man darauf gefasst sein, Fehler zu beheben, nur weil man es Bequemer haben will. Den Zusammenhang kriege nicht auf die Reihe.

[BlackJack]

@Erwin: Das Inhaltsverzeichnis der 1541-Demodiskette:

Code: Alles auswählen

0 "test/demo  1/85 " 84 2a
14    "how to use"        prg
8     "how part two"      prg
7     "how part three"    prg
4     "vic-20 wedge"      prg
1     "c-64 wedge"        prg
4     "dos 5.1"           prg
9     "printer test"      prg
6     "disk addr change"  prg
12    "view bam"          prg
15    "display t&s"       prg
4     "check disk"        prg
11    "performance test"  prg
5     "seq.file.demo"     prg
18    "rel.file.demo"     prg
7     "sd.backup.c16"     prg
7     "sd.backup.plus4"   prg
10    "sd.backup.c64"     prg
7     "print.64.util"     prg
7     "print.c16.util"    prg
7     "print.+4.util"     prg
13    "uni-copy"          prg
30    "c64 basic demo"    prg
35    "+4 basic demo"     prg
8     "load address"      prg
7     "unscratch"         prg
5     "header change"     prg
319 BLOCKS FREE.

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.

Irgendwie scheinst Du davon aus zu gehen, das so etwas wie ein Dateiname standardisiert und rechner- und systemübergreifend gleich sein muss. Das ist keinesfalls so. Es ist nicht einmal vom Betriebssystem als ganzes vorgegeben, sondern hängt letztendlich vom konkret verwendeten Dateissystem auf den einzelnen Datenträgern ab. Ein Dateiname, der auf einer NTFS-Partition okay ist, muss sich nicht auf eine CD mit Joliet-Erweiterung schreiben lassen können.

Mit Deinen Wünschen zur Abwärtskompatibilität würden wir heute noch bei 8.3 Namen kleben. Wobei die für mich beim Umstieg von C64 (16 Zeichen) und Amiga (30 Zeichen) zum PC schon eine ärgerliche Einschränkung waren.

Warum alte Programme mit Leerzeichen Probleme haben? Aus dem gleichen Grund, warum es das Jahr-2000-Problem gab: Programmierer die sich dachten, das braucht schon keiner. Bei Tcl und Shell-Skripten, liegt's häufig daran, dass die keine richtigen Datenstrukturen kennen, sondern alles über Zeichenketten lösen und ein Leerzeichen so ein praktischer Trenner zu sein scheint. Jedenfalls solange bis das Leerzeichen selbst in den Daten auftauchen kann.

Was soll die 8 Zeichen-Beschränkung bei DOS-Dateinamen mit 8 Bit zu tun haben? Vor allem: von welchen 8 Bit reden wir hier? Mit einem 8-Bit-Offset lassen sich problemlos 256 Bytes ansprechen. Es wird eher der Speicherverbrauch ausschlaggebend gewesen sein ─ die Rechner hatten damals ja nicht die Mega- und Gigabytes an Arbeits- und Hintergrundspeicher.

Das Gross- und Keinschreibung nicht unterschieden wurden geht, wie bei den alten Programmiersprachen darauf zurück, dass nicht alle Rechner bzw. Tastaturen die Eingabe von beidem erlaubten.

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.

[Leonidas]

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.

[Erwin]

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.

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?

[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]

@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.

[Leonidas]

@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.

[Erwin]

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?

[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]

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?

[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]

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?