A JavaScript-fejlesztés átköltöztetése a Windows Bashre

A szerzőről

Burke Holland front-end fejlesztő, aki a TN Nashville-ben él; a világ legjobb városában. Nagyon élvezi a JavaScriptet, mert csak így …További információBurke↬

Egyike vagyok azoknak, akik nem tudnak a Bash-termináljuk nélkül élni. Ez az egyetlen tény megnehezítette számomra a frontend munkát Windowson. A Microsoftnál dolgozom, és Mac-en dolgozom. Csak akkor jöttem rá, amikor pár éve megjelent az új Surface hardvercsalád:

Szóval vettem egyet. Pontosabban egy Surface Book 2-t Windows 10 operációs rendszerrel. Éppen ezt a cikket írom rajta. És mi van az én édes, édes Bash promptommal? Nos, természetesen magammal hoztam.

Ebben a cikkben részletesen megnézem, hogy a Windows 10 új technológiája hogyan teszi lehetővé egy teljes Linux terminál futtatását Windowson. Megmutatom továbbá a csodálatos terminálbeállításomat (amelyet “én” a “valaha volt legjobbnak” nevezett), és azt is, hogyan állíthatod be te is a saját Windows/Linux fejlesztőgépedet.

Ha vágysz a Surface hardverre, de nem tudsz Linux terminál nélkül élni, akkor a legjobb helyen jársz.

Megjegyzés: E cikk írásakor a cikk számos eleméhez különböző elemek, köztük a Windows “preview” vagy “insiders” buildjeinek használata vagy váltása szükséges. Ezeknek a dolgoknak a többsége valamikor a jövőben bekerül a Windows fő verziójába.

Windows Subsystem For Linux (WSL)

A Windows Subsystem for Linux, vagy “WSL” az, ami lehetővé teszi a Linux futtatását Windowson. De mi is pontosan ez az őrült tudomány?

A WSL jelenlegi inkarnációjában egy fordítóréteg, amely a Linux rendszerhívásokat Windows rendszerhívásokká alakítja át. A Linux a WSL tetején fut. Ez azt jelenti, hogy ahhoz, hogy a Linux a Windowson legyen, három dolgot kell tenned:

1. Enable the WSL,
2. Install Linux,
3. Always include three items in a list.

Amint kiderült, ez a fordítóréteg egy kicsit lassú – olyan, mintha én próbálnám megjegyezni, hogy splice vagy slice kell-e nekem. Ez különösen akkor igaz, amikor a WSL olvas és ír a fájlrendszerbe. Ez elég nagy probléma a webfejlesztők számára, mivel bármelyik megfelelő npm install több ezer fájlt másol a gépedre. Úgy értem, nem tudom, te hogy vagy vele, de én nem fogom a saját karakterláncaimat balra írni.

A WSL 2. verziója már más tészta. Jelentősen gyorsabb, mint a jelenlegi verzió, mert a fordítási réteg helyett a Windows virtualizációs magját használja ki. Amikor azt mondom, hogy “jelentősen gyorsabb”, akkor úgy értem, hogy sokkal, de sokkal gyorsabb. Például olyan gyors, mintha a “splice vs slice” kifejezést gugliznám.

Ezért most megmutatom, hogyan kell telepíteni a WSL 2-t. A cikk írásakor ehhez a Windows “Insider” buildjére lesz szükség.

Először is: kövesse ezt a rövid útmutatót a WSL engedélyezéséhez a Windows 10-en, és ellenőrizze a Windows verziószámát.

Amikor telepítette, nyomja meg a Windows billentyűt, és írja be a “windows insider” szót. Ezután válassza a “Windows Insider program beállításai” lehetőséget.

Egy pár különböző lehetőséged lesz, hogy melyik “gyűrűn” szeretnél lenni. Sok ismerősöm a gyors gyűrűn van. Én viszont óvatos vagyok. Gyerekkoromban a játszótéren a csúszdán hason csúsztam lefelé, az oldalába kapaszkodva. Ezért maradok a lassú gyűrűn. Már több hónapja rajta vagyok, és nem tartom zavaróbbnak vagy instabilabbnak, mint a normál Windows-t.

Ez egy jó választás, ha a WSL 2-t akarod, de nem akarsz meghalni a csúszdán.

