Permalink

OpenTerm · Open Source Terminal für das iPhone und iPad

Falls bei jemandem schon mal der Wunsch nach einer nativen Kommandozeile in iOS aufgekommen ist, sollte der Blick in Richtung OpenTerm gehen.

Derzeit werden knapp 50 Terminalkommandos unterstützt, die über eine Tastaturerweiterung jederzeit (scrollbar) zum Schnellzugriff eingeblendet werden.

Datei 06.02.18, 10 07 17_1300px

Da die App darüber hinaus sandboxed ist, können selbst Leute die nicht so erfahren im Umgang mit dem Terminal sind, relativ sicher erste Schritte wagen und nicht wirklich etwas kaputt machen.

Gerade im Zusammenspiel mit Apples Dateien-App (Strichwort: Splitscreen) und dem iCloud Drive ergeben sich hier einige interessante Möglichkeiten.

Der Quellcode von OpenTerm ist bei GitHub zu finden. Die App selbst wird über den iOS App Store verteilt und setzt ein iPhone oder iPad mit iOS 11 oder neuer voraus.

OpenTerm
OpenTerm
Entwickler: Silver Fox
Preis: Kostenlos
Permalink

On the macOS Version

In many administration scripts, you need to check the version of macOS, to make sure you don’t try to access features that are not present on other versions.

The first part of the version number (“major” version) is always 10 (so far). The second part (“minor” version) denotes the version of macOS (11: El Capitan, 12: Sierra, 13: High Sierra, etc.) and the third (“patch” or update version) the update number. (Useful list of macOS versions and names on Wikipedia.)

Aside from the numerical version number or product version, macOS also has a build number, which follows a different schema. The first part is a number which matches the “Darwin version” of macOS. Mac OS X 10.0 had a Darwin version of 4 and that number has increased with every version of Mac OS X. Currently, macOS High Sierra 10.13 has a Darwin version of 17. Then follows a single capital letter, with A being the first release of a version (i.e the 10.x.0 version), B is the first patch update (10.x.1) and so on.).

Wissenswert 🙂

Permalink

macOS Tipp: Zugriffsrechte des Papierkorbs reparieren

Es soll ja vorkommen, dass man sich durch verschiedene Testszenarien seinen Papierkorb zerschießt bzw. sich das eigentliche Verzeichnis des Papierkorbs in eine Datei ohne Zugriffsrechte verwandelt. Das hat zur Folge, dass Daten, die eigentlich in den Papierkorb gelegt werden sollen, sofort gelöscht werden.

So geschehen kürzlich bei Alexander, der durch einen Clean Install von macOS High Sierra, einem Bug in Hazel, der mittlerweile behoben ist, und einigen weiteren Begleitumständen vor genau diesem Problem stand.

Bildschirmfoto 2017-11-21 um 11.02.29-minishadow

Um jetzt nicht erneut einen Clean Install von macOS anzuschubsen, genügen im Prinzip zwei kleine Terminalkommandos, die das Problem lösen.

rm ~/.Trash
mkdir -m 700 ~/.Trash

(danke Alex, via)

Permalink

iTerm 2 · DNS Lookup Issue

Als großer Fan von iTerm 2 bin ich gestern Abend etwas zusammengezuckt.

Über Twitter bin ich mehr oder weniger zufällig über einen Bug gestolpert, der seit Version 3.0.0 besteht und der es ziemlich in sich hat:

Bildschirmfoto 2017-09-20 um 15.07.00-minishadow_1300px

Kurzgesagt kann es mit den Standardeinstellungen von iTerm 2 per DNS Request passieren, dass persönliche Daten (inkl. Passwörter) im Klartext über den DNS-Server des ISP versendet werden. Ein mehr als übles Sicherheitsrisiko, das in den Einstellungen von iTerm 2 behoben werden kann:

iTerm 2 Einstellungen > Advanced > Perform DNS lookups to check if URLs are valid? > NO

Dazu muss der Haken bei folgender Option entfernt werden:

iTerm 2 Einstellungen > Pointer > CMD-Click Opens Filename/URL (Semantic History)

Bildschirmfoto 2017-09-20 um 15.07.25-minishadow_1300px

Mittlerweile haben die Entwickler von iTerm 2 aber auch reagiert und mit Version 3.1.1 eine gefixte Version zum Download bereitgestellt, die die Standardeinstellungen berichtigt.

Daher: Unbedingt das Update einspielen!!!

-> https://www.iterm2.com

iTerm2 added a feature in version 3.0.0 which would perform DNS requests on the text under the cursor to get a hint whether it was a clickable URL. This was a bad idea because DNS requests are not privacy-preserving. The feature has been disabled by default in 3.1.1 in commit e4eb1063529deb575b75b396138d41554428d522.

I don’t have an excuse: I just didn’t give this issue enough thought. I apologize for the oversight and promise to be more careful in the future. Your privacy will always be my highest priority.

Bildschirmfoto 2017-09-20 um 15.09.45-minishadow_1300px

Permalink

macOS Tipp: PATH Variable anzeigen und ändern

Gerade als Entwickler kann es vorkommen, dass man die $PATH Variable, eine Umgebungsvariable des Betriebssystems, die einen oder mehrere Pfade zu bestimmten Programmen oder Daten enthält, anpassen muss.

