OK, die stuendlichen Snapshots gehen wieder
	(Einige Stunden spater:)
	Auch die taeglichen Snapshots gehen wieder
	Apple ist soooo benutzerfreundlich. Wenn der User mit Safari oder Firefox eine
	  PDF Datei runterlaedt, vermutlich in der Absicht, sie zu lesen oder zu drucken,
	  dann zeigen Preview (dt. Vorschau) und der Adobe Reader die Fehlermeldung
	   "Die Datei ist beschaedigt"
	  und schlagen vor, sie in den Muell zu werfen.
	  Wenn man die Datei mit pdf2ps nach PostScript wandelt und dann mit Preview "oeffnet",
	  dann wandelt der es wieder nach PDF und kanns anzeigen. Wenn man die Datei nach
	  /tmp bewegt und in $HOME/Downloads einen symlink nach /tmp/$diedatei.pdf macht,
	  kann ers auch anzeigen. Wunder der Technik (und User Experience, im Folgenden als UX
	  abgekuerzt). Nachdem die Apple Community ja vieleviele Foren hat, schaut man da
	  mal rum und findet Kwalitaetsvorschlaege wie z.B. den Adobe Reader Plugin zu entfernen
	  (der hat ja funktioniert), den Adobe Reader auf eine bestimmte Version zu bringen
	  (unsere ist neuer), die Datei nochmal runterzuladen (bringt nix), sie mit dem
	  Disketten-Icon des Reader Plugins zu speichern (bringt nix), usf.
	  Also in der Shell mal schaun, was an diesen Dateien anders ist:
	   file *
	  sagt, dass sind alles PDFs,
	   ls -l 
	  in zeigt Zeilen der Form
	   -rw------@  1 user    group    135245 Jan 19  2014 tr-20003.pdf
	  Was bedeutet der Kringel am Ende der Permissions??? Also in die Manpage von ls(1)
	  geschaut. Keine Erwaehnung des Kringels (UX++). Mit
	   ls -lO
	  nach moeglichen BSD flags (chflag(1)) geschaut, keine. Tante Google verweist
	  auf eine Erklaerung, dass das "extended attributes" sind (wie das MacOS die
	  auf NFS gespeichert kriegt waer noch spannend). Mit 
	   xattr $datei.pdf
	  kann man sehen, dass hier
	   com.apple.quarantine
	  als Attribute gesetzt ist, mit
	   xattr -d com.apple.quarantine $datei.pdf
	  kann man das auch entfernen, und die PDF Viewer akzeptieren die Datei dann,
	  aber beim naechsten Download hat man das Problem ja wieder (UX++).
	  Eine Moeglichkeit, diesen Unfug zu beenden, ist angeblich
	   defaults write com.apple.LaunchServices LSQuarantine -bool NO
	  Das kann man als User und als Sysadmin eingeben und kriegt eventuell verschiedene Antworten
	  auf
	   defaults read | grep LSQ
	  (UX++)
	  Wenn man in der Suchzeile rechts oben "Launch" eingibt, kriegt man keinen Hinweis auf
	  diesen Service, der fuer andere Programme Daten ablegt und diese lustigen xattr dranhaengt
	  (UX++).
	   
	Und nochwas: Wenn man in einem Terminal auf MacOS eine Pipe | tippt, muss man wegen
	  den kranken Tastaturen auf Alt+7 druecken. Wenn man danach noch einen Space tippert,
	  weil das einfach schoen ausschaut, und den Finger nicht von der Alt-Taste genommen
	  hat, dann wird da ein Space auf den Bildschirm gemalt und man tippt froehlich weiter,
	  zum Beispiel
	    defaults read | grep LSQ
	  Dann kriegt man den Fehler 
	     grep: command not found
	  und tippt
	     which grep
	  was
	     /usr/bin/grep
	  liefert. 

	  Was ist die Erklaerung? In den Mac-Guru-Foren wird empfohlen:
	    1. das System neu zu installieren
	    2. die Tastatur an einen anderen USB Port zu haengen
	    3. eine PC Tastatur zu nehmen (eh schlauer)

	  Was aber das tatsaechliche Problem ist:
	  Das nach der Pipe ist kein Space (U+0020), 
	  sondern der non-breaking Space (U+00A0). Und der ist (auch bei Apple(TM))
	  nicht in der Liste $IFS der Field-Separators der Shell und wird deswegen als Teil des Kommandonamens
	  genommen, und ein Kommando " grep" gibt es wirklich nicht.
	  What were they thinking?!??
	

[/bauerm] permanent link