Megjegyzés: A cikk megjelenése után tudtam meg, hogy a WSL 2 valójában nem a lassú gyűrűn van. A gyors gyűrűn kell lenned ahhoz, hogy megkapd. Valamikor a cikk írása közben a gyors gyűrűn kellett lennem. Tehát a gyors gyűrűn van. Sok sikert a csúszáshoz!

A következőkben engedélyeznie kell a Windowsban a “Virtual Machine Platform” funkciót, amelyet a WSL 2. verziója igényel. Ehhez a képernyőhöz nyomja meg a Windows billentyűt, és írja be a “windows features” szót. Ezután válassza a “Windows funkciók be- vagy kikapcsolása” lehetőséget. Válassza ki a “Virtuális gép platform” lehetőséget. A “Windows Subsystem for Linux” opciónak már engedélyezve kell lennie.

Most, hogy a WSL engedélyezve van, telepítheti a Linuxot. Ezt ironikus módon közvetlenül a Windows Store-ból teheted meg. Csak 2019-ben javasolnám, hogy “telepítsd a Linuxot a Windows Store-ból”.

Másféle disztribúciók közül választhatsz, de az Ubuntu lesz a leginkább támogatott az összes eszközzel, amit később konfigurálni fogunk – beleértve a VS Code-ot is. Az összes innentől kezdve következő utasítás Ubuntu telepítést feltételez. Ha egy másik disztribúciót telepít, minden tétnek vége.

Keresd az “Ubuntu”-t a Windows Store-ban. Három közül választhat: Ubuntu, Ubuntu 18.04 és Ubuntu 16.04. Az Ubuntu nagyon szereti ezt a 04 minor verziószámot, nem igaz?

Az “Ubuntu” disztró (az első ezen a képernyőképen) a “meta verzió”, vagyis egy helyőrző, ami csak a legújabb verzióra mutat. Jelen pillanatban ez a 18.04.

A meta verziót választottam, mert később megmutatom, hogyan böngészheted a Linux fájlrendszerét a Windows Explorerrel, és eléggé zavaró, hogy “Ubuntu 18.04” legyen a meghajtó neve, szemben az “Ubuntu”-val.

A telepítés elég gyors, az internetkapcsolattól függően. Csak kb. 215 megabájt, de én itt egy gigabites kapcsolaton vagyok, és honnan tudod, hogy valaki gigabites kapcsolaton van-e? Ne aggódj, majd ők megmondják.

A telepítés után mostantól lesz egy “Ubuntu” alkalmazás a Start menüben.

Ha erre kattintasz, egy Bash terminált kapsz!

Töltsön el egy pillanatot, és gyönyörködjön a technika csodájában.

Egy alapértelmezés szerint a WSL 1-es verziójában fog futni. A 2-es verzióra való frissítéshez meg kell nyitnia egy PowerShell terminált, és futtatnia kell egy parancsot.

Lenyomja a “Windows” billentyűt, és írja be a “Powershell”-t.

A PowerShell terminálból a wsl --list --verbose végrehajtásával láthatja, hogy a WSL melyik verziójával rendelkezik.

Ha az 1-es verzió jelenik meg, akkor a --set-version parancsot kell végrehajtani, és megadni a példány nevét (Ubuntu) és a kívánt verziót (2).

wsl --set-version Ubuntu 2

Ez eltart egy darabig, attól függően, hogy mennyi hús van a gépeden. Az enyémnek “néhány percbe” telt plusz-mínusz. Ha kész, a WSL legújabb és legjobb verzióján leszel.

Az Is Your Brain On Linux… On Windows.

A Linux nem Windows. A WSL nem egy bash prompt a Windows operációs rendszer tetején. Ez egy teljes operációs rendszer önmagában, saját mappastruktúrával és telepített alkalmazásokkal. Ha a Node-ot a Windows telepítővel telepíti, a node beírása Linuxban nem fog sikerülni, mert a Node nincs telepítve Linuxban. A Windowsra van telepítve.

A WSL igazi varázsa azonban abban rejlik, hogy zökkenőmentesen összekapcsolja a Windowst és a Linuxot, így azok egy fájlrendszerként jelennek meg a gépén.

Fájl- és mappanavigáció

Az Ubuntu terminál alapértelmezés szerint a Linux home könyvtárába (vagy /home/your-user-name) dobja be. A Windows oldalra a /mnt/c.

