Alex Online Today

some experience to be shared

By

cUrl unter Mac OS updaten/reparieren

Vorgeschichte: (Vermutlich) seit dem Update auf Mavericks funktioniert mein cUrl nicht mehr korrekt. Beim Ausführen von curl im Terminal erhalte ich folgende Fehlermeldung: “Bad CPU type in executable” (eventuell wurde mein eigenes build nicht durch Mavericks überschreiben)

Warum auch immer, folgendermaßen läd und installiert man cUrl neu:

1. Download der aktuellen Version von http://curl.haxx.se/download.html [Download der sourcen als .tar.gz
2. Navigiere im Terminal zu Downlaods: cd ~/Downloads
3. Entpacke den Download: tar zxf curl-7.33.0.tar.gz
4. Wechsel ins richtige Verzeichnis: cd curl-7.33.0
5. Build + install: make && sudo make install

–> Anschließend sollte curl wieder funktionieren:
6. Test: curl –version
—> curl 7.33.0 (x86_64-apple-darwin13.0.0) libcurl/7.33.0 OpenSSL/0.9.8y zlib/1.2.5

By

$PATH unter Mac OS X

Was ist $PATH
Die $PATH Variable definiert, in welchen Verzeichnissen ausführbare Dateien d.h. per Befehl ausführbare Programme, abgelegt sind, sowie die Reihenfolge in welcher diese Verzeichnisse nach ausführbaren Dateien durchsucht werden.
$PATH besteht aus Einträgen des Systems, die für alle Benutzer gleich sind (systemweit), sowie individuellen Benutzereinträgen (benutzerspezifisch).
Die $PATH Variable gibt es übrigens nicht nur unter OS X sondern auf quasi allen Unix und Linux Systemen und auch unter Windows. Die Funktion ist hierbei allgemein die Gleiche – nur wie und wo $PATH definiert wird ist unterschiedlich. Die folgende Anleitung beschreibt das Verhalten unter OS X 10.5 bis 10.8.

1. $PATH auslesen
Um $PATH zu auszulesen öffnet man ein Terminal Fenster (Spotlight –> “Terminal”) und gibt folgenden Befehl ein:

echo $PATH

Man erhält dann beispielsweise folgende Ausgabe:

/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/usr/local/git/bin:/usr/local/MacGPG2/bin:/usr/texbin

2. $PATH Syntax
Die Variable besteht aus einer Aneinanderreihung von Verzeichnispfaden, die durch einen Doppelpunkt “:” getrennt sind.
z.B. sind /usr/bin und /bin Standardverzeichnisse des Systems. Dort finden sich auch Programme wie “echo” -> wie wir es zur Anzeige von $PATH gerade verwendet haben. Wichtig ist folgendes – je früher ein Verzeichnis in $PATH auftaucht, desto höher ist seine Priorität.

Ein Beispiel:
Das Programm echo liegt standardmäßig im Verzeichnis /bin. Wird nun ein weiteres Programm mit dem Namen echo in /usr/local/bin abgelegt, so hat das Programm echo im Verzeichnis /bin immer vorrang, denn bei der Auführung wird beim Auffinden eines passenden Programms im $PATH die Suche abgebrochen. Wenn nun in Zukunft die Programme in /usr/local/bin vorrangig ausgeführt werden sollen, muss man $PATH ändern in etc/paths

3. $PATH systemweit anpassen
Seit Mac OS 10.5 Leopard wird $PATH durch das Programm /usr/libexec/path_helper verwaltet. path_helper wird durch /etc/profile beim Öffnen eines neuen Terminal Fensters ausgeführt.

1. Die Einträge der Datei /etc/paths
/usr/bin
/bin
/usr/sbin
/sbin
/usr/local/bin

2. Die Einträge in allen Dateien im Verzeichnis /etc/paths.d/
– Hier hinterlegen häufig Frameworks ihre Pfad-Einträge, z.B. von git oder LaTex
– Diese Einträge werden in Alphabetischer Reihenfolge hinzugefügt
– Eine Datei muss mit einer leeren Zeile enden