Um die aktuell gesetzten Werte dieser Variable auszulesen, genügt einer der beiden folgenden Terminalkommandos:

echo $PATH

printf "%s\n" $PATH

Bildschirmfoto 2017-08-29 um 09.23.57-minishadow_1300px

Im Ergebnis werden, durch Doppelpunkt getrennt, die gesetzten Pfade angezeigt:

/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/MacGPG2/bin

Doch wie passt man diese Variable nun an? Hier gibt es verschiedene Möglichkeiten:

Variante 1

Die erste Variante besteht im Editieren der zur eingesetzten Shell passenden Konfigurationsdatei. Das hat den Vorteil, dass dieses Vorgehen nutzerbasiert und somit individuell ist. Da ich beim Editor auf Vim setze, kann das beispielsweise wie folgt aussehen:

vim ~/.bash_profile
vim ~/.profile
vim ~/.bashrc
vim ~/.zshrc

Anschließend kann man in der Konfigurationsdatei über das export Kommando die PATH Variable erweitern (abspeichern nicht vergessen):

export PATH=$PATH:/new/dir/location1

Um die Änderungen direkt nutzen zu können, muss das Terminal neu gestartet oder eine der beiden folgenden Terminalkommandos ausgeführt werden:

source ~/.zshrc
. ~/.zshrc

Abschließend überprüft man über eines der ganz am Anfang des Artikels erwähnten Kommandos, ob die PATH Variable auch tatsächlich geändert wurde.

Bildschirmfoto 2017-08-29 um 09.11.55-minishadow_1300px

Variante 2 (Admin-Rechte erforderlich)

In dieser Variante, in der Änderungen der PATH Variable für alle Nutzer gelten, sind die Pfade in einzelnen Dateien gruppiert. Dazu werden bzw. sind bereits Dateien mit den gewollten Pfadangaben im Verzeichnis /etc/paths.d angelegt. Um sich die existierenden Einträge anzusehen, benötigt man wieder ein Terminalkommando:

ls -l /etc/paths.d

Über das anschließende cat Kommando kann man sich den Inhalt der bereits existierenden Dateien ansehen:

cat /etc/paths.d/MacGPG2

Bildschirmfoto 2017-08-28 um 16.40.14-minishadow_1300px

Um jetzt die PATH Variable zu erweitern, muss man in /etc/paths.d eine neue Datei anlegen und diese mit dem gewünschten Pfad befüllen. Dafür benötigt ein Terminalkommando, für das man allerdings Admin-Rechte benötigt:

sudo -s 'echo "/new/dir/location1" > /etc/paths.d/location1'

Um die Veränderungen zu übernehmen, muss man das Terminal neu starten und man sollte, wie in Variante 1, überprüfen, ob die Veränderungen tatsächlich übernommen wurden.

Variante 3 (Admin-Rechte erforderlich)

Bei dieser letzten Variante handelt es sich um eine Abwandlung der Variante 2.

Anstatt einzelne Dateien anzulegen bzw. zu editieren, knöpft man sich die zentrale Datei /etc/paths vor und kann dort zeilenweise (untereinander) Pfade ändern, löschen oder hinzufügen:

sudo vim /etc/paths

Bildschirmfoto 2017-08-29 um 10.46.47-minishadow_1300px

Zur Info:
/etc ist ein symbolischer Link zum Verzeichnis /private/etc

Da beide den identischen Inhalt haben, können die Änderungen von Variante 2 und 3 auch in /private/etc erfolgen.

Bildschirmfoto 2017-08-29 um 10.59.01-minishadow_1300px

Permalink

macOS Tipp: 32-Bit Apps identifizieren

Was nächsten Monat mit iOS 11 für iPhone, iPad und iPod touch Realität wird, kommt spätestens in zwei Jahren auch auf den Mac zu: das Ende der 32-Bit Apps.

Wie Apple auf der diesjährigen Platforms State of the Union Keynote der WWDC verkündete, wird macOS 10.13 High Sierra das letzte Desktop-Betriebssystem sein, das 32-Bit Apps ohne Murren akzeptiert.

snipaste20170817_114103_1300px

Mit macOS 10.14 Mount Whitney wird es die von iOS 10 bekannten Warnungen geben; mit macOS 10.15 Riesenmammutbaum, das vermutlich Ende 2019 erscheinen wird, ist das Sterben der 32-Bit Apps besiegelt.

Wer jetzt schon mal neugierig ist, kann sich seine aktuell installierten 32-Bit Apps mit einem simplen Terminalbefehl in eine Textdatei (die dann auf dem Schreibtisch liegt) herausschreiben lassen.

system_profiler SPApplicationsDataType | grep -B 6 -A 2 "(Intel): No" > ~/Desktop/non64bit.txt

Ich war wirklich überrascht, welche Apps (inkl. Apples eigener Apps) bei mir betroffen sind. Wobei Apple in der gleichen Keynote auch ankündigte, dass bis spätestens Juni 2018 zumindest alle Apps im Mac App Store der 64-Bit Architektur entsprechen müssen.

Bildschirmfoto 2017-08-17 um 09.15.17_1300px

(via)