Megjegyezzük, hogy itt néhány engedélyt megtagadnak. Az Ubuntu ikonjára jobb egérgombbal kellene kattintanom, és a “Futtatás rendszergazdaként” parancsra kellene kattintanom, hogy hozzáférjek ezekhez a fájlokhoz. Így csinálja a Windows a megemelt jogosultságokat. A Windowson nincs sudo.

Alkalmazások indítása

Az Ubuntu terminálból bármilyen Windows-alkalmazást elindíthat. Például a Windows Intézőt meg tudom nyitni az Unbuntu terminálból.

Ez fordítva is működik. A Linux oldalra telepített bármelyik alkalmazást futtathatod. Itt a Linuxra telepített “fortune”-t futtatom a Windows parancssorából. (Mert nem is igazi Linux telepítés véletlenszerű, értelmetlen szerencsék nélkül.)

Két különböző operációs rendszer. Két különböző fájlrendszer. Két különböző telepített alkalmazáskészlet. Látja, hogy ez mennyire zavaró lehet?

Azért, hogy minden rendben legyen, azt javaslom, hogy az összes JavaScript fejlesztői fájlját és eszközét a Linux oldalára telepítse. Ennek ellenére a Windows és a Linux közötti váltás és a fájlok mindkét rendszerről való elérésének képessége a WSL alapvető varázsa. Ne felejtsd el, mert ez az, ami ezt az egész beállítást jobbá teszi, mint egy hagyományos Linux box.

A fejlesztőkörnyezet beállítása

Innentől kezdve egy véleményes listát fogok adni arról, hogy szerintem mitől lesz gyilkos egy Linux on Windows beállítás. Ne feledd: az én véleményem csak az. Vélemények. Csak történetesen, mint minden véleményem, ezek is 100%-ban helytállóak.

Jobb terminál

Igen, kaptál egy terminált, amikor telepítetted az Ubuntut. Ez tulajdonképpen a Windows konzol, ami a Linux disztribúciódhoz csatlakozik. Ez nem egy rossz konzol. Átméretezheted, bekapcsolhatod a másolást/beillesztést (a beállításokban). De nem tudsz olyan dolgokat csinálni, mint a lapok vagy új ablakok nyitása. Ahogy sokan használnak helyettesítő terminálprogramokat Macen (én a Hyper-t használom), úgy Windowsra is vannak más lehetőségek. A Githubon található Awesome WSL lista elég kimerítő listát tartalmaz.

Ezek mind jó emulátorok, de van egy új lehetőség, amelyet olyan emberek készítettek, akik elég jól ismerik a Windowst.

A Microsoft egy új alkalmazáson dolgozik, amelynek neve “Windows Terminal”.

A Windows Terminal telepíthető a Windows Store-ból, és jelenleg előnézetben van. Már jó ideje használom, és elég funkcióval rendelkezik és elég stabil ahhoz, hogy teljes mellszélességgel kiálljak mellette.

Az új Windows Terminal teljes lapos felületet, másolást/beillesztést, több profilt, átlátszó hátteret, háttérképeket – sőt átlátszó háttérképeket – kínál. Mezőnyjáték, ha szereted testreszabni a terminálodat, és én azért jöttem, hogy megnyerjem ezt a zsákversenyt.

Itt a jelenlegi terminálom. Itt végigsétálunk néhány fontos finomításon.

A Windows terminál eléggé testreszabható. A bal felső sarokban lévő “⌄” nyílra kattintva (a “+” jel mellett) hozzáférhet a “Beállítások” menüponthoz. Ez megnyit egy JSON fájlt.

Bind Copy/Paste

A fájl tetején található az összes billentyűkötés. Az első dolog, amit csináltam, hogy a “másolás”-t a Ctrl + C-hez, a beillesztést pedig a Ctrl + V-hez képeztem le. Hogyan másoljak és illesszek be olyan parancsokat a Stack Overflow-ról, amelyeket nem értek?

{ "command": "copy", "keys": },{ "command": "paste", "keys": },

A probléma az, hogy a Ctrl + C már a SIGINT-hez, vagy a Linuxon a megszakítás/kill parancshoz van hozzárendelve. Van egy csomó terminál Windowsra, ami ezt úgy kezeli, hogy a Copy/Paste-t a Ctrl + Shift + C-re, illetve a Ctrl + Shift + V-re képezi le. A probléma az, hogy a másolás/beillesztés minden más helyen Ctrl + C / Ctrl + V a Windowsban. A terminálban újra és újra lenyomtam a Ctrl + C billentyűt, hogy megpróbáljak másolni dolgokat. Nem tudtam abbahagyni.

