Brauchen wir ein Bugfix-macOS? - Ein Pro und Contra bei heise online

[tehabe]

Nein, eher „ist nicht vorgesehen“ in Quicklook, weil Quicklook überwiegend mit System-integrierten Dateien funktioniert, funktionieren soll.

Eine Funktion funktioniert nicht wie erwartet, Quicklook kann .eml Datei lesen aber nur wenn diese LF-Zeilenenden haben. Und früher konnte Quicklook auch mit CRLF umgehen aber seit mindestens 2020 nicht mehr.

TextEdit kann auch Textdateien sowohl mit LF als auch mit CRLF-Zeilenenden richtig anzeigen. Und wenn du .eml durch .txt ersetzt zeigt Quicklook auch die Datei komplett an, inkl. der CRLF-Zeilenschaltungen.

Solche kleinen Fehler sind einfach nur nervig.

P.S. Selbst Windows' Notepad kann seit einen Jahren mit LF-Zeilenenden umgehen.

P.P.S. Classic Mac OS hat IIRC CR-Zeilenenden benutzt

 

[Difool]

Eine Funktion funktioniert nicht wie erwartet, Quicklook kann .eml Datei lesen aber nur wenn diese LF-Zeilenenden haben. Und früher konnte Quicklook auch mit CRLF umgehen aber seit mindestens 2020 nicht mehr.

CRLF ist ein von Windows genutztes Format.
Macs und Linux-Systeme nutzen nur Line Feed (LF).

TextEdit kann auch Textdateien sowohl mit LF als auch mit CRLF-Zeilenenden richtig anzeigen. Und wenn du .eml durch .txt ersetzt zeigt Quicklook auch die Datei komplett an, inkl. der CRLF-Zeilenschaltungen.

Hurray! Das ist doch fein.
Quicklook zeigt alle Formate richtig an – bis auf eben halt die durch „safe as“ erstellten .eml-Dateien.
Weil – imo – diese Plattform-übergreifend sein sollen … respektive Extrawurst für Windows.

Solche kleinen Fehler sind einfach nur nervig.

Daher sehe ich das nicht als Fehler an.

P.S. Selbst Windows' Notepad kann seit einen Jahren mit LF-Zeilenenden umgehen.

Wow. Das wurde aber mal Zeit – haben die sich an Mac und Linux Ausgaben angenähert. Ist doch positiv.

P.P.S. Classic Mac OS hat IIRC CR-Zeilenenden benutzt

Keine Ahnung.

Insgesamt könnte diese Aussage diesbezüglich kontrolliert werden:

Zusammenfassend: QuickLook kann CRLF-Textdateien problemlos öffnen und anzeigen, da QuickLook die Zeilenumbruch-Konvertierung unterstützt. Dies ist besonders wichtig, wenn man mit Textdateien arbeitet, die von Windows-Systemen stammen.

Denn, wenn überhaupt, wäre die ausgehende Formatierung durch Mail.app zur Interoperabilität von CRLF hier fehlerhaft und nicht Quicklook.

Hättest du denn eine Option, mal eine generierte .eml-Datei von Windows mit Quicklook voranzuschauen?

 

[meisterleise]

Hmm, seltsam dass hier niemand mal auf die Idee kommt, das eml-Problem von @tbo gegenzuprüfen, obwohl ich bereits in #35 - #39 darauf hingewiesen habe, dass ICH auf allen meinen Macs dieses Problem nicht habe.

Nun, ich habe gerade herausgefunden, warum @tbo das Problem hat und ich nicht.
@tbo wählt anscheinend in der Mail.app "Speichern unter", während ich mir einfach die jeweilige eMail auf den Schreibtisch ziehe. Im ersteren Fall kommt es tatsächlich zum genannten Fehler, bei meiner Vorgehensweise allerdings nicht.

Insofern würde ich einerseits zustimmen, dass es sich dabei um einen Bug handelt, wofür es aber andererseits eine einfache Lösung gibt.

 

[Difool]

Hmm, seltsam dass hier niemand mal auf die Idee kommt, das eml-Problem von @tbo gegenzuprüfen, obwohl ich bereits in #35 - #39 darauf hingewiesen habe, dass ICH auf allen meinen Macs dieses Problem nicht habe.

