Mac i problemy z locale w terminalu – HOWTO

Jak pisałem, częściowo siedzę na macu. Zrozumiałem ludzi, którzy narzekali na obsługę systemu klawiaturą w macach. Wiele skomplikowanych combo na trzy palce. Ale to mogła by być kwestia przyzwyczajenia, zwłaszcza w trybie graficznym. Jeśli jednak ktoś korzysta głównie z terminala, to „fun” jest na zupełnie innym poziomie. Otóż funkcję klawisza Ctrl w macOS „normalnie” (czyli w GUI) spełnia lewy klawisz command, umieszczony tam, gdzie normalnie jest alt. Jeśli jednak przejdziemy do terminala, to w aplikacjach uruchomionych w konsoli żeby zrobić ctrl-c należy wcisnąć… control-c. Tak, jest też osobny klawisz control, którego należy używać w terminalu.

Jeśli jednak korzystamy z VirtualBox i uruchomimy tam Linuksa, to żeby utworzyć nową zakładkę w przeglądarce należy użyć… control-t. W GUI. W tej samej przeglądarce pod macOS używamy command-t. IMO totalna porażka UXowa i coś do czego nie sposób się przyzwyczaić, jeśli ktoś używa systemów na przemian. Można najwyżej nieustannie pamiętać, ale u mnie kończy się to masą missclicków. Zobaczę jeszcze co będzie po podłączeniu zewnętrznej, pecetowej klawiatury, choć to raczej z ciekawości – w końcu to nie stacjonarka. Ew. poszukam jakiegoś software’owego rozwiązania, choć staram się unikać przemapowywania klawiszy jak mogę – ciężko się później korzysta z instrukcji w necie.

Z pozytywów – doceniam działające kopiowanie i wklejanie w terminalu przy pomocy command-c i command-v. Pod Linuksem są na to osobne skróty, choć do tego akurat używałem myszy i zaznacz (i automatycznie skopiuj) i środkowego przycisku do wklejania. Domyślnie działa też – analogicznie jak pod Linuksem – wklejanie zaznaczonego w terminalu tekstu przy pomocy środkowego klawisza myszy. Niestety, jest ograniczone do konsoli, aby skopiować jakieś polecenie z przeglądarki trzeba już używać skrótów klawiszowych.

Wracając do tematu z topica. Po zmianie systemu na macOS i logowaniu przy pomocy ssh na serwery witał mnie komunikat w stylu:

-bash: warning: setlocale: LC_ALL: cannot change locale (pl_PL.UTF-8)
-bash: warning: setlocale: LC_ALL: cannot change locale (pl_PL.UTF-8)
-bash: warning: setlocale: LC_ALL: cannot change locale (pl_PL.UTF-8)

Sprawa jasna, problem ustawieniami locales, tyle, że nigdy mi się nie zdarzał, w systemie (macOS) niby są ustawione. Na chwilę odpuściłem temat, bo mało estetyczny komunikat przy logowaniu to nie dramat, ale szybko okazało się, że potrafi to wpływać – rzecz jasna ujemnie – na działanie poleceń i skryptów. Gdy tylko siadłem do szukania rozwiązania okazało się, że problem jest popularny, wręcz powszechny.

Pierwsze rozwiązanie, które znalazłem, wyglądało elegancko i nawet tłumaczyłoby, czemu nie działa skoro locales są ustawione. Niestety, po włączeniu i otwarciu nowych zakładek w terminalu, a nawet restarcie terminala okazało się, że… nie działa. Teraz widzę, że rozwiązanie jest stare, z 2012, wtedy mi umknęło.

Dopiero tu znalazłem faktyczne rozwiązanie problemu z locale w terminalu pod macOS. Jest proste i sprowadza się do dodania dwóch linii w pliku ~/.bash_profile:

export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8

Powinno działać także z wersją polską, ale nie testowałem – w moim przypadku powyższa wersja jest OK, przynajmniej po pobieżnym sprawdzeniu nie zauważyłem problemów. Ustawienie z pierwszego rozwiązania również zostawiłem.

Pierwszy mac