A Windows terminál ezt másképp kezeli. Ha szöveg van kiemelve, és megnyomja a Ctrl + C billentyűkombinációt, akkor másolja a szöveget. Ha van egy futó folyamat, akkor is leküldi a SIGINT parancsot, és megszakítja azt. Ez azt jelenti, hogy a Windows terminálban a Ctrl + C / Ctrl + V parancsot nyugodtan hozzárendelheti a másoláshoz/beillesztéshez, és ez nem fogja zavarni a folyamatok megszakításának képességét.

Ki gondolta volna, hogy a másolás/beillesztés ennyi szívfájdalmat okozhat?

Az alapértelmezett profil megváltoztatása

Az alapértelmezett profil az, ami egy új lap megnyitásakor megjelenik. Alapértelmezés szerint ez a Powershell. Görgessen lefelé, és keresse meg a Linux profilt. Ez az, amelyik megnyílik wsl.exe -d Ubuntu. Másolja ki a GUID-jét, és illessze be a defaultProfile beállításba.

Ezt a két beállítást áthelyeztem, hogy közvetlenül egymás mellett legyenek, hogy könnyebb legyen látni:

Háttér beállítása

A hátteret sötét egyszínűnek szeretném, a jobb sarokban egy lapos logóval. Ezt azért teszem, mert azt akarom, hogy a logó világos és látható legyen, de ne legyen a szöveg útjában. Ezt a képet magam készítettem, de a Simple Desktops oldalon nagyszerű lapos képekből lehet válogatni.

A hátteret a backgroundImage tulajdonsággal állítom be:

"backgroundImage": "c:/Users/YourUserName/Pictures/earth.png"

Az “akril” nevű beállítást is észre fogod venni. Ez az, amivel a háttér átlátszatlanságát állíthatod be. Ha egyszínű háttérrel rendelkezel, ez elég egyszerű.

"background": "#336699","useAcrylic": true,"acrylicOpacity": 0.5

Az arcylicOpacity és a backgroundImageOpacity beállítás kombinálásával ezt egy háttérképpel is megvalósíthatja:

"backgroundImage": "c:/Users/username/Pictures/earth-and-stars.png","useAcrylic": true,"acrylicOpacity": 0.5

Az én témámban az átlátszóság miatt minden tompának tűnik, ezért a useAcrylic-et false-re állítom.

A betűtípus megváltoztatása

A Windows-terminált készítő csapat egy új betűtípuson is dolgozik, a “Cascadia Code”-on. Ez az írás időpontjában még nem elérhető, így helyette az alapértelmezett Windows betűtípust kapja.

A Windows terminál alapértelmezett betűtípusa a “Consolas”. Ez ugyanaz a betűtípus, amelyet a Windows parancssor is használ. Ha igazi Ubuntu érzést szeretne, Chris Hoffman megmutatja, hogyan telepítheti a hivatalos Ubuntu Mono betűtípust.

Itt egy előtte és egy utána, hogy láthassa a különbséget:

"fontFace": "Ubuntu Mono"

Meglehetősen hasonlóan néznek ki; a fő különbség az Ubuntu Mono távolságtartásában van, ami a terminált csak egy kicsit feszesebbé és tisztábbá teszi.

Színsémák

A színsémák mind a beállításfájl alján találhatók. Én a “Campbell” színsémát másoltam alapként. Igyekszem a színeket a nevükhöz igazítani, de nem félek a szélhámosságtól sem. A “#ffffffff”-t leképezem a “kékre” – nem is érdekel.

Ha tetszik ez a bizonyos séma, amit “Föld”-nek neveztem el, összeállítottam ezt a gist-et, hogy ne kelljen kézzel kimásolnod ezt az egész káoszt egy screenshotból.

Megjegyzés: A színelőnézetek a VS Code “Color Highlight” bővítményének köszönhetően jönnek létre.

Change The Default Starting Directory

A WSL-profil alapértelmezés szerint a Windows oldalán az otthoni könyvtárba dobja a WSL-profil. Az általam ebben a cikkben ajánlott beállítás alapján jobb lenne, ha ehelyett a Linux home mappájába dobná le. Ehhez módosítsa az startingDirectory beállítást az “Ubuntu” profiljában:

"startingDirectory": "\\wsl$\Ubuntu\home\burkeholland"