Die Dateien sind für gewöhnlich schreibgeschützt und die Verzeichnisse versteckt. Am besten man arbeitet im Terminal:
a) Navigation zu den Ordnern:

> cd /bin

b) Editieren mit vim (sudo für root Rechte)

>sudo vi paths

Nütliche Befehle in vim sind:
i Editieren der aktuellen Zeile
dd Löschen der aktuellen Zeile
i und dd werden mit esc beendet.
:q! Beenden (explizit ohne Speichern der Änderungen)
:wq! Beenden und speichern einer readonly Datei

4. Benutzerdefinierte Einträge in $PATH
Vor dem Öffnen eines neuen Terminal Fensters werden werden die Datein .profile und .bash_profile (in dieser Reihenfolge) im Benutzerordner (~) des aktuellen Nutzers ausgeführt. Es handelt sich um versteckte Dateien (beginnend mit ‘.’) weshalb man sie normalerweise im Finder nicht sieht. Um sie im Terminal anzuzeigen geht man folgendermaßen vor:
a) Navigation zum Benutzerverzeichnis:

>cd ~

b) Anzeigen aller Dateien

> ls -a

Um die Dateien zu bearbeiten, nutzt man am besten wieder vim
c) Bearbeiten mit vim (ohne root Rechte)

vi .profile

In diesen Dateien kann durch den Eintrag

export PATH=$PATH:/newpath

die $PATH Variable für diesen Benutzer erweitert werden. Den bestehenden $PATH stellt man für gewöhnlich vorne an.

By

Java:deprecated – welche Strategie verfolgt Apple?

Kurz nach Vorstellung des neuen Macbook Air hat Apple auch ein Update für Java veröffentlicht. In den release Notes ist folgendes prominent an erster Stelle zu lesen:

As of the release of Java for Mac OS X 10.6 Update 3, the version of Java that is ported by Apple, and that ships with Mac OS X, is deprecated.
This means that the Apple-produced runtime will not be maintained at the same level, and may be removed from future versions of Mac OS X. The Java runtime shipping in Mac OS X 10.6 Snow Leopard, and Mac OS X 10.5 Leopard, will continue to be supported and maintained through the standard support cycles of those products.

darauf hat mich vorhin ein Artikel auf heise.de aufmerksam gemacht.

Welche Bedeutung hat die Java Runtime auf der Mac Plattform? Einige Fakten

– Die Java Runtime dient als Grundlage für viele Anwendungen, von denen einige auch nur deshalb für den Mac portiert wurden, da sich durch die Verwendung von Java der Aufwand in Grenzen hält.
– Besonders beliebt war Java auf dem Mac auch deshalb, weil es stets mit dem Betriebsystem mitgeliefert wurde. Bis heute ist die JRE auf jedem Mac vorinstalliert.
– Die gute Integration erlaubt, dass viele Java Anwendungen optisch nicht von Cocoa Anwendungen (der nativen Mac Umgebung) zu unterscheiden sind.

Die Alternative
– z.B. für Windows wurde die Java Runtime immer von Oracle bzw. Sun entwickelt.
– Das Open Source Projekt SoyLatte bietet schon seit langem aktuellere Releases des JDK für die Mac Plattform (insbesondere relevant für Entwickler).

Die möglichen Gründe für Apple von der eigenen Runtime abzuweichen?
– Apple möchte den Mac als Anwendungsplattform geschlossener gestalten und versucht zukünftig ausschließlich auf Cocoa zu setzen.
– Apple sieht in der Entwicklung von Java auf Clientseite keinen so großen Nutzen mehr und hofft auf andere Anbieter (Oracle, Open Source Community).
– Apple ist von der neuen Abmahn-Politik Oracles eingeschüchtert und möchte einen Rechtsstreit verhindern.

Was bedeutet das für die Zukunft von Java auf dem Mac?

