Sonoma

O ile poprzednia aktualizacja była nudna, to ta zdecydowanie nudna nie jest. Niestety. Parę dni temu zaktualizowałem macOS do najnowszej wersji Sonoma i… jest wesoło. Przede wszystkim mamy nową tapetę czy też wygaszacz ekranu. Animowany. Zapytał, czy przełączyć przy instalacji, a ja się nieopatrznie zgodziłem. Niestety bardzo widoczny staje się wtedy notch. Zdecydowanie lepiej sprawdza się – przynajmniej u mnie – tapeta z ciemnym tłem u góry.

Na to, że nie działa hidutil byłem przygotowany. Szczęśliwie okazało się, że teraz prawe option i cmd pozwalają wpisywać pl-znaki. Czyli albo coś tam jednak działa, albo inne ustawienie wzięło górę. W każdym razie da się żyć. Mapowania tyldy i tak nie używałem. Braku normalnego wprowadzania pl-znaków bym nie zniósł.

Znajomi pytają, czy po upgrade do Sonomy miga mi ekran. Tak, ale naprawdę rzadko i minimalnie. Nie wiem czy bym zauważył, gdyby nie zapytali. Chyba podrzucę im poradę z usuwaniem profili kolorów.

W każdym razie macOS Sonoma to bardzo słaba, problematyczna wersja. Chyba najsłabsza aktualizacja w historii, choć mnie szczęśliwie problemy dotykają jedynie minimalnie.

MacOS 14.2 – nie działa hidutil

Ja jeszcze nie zaktualizowałem MacOS do wersji Sonoma, ale znajomi zdążyli to zrobić i narzekają, że polecenie hidutil przestało działać. Nie zwraca błędu, ale nie mapuje klawiszy. W związku z tym polecane kiedyś przeze mnie mapowanie klawiszy bez użycia Karabiner Elements również nie będzie działać.

Sprawdzonego rozwiązania w tej chwili nie podam, zamiast tego odsyłam do wątku na forum Apple oraz wątku na Reddicie. Jest tam wiele pomysłów na rozwiązanie, można przymierzyć – może ktoś znajdzie satysfakcjonujące dla siebie.

Ludzie zgłaszają błąd do Apple, więc liczę, że błąd zostanie poprawiony w kolejnej aktualizacji. Mapowanie bez dodatkowych programów było eleganckie.

MacOS, iTerm i problemy z pl-znakami

Niezbyt często używam pl-znaków w konsoli łącząc się po SSH, ale jest parę miejsc, gdzie ich potrzebuję. Po dłuższym czasie zauważyłem, że na nowym komputerze mam problem z pl-znakami. Występował tylko przy połączeniu się z tego macOS przy pomocy SSH do Linuksa. Nic krytycznego, bo w zasadzie nie potrzebuję się tam łączyć z macOS, z innych Linuksów działało, ale byłoby miło, gdyby działało wszędzie. W końcu znalazłem chwilę i postanowiłem się zająć sprawą.

Krótko o środowisku: na workstacji macOS Ventura 13.4 z zsh 5.9 oraz iTerm2 3.4.19. Dla pamięci opis sprawdzania ustawień krok po kroku.

ustawienia iTerm

Upewniamy się, że iTerm korzysta z kodowania UTF-8. W tym celu należy wybrać
settings -> profiles -> terminal
Upewniamy się, że character encoding jest ustawione na UTF-8.

zmienne środowiskowe

Sprawdzamy ustawienia zmiennych środowiskowych na macOS. W tym celu należy wpisać
echo $LANG
i sprawdzić wartość zmiennej LANG. Powinna być jakaś z UTF-8, na przykład pl_PL.UTF-8.

Jeśli jest inaczej, można dopisać odpowiednią wartość w pliku .zshrc[1]
export LANG=pl_PL.UTF-8

Jeśli wykonujemy zmianę, należy uruchomić nowy terminal, aby została zastosowana.

kodowanie w powłoce

Sprawdzamy na macOS, jakie kodowanie mamy ustawione w terminalu. Wpisujemy locale i weryfikujemy zawartość zmiennych LC_CTYPE oraz LANG. Powinny zawierać kodowanie UTF-8. Jeśli tak nie jest, można ustawić odpowiednie zmienne w sposób opisany w poprzedniem akapicie.

ustawienia systemu zdalnego

Należy sprawdzić, czy na serwerze zdalnym locale ustawione są na wersję z UTF-8. W tym celu wpisujemy locale. Jeśli tak nie jest, to w Debianie i Ubuntu polecenie dpkg-reconfigure locales umożliwi zarówno wygenerowanie odpowiednich locali, jak i ustawienie domyślnych.

Przy powyższych ustawieniach pl-znaki powinny wyświetlać się poprawnie.

Dla zupełnej transparentności: tym razem nie ma odnośników do stron, których używałem przy rozwiązywaniu problemu. Posiłkowałem się bowiem chatGPT z niewyszukanym promptem macos problem utf-8 iterm how to solve. Całkiem sprawnie sobie poradził.

[1] Jeżeli z jakiegoś powodu korzytamy z bash, nie zsh, to właściwym plikiem będzie .bash_profile