Megjegyzi az ottani elérési utat. Ezt az elérési utat (a plusz escape slashek nélkül) használhatja a WSL eléréséhez a Windows parancssorból.

A Zsh/Oh-My-Zsh telepítése

Ha még soha nem használta a Zsh-t és az Oh-My-Zsh-t, akkor igazi élvezetben lesz része. A Zsh (vagy “Z Shell”) egy helyettesítő shell a Linuxhoz. Kibővíti a Bash alapvető képességeit, beleértve a hallgatólagos könyvtárváltást (nem kell beírni a cd-t), a jobb témák támogatását, a jobb promptokat és még sok mást.

A Zsh telepítéséhez szerezd be az apt csomagkezelővel, amely a Linux telepítésével együtt érkezik:

sudo apt install zsh

Telepítsd az oh-my-zsh-t a curl segítségével. Az oh-my-zsh egy konfigurációs készlet a zsh-hez, amely bővítményekkel, témákkal és számtalan billentyűparanccsal még tovább javítja a shell-élményt.

sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"

Ezután megkérdezi, hogy az alapértelmezett shell-t Zsh-re akarod-e változtatni. Ha igen, akkor válaszolj igennel, és máris használhatod a Zsh-t és az Oh-My-Zsh-t.

Észreveheted, hogy a prompt sokkal tisztább lett. Megváltoztathatod a prompt kinézetét a ~/.zshrc fájlban lévő téma megváltoztatásával.

Nyisd meg a nano segítségével, ami olyan, mint a VIM, de szerkesztheted a dolgokat, és kiléphetsz, amikor kell.

nano ~/.zshrc

Változtasd meg a témát beállító sort. Van fölötte egy URL a témák teljes listájával. Szerintem a “felhő” az szép. És aranyos.

Hogy a .zshrc módosításait átvegye, a forrásra van szükséged:

source ~/.zshrc

Note: Ha olyan témát választasz, mint az “agnoster”, amihez glifák kellenek, akkor szükséged lesz az Ubuntu Mono egy olyan powerline-os verziójára, amely rendelkezik… glifákkal. Ellenkező esetben a terminálod tele lesz furcsa karakterekkel, mintha az arcodat nyomnád a billentyűzetre. A Nerd Fonts kínál egyet, ami úgy tűnik, elég jól működik.

Most már olyan dolgokat is megtehetsz, mint például a könyvtárak megváltoztatása, csak a könyvtár nevének megadásával. Nem szükséges cd. Vissza akarsz menni egy könyvtárba? Csak adj meg egy ..-t. Még a teljes könyvtárnevet sem kell beírnod, csak az első néhány betűt, és nyomd meg a tab billentyűt. A Zsh egy listát fog adni a keresésednek megfelelő összes fájlról/könyvtárról, és te átlapozhatod őket.

Node telepítése

Webfejlesztőként valószínűleg telepíteni akarod a Node-ot. Feltételezem, hogy nem kell telepítened a Node-ot ahhoz, hogy webfejlesztést végezz, de 2019-ben biztosan úgy érzed!

Az első ösztönöd lehet, hogy a apt segítségével telepíted a node-ot, amit meg is tehetsz, de két okból is megbánnád:

1. A Node apt-n lévő verziója dolorously elavult;
2. A Node-ot verziókezelővel kell telepítened, hogy ne ütközz jogosultsági problémákba.

A legjobb megoldás mindkét problémára az nvm (Node Version Manager) telepítése. Mivel telepítetted a zsh, csak hozzáadhatod az nvm plugint a zshrc fájlodhoz, és a zsh elintézi a többit.

Először is telepítsd a plugint a zsh-nvm repo klónozásával. (Ne aggódj, a Git alapértelmezett az Ubuntu telepítésedben.)

git clone https://github.com/lukechilds/zsh-nvm ~/.oh-my-zsh/custom/plugins/zsh-nvm

Ezt követően add hozzá, mint plugint a ~/.zshrc fájlban.

`nano ~/.zshrc`plugins (zsh-nvm git)

Ne felejtsd el újra a zshrc fájlt a source ~/.zshrc forráskóddal, és látni fogod, hogy az nvm települ.

Most már telepítheted a node-ot az nvm-mel. Ez megkönnyíti a node több egymás melletti verziójának telepítését, és a közöttük való könnyed váltást. Továbbá, nincsenek jogosultsági hibák, amikor globális npm telepítést végzel!