Hier sind verschiedene Szenarien möglich, manche machen den Mac für Java Entwickler und High-End User sehr uninteressant. Aber Ich kann mir nicht vorstellen, dass Apple es sich unbedingt mit der (Java-) Entwicklergemeinde verscherzen möchte, schließlich gibt es hier viele Zusammenhänge auch zur Mac Entwicklergemeinde und der Mac als Entwicklungsplattform hat gerade in letzter Zeit enormen Zuwachs erfahren.

1. Szenario: Apple möchte den Mac als Anwendungsplattform geschlossener gestalten und versucht zukünftig ausschließlich auf Cocoa zu setzen.
Folge: Im App Store werden keine Java Applikationen zugelassen. Zu erwarten ist dann allerdings, dass Oracle relativ schnell eine eigene und auch möglichst gute Runtime zur Verfügung stellen wird, um Apple gegenzusteuern. Könnte für Apple nach hinten losgehen, weil man erstens die Entwickler verärgert und zweitens nicht wirklich etwas erreicht.

2. Szenario: Apple hat schon seit einiger Zeit sehr zögerlich neue Java-Versionen übernommen. Offenbar hat man einfach die Lust daran verloren und hofft, Oracle oder OpenSource Projekte wie SoyLatte werden zukünftig die Arbeit übernehmen.
Folge: Genau das passiert auch, eine Verzögerung ist jedoch vorerst nicht auszuschließen. Die Folgen sind besonders schlimm, denn von Oracle oder der Open Source community sind keine derartig guten Integrationen der JRE in Mac OS zu erwarten, wie wir sie momentan kennen. Dies könnte Java auf dem Mac tatsächlich gehörig schaden.

Die Zukunft von Java wird auch für Mac OS eine wichtige Rolle spielen. Ich persönlich als Entwickler würde mich eventuell von Apple trennen, wenn zukünftig keine ordentliche JRE mehr aufzutreiben ist. Denn selbst wenn ich auf einige Javaprogramme verzichten könnte, so basieren doch die alle Eclipse-Derivate ebenso auf Java. Das SKD alleine reicht zum Entwickeln leider nicht aus.

By

Automatisches Backup von FAT32 USB Sticks auf dem Mac

Leider unterstützt die hervorragende Backuplösung von Apple – Time Maschine – keine FAT32 formatierten USB Sticks als Quellmedien. Gerade bei diesen kleinen Dingern ist die Wahrscheinlichkeit eines Verlustes jedoch besonders hoch, weshalb man entweder gar keine kritischen Daten darauf speichern, oder regelmäßig Backups erstellen sollte.

Mein Ziel: Bei jedem Anstecken des USB Sticks wird der gesamte Inhalt automatisch via AppleScript und rSync auf ein Verzeichnis auf meinen Mac kopiert. Vor korrupten Dateien schützt mich dann das automatische Time Maschine Backup.

Ich bin natürlich nicht der erste, der sich mit der Thematik befasst. Im Internet fand  zwei etwas angestaubte Einträge, einer beschrieb eine Lösung mit AppleScript und dem Tool “Do Something When” [Link1], der andere mit einer FolderAction im Volumes Verzeichnis und einem Script auf jedem USB Stick [Link2]. Wem meine Lösung nicht gefällt, der wird eventuell dort glücklich.

Der Ansatz mit der FolderAction und einem Script auf dem USB Stick gefällt mir am besten. Allerdings habe ich das Script ein wenig für meine Bedürfnisse angepasst, da ich das Archivieren der Daten im Endeffekt Time Maschine überlassen möchte. Ausserdem habe ich eine Abfrage eingebaut, denn das Script startet in der ursprünglichen Form beim Anschließen eines Datenträgers ohne Rückfrage das Script rsync.app vom Stick, was Sicherheitstechnisch bedenklich ist.

Also folgend meine Lösung: (Der Code wurde größtenteils von hier kopiert und modifiziert)

Teil 1: Das Folderaction Script:

property backup_script : "rsync.app" (* add/change this string to match the name of your script *)
 
