Mal ein bisschen Hintergrundwissen:
\r\n kommt von den Schreibmaschienen, die fuer eine neue Zeile zwei Aktionen benoetigen: Den Wagen zum Zeilenanfang zurueck zu fahren (Carriage Return) und die Rolle eine Zeile weiter zu drehen (Line Feed). Bei mechanischen Schreibmaschinen macht das der grosse Hebel rechts oben beides kombiniert. Wenn man Typewriter automatisiert ansteuert muss man die zwei Aktionen separat veranlassen. Das ist eine Hinterlassenschaft der Mechanik dieser Maschienen.
Die Macher von Unix haben sich entschieden, auf ihrem digitalen System diese Doppelaktion in \n (New Line) zu vereinen, da sie normalerweise nur in Kombination Sinn macht. Der Teletype-Treiber, der die tatsaechliche Hardware (die damals sowas wie eine Schreibmaschine war) angesteuert hat, hat die dann automatisch beide Aktionen veranlasst. Dass das Zeilenende nur ein Zeichen umfasst, statt zwei hat Vorteile. Es vereinfacht die Statemachine von Parsern und erlaubt es, nur ein Zeichen fuer ungetc(3) zu puffern. Zudem: Warum zwei Zeichen verwenden, wenn eines ausreicht?!
Dass DOS und danach Windows *viel* spaeter \r\n verwendet haben ist IMO eine schlechte Entscheidung gewesen. (MacOS (pre X) hat nur \r verwendet, was aehnlich gut wie \n ist -- von der Sinnhaftigkeit IMO nicht ganz auf gleicher Hoehe, aber ebenso deutlich besser wie die Kombination aus zwei Zeichen. Die Klartext-Internetprotokolle verwenden auch \r\n weil das am portabelsten war. Windows konnte nur \r\n, Unix war in der Lage \n oder \r\n zu senden und zu lesen.
Dass Unix nun nicht beliebige Zeilenendezeichen und -kombination akzeptiert sollte nicht weiter verwundern. Seit 50 Jahren (!) verwendet Unix \n, stimmig, einheitlich und durchgaengig. Ein \r kann in Unix fuer ander Dinge eingesetzt werden. Es hat nichts mit Zeilenenden zu tun. Wenn man nun alle Programme dahingehend erweitern wuerde, dass sie verschiedene Zeilenendekombination akzeptieren wuerden, die zuvor keine Zeilenenden waren und vermutlich zu anderen Zwecken eingesetzt worden sind, waere das nicht nur ein Riesenaufwand, sondern auch ein Riesenchaos. Man koennte sich auf nichts mehr verlassen. Man wuerde die Konsistenz und Stimmigkeit aufgeben, zugunsten einer Bequemlichkeit, die auf Unwissenheit und Datenchaos basiert.
Dass am Ende der letzten Zeile ein Newline stehen muss, ist eine Definitions- und Konventionsentscheidung: Textdateien in Unix bestehen aus Zeilen und Zeilen enden mit einem Newline-Zeichen. So einfach ist das. (Hier sei auch an Doug McIlroys ``The UNIX and the Echo'' hingewiesen.
https://everything2.com/title/The+UNIX+and+the+Echo) Alle Textutilities in Unix fuegen diese letzte Newline an -- nicht als Sonderfall, sondern als Normalfall, denn jede Zeile, egal ob die letzte oder eine davor, endet auf ein Newline. Taeten sie das nicht, dann koennte man beispielsweise `cat a b' nicht generell verwenden. Dann muesst cat(1) eine Logik haben, Newlines zwischendurch einzufuegen ... aber nur wenn es sich um Textdateien handelt, denn bei Binaerdateien duerfte es das nicht ... aber wie unterscheidet man Text- und Binaerdateien. In Unix ist alles Text, und damit ist die Frage eine Interpraetationssache der verarbeitenden Programme. Ein generisches Tool wie cat(1) kann es somit nicht wissen. Zudem waere es noch nicht mal so einfach, denn man koennte beim Wiederzusammenfuegen mit cat(1) nicht unterscheiden, ob eine Textdatei mit `split -b' oder `split -l' zerteilt worden ist. -- Das nur als kleiner Einblick in die Abgruende und auf die Drachen, denen man gegenuebersteht, wenn man es ``viel bequemer und besser'' machen will.
Cross-Plattform-Arbeiten und beschraenkte Programme, wie der interne Editor von WinSCP, sind zumeist frustrierend, weil sie nur versuchen koennen, sich jeweils richtig zu verhalten, ohne definitiv wissen zu koennen, was tatsaechlich richtig waere. Probleme wie deines sind mri auch schon oft genug untergekommen. Wenn die Emotion verflogen ist, solltest du es als Pech bei der Kombination der Programme und Arbeitsumgebungen werten und nicht mehr einer vermeintlich schlechten Programmierung von Unix die Schuld dafuer geben.