Drugi raz wpis o podobnym tytule. Poprzedni był primaaprilisowym żartem, ten jest jak najbardziej na serio. Przesiadka z Linuksa nie do końca z własnej woli – ot, korporacyjne standardy, czyli jedzie walec i równa, ale mniejsza o powody. Ludzie z Linuksami na pokładzie otrzymali propozycję nie do odrzucenia zmiany systemu i/lub sprzętu na coś należycie korporacyjnego. Znaczy Windows lub macOS, co kto lubi. Oddając sprawiedliwość – firma poszła na rękę i zapewniła okres przejściowy i możliwość szybkiego pomacania nowego sprzętu. Przynajmniej w teorii, bo to grubsza zmiana, dostosowanie komputera trochę trwa, a na nadmiar czasu nikt nie narzeka.

Tak czy inaczej – stało się. Wybrałem macOS na laptopie 13″ (co to dokładnie – uzupełnię wkrótce, nie mam go chwilowo pod ręką) z amerykańską klawiaturą (szeroki Enter). Powodów kilka – większość ludzi z którymi mam styczność w firmie korzysta, od Linuksa do Uniksa niby niedaleko (choć już wcześniej wiedziałem, że niektóre specyficzne dla macOS problemy są z commandline’owymi narzędziami są bohatersko rozwiązywane), no i last but not least będzie okazja poznać coś nowego. Wcześniej upewniłem się tylko, że ludzie, którzy się przesiadają jakoś żyją (mapowanie klawiszy, konfiguracja przewijania, soft) i że mysz (zwykły bezprzewodowy Logitech) działa normalnie, bo fanem gładzików nie jestem, delikatnie rzecz ujmując, a brak przycisków myszy zwyczajnie mnie drażni. Tak, wiem, gładzik w macach jest lepszy. Przelotnie korzystałem i nadal nie jestem fanem, lubię pewność sterowania i kliknięć, jaką daje mysz.

Wybrałem słabszą wersję 13″ – niestety 15″, choć ma mocniejsze komponenty, jest dla mnie odrobinę za duży. Już jakiś czas temu stwierdziłem, że optymalny dla mnie rozmiar ekranu w lapku to 14″, jeśli mam korzystać mobilnie. Nie do końca rozumiem, czemu robią właśnie 13″ – porównywałem z Dellem 14″ i mac jest jedynie minimalnie mniejszy.

Trochę żałowałem wyboru jeszcze nim odebrałem sprzęt, bo wkrótce po nim okazało się, że Windows jeszcze mocniej integruje się z Linuksem (WSL2), ale nie chciałem ryzykować WSL, z którego wcześniej nie korzystałem, tym bardziej, że znajomi generalnie są z maców zadowoleni. Znaczy z macOS, bo na wbudowane klawiatury klną wszyscy, posiłkując się dołączanymi bezprzewodowymi.

Na wstępie dostałem… przejściówkę z USB-C na USB-A, żebym mógł podłączyć czy to dysk, czy pendrive czy – w moim przypadku – mysz. Pierwsze wrażenie – mieszane. Sprzęt wygląda na bardzo delikatny, ale w dotyku jest solidny i… zaskakująco ciężki. Zdjęć z unboxingu nie mam, zresztą chyba nie podszedłem do niego z należytym szacunkiem. W stosunku do Della, którego miałem wcześniej – po obrysie jak pisałem podobny, różnicę widać gdy się je położy obok siebie, zamknie i spojrzy od frontu. Mac jest znacznie cieńszy, niemal o połowę, choć Dell również z tych cieńszych, z ruchomym elementem dla gniazda ethernet. Trochę sztuka dla sztuki jak dla mnie – pewnie utrudnia to upchanie gratów w środku, chłodzenie, odbija się na solidności itp., a korzyść dla mnie żadna.

Jak widać założyłem kategorię, więc planuję trochę wpisów w temacie, pewnie z czasem pojawi się trochę howto dla przesiadających się. Są pierwsze pozytywy z godzinnego obcowania i podstawowej konfiguracji – o dziwo mimo braku przemapowania klawiszy nie zauważyłem trudności z klawiaturą. Poza brakiem klawiszy funkcyjnych, PgUp/PgDn, backspace i fizycznego Esc, oczywiście. I dopóki nie zacząłem próbować pisać z pl-znakami. Aplikacje umiem instalować, choć o instalacji będzie następnym razem.

Taki nieco zaległy wpis, w zasadzie powinienem już pisać o instalacji…

Banana Pi i ekran LCD podłączony po i2c

Dawno temu NAS został wyłączony, ale zmierzam do jego reaktywacji. Po głowie chodziło mi zamknięcie wszystkiego (zasilacz, dysk, Banana Pi) w zgrabnej, tym razem dedykowanej do elektroniki, obudowie.

