Te złe Linuksy to straszne systemy. Ciągle trzeba siedzieć w czarnych okienkach i wpisywać komendy, które tenże system dopiero potrafi zrozumieć. Na nic klikanie. Co innego Windows.

W Windowsie nie trzeba tego robić, wszystko da się wyklikać. Tyle, że klikanie does not scale, choćby w przypadkach, gdy część powtarzalnych rzeczy można (i trzeba!) zautomatyzować.

Wtedy przysłowiowy Kowalski sięga po cmd.exe. I jak szybko po niego sięga, tak prędko go wyłącza i szuka w Internecie czegoś klikalnego (jednak).

Dlaczego tak się dzieje? Bo cmd.exe nie zmieniło się od czasów command.com, czyli dalej mamy toporny interfejs użytkownika, który znamy z czasów DOSa. Brak podpowiadania, bark permanentnej historii poleceń (lub jej marny substytut pod F3 lub strzałką w górę), oraz operacji wspomagających wyszukiwanie, dopełnień czy podobnych wodotrysków znanych ze współczesnych powłok typu bash, zsh czy też bajecznie wypasiony fish, czyli powłoki, które funkcjonalnością miażdżą windowsowy interpreter w przedbiegach.

Dobrze, ale nie kopmy leżącego, wszakże jest jeszcze cygwin, który dostarcza wszelakich linuksowych interpreterów.. Jednakże szkoda, że taki bash uruchomiony w cmd.exe wcale nie zamienia środowiska w jakim został uruchomiony na lepsze, bo okienko cmd.exe to najgorsza rzecz, jaka może spotkać użytkownika windows. Jest powolne i absolutnie nieskalowalne. Ze stałą wielkością bufora, stałą szerokością, paskudnym domyślnym fontem -- wszystko w imię tzw. kompatybilności wstecznej. Cóż więc zrobić ma ów Kowalski, bądź (co gorsza) użytkownik systemu, gdzie takowych ograniczeń nie ma? Wyborów jest kilka, każdy z nich ma jednak wady i zalety.

Czyli, dla usystematyzowania. W windowsowym interpreterze poleceń udało się zepsuć dwie rzeczy na raz:

• interpreter (mamy przedpotopowy interfejs użytkownika rodem z MS-DOS)
• interfejs graficzny, (czyli to czym jest Xterm dla systemów Uniksowych - graficznym środowiskiem, który emuluje znakowy terminal), który utknął gdzieś na początku Windows 95 - toporny, powolny, niewygodny, bez możliwości łatwej zmiany rozmiaru.

Cygwin

Obecnie Cygwin dostarczany jest z mintty (wcześniej używał rzeczonego interfejsu w cmd.exe), dzięki czemu wreszcie da się zmaksymalizować okno pseudoterminala na cały ekran bez uciekania się w jakieś sztuczki z ustawianiem na sztywno ilości kolumn w ustawieniach okna cmd. Jest to moim zdaniem spora zaleta.

Wady. Niestety Cygwin jest środowiskiem na tyle obcym w stosunku do Windowsa, że wymaga od użytkownika sporej ilości samozaparcia i włożenia wysiłku w konfigurację, żeby zmusić do symbiozy oba środowiska - np. uruchamianie programów kosnolowych (dir, copy, move, findstr itp) nie radzi sobie ze ścieżkami typowymi dla cygwina (np. /cygdrive/c/Program\ Files/).

Z kolei tzw. power userzy nie dostrzegą niczego zadziwiająco świetnego w mintty który powstał około 2008 roku, czyli jakieś 25 lat po… xterm (dającego podobne możliwości). O dzieleniu okna, zakładkach/kartach (tabs), kopiowaniu myszą/z klawiatury, obsłudze 256 kolorów można zapomnieć.

Console2

W czasach, jak musiałem korzystać z MS Windows jedynym rozsądnym emulatorem terminali tudzież interpreterów w był console lub Console2 jak zwykło się go określać. Było to środowisko potrafiące uruchomić interpreter poleceń w kartach poprzez zdefiniowane skróty klawiszowe. Zresztą - nie tylko cmd.exe, dowolny program, który działał w konsoli (a więc powershell, ipython czy cygwinowy bash!). Wadą console2 była jedna mała upierdliwa rzecz - nie potrafił zrobić pełnej maksymalizacji okna, pomimo tego, że swobodnie dało się zmieniać rozmiar okna. Ponadto, część programów nie radziła sobie kompletnie ze zmianą okna po uruchomieniu (np far manager).

ConEmu

ConEmu początkowo powstał jako interfejs dla menadżera plików far właśnie, by ewoluować jako pełnoprawne narzędzie, które zastępuje i naprawia wszelkie braki konsoli interpretera poleceń. Nie będę wymieniał wszystkich zalet programu, jednakże dla mnie najbardziej istotne są:

• pełna obsługa z klawiatury (tworzenie, nawigacja, zamykanie, dzielenie okna itd)
• tabbed interface, czyli karty/taby
• prawdziwe maksymalizacja okna
• zaznaczanie i wklejanie tekstu liniowo lub blokowo zamiast tylko blokowego, którego zwykle nie chcemy
• możliwość uruchomienia dowolnych powłok czy programów (cmd.exe, powershell, cygwinowy bash, far i nie tylko)

Z wad mogę wymienić domyślne trzymanie konfiguracji w rejestrze (choć jest możliwość zmiany tego zachowania na plik konfiguracyjny w odpowiednim miejscu) oraz makabryczne okienko do zmiany opcji konfiguracyjnych, które przywodzi na myśl radosną twórczość jak z czasów Windowsa XP… Ale, po przebrnięciu przez koszmarny interfejs konfiguracji otrzymujemy w zamian całkiem wygodne i używalne narzędzie.

Cmd.exe

Wciąż jednak zostajemy uwiązani do cmd.exe jako interpretera, bądź cygwinowego basha lub do powershella (którego nie miałem okazji poznać bliżej). Czasem jednak nie ma innego wyjścia i zmuszeni jesteśmy korzystać z cmd.exe - czy to dlatego, że kompatybilność jest konieczna, czy to trzeba uruchamiać pliki wsadowe *.bat, czy jakiekolwiek inne mniej lub bardziej istotne powody. Co wtedy? Jak żyć panie premierze?

Ostatnio natknąłem się na program o nazwie Clink. Jest to w zasadzie rozszerzenie standardowego interpretera cmd.exe o kilka użytecznych cech, takich jak dopełnianie nazw programów poprzez klawisz tab, permanentną historię poleceń, readline, konfigurowalny znak zachęty, możliwość pisania skryptorów w Lua i parę innych rzeczy. Tylko tyle i aż tyle.