Zawsze myślałem, że problemy dotyczące kodowania polskich znaków nie dotyczą użytkowników Windows. W końcu to taki spójny i jednolity system, posiadający nawet swój własny ’standard’ kodowania. Jakież było moje rozczarowanie, gdy prosty skrypt batchowy pozwalający na wczytanie skryptu SQL do bazy daanych zainstalowanej w MS SQL Server:

set OSQL="c:\Program Files\MS SQL Server\80\Tools\Binn\osql.exe"
%OSQL% -E -d moja_baza < skrypt.sql

…wczytał, i owszem, moje wypociny w SQL, ale… zupełnie zniekształcił polskie znaki. Dostałem w ich miejsce jakieś dziwaczne krzaki, przypominające czasy źle skonfigurowanych Linuksów ;)
Nie pomaga w tej sytuacji zmiana kodowania pliku wejściowego (skrypt.sql), ani cudaczne opcje, z którymi można uruchomić ‘osql’.
Okazuje się, że winą za ten stan rzeczy obarczać możemy… windowsowy wiersz poleceń. Otóż ‘cmd.exe’, w środowisku którego wykonywane są wszystkie skryptu batchowe w Windows, pracuje używając innego kodowania znaków niż reszta systemu. Dlaczego? Nie mam pojęcia, pewnie ze względu na kompatybilność z DOS’em.
Sposobem obejścia tego problemu jest rezygnacja z windowsowej możliwości przekierowania strumieni na wejścia/wyjścia programów (bo to właśnie tam powstaje nieszczęsna konwersja znaków do DOS’owych krzaków). Na szczęście znalazła się w opcjach ‘osql’ (czyli trochę jednak skłamałem pisząc kilka linijek wyżej, że ‘osql’ nie miał pomocnej w tej sytuacji opcji ;) ) możliwość wykonania polecenia z plikiem zadanym na wejściu.
Rozwiązaniem jest zapisanie skryptu w kodowaniu, którego używa MS SQL Server (u mnie UTF-8) i wykonanie poniższego poleconka (uprzednio oczywiście ustawiając zmienną OSQL):

%OSQL% -E -d moja_baza -i skrypt.sql

Od tej pory znaki ze skryptu wędrują nienaruszone prosto do mojej bazy :)

Wszyscy sympatycy np. Basha (i chyba nie tylko ci), którzy mieli kiedykolwiek do czynienia z windowsowym cmd.exe, zgodnie przyznają, że produkt z Redmond nie przyniósł rewolucji w dziedzinie obsługi wiersza poleceń. Mimo, że w windowsach linii NT sytuacja polepszyła się diametralnie, to możliwości skryptowo-konsolowe okien są wciąż, delikatnie mówiąc, marne i nawet nie umywają się do potęgi duetu Bash+Konsole.

Znalazłem jednak ostatnio kilka sposobów by sobie z tą sytuacją poradzić. Pierwszym z rozwiązań jest oczywiście CygWin, dzięki któremu można już cieszyć się dobrodziejstwami SH w windows. Teraz znalazłem też i sam konkretny emulator terminala - otwarty i dużo mniej toporny.
Z tymi narzędziami praca w tym, niezbyt lubianym przeze mnie, systemie staje się od razu mniej męcząca :)

Niejeden pewnie zna zalety mechanizmu DCOP. Jeszcze więcej osób używa go z pasją nawet o tym nie wiedząc. Dzięki niemu np. możliwa jest komunikacja wielu aplikacji KDE ze sobą, a także komunikacja użytkownika z aplikacjami (np. z poziomu skryptów). Mechanizm, dzięki temu, że jest dobrem ogólnym KDE, jest niesamowicie potężny. Zwłaszcza wsadowa komenda dcop.
W moim MetaMonitorze na przykład możesz ‘zdalnie’ uruchomić okno konfiguracyjne, pokazać komunikat, zamknąć go itd. Możesz wymusić sprawdzanie poczty w KMail jednym poleceniem (wpisanym np. do Crona), jeśli oczywiście chcesz, bo KMail ma własny mechanizm sprawdzania poczty co jakiś czas. ;) Możesz napisać skrypt, który wyświetla użytkownikowi pytanie o to czy np. chce przejść na stronę domową projektu, a gdy ten się zgodzi, wykonać:

dcop konqueror KonquerorIface createNewWindow http://moja.strona.net