nvm install --lts

Azt ajánlom a standard nvm telepítéssel szemben, mert a plugin lehetővé teszi az nvm egyszerű frissítését. Ez eléggé fájdalmas a standard “curl” telepítéssel. A pluginnel ez egyetlen parancs.

nvm upgrade

Automatikus javaslatok kihasználása

Az egyik nagyon kedvenc pluginom a zsh-hez a zsh-autosuggestions. Emlékszik azokra a dolgokra, amiket korábban beírtál a terminálba, majd felismeri őket, amikor újra elkezded beírni őket, valamint “auto-suggests” a sorra, amire szükséged lehet. Ez a bővítmény többször jött jól, mint amennyire vissza tudok emlékezni – különösen, amikor hosszú CLI-parancsokról van szó, amelyeket a múltban használtam, de soha nem emlékszem rá.

Klónozd a repót a zsh extensions mappába:

git clone https://github.com/zsh-users/zsh-autosuggestions ~/.oh-my-zsh/custom/plugins/zsh-autosuggestions

Majd add hozzá a zsh pluginjaidhoz és forrásold a zshrc fájlt:

nano ~/.zshrc# In the .zshrc fileplugins(zsh-nvm zsh-autosuggestions git)source ~/.zshrc

A plugin olvassa a zsh előzményeidet, szóval kezdj el beírni valami korábban már beírt parancsot és figyeld a varázslatot. Próbáld meg beírni a fenti hosszú clone parancs első részét.

Ha lenyomod a ↹ -t, automatikusan kitölti a parancsot. Ha továbbra is lenyomja a ↹ gombot, akkor az előzményekben lévő összes olyan parancsot átnézi, amely megfelelhet.

Fontos billentyűkombinációk

Van néhány terminálbillentyűparancs, amelyet állandóan használok. Ezt minden eszközömnél megtalálom – beleértve a VS Code-ot is. Ha megpróbálod megtanulni az összes gyorsbillentyűt, az időpocsékolás, mert nem fogod őket elégszer használni ahhoz, hogy megjegyezd őket.

Itt van néhány, amit rendszeresen használok:

Ez az! Minden mást valószínűleg megtanultam, aztán elfelejtettem, mert sosem használom.

Git(Hub/Lab/Whatevs)

A Git Ubuntun van, így nincs szükség telepítésre. Követheted az általad választott forráskezelő tárhelyen található utasításokat az ssh kulcsok létrehozásához és működéséhez.

Figyelj arra, hogy a Github utasításaiban azt írja, hogy a “copy” segédprogramot kell használni az ssh kulcs másolásához. Az Ubuntunak van az “xcopy” parancs, de ez itt nem fog működni, mert nincs interop a Linux és a Windows között a vágólap tekintetében.

Ehelyett használhatod a Windows Clipboard futtatható programját, és közvetlenül a terminálból hívhatod meg. A szöveget először a cat segítségével kell megszerezned, majd ezt átvezetni a Windows vágólapjára.

cat ~/.ssh/id_rsa.pub | clip.exe 

A Github dokumentációban azt írják, hogy győződj meg róla, hogy a ssh-agent fut. Ez nem így van. Ezt látod, amikor megpróbálod hozzáadni a kulcsodat az ügynökhöz:

Az ügynököt elindíthatod, de a Windows következő újraindításakor vagy a WSL leállításakor újra kell indítanod. Ennek oka, hogy a WSL-ben nincs inicializáló rendszer. Nincs systemd vagy más folyamat, amely a WSL indításakor elindítja az összes szolgáltatást. A WSL még előzetesben van, és a csapat dolgozik egy megoldáson erre.

Addig is, akár hiszed, akár nem, erre is van egy zsh plugin. A neve ssh-agent, és az oh-my-zsh-vel együtt telepítve van, így csak hivatkoznod kell rá a .zshrc fájlban.

zsh-nvm zsh-autosuggestions ssh-agent git

Ez automatikusan elindítja az ssh-agentet, ha az nem fut a WSL első indításakor. Hátránya, hogy minden egyes alkalommal, amikor a WSL-t frissen indítod, kérni fogja a jelszavadat. Ez lényegében azt jelenti, hogy bármikor, amikor újraindítja a számítógépét.

VS Code és a WSL

