Python 2.5.1 startet nicht unter Vista32bit

[Leonidas]

Wobei man sich wundert, was Tcl für ein Schrott ist, dass es nicht mit Leerzeichen im Pfad zurecht kommt.

[Erwin]

Wobei man sich wundert, was Tcl für ein Schrott ist, dass es nicht mit Leerzeichen im Pfad zurecht kommt.

Der Schrott ist in dem Fall für mich Windows, weil die unbedingt dieses unreale Leerzeichen mit einbauen mussten.
Ich selbst habe, seit ich erfuhr, dass das Leer nicht wirklich existiert, sondern auf Art herumtrickserei des BS beruht (was vermutlich auch auf Umlaute und Sonderzeichen zutreffen soll), sofort alles umbenannt, und überall das Leer und Sonderzeichen-Zeug raus getan.

'program files' oder 'program-files', als wenn das für den Nutzer so dermaßen schlimm wäre.
Aber nein, MS muss scheinbar unbedingt ein (vermutlich künstliches - da es für Namen nicht wirklich machbar sein soll) Leerzeichen dazwischen hauen. Derweil würde der '-' sehr viel Ärger ersparen.
Tcl ist bestimmt nicht das einzige Programm, dass damit nicht klar kommt.

Und wer sauber programmiert, der vermeidet eigentlich Leer- und Sonderzeichen in Datei- und Ordnernamen. Und Er rechnet normalerweise auch nicht damit, dass solche Ordner als Standard auf der Festplatte sind.

Das Leerzeichen-Zeug ist eben unsicher, weil es, so weit ich weiß, künstlich erzeugt wird. Was meiner Meinung nach mit Tcl somit bewiesen ist.
Deshalb meide ich, seit ich das über Leerzeichen weiß, bei der Namensgebung all diese Leer- und Sonderzeichen wie die Pest.


PS: Denke ich werde dann doch Tkinter nehmen.
Weil ich diese Verweigerung unter komischen Ordner-Namen laufen zu wollen, mir sympathisch ist.

[Leonidas]

Und wer sauber programmiert, der vermeidet eigentlich Leer- und Sonderzeichen in Datei- und Ordnernamen. Und Er rechnet normalerweise auch nicht damit, dass solche Ordner als Standard auf der Festplatte sind.

Doch, wenn er sauber programmiert, dann rechnet er gerade damit. Sauber geschriebene Programme sollten immer funktionieren und nicht ihre Funktionsweise von Leerzeichen im Pfad abhängig machen. Sowas ist stümperhaft.

Stell dir vor, der User installiert dein Programm in ``$HOME/Meine Python Programme/``. Warum sollte es dort nicht laufen? Der User wird nicht einsehen, warum er die Leerzeichen durch Unterstriche ersetzen sollte. Das ist nämlich technisch nicht einmal notwendig und es ist widernatürlich. Ich_schreibe_meine_Texte_auch_mit_Leerzeichen. So what?

Und Tkinter auszuwählen, weil es auf Vista generell nicht funktionieren wird halte ich für ein hmm, seltsames Kriterium.

[Erwin]

Stell dir vor, der User installiert dein Programm in ``$HOME/Meine Python Programme/``. Warum sollte es dort nicht laufen? Der User wird nicht einsehen, warum er die Leerzeichen durch Unterstriche ersetzen sollte. Das ist nämlich technisch nicht einmal notwendig und es ist widernatürlich. Ich_schreibe_meine_Texte_auch_mit_Leerzeichen. So what?

Weil es laut meinen Informationen kein wirkliches Leerzeichen in Ordnern und Dateien gibt.
Es hat somit eine Unnötige Instabilität, weil da herumgetrickst wird.

Das Zeug hat doch vor allem MS (deshalb) daher gebracht, um damit die Spieler zu beeindrucken.
Meines Wissen ist all dies nichts vernünftiges.
Nicht wenn es einem um maximale Stabilität geht.

'$HOME' ??
Du benutzt Linux?
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.
Und ein Freund hat mich dann aufgeklärt, was es mit Leerzeichen (und Sonderzeichen) auf sich hat.
Also habe ich dann das Leerzeichen weggelassen. Und siehe da, auf einmal ging es.

[gerold]

Und wer sauber programmiert, der vermeidet eigentlich Leer- und Sonderzeichen in Datei- und Ordnernamen. Und Er rechnet normalerweise auch nicht damit, dass solche Ordner als Standard auf der Festplatte sind.

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

Was ich nicht verstehe ist, dass statt einheitlich englische Ordnernamen einzuführen, die Ordnernamen für den Benutzer maskiert werden. So schlimm ist das auch wieder nicht, wenn ein Ordner "program files" statt "Programme" heißt. Damit sollte jeder Computerbenutzer klar kommen. Aber nein, Vista muss die Sache ja wieder verkomplizieren. Beim Installieren wird dem Installationsprogramm "program files" angezeigt und anscheinend gibt es dann Probleme mit den Pfaden.

Lass uns mal Service Pack 1 abwarten -- vielleicht auch noch Service Pack 2. Vielleicht kann man Vista dann ohne Probleme zum Verlangsamen schneller Computer benutzen. Und Windows XP -- das seit Service Pack 1 sogar zum Arbeiten verwendet werden kann -- wird zur Mitte dieses Jahres nicht mehr verkauft.

Ach wie schön wäre es, wenn die Programme die ich zum Arbeiten brauche, endlich auch unter Linux funktionieren würden. Aber das wird in den nächsten zehn Jahren wahrscheinlich nicht der Fall sein.

mfg
Gerold

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