Trochę z myślą o programie do przełączania łącza internetowego, a trochę o pomiarze temperatury przy pomocy komputera, przyszedł mi pomysł, by sygnalizować stan różnych rzeczy w sposób nie wymagający łączności sieciowej, czyli najdoskonalszy, analogowy: migając diodą. Oczywiście szybko doszedłem do wniosku, że jedna dioda nie wystarczy, wbudowane diody to trochę mało, ale przecież w Raspbery Pi i analogach mamy GPIO, możemy tych LEDów podłączyć kilka…

Nie wiem jak dokładnie doszło do tego, ale podczas poszukiwań szybko wpadłem na ekrany LCD z serii 1602, które również można podłączyć przez GPIO. Skoro tak, to pomyślałem, że nie ma się co ograniczać. Zamiast prostej sygnalizacji stanu i konieczności pamiętania która kombinacja co oznacza można po prostu wyświetlać dowolny tekst. Niezbyt długi, ale nadal jest to znacznie większa ilość informacji, niż z kilku czy nawet kilkunastu LEDów. W dodatku cena takiego jest bardzo przystępna, czego o różnych ekranach dotykowych czy e-ink powiedzieć nie można.

Pierwotnie chciałem podłączyć LCD do Orange Pi zero, ale niestety, nie ma on pinów GPIO – są wyprowadzenia, ale trzeba by lutować, co pewnie docelowo zrobię, ale bardziej chodziło mi o sprawdzenie sterowania, a mam pod ręką Banana Pi. Gdy szukałem schematu jak podłączyć ekran do Banana Pi, natknąłem się na coś znacznie ciekawszego – wersję ekranu LCD ze sterownikiem podłączanym przez interfejs i2c. Dzięki podłączenie temu jest bardzo proste – raptem cztery przewody, nawet nie trzeba lutować, o ile używa się gotowych przewodów z końcówkami. Dodatkowo – i to najlepsza część –  całością daje się w elegancki sposób sterować za pomocą Pythona.

Efekt końcowy wygląda tak:

LCD 1602
LCD 1602 Źródło: fot. własna

Zdjęcie zrobione telefonem, po ciemku. Z tyłu płytki jest potencjometr pozwalający na regulację kontrastu. Poziom podświetlenia jest stały, można tylko włączyć i wyłączyć LED, zarówno hardware’owo (zworka), jak i programowo. Ekran LCD bierze bardzo mało prądu – przy pomocy watomierza nie udało mi się zarejestrować różnicy, czyli całość zużywa poniżej 0,1 W.

Jak to zrobić? Powtórzę instrukcje, z których korzystałem. Instalujemy dodatkowe pakiety:

apt-get install i2c-tool python-smbus

Następnie podłączamy ekran i sprawdzamy adres przy pomocy polecenia:

i2cdetect -y 1

Otrzymaną wartość należy wpisać w skrypcie (stała ADDRESS, linia 29 w przytoczonym przykładzie).

Następnie możemy sterować ekranem z poziomu języka Python. Na przykład wywołanie efektu widocznego na ekranie można zrobić przy pomocy polecenia:

python test_lcd.py "Pomiedzy bitami" "https://zakr.es/"

Gdzie test_lcd.py ma zawartość:

import sys

from i2c_lcd import *

display = lcd()
display.lcd_display_string(sys.argv[1], 1)
display.lcd_display_string(sys.argv[2], 2)

Biblioteka pozwala na dużo więcej, między innymi na własne znaki, ale tym się póki co nie bawiłem. Wyświetlony tekst pozostaje na ekranie po zakończeniu programu do momentu wpisania nowego lub skasowania poprzedniego. Jeśli do ekranu będzie dostarczone napięcie, to wyłączenie Banana Pi nie wpływa na wyświetlany tekst. Dlatego jeśli chcemy monitorować, czy nasz komputer się nie zawiesił, musimy zmieniać okresowo tekst – w innym wypadku zawartość LCD nie świadczy o niezawieszeniu się komputera.

Sterowanie włączaniem i wyłączaniem podświetlania to:

display.backlight_on(False)
display.backlight_on(True)

Wyświetlać można cokolwiek – temperaturę, zajętość dysku, opóźnienia/straty na sieci, kurs BTC (pozdro dla L.!), adres IP (po starcie!), informacje o nowych mailach…