Generalnie reklamować DCOP nie trzeba (może warto tylko dodać, że w KDE 4 będziemy mieli jeszcze lepiej za sprawą nowocześniejszego i jeszcze bardziej powszechnego D-Bus, który nie jest ograniczony tylko do KDE).

Było jednak coś, co nie pozwalało mi wykorzystywać dobrodziejstw polecenia dcop w pełni. O ile przekazywanie argumentów numerycznych było proste (wystarczy wpisać liczbę), argumentów tekstowych dość intuicyjne (stringi piszemy w apostrofach jeśli zawierają kilka słów, lub niekoniecznie z nimi, jeśli to tylko jedno słowo), o tyle przekazanie argumentu QStringList było dla mnie czarną magią.
Jak to się robi? Kombinowałem ze wszystkimi znanymi mi sposobami i nic…

Dopiero Michelle sprawiła, że zająłem się tym nieco konkretniej. Michelle używa Firefoksa, a - jak wszyscy wiemy - jego wbudowany czytnik kanałów RSS jest, delikatnie mówiąc, dość ubogi. Więc jak tylko zaraziłem Ją RSSoManią, natychmiast pożałowałem, bo przygniotła mnie sterta pytań ‘A jak ustawić, żeby…’ ;) Na pomoc przyszedł mi Akregator - niesamowity czytnik. Wygodny, konfigurowalny, szybki i… KDE’owy :) Pozostał tylko jeden problem. Jak przekazać Akregatorowi informację o URL kanału z poziomu Firefoksa? Na szczęście FF ma możliwość wykonania komendy z adresem kanału. No, ale tu właśnie pojawił się problem. Interfejs DCOP Akregatora pozwala wprawdzie na dodanie do niego kolejnego URL kanału RSS, jednak postać polecenia jest taka:

xis@hedera ~ $ dcop akregator AkregatorIface
QCStringList interfaces()
QCStringList functions()
void openStandardFeedList()
void fetchFeedUrl(QString)
void fetchAllFeeds()
void saveSettings()
void addFeedsToGroup(QStringList,QString)
void exportFile(KURL url)
void addFeed()

Łatwo się domyślić, że pierwszy parametr to lista URLi, a drugi to grupa, do jakiej mają być kanały dodane. I jak tę listę przekazać? Ano tak:

#!/bin/bash
dcop akregator AkregatorIface addFeedsToGroup [ $1 ] Michelle

Taki skrypcik zapisujemy pod postacią np. ‘addrss’, dajemy prawa wykonania, umieszczamy gdzieć na naszej $PATH i już możemy konfigurować Firefoksa wskazując mu komendę addrss do wykonania przy dodawaniu kanału informacyjnego.

Działa super :)

Dodam tylko, że aby przekazać w QStringList większą ilość stringów, wystarczy oddzielić je przecinkami.

KDE to naprawdę elastyczne i konfigurowalne środowisko. Wielu na nie narzeka, bo ‘ciężkie’, ‘wolne’, bo ‘przeciążone wodotryskami’, ale chyba każdy, kto go używał przyzna, że trudno o bardziej wygodne w kwestii dopasowania do potrzeb użytkownika środowisko graficzne.

Napisałem kiedyś skrypcik, w PHP, który generował dla mnie losowe obrazki na zawołanie. Pomysł nie mój, dość oklepany, ale wykonanie było moje. :) Używałem go do wszelkich avatarów, sygnaturek i wszystko byłoby pięknie, gdyby nie jego rozszerzenie - php.

Większość forów internetowych - ze względów bezpieczeństwa - nie zezwala na umieszczanie w avatarze, czy sygnaturce obrazka z rozszerzeniem ‘php’, i nic w tym dziwnego.
Ze względu na to, że serwer, na którym trzymam skrypt nie daje mi możliwości modyfikacji konfiguracji (nie mogę przekonfigurować apacza, by ‘interpretował’ np. pliki o rozszerzeniu ‘png’ jak skrypty php) nie mogę po prostu zmienić rozszerzenia pliku z kodem skryptu.
Pomocna okazała się technologia .htaccess. Jesli serwer wspiera ten mechanizm, wystarczy w katalogu, w którym znajduje się skrypt umieścić pliczek .htaccess, a w nim:

Options +FollowSymlinks
RewriteEngine on
RewriteRule ^ja.png$ ee.php [nc]

Od tej pory mogę wskazywać na mój skrypt adresem http://schowek.net/stuff/ja.png. Więcej o samym .htaccess tutaj i tutaj.