A WSL-nek nincs GUI-ja, így nem tud olyan vizuális eszközt telepíteni, mint a VS Code. Azt a Windows oldalon kell telepíteni. Ez problémát jelent, mert a Windows oldalon futó program a Linux oldalon lévő fájlokhoz fér hozzá, és ez mindenféle furcsaságokat és “permission denied” problémákat eredményezhet. Általános szabályként a Microsoft azt ajánlja, hogy Windows programokkal ne módosítsunk fájlokat a WSL oldalon.

A megoldáshoz létezik egy “Remote WSL” nevű bővítmény a VS Code-hoz. Ezt a bővítményt a Microsoft készítette, és lehetővé teszi, hogy a WSL-en belül, de a VS Code-on belül fejlesszen.

A bővítmény telepítése után a VS Code-ot közvetlenül az Ubuntu oldalához csatolhatja, ha megnyitja a parancspalettát (Ctrl + Shift + P), és kiválasztja a “Remote-WSL: Új ablak” lehetőséget.

Ez megnyitja a VS Code egy új példányát, amely lehetővé teszi, hogy úgy dolgozzon, mintha teljesen a Linux oldalán lenne. A “File/Open” parancsot végrehajtva a Windows helyett az Ubuntu fájlrendszerét böngészi.

A VS Code integrált terminálja megnyitja a szépen testre szabott zsh beállítását. Minden úgy “működik”, ahogy kell, ha telepítve van a Remote WSL kiterjesztés.

Ha a terminálból a code . segítségével nyitja meg a kódot, a VS Code automatikusan felismeri, hogy a WSL-ből nyitotta meg, és automatikusan csatolja a Remote WSL kiterjesztést.

VS Code kiterjesztések a Remote WSL-lel

A VS Code Remote WSL kiterjesztése úgy működik, hogy Linux oldalon létrehoz egy kis szervert, majd ehhez csatlakozik a VS Code Windows oldaláról. Ebből adódóan a VS Code-ban telepített bővítmények nem fognak automatikusan megjelenni, amikor megnyitsz egy projektet a WSL-ből.

Egy Vue projektet nyitottam meg például a VS Code-ban. Annak ellenére, hogy az összes megfelelő Vue-bővítményt telepítettem a szintaxis-kiemeléshez, formázáshoz és hasonlókhoz, a VS Code úgy viselkedik, mintha még soha nem látott volna .vue fájlt.

A WSL-ben minden telepített bővítmény engedélyezhető. Csak keresse meg a WSL-ben a kívánt bővítményt, és kattintson a “Telepítés a WSL-ben” gombra.

A WSL-ben telepített összes bővítmény saját szekciójában jelenik meg a Bővítmények Intézője nézetben. Ha sok bővítménye van, kissé bosszantó lehet, ha mindegyiket külön-külön kell telepítenie. Ha csak a WSL-ben lévő összes bővítményt szeretné telepíteni, kattintson a kis felhő-letöltés ikonra a “Helyi – Telepített” szakasz tetején.

How To Setup Your Dev Directories

Ez már egy véleményes cikk, ezért itt van egy, amit nem kértél, arról, hogy szerintem hogyan kellene strukturálnod a projektjeidet a fájlrendszereden.

Én minden projektemet a Linux oldalán tartom. Nem teszem a projektjeimet a “Saját dokumentumok”-ba, hogy aztán a WSL-ből próbáljak velük dolgozni. Az agyam ezt nem tudja kezelni.

Létrehozok egy /dev nevű mappát, amelyet a /home mappám gyökerébe teszek Linuxon. Ezen a mappán belül létrehozok egy másikat, amelynek ugyanaz a neve, mint a Github repómnak: /burkeholland. Ebbe a mappába kerül az összes projektem – még azok is, amelyek nem kerülnek fel a Githubra.

Ha klónozok egy repót egy másik Github-fiókból (pl. “microsoft”), akkor létrehozok egy új mappát a “dev”-ben /microsoft néven. Ezután klónozom a repót egy azon belüli mappába.

Gyakorlatilag ugyanazt a struktúrát utánzom, mint a helyi gépemen a forráskontrolt. Szerintem sokkal könnyebb következtetni arra, hogy hol vannak a projektek és milyen repókhoz kapcsolódnak, pusztán a helyük alapján. Ez egyszerű, de nagyon hatékonyan segít abban, hogy mindent rendben tartsak. És nekem minden segítségre szükségem van.

Fájlok böngészése a Windows Explorerből