Pozostało mi wymyślenie, w jaki sposób zrobić sensowne sterowanie. Po głowie chodzi mi demon, który będzie pobierał informacje do wyświetlenia z jakiejś kolejki, w zależności od ich priorytetu, czasu ostatniego wyświetlenia i pory dnia sterował oświetleniem i wyświetlał informacje. A może już jest coś takiego?

I garść linków pomocnych przy tworzeniu ww. rozwiązania AKA źródła:

  1. pinout Banana Pi
  2. LCD i2c dla Raspberry Pi
  3. Banana Pi i urządzenia i2c
  4. Skrypt w Pythonie
  5. Biblioteka Python do obsługi ekranów LCD po i2c

UPDATE Dla zainteresowanych kupnem – ekran z modułem do komunikacji i2c kosztuje ok. 12 zł na Allegro. Na zdjęciu jest wersja zielona, ale istnieją też wersje niebieskie, gdzie tło jest ciemne, a napisy jasne.

Solaar – parowanie urządzeń bezprzewodowych Logitech

Urządzenie bezprzewodowe podłączane do komputera składa się z właściwego urządzenia, oraz odbiornika, podłączanego do komputera. Ten ostatni jest niewielki, przez co łatwo go zgubić. Bywa też, że w środowisku, gdzie podobnych urządzeń jest wiele, urządzenia zostaną zamienione. Z racji częstego przenoszenia, niewielkich rozmiarów urządzeń i braku elementów charakterystycznych, opisywany problem dotyczy raczej myszy bezprzewodowych.

Mysz bezprzewodowa Logitech

Źródło: https://www.mwave.com.au/

Zatem tam, gdzie jest sporo bezprzewodowych urządzeń podobnego typu, na przykład w biurach, często zdarza się, że stopniowo pojawiają się zdekompletowane lub przemieszane zestawy bezprzewodowe. Teoretycznie niesprawne, ponieważ szybki test polegający na włożeniu nowej baterii i podłączeniu urządzenia nie da żadnych efektów – urządzenie nie zadziała ze względu na nieprawidłowe parowanie urządzenia z odbiornikiem.

Jak dowiedziałem się niedawno podczas rozmowy o przydasiach, użytkownicy systemu Linux mają rozwiązanie na tego typu problemy, przynajmniej dla wielu urządzeń firmy Logitech. Istnieje bowiem program Solaar, czyli narzędzie pozwalające na zarządzanie parowaniem urządzeń bezprzewodowych tej firmy.

W przypadku Ubuntu i Debiana wystarczy zainstalować pakiet solaar, a następnie uruchomić program. Użycie jest bardzo proste, wystarczy włączyć urządzenie, które ma być sparowane.

Poza umożliwieniem parowania z dowolnym odbiornikiem tego samego typu, daje ono – na niektórych urządzeniach – dostęp funkcji, do których standardowo nie ma dostępu. Praktycznie dla wszystkich urządzeń pozwala na odczyt stanu baterii (akumulatora!), dzięki czemu można zawczasu przygotować się do wymiany i uniknąć przykrej niespodzianki w postaci niespodziewanego rozładowania.

Dodatkowo program można teoretycznie wykorzystać do zmniejszenia ilości podłączonych urządzeń USB – do jednego odbiornika można przypisać kilka urządzeń, np. mysz i klawiaturę, o ile korzystają z odbiornika tego samego typu. Nie testowałem jednak konfiguracji z podłączonymi jednocześnie kilkoma urządzeniami.

Tak czy inaczej, posiadając „niesprawne” lub zdekompletowane urządzenie firmy Logitech, niekoniecznie warto je od razu wyrzucać, może się ono jeszcze komuś przydać. Jeśli istnieją podobne rozwiązania dla innych systemów, dajcie znać w komentarzach.

Debian SID jest czasem zepsuty

Niezbyt krótki wpis o urokach Linuksa na desktopie, o tym, że człowiek uczy się całe życie i o tym, czemu warto jednak korzystać z Debiana w wersji unstable AKA SID.

I przekornie zacznę od końca. Dawno temu przeczytałem świetny wpis o tym, dlaczego Debian unstable nie zasługuje na tę nazwę. Jak lubię Debiana i od dawna jest to mój podstawowy system na desktop, jeśli tylko mogę go używać (z polityką firmy się nie dyskutuje; nie każdy soft działa na Linuksie), tak używanie wersji stabilnej było nieco męczące, choćby ze względu na nieco stary soft. Przypominam, że było to w czasach, gdy backports nie były oficjalną częścią dystrybucji.