on adding folder items to this_folder after receiving these_volumes
tell application "Finder"
try
set the volume_list to every file of this_folder
 
(* go through all entries in /Volumes/ *)
repeat with i from 1 to number of items in volume_list
set this_item to the original item of item i of volume_list
if the kind of this_item is "Volume" then
set this_disk to (this_item as alias)
 
(* is this item the newly mounted disk? *)
if this_disk is in these_volumes then
 
(* iterate through all files in the root of disk *)
set searchCmd to "ls -d " & quoted form of POSIX path of this_disk & backup_script
(* check to see if a backup script is available *)
set searchResult to ""
try
set searchResult to do shell script searchCmd
end try
(* run the backup script *)
if (searchResult starts with "/Volumes") then
set backupFile to POSIX file searchResult as alias
display dialog "Backupscript auf Volume gefunden, backup ausführen?" buttons {"JA", "NEIN"} default button 2 with icon stop
if button returned of result is "NEIN" then return
open backupFile
end if
 
end if
end if
end repeat
on error error_message number error_number
if the error_number is not -128 then
display dialog error_message buttons {"OK"} default button 1
end if
end try
end tell
end adding folder items to

1. Kopiere das Script in den Script Editor

2. Speichern als… “Script” unter /Library/Scripts/Folder Action Scripts/

3.-  Mit 10.6 und folgenden: Öffne im Finder die Systempartition

Rechtsklicke auf /Volumes und wähle im Kontextmenü Folder Action Setup

– Mit 10.5 und früher: Öffne den Finder und wähle Gehe zu Ordner > /Volumes/

Öffne Folder Actions Setup (aus dem Dienstprogrammen)

Dragge das Ordnericon aus der Titelleiste des Finder Fensters auf das geöffnete Formular und klicke OK

4. Wähle im Dialogfenster das gespeicherte Script aus.

Teil 2: Das Script auf dem Datenträger

property display_notification : false
property backup_target : "Documents/Backups/" (* MUST be a folder location with trailing slash! Always relative to home folder *)
 
property rsync_params : "-aEz --delete-excluded"
(* END OF PREFERENCES *)
 
set WhereImRunningFrom to path to me
tell application "Finder"
 
(* NEVER run from the hard drive! comment: nice feature, thats why it stays!*)
set bootVolume to name of disk of home (* safety feature! *)
set NameOfDisk to name of disk of WhereImRunningFrom
if NameOfDisk is bootVolume then
beep
display alert "Should not run this script from the boot volume!"
return
end if
 
(* setup backup dir *)
set homeDir to path to home folder from user domain
set backup_folder to POSIX path of homeDir & backup_target
try
(* quick and dirty check to see if folder exists - must be a good way to do this in applescript? *)
do shell script "cd " & backup_folder
on error
try
do shell script "mkdir " & backup_folder
on error
display alert "There was an error creating the backup folder " & backup_folder
return
end try
end try
 
(* find source and target *)
set backupBase to NameOfDisk & "-Backup"
set targetDir to backup_folder & quoted form of backupBase
set sourceDir to quoted form of ("/Volumes/" & NameOfDisk & "/")
end tell
 
(* do the backup *)
 
set excluded to " --exclude='.Trash*' --exclude='.Spotlight*'  "
 
set theScript to "rsync " & rsync_params & excluded & sourceDir & " " & targetDir & "; touch " & targetDir
 
do shell script theScript
 
activate of me
beep
if display_notification then display alert NameOfDisk & " drive backed up"

1. Kopiere das Script in den Script Editor

2. Ändere die Konstante backup_targets, beachte dass das Script keine Adminrechte hat und deshalb nur in den Benutzerordner speichern kann!

3. Speichere das Script auf dem USB Stick als Application mit dem Namen rsync.app (oder dem Namen, der im anderen Script angegeben ist).

4. Teste ob es funktioniert! Beim erneuten Anschließen des USB Sticks sollte eine Warnung erscheinen, die fragt ob ein Backup erstellt werden soll.