Die kleinen Hürden der Interoperabilität

English

Heute hat sich in der IT-Landschaft vieles vereinheitlicht, so dass Interoperabilität besser geworden ist als vor 20 Jahren.

Ein paar Beispiele:

  • Netzwerktechnologie: Heute hat sich TCP/IP als Netzwerktechnologie durchgesetzt. Sogar die Verkabelung mit RJ45/Ethernet und die Funknetze (WLAN) sind standardisiert und passen zwischen verschiedensten Geräten zusammen. Vor ein paar Jahren gab es beliebig viele proprietäre Netzwerktechnologiene, die nicht miteinander kompatible waren, z.B. BitNet (IBM), NetBios (MS), DecNet (DEC), IPX (Novell),….
  • Zeichensätze: Heute haben wir Unicode und ein paar standardisierte Zeichensätze und Codierungen und zumindest für Web und EMail Wege, diese Metainformation zur Verfügung zu stellen. Dieser Bereich ist noch nicht problemfrei, aber im Vergleich zu früheren Jahren, wo verschiedene EBCDIC-Codierungen regierten oder wo Zeichensätze üblich waren, die keine Umlaute enthielten, haben wir hier auch große Fortschritte in der Standardisierung erlebt.
  • Zahlen: Es hat sich für Fließkommazahlen und für Ganzzahlen eine gewisse, relativ kleine Menge von numerischen Typen etabliert, die immer wieder benutzt werden und die sich überall (fast) gleich verhalten. Problematisch bleibt der Integer-Überlauf.
  • Software: Früher hat man Software für eine spezifische Maschine entwickelt, also eine CPU-Architektur mit einem Betriebssystem. Heute hat man die Möglichkeit, einheitliche „Plattformen“ auf verschiedenester Hardware zu haben: Linux läuft auf fast jeder physikalischen und virtuellen Hardware vom Mobiltelefon bis zum Supercomputer und es ist praktisch derselbe Kernel, lässt sich also gleich nutzen. Java, Ruby, Perl, Scala und andere Programmiersprachen sind auf verschiedensten Plattformen vorhanden und bieten sozusagen ihre eigene abstrakte Plattform. Und das Web ist eine einfache und sinnvolle Möglichkeit, Applikationen für verschiedenste Geräte nur einmal zu entwickeln.
  • Dateisysteme: Es hat sich ein einigermaßen einheitliches Verständnis dafür, wie ein Dateisystem aussehen soll, entwickelt, mit einigen betriebssystemspezifischen Besonderheiten. Für Datenhaltung lassen sich Dateisysteme aber gemeinsam für verschiedene Betriebssyteme nutzen, zum Beispiel mit Samba.
  • GNU-Tools: Die GNU-Tools (bash, ls, cp, mv,……..) sind unter Linux zum Standard geworden und ihren traditionellen Unix-Pendents, wie man sie noch heute z.B. unter Solaris findet, haushoch überlegen. Man kann sie aber auf praktisch jedem Unix installieren und es gibt mit cygwin sogar eine Portierung für MS-Windows.

Interoperabilität ist heute für viele Interoperabilität zwischen Linux (oder anderen Posix-Systemen) und Win32/Win64 (MS-Windows).

Erfahrene Linux-Anwender sind es gewohnt, als Trennzeichen für Pfade diesen Schrägstrich „/“ (forward slash) zu verwenden. Der umgekehrte Schrägstrich „\“ wird benötigt, um Sonderzeichen zu „escapen“. In der MS-Windows-Welt sieht man häufig, dass der umgekehrte Schrägstrich „\“ (backslash) als Trennzeichen verwendet wird. Das ist nötig im CMD-Fenster, weil dieses den normalen Schrägstrich „/“ nicht durchlässt. Meine Erfahrung ist aber, dass die low-level-Win32-Bibliotheken beide Varianten verstehen. Sowieso werden die normalen Schrägstriche „/“ von cygwin, ruby, perl, java u.s.w. verstanden. Man kann sich also fast immer die Mühe sparen, hierfür Fallunterscheidungen zu machen, außer man schreibt cmd-Skripte. Und wer will sich das schon für mehr als fünf oder sechs Zeilen antun. Ich empfehle also für Java-, Perl- und Ruby-Entwickler auch unter MS-Windows ausdrücklich immer den normalen Schrägstrich „/“ als Trenungszeichen in Pfaden zu verwenden. Das ist lesbarer, schon weil man den umgekehrten Schrägstrich „\“ oft verdoppeln muss, und es erleichtert die Portablität auf Linux oder Posix.

Tückischer ist die Sache mit dem Zeilenwechsel. In der Linux- und Unix-Welt ist in Textdateien ein „Linefeed“ („\n“=Ctrl-J) als Zeilenwechsel üblich. In der MS-DOS und MS-Windows-Welt hat sich dagegen „Carrige-Return+Linefeed“ („\r\n“=Ctrl-M Ctrl-J) etabliert. Die meisten heutigen Programme stören sich nicht daran und kommen unter beiden Plattformen mit beidem klar. Wer unter MS-Windows Notepad verwendet, wird mit Linux-Zeilenenden keine Freude haben, aber Notepad muss man wirklich unter MS-Windows nicht benutzen, da es dort bessere Editoren (gvim, emacs, ultraedit, scite, …) gibt. Umgekehrt führt der MS-Windows-Zielenwechsel bei ausführbaren Skripten unter Linux zu Probleme. Skripte enthalten normalerweise in der ersten Zeile so etwas wie „#/usr/bin/ruby“. Das nimmt das Betriebssystem als Hinweis, dass man das Programm /usr/bin/ruby verwenden soll, um dieses Skript auszuführen. Wenn aber die Zeile mit Ctrl-M Ctrl-J endet, dann wird nach einem Programm „/usr/bin/ruby^M“ gesucht (^M = Ctrl-M = „\r“) gesucht, das es natürlich nicht gibt und man erhält eine unverständliche Fehlermeldung.

Ad hoc kann man die Umwandlung schnell so machen:

$ perl -i~ -p -e ’s/\r//g;‘ script

Oder für die Umgekehrte Richtung:

$ perl -i~ -p -e ’s/\n/\r\n/g;‘ textfile

Wer noch Subversion verwendet, sollte Skripte dort so einstellen, dass sie immer nur mit „LF“ als Zeichenwechsel gespeichert werden und Textdateien vielleicht jeweils mit der Konvention des Betriebsystems, unter dem der Client läuft.

Links

Share Button

Beteilige dich an der Unterhaltung

3 Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

*