Struppi+2008-12-12 15:32:39--

[...]
D.h. also alle Skripte, die den Slash als Pfadtrenner verwenden, laufen nicht auf alten Macs?

Kommt darauf an. Wenn man Glück hat, laufen sie, denn '/' ist auf alten MacOS ein erlaubtes Zeichen in einem Dateinamen. So wie '\' unter *nix. Es trennt halt nicht die Verzeichniskomponenten.

MacOS 9 würde den Dateinamen C:/blubb/foo.txt also so interpretieren: Die Datei mit dem Namen /blubb/foo.txt im Wurzelverzeichnis des Laufwerkes mit dem Namen C.

Bei MacOS X kommt es übrigens darauf an, welche API-Funktionen man aufruft. Das meiste funktioniert mit POSIX-Pfaden, aber ein paar antike Funktionen, insbesondere solche, die sich mit AppleScript befassen, erwarten immer noch die alten HFS-Pfade.

Tut mir leid, wenn ich hier nachhake aber für mich klingt das alles nicht schlüssig. Welche API Funktionen? Ich spreche von den builtin Funktionen von Perl, als von open, sysopen, unlink, chdir usw.

Es ist also definitiv so, dass wenn ich in meinem Perlskript schreibe... ... das Perl dann abricht, wenn nicht eine Datei mir dem Namen "/blubb/foo.txt" im aktuellen Verzeichnis ist?
Das ist ja abenteuerlich, gut dass ich nie mit einem Mac zu tn hatte.

Was heißt builtin? Da geht nix automatisch!

Du musst an Perl einen für das jeweilige OS gültigen Dateinamen übergeben.

Oder glaubst du dass Unix aus C:\test.dat (ist ein gültiger Dateiname unter MS-DOS) auch einen gültigen Dateinamen in Unix-Manier wandeln kann?
Nein.

Gast+2008-12-13 13:07:02--

Was heißt builtin? Da geht nix automatisch!

Du musst an Perl einen für das jeweilige OS gültigen Dateinamen übergeben.

Das war mir neu, obwohl ich jetzt seit 10 Jahren Perl programmiere. Ich verwende immer den Slash als trenner für den Pfad.

Um auf meine Frage zurück zu kommen, d.h. also ja, Perl bricht dann mit einem Fehler ab, bzw. öffnet nicht die Datei foo.txt im Verzeichnis blubb?

Struppi+2008-12-13 12:56:45--

Es ist also definitiv so, dass wenn ich in meinem Perlskript schreibe...

Code (perl): (dl )

1
2
3

my $file = '/blubb/foo.txt'; # Das LW mal aussen vorgelassen
open FH, '<', $file;
....

... das Perl dann abricht, wenn nicht eine Datei mir dem Namen "/blubb/foo.txt" im aktuellen Verzeichnis ist?

Nö, wieso bricht bei dem Code Perl ab?
Eher wenn es so wäre:

Struppi+2008-12-13 12:56:45--

[...]
Es ist also definitiv so, dass wenn ich in meinem Perlskript schreibe...

Code (perl): (dl )

1
2
3

my $file = '/blubb/foo.txt'; # Das LW mal aussen vorgelassen
open FH, '<', $file;
....

... das Perl dann abricht, wenn nicht eine Datei mir dem Namen "/blubb/foo.txt" im aktuellen Verzeichnis ist?

Nein, in dem Fall wird Perl ziemlich sicher abbrechen, da auf den alten MacOS ein relativer Pfad mit einem ':' beginnen muss. Was nicht mit einem Doppelpunkt beginnt, ist ein absoluter Pfad. Das Betriebssystem würde also versuchen, das Hauptverzeichnis eines gemounteten Datenträgers, der /blubb/foo.txt heißt, zu öffnen.

Quote

Das ist ja abenteuerlich, gut dass ich nie mit einem Mac zu tn hatte.

Ich bin auch froh, dass ich mit MacOS 10.x arbeite und nur ab und zu am Rande mitbekomme, was für verrückte Vorstellungen das alte MacOS <= 9 so hatte ;-)

Nein, Perl bricht nicht automatisch ab!
Das open schlägt zwar fehl, es wird aber mit dem Code weiter gemacht, da kein die dem open folgt.

@GwenDragon: Stimmt natürlich – ich hatte gar nicht mehr so genau auf den Code geschaut.

GwenDragon+2008-12-13 17:16:35--

Nein, Perl bricht nicht automatisch ab!
Das open schlägt zwar fehl, es wird aber mit dem Code weiter gemacht, da kein die dem open folgt.

ich bin ja nicht dämlich ich wollte nur mein Posting nicht nachträglich ändern, deshalb hatte ich meine Frage ja auch nochmal erweitert.
Aber ich sehe ihr wollt oder könnt mir nicht konkret antworten. Schade, es hätte mich wirklich interessiert.

Perl nutzt die üblichen Funktionen eines systems, oder emuliert sie wenn sie nicht zur Verfügung stehen.
Aber konvertierungen macht er nur bedingt. Es hängt davon ab, wie viel Arbeit sich die Programmierer für die Portierung gemacht haben. Aber im allgemeinen wird fast nichts konvertiert.
Das betrifft nicht nur open,opedir sondern auch time und alle anderen Funktionen, die Systemcals repräsentieren. Bei Systemen, die POSIX-konform sind fällt das meinst nicht auf, jedoch bei wenn man Systeme hat, die sich anders verhalten, kann man schnell auf die Nase fallen.
Nehmen wir das open. Unter Windows ist sowohl "\" als auch "/" möglich, da die Programmierer das so vorgesehen haben. Unter MACOS <10 (MacOSX hst einen BSD Unterbau) bekommt man halt Probleme.

Nun konkret.
Öffnest du eine Datei mit dem Namen "/home/test/foo.txt" wird unter Windows unter "C:\home\test\foo.txt" gesucht findet aber auch "C:\HOME\TEST\FOO.TXT"
Problem: Was passiert wenn das Programm auf "D:" liegt? dann wird "D:\home\test\foo.txt" gesucht, oder doch in "C:\home\test\foo.txt" wenn das Arbeitsverzeichnis dort ist (was nicht gleich dem Verzeichnis sein muss in dem man sich gerade befindet).
Bei MacOS (<10) sucht er "SC00:/home/test/foo.txt" wobei "/home/test/foo.txt" der vollständige Name der Datei ist. Nicht erlaubtes Zeichen ist nur ":".
Vor allem die nicht erlaubten Zeichen können Probleme bereiten. Windows hat da eine ganze Reihe von Zeichen, TOS und CPM stoßen sich auch an ein paar, BEOS ist weitgehend POSIX konform und erlaubt alle Zeichen ebenso OS2.

Solange du nur auf einem System arbeitest, fällt das nicht auf. wenn du aber versuchst Code oder generierte Daten zu transferieren, kann es zu Problemen kommen.

Vor allem von POSIX-Systemen auf andere kann es reichlich kompliziert werden.