Radziłem sobie na różne sposoby – a to używając pakietów z wersji testing lub unstable, a to robiąc backporty. Jakoś to działało, ale wpis mi się spodobał i stwierdziłem, że dam szansę wersji unstable. Ku mojemu zaskoczeniu, zrobiło się dużo prościej i wcale nie mniej stabilnie. Rzekłbym nawet, że problemów z aktualizacją pakietów jest znacznie mniej, niż przy mieszaniu wersji. Nie to, że zawsze wszystko działa, ale konieczność downgrade pakietu, bo jakaś kluczowa funkcjonalność nie działa, zdarzyła mi się małe parę razy. W ciągu kilku lat.

No i właśnie, wróciłem z konfy, odpalam rano do kawy komputer, by sprawdzić pocztę i… nie wstał. Czarny ekran z kursorem, nawet nie migającym. Przejście do trybu tekstowego nie działa. I ciężko stwierdzić, która aktualizacja namieszała, bo zwykle usypiam laptopa, zamiast wyłączać. Smuteczek i zły moment.

W jakieś pół godziny nie udało mi się do niczego sensownego dojść, poszedłem do pracy. Po powrocie nie było wiele lepiej. Uruchomienie w single mode i aktualizacja pakietów nie pomogła, choć bardzo liczyłem na to.

Po krótkiej walce udało mi się za to ustalić, że wina leży w okolicy xorg. Tu słowo wyjaśnienia i ważna uwaga. Laptop to Dell Vostro 1440 i ma dwie karty graficzne. I zawsze były z nimi przygody, głównie za sprawą niedziałającego przełączania między nimi. Nie żeby mi jakoś specjalnie zależało na konkretnej – jak były działające sterowniki, to korzystałem z ATI, jeśli nie – z Intela, a przełączałem je przy pomocy zmiany konfiguracji w xorg.conf, dlatego w ogóle ten plik posiadam. Pamiętam, że kiedyś przestała działać mysz i klawiatura i musiałem dopisać stosowne sekcje w xorg.conf. I w ogóle przez lata zebrało się kilka wersji tych konfiguracji, chociaż gdzieś tak od dwóch korzytałem z tej samej.

W każdym razie, po nieco dłuższej walce z downgrade podejrzanych pakietów i zasięgnięciu języka na IRCu udało mi się uruchomić Xy, ale… znowu bez klawiatury i myszy. Dopisywanie stosownych sekcji w xorg.conf powodowało albo powrót do niedziałania grafiki, albo nie przynosiło efektów. Stwierdziłem, że pomysły mi się skończyły i pora na bardziej radykalne rozwiąznia, czyli sprawdzenie, jak też wygląda konfiguracja Xów i działanie pod Debianem live. I o dziwo nie miał najmniejszych problemów, mimo braku xorg.conf. Jednak Debian live jest oparty o wersję stabilną, nie unstable.

Wygenerowałem xorg.conf na live, potem jeszcze trochę poszukałem i znalazłem rozwiązanie. Okazało się, że wszystkie pakiety były w porządku, za to brakowało mi w systemie pakietu xserver-xorg-input-evdev – pewnie został usunięty przy ostatniej aktualizacji, a ja tego nie zauważyłem. Po jego doinstalowaniu zarówno klawiatura jak i mysz działają.

Pochwaliłem się na IRC (kanał debian-next na OFTC) i wywołałem spore zdziwienie. Po pierwsze, wszystko powinno działać bez xorg.conf. Za to warto mieć zainstalowane xserver-xorg-input-libinput oraz xserver-xorg-input-all, które to pakiety instalują się domyśnie przy instalacji xserver-xorg. Zapewne kiedyś były zainstalowane lecz usunąłem je przy jakichś problemach z aktualizacją pakietów – uroki SIDa. I stąd całe zamieszanie.

Piszę o tym, bo mimo wszystko polecam Debiana unstable na dekstop, a tego typu problemy to wyjątek. Nie zmienia faktu, że łącznie zeszły mi ze trzy godziny na przywrócenie pełnej funkcjonalności systemu. Pozostało mi doinstalowanie brakujących pakietów i wypróbowanie działania bez xorg.conf, ale chwilowo nie mam weny. Pewnie wkrótce zaktualizuję wpis.

UPDATE: Po doinstalowaniu obu brakujących pakietów i skasowaniu xorg.conf wszystko działa. Czyli całe zamieszanie z powodu przekombinowania było.