Nun, ich habe gerade herausgefunden, warum @tbo das Problem hat und ich nicht.
@tbo wählt anscheinend in der Mail.app "Speichern unter", während ich mir einfach die jeweilige eMail auf den Schreibtisch ziehe. Im ersteren Fall kommt es tatsächlich zum genannten Fehler, bei meiner Vorgehensweise allerdings nicht.

Insofern würde ich einerseits zustimmen, dass es sich dabei um einen Bug handelt, wofür es aber andererseits eine einfache Lösung gibt.

Das hatte ich heute doch alles bereits so nachvollzogen.
Und ja, es beruht nur auf der „Speicher unter“-Variante aus Mail.app, weil damit die Interoperabilität zu Windows gegeben sein soll.
Quicklook mag das anscheinend nicht; zumindest kann Quicklook mit dem macOS und Linix-Standard umgehen. (siehe oben meine Beiträge)

 

[tehabe]

CRLF ist ein von Windows genutztes Format.
Macs und Linux-Systeme nutzen nur Line Feed (LF).

Es geht hier nicht um Windows oder macOS oder so, sondern E-Mail und hier gilt:

Messages are divided into lines of characters. A line is a series of characters that is delimited with the two characters carriage-return and line-feed;

Übersetzt: Nachrichten sind unterteilt in Zeilen mit Zeichen. Eine Zeile ist eine Reihe von Zeichen die mit den zwei Zeichen carriage-return (CR) und line-feed (LF) endet.

Daher ist CRLF richtig, wenn du eine E-Mail von RoundCube herunterlädst benutzt diese auch CRLF.

 

[meisterleise]

Das hatte ich heute doch alles bereits so nachvollzogen.

Okay, aber dass sich "speichern unter" anders verhält als "ziehen und ablegen" ist doch nicht logisch – oder stimmst du mir da nicht zu?

 

[Difool]

Es geht hier nicht um Windows oder macOS oder so, sondern E-Mail und hier gilt:


Übersetzt: Nachrichten sind unterteilt in Zeilen mit Zeichen. Eine Zeile ist eine Reihe von Zeichen die mit den zwei Zeichen carriage-return (CR) und line-feed (LF) endet.

Daher ist CRLF richtig, wenn du eine E-Mail von RoundCube herunterlädst benutzt diese auch CRLF.

Mag ja sein, nur ist bei Unix halt Line Feed (LF) Standard.
Und du dürftest wohl auch keine native macOS App finden, welche „CR“ mit reinschreibt.
Oder muss ich jetzt auch sagen: „Es geht hier nicht um RoundCube“?

Vor MacOSX wurde auf einem Macintosh „CR“ benutzt und ab OSX dann traditionell Unix-mäßig „LF“.
Windows konvertiert alles in „CRLF“, daher der ewige struggle ala \r\n vs \n.

Kontrolliere ich also eine mit „save as“ aus Mail.app gespeicherte eMail im Terminal, kommt die Bestätigung zur Verwendung von CRLF:

me@Mini ~ % file /Users/me/Documents/02_PROJEKTE/Test-saveas.eml
/Users/me/Documents/02_PROJEKTE/Test-saveas.eml: SMTP mail text, ASCII text, with CRLF line terminators

Alles gut und Mail.app speichert hinsichtlich zur allgemeinen Verwendung mit CRLF-Format.

Selbes Prozedere im Terminal mit file Datei einer per Drag & Drop aus Mail.app gezogenen eMail:

me@Mini ~ % file /Users/me/Documents/02_PROJEKTE/Test.eml
/Users/me/Documents/02_PROJEKTE/Test.eml: SMTP mail text, ASCII text

Ergebnis: ASCII text > LF

So auch mit Mails als „reiner Text“.

@meisterleise
Für mich besteht hier die Logik des unterschiedlichen Verhaltens darin, dass man mit „Sichern unter“ eine CRLF-kompatible-Datei erhält.
Da diese aber nicht beim unixoiden macOS als Standard gilt, zeigt Quicklook diese auch nicht korrekt an. Die LF-Dateien bzw. ASCII text schon.