Vannak esetek, amikor Linuxban Windows oldalról kell elérni egy fájlt. A WSL-ben az a szép, hogy ezt még mindig megtehetjük.

Egyik módja, hogy a WSL-t úgy érjük el, mint egy leképezett meghajtót. Egy \wsl$ segítségével közvetlenül az explorer sávból érheted el:

\wsl$

Ezt többféle okból is megteheted. Például éppen ma volt szükségem egy olyan Chrome-bővítményre, amely nincs a webáruházban. Ezért klónoztam a WSL-ben a repót, majd “kicsomagolt bővítményként” navigáltam hozzá, és betöltöttem az Edge-be.

Az egyik dolog, amit bizonyos gyakorisággal csinálok Linuxon, hogy közvetlenül a terminálból megnyitom a fájlt tartalmazó könyvtárat. Ezt a WSL-ben is megteheted, közvetlenül a explorer.exe hívásával. Ez a parancs például megnyitja az aktuális könyvtárat a Windows Intézőben.

$ explorer.exe .

Ez a parancs azonban egy kicsit nehézkes. Linuxon egyszerűen csak open .. Ugyanezt a varázslatot elvégezhetjük, ha létrehozunk egy aliast a ~/.zshrc-ban.

alias open="explorer.exe"

Docker

Amikor azt mondtam, hogy minden eszköznek a Linux oldalán kell lennie, akkor ezt úgy értettem. Ez magában foglalja a Dockert is.

Ez az a pont, ahol a gumi igazán elkezd találkozni az úttal. Amire itt szükségünk van, az a Windowson belül futó Linuxon belül futó Docker. Ez egy kicsit olyan, mint egy orosz fészekrakó baba, ha leírod egy blogbejegyzésben. A valóságban elég egyszerű.

A Docker megfelelő verziójára lesz szükséged Windowshoz. E cikk írásakor ez a WSL 2 Tech Preview.

A telepítő futtatásakor megkérdezi, hogy a Linux konténerek helyett Windows konténereket szeretne-e használni. Mindenképpen ezt kell tennie. Ellenkező esetben nem kapja meg a Docker futtatásának lehetőségét a WSL-ben.

A Dockert most már engedélyezheti a WSL-ben, ha a rendszertálcán lévő elemre kattintva kiválasztja a “WSL 2 Tech Preview”-t:

A szolgáltatás elindítása után a Dockert a WSL-en belül is használhatja, ahogyan arra számíthat. A Docker futtatása a WSL-ben elég nagy teljesítménynövekedést biztosít, valamint a konténerek hidegindítási idejét is növeli.

A Docker bővítmény telepítését is javasolnám a VS Code-hoz. Ez egy vizuális felületet ad a Docker beállításához, és általában csak megkönnyíti a Dockerrel való munkát, mert nem kell megjegyeznie az összes parancssori zászlót és opciót.

Több Bash a Windowson

Ezzel a ponttal meg kell kapnia az ötletet arról, hogyan lehet a Bash-t Windowsra tenni, és hogyan működik, ha már ott van. A végtelenségig testreszabhatod a terminálodat, és mindenféle radikális program van, amit hozzáadhatsz olyan dolgokhoz, mint például a PATH változók automatikus beállítása, aliasok létrehozása, ASCII tehén megjelenése a terminálodban, és még sok minden más.

A Bash futtatása Windowson egy teljesen új univerzumot nyitott meg előttem. Képes vagyok kombinálni a Windowst, amelyet a produktivitás miatt szeretek, és a Linuxot, amelyre fejlesztőként támaszkodom. A legjobb az egészben, hogy most már mindkét platformra tudok alkalmazásokat készíteni egy géppel.

További olvasmányok

A Windowson futó Bash-ről itt olvashat bővebben:

• “Windows Subsystem For Linux Installation Guide For Windows 10,” Microsoft Docs
• “How To Install And Use The Bash Shell On Windows 10,” Chris Hoffman, How-To Geek
• “Sharing SSH With WSL,” Drew Wilson
• “Getting Crazy With The Window Subsystem For Linux,” Brian Ketelsen
• “Everything You Can Do With Windows 10’s New Bash Shell,” Chris Hoffman, How-To Geek

Külön köszönet Brian Ketelsennek, Matt Hernandeznek, Rich Turnernek és Craig Loewennek a cikkhez nyújtott türelmükért, segítségükért és útmutatásukért.

(rb, dm, il)