Flytta din JavaScript-utveckling till Bash i Windows

Om författaren

Burke Holland är en front-end-utvecklare som bor i Nashville, TN; den bästa staden i världen. Han tycker mycket om JavaScript eftersom det är det enda sättet han …Mer omBurke↬

Jag är en av dem som inte kan leva utan sin Bash-terminal. Detta enda faktum har gjort det svårt för mig att göra frontend-arbete på Windows. Jag arbetar på Microsoft och jag sitter på en Mac. Det var inte förrän den nya hårdvarusortimentet Surface kom ut för några år sedan som jag insåg det: Jag måste ha en sådan.

Så jag skaffade en. En Surface Book 2 med Windows 10 för att vara exakt. Jag håller på att skriva den här artikeln på den just nu. Och hur är det med min söta, söta Bash-prompt? Tja, den tog jag förstås med mig.

I den här artikeln ska jag ta en djupgående titt på hur ny teknik i Windows 10 gör det möjligt att köra en fullständig Linux-terminal i Windows. Jag kommer också att visa dig min fantastiska terminaluppsättning (som utsågs till ”bäst någonsin” av ”mig”) och hur du också kan sätta upp din alldeles egna Windows/Linux-utvecklingsmaskin.

Om du har längtat efter lite av den där Surface-hårdvaran, men inte kan leva utan en Linux-terminal, har du kommit till rätt ställe.

Notera: I skrivande stund kräver många av punkterna i den här artikeln att du använder eller byter till ”preview”- eller ”insiders”-byggnader av olika objekt, inklusive Windows. De flesta av dessa saker kommer att finnas i Windows huvudversion någon gång i framtiden.

Windows Subsystem For Linux (WSL)

Windows Subsystem for Linux, eller ”WSL”, är det som gör det möjligt att köra Linux på Windows. Men vad är egentligen denna galna vetenskap?

WSL, i sin nuvarande form, är ett översättningslager som omvandlar Linux-systemanrop till Windows-systemanrop. Linux körs ovanpå WSL. Det betyder att för att få Linux på Windows måste du göra tre saker:

1. Aktivera WSL,
2. Installera Linux,
3. Inkludera alltid tre saker i en lista.

Det visar sig att det översättningslagret är en smula långsamt – ungefär som när jag försöker komma ihåg om jag behöver splice eller slice. Detta gäller särskilt när WSL läser och skriver till filsystemet. Det är ett ganska stort problem för webbutvecklare eftersom varje korrekt npm install kopierar tusentals filer till din maskin. Jag menar, jag vet inte hur det är med dig, men jag tänker inte vänstera mina egna strängar.

Version 2 av WSL är en annan historia. Den är betydligt snabbare än den nuvarande versionen eftersom den utnyttjar en virtualiseringskärna i Windows i stället för att använda översättningslagret. När jag säger att den är ”betydligt snabbare” menar jag mycket, mycket snabbare. Typ lika snabbt som att jag googlar ”splice vs slice”.

För den skull ska jag visa hur man installerar WSL 2. I skrivande stund kommer det att kräva att du har en ”Insider”-build av Windows.

Först av allt: följ den här korta guiden för att aktivera WSL i Windows 10 och kontrollera ditt Windows-versionnummer.

När du väl har installerat det trycker du på Windows-tangenten och skriver ”windows insider”. Välj sedan ”Windows Insider Program Settings”.

Du kommer att ha ett par olika alternativ när det gäller vilken ”ring” du vill vara med på. Många människor som jag känner är på den snabba ringen. Jag är dock en försiktig kille. När jag var liten åkte jag ner för rutschkanan på lekplatsen på mage och höll mig i sidorna. Det är därför jag håller mig till den långsamma ringen. Jag har varit på den i flera månader nu, och jag tycker inte att den är mer störande eller instabil än vanliga Windows.

Det är ett bra alternativ om du vill ha WSL 2, men inte vill dö på rutschkanan.

Notis: Efter att ha publicerat den här artikeln fick jag veta att WSL 2 i själva verket inte finns på den långsamma ringen. Du måste vara på den snabba ringen för att få den. Jag måste ha varit på den snabba ringen någon gång när jag skrev den här artikeln. Så det är den snabba ringen som gäller. Lycka till med glidningen!

Nästan måste du aktivera funktionen ”Virtual Machine Platform” i Windows, vilket krävs av WSL version 2. För att komma till den här skärmen trycker du på Windows-tangenten och skriver ”windows features”. Välj sedan ”Slå på eller av Windows-funktioner”. Välj ”Virtual Machine Platform”. Alternativet ”Windows Subsystem for Linux” bör redan vara aktiverat.

Nu när WSL är aktiverat kan du installera Linux. Du gör detta, ironiskt nog, direkt från Windows Store. Först 2019 skulle jag föreslå att du ”installerar Linux från Windows Store”.

Det finns flera olika distributioner att välja mellan, men Ubuntu kommer att ha mest stöd för alla de verktyg som vi kommer att konfigurera senare – inklusive VS Code. Alla instruktioner som kommer hädanefter utgår från en Ubuntu-installation. Om du installerar en annan distro är allting okej.

Sök efter ”Ubuntu” i Windows Store. Det kommer att finnas tre att välja mellan: Ubuntu, Ubuntu 18.04 och Ubuntu 16.04. Ubuntu gillar verkligen det där 04 minor versionsnumret, eller hur?

Distro ”Ubuntu” (den första i den här skärmdumpen) är ”metaversionen”, eller snarare en platshållare som bara pekar på den senaste versionen. Just nu är det 18.04.

Jag valde metaversionen eftersom jag senare kommer att visa hur man bläddrar i Linux filsystem med Windows Explorer och det är lite rörigt att ha ”Ubuntu 18.04” som enhetsnamn jämfört med bara ”Ubuntu”.

Den här installationen går ganska snabbt, beroende på din internetanslutning. Den är bara cirka 215 megabyte, men jag har en gigabit-anslutning här borta och hur vet man om någon har en gigabit-anslutning? Oroa dig inte, de berättar det för dig.

När det är installerat har du nu en ”Ubuntu”-app i startmenyn.

Om du klickar på den får du upp en Bash-terminal!

Ta en stund för att njuta av teknikens mirakel.

Som standard kör du i WSL version 1. För att uppgradera till version 2 måste du öppna en PowerShell-terminal och köra ett kommando.

Dryck på ”Windows”-tangenten och skriv ”Powershell”.

Från PowerShell-terminalen kan du se vilken version av WSL du har genom att exekvera wsl --list --verbose.

Om du visar version 1 måste du exekvera kommandot --set-version och ange namnet på instansen (Ubuntu) och vilken version du vill ha (2).

wsl --set-version Ubuntu 2

Det här kommer att ta lite tid, beroende på hur mycket kött din maskin har. Min tog ”några minuter” ungefär. När det är klart har du den senaste och bästa versionen av WSL.

Den är din hjärna på Linux… på Windows.

Linux är inte Windows. WSL är inte en bash-prompt ovanpå ett Windows-operativsystem. Det är ett fullständigt operativsystem i sig självt med en egen mappstruktur och installerade program. Om du installerar Node med Windows-installationsprogrammet kommer det att misslyckas att skriva node i Linux eftersom Node inte är installerat i Linux. Det är installerat i Windows.

Den verkliga magin med WSL ligger dock i det sätt på vilket den sömlöst kopplar ihop Windows och Linux så att de framstår som ett enda filsystem på din maskin.

Fil och mappnavigering

Som standard släpper Ubuntu-terminalen dig till din Linux-hjemkatalog (eller /home/your-user-name). Du kan gå över till Windows-sidan genom att gå till /mnt/c.

Bemärk att vissa behörigheter nekas här. Jag skulle behöva högerklicka på Ubuntu-ikonen och klicka på ”Kör som administratör” för att få tillgång till dessa filer. Så här gör Windows förhöjda behörigheter. Det finns inget sudo i Windows.

Lansera program

Du kan starta alla Windows-program från Ubuntu-terminalen. Jag kan till exempel öppna Windows Explorer från Ubuntu-terminalen.

Detta fungerar även i motsatt riktning. Du kan köra alla program som är installerade på Linuxsidan. Här kör jag ”fortune” installerat i Linux från Windows kommandorad. (Eftersom det inte är en riktig Linuxinstallation utan slumpmässiga, meningslösa förmögenheter.)

Två olika operativsystem. Två olika filsystem. Två olika uppsättningar installerade program. Ser du hur detta kan bli förvirrande?

För att hålla ordning på allt rekommenderar jag att du håller alla dina JavaScript-utvecklingsfiler och verktyg installerade på Linux-sidan. Med det sagt, möjligheten att flytta mellan Windows och Linux och få tillgång till filer från båda systemen är kärnan i WSL:s magi. Glöm inte det, för det är det som gör hela den här installationen bättre än bara en vanlig Linux-box.

Inställning av din utvecklingsmiljö

Från och med nu kommer jag att ge dig en lista med åsiktsartiklar för vad jag tycker gör en bra Linux på Windows-installation. Kom ihåg: mina åsikter är bara det. Åsikter. Det råkar bara vara så att precis som alla mina åsikter är de 100 procent korrekta.

Få en bättre terminal

Ja, du fick en terminal när du installerade Ubuntu. Det är faktiskt Windows Console som är ansluten till din Linux-distribution. Det är ingen dålig konsol. Du kan ändra storlek på den, aktivera kopiera/klistra in (i inställningar). Men du kan inte göra saker som flikar eller öppna nya fönster. Precis som många använder ersättningsterminalprogram på Mac (jag använder Hyper) finns det andra alternativ för Windows också. Awesome WSL-listan på Github innehåller en ganska uttömmande lista.

Dessa är alla bra emulatorer, men det finns ett nytt alternativ som byggs av personer som kan Windows ganska bra.

Microsoft har arbetat med ett nytt program som heter ”Windows Terminal”.

Windows Terminal kan installeras från Windows Store och befinner sig för närvarande i förhandsvisningsläge. Jag har använt den ett bra tag nu och den har tillräckligt med funktioner och är tillräckligt stabil för att jag ska kunna ge den ett helhjärtat stöd.

Den nya Windows Terminal har ett fullständigt flikgränssnitt, kopiera/klistra in, flera profiler, genomskinliga bakgrunder, bakgrundsbilder – till och med genomskinliga bakgrundsbilder. Det är en fältdag om du gillar att anpassa din terminal, och jag kom att vinna det här säckracet.

Här är min nuvarande terminal. Vi ska ta en promenad genom några av de viktiga justeringarna här.

Windows terminal är ganska anpassningsbar. Genom att klicka på pilen ”⌄” uppe till vänster (bredvid tecknet ”+”) får du tillgång till ”Inställningar”. Detta öppnar en JSON-fil.

Bind Copy/Paste

Ovanför filen finns alla tangentbindningar. Det första jag gjorde var att mappa ”kopiera” till Ctrl + C och klistra in till Ctrl + V. Hur ska jag annars kunna kopiera och klistra in kommandon från Stack Overflow som jag inte förstår?

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

Problemet är att Ctrl + C redan är mappat till SIGINT, eller kommandot Interrupt/kill på Linux. Det finns många terminaler för Windows som hanterar detta genom att mappa Copy/Paste till Ctrl + Shift + C respektive Ctrl + Shift + V. Problemet är att kopiera/klistra in är Ctrl + C / Ctrl + V på alla andra ställen i Windows. Jag fortsatte bara att trycka på Ctrl + C i terminalen om och om igen för att försöka kopiera saker. Jag kunde inte sluta göra det.

Windows-terminalen hanterar detta annorlunda. Om du har text markerad och trycker på Ctrl + C kopierar den texten. Om det finns en pågående process skickar den fortfarande ner SIGINT-kommandot och avbryter den. Det betyder att du säkert kan mappa Ctrl + C / Ctrl + V till Kopiera/klistra in i Windows-terminalen och det kommer inte att störa din förmåga att avbryta processer.

Vem trodde att Kopiera/klistra in skulle kunna orsaka så mycket hjärtesorg?

Ändra standardprofilen

Standardprofilen är det som kommer upp när en ny flik öppnas. Som standard är det Powershell. Du vill bläddra ner och hitta Linuxprofilen. Det är den som öppnas wsl.exe -d Ubuntu. Kopiera dess GUID och klistra in den i inställningen defaultProfile.

Jag har flyttat de här två inställningarna så att de ligger precis bredvid varandra för att göra det lättare att se:

Inställ bakgrunden

Jag vill att bakgrunden ska vara en mörk enfärgad färg med en platt logotyp i höger hörn. Jag gör detta eftersom jag vill att logotypen ska vara ljus och synlig, men inte vara i vägen för texten. Den här har jag gjort själv, men det finns en stor samling platta bilder att välja mellan på Simple Desktops.

Bakgrunden är inställd med egenskapen backgroundImage:

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

Du märker också att det finns en inställning som heter ”acrylic”. Med denna inställning kan du justera bakgrundens opacitet. Om du har en enfärgad bakgrundsfärg är detta ganska enkelt.

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

Du kan göra detta även med en bakgrundsbild genom att kombinera inställningen arcylicOpacity med backgroundImageOpacity:

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

För mitt tema får transparens allt att se dämpat ut, så jag håller useAcrylic inställd på false.

Ändra typsnittet

Det team som bygger Windows Terminal arbetar också på ett nytt typsnitt som heter ”Cascadia Code”. Det är inte tillgängligt när detta skrivs, så du får standardtypsnittet för Windows istället.

Standardtypsnittet i Windows-terminalen är ”Consolas”. Det är samma typsnitt som används i Windows kommandorad. Om du vill ha den riktiga Ubuntu-känslan visar Chris Hoffman hur du kan installera Ubuntus officiella Mono-teckensnitt.

Här är ett före och ett efter så att du kan se skillnaden:

"fontFace": "Ubuntu Mono"

De ser ganska lika ut; den största skillnaden är avståndet i Ubuntu Mono som gör terminalen lite snävare och renare.

Färgscheman

Färgscheman finns längst ner i inställningsfilen. Jag kopierade färgschemat ”Campbell” som en baslinje. Jag försöker matcha färgerna med deras namn, men jag är inte heller rädd för att gå på skoj. Jag mappar ”#ffffffff” till ”blå” – jag bryr mig inte ens.

Om du gillar just det här schemat, som jag har döpt till ”Earth”, har jag sammanställt denna gist så att du slipper kopiera all den här röran manuellt från en skärmdump.

Notera: Färgförhandsgranskningarna kommer i kraft av tillägget ”Color Highlight” för VS Code.

Ändra standardstartkatalogen

Som standard släpper WSL-profilen dig till din hemkatalog på Windows-sidan. Baserat på den inställning som jag rekommenderar i den här artikeln skulle det vara att föredra att du släpps till din Linux-mapp home istället. För att göra det ändrar du inställningen startingDirectory i din ”Ubuntu”-profil:

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

Notera sökvägen där. Du kan använda den här sökvägen (minus de extra escape-slashes) för att komma åt WSL från Windows-kommandoraden.

Installera Zsh/Oh-My-Zsh

Om du aldrig har använt Zsh och Oh-My-Zsh tidigare har du en riktig höjdare framför dig. Zsh (eller ”Z Shell”) är ett ersättningsskal för Linux. Det utökar de grundläggande funktionerna i Bash, inklusive implicit katalogbyte (du behöver inte skriva cd), bättre stöd för teman, bättre prompts och mycket mer.

För att installera Zsh hämtar du det med apt-pakethanteraren, som följer med din Linux-installation:

sudo apt install zsh

Installera oh-my-zsh med hjälp av curl. Oh-my-zsh är en uppsättning konfigurationer för zsh som förbättrar skalupplevelsen ytterligare med plugins, teman och en myriad av tangentbordsgenvägar.

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

Därefter frågar den dig om du vill ändra ditt standardskal till Zsh. Det vill du, så svara jakande och du är nu igång med Zsh och Oh-My-Zsh.

Du kommer att märka att prompten är mycket renare nu. Du kan ändra utseendet på den prompten genom att ändra temat i filen ~/.zshrc.

Öppna den med nano, vilket är ungefär som VIM, men du kan redigera saker och avsluta när du behöver det.

nano ~/.zshrc

Förändra raden som anger temat. Det finns en URL ovanför den med en hel lista över teman. Jag tycker att det med ”molnet” är trevligt. Och söt.

För att få ändringar i .zshrc upplockade måste du källsortera den:

source ~/.zshrc

Note: Om du väljer ett tema som ”agnoster” som kräver glyfer behöver du en powerline-infunderad version av Ubuntu Mono som har… glyfer. Annars kommer din terminal bara att vara full av konstiga tecken som om du mosat ansiktet mot tangentbordet. Nerd Fonts erbjuder en som verkar fungera ganska bra.

Nu kan du göra saker som att byta kataloger bara genom att ange katalognamnet. Ingen cd krävs. Vill du gå tillbaka till en katalog? Gör bara en ... Du behöver inte ens skriva hela katalognamnet, skriv bara de första bokstäverna och tryck på tab. Zsh kommer att ge dig en lista med alla filer/kataloger som matchar din sökning och du kan tabba igenom dem.

Installation av Node

Som webbutvecklare kommer du förmodligen att vilja installera Node. Jag antar att du inte behöver installera Node för att göra webbutveckling, men det känns verkligen så 2019!

Din första instinkt kanske är att installera Node med apt, vilket du kan göra, men du skulle ångra det av två anledningar:

1. Versionen av Node på apt är sorgligt föråldrad;
2. Du bör installera Node med en versionshanterare så att du inte stöter på problem med behörigheter.

Det bästa sättet att lösa båda dessa problem är att installera nvm (Node Version Manager). Eftersom du har installerat zsh kan du bara lägga till insticksprogrammet nvm i din zshrc-fil och zsh tar hand om resten.

Först installerar du insticksprogrammet genom att klona i zsh-nvm repo. (Oroa dig inte, Git är standard på din Ubuntu-installation.)

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

När du sedan lägger till det som ett insticksprogram i ~/.zshrc-filen.

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

Håll dig till källkoden i zshrc-filen igen med source ~/.zshrc och du kommer att se att nvm installeras.

Nu kan du installera node med nvm. Det gör det enkelt att installera flera versioner av node sida vid sida och växla mellan dem utan ansträngning. Dessutom inga behörighetsfel när du gör globala npm-installationer!

nvm install --lts

Jag rekommenderar detta framför den vanliga nvm-installationen eftersom insticksmodulen ger dig möjlighet att enkelt uppgradera nvm. Detta är ganska jobbigt med den vanliga ”curl”-installationen. Det är ett enda kommando med insticksprogrammet.

nvm upgrade

Använd automatiska förslag

Ett av mina absoluta favoritinsticksprogram för zsh är zsh-autosuggestions. Den kommer ihåg saker som du har skrivit i terminalen tidigare och känner sedan igen dem när du börjar skriva dem igen samt ”auto-suggestionerar” den rad du kan behöva. Det här insticksprogrammet har kommit till nytta fler gånger än jag kan komma ihåg – särskilt när det gäller långa CLI-kommandon som jag har använt tidigare, men som jag aldrig kan komma ihåg.

Klona repo:n till mappen zsh extensions:

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

Följ sedan till dina zsh-plugins och källkoden till zshrc-filen:

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

Pluginet läser din zsh-historik, så börja skriva något kommando som du har skrivit tidigare och se magin. Prova att skriva den första delen av det långa klonkommandot ovan.

Om du trycker på ↹ kommer det att autokomplettera kommandot. Om du fortsätter att trycka på ↹ kommer den att cykla genom alla kommandon i din historik som kan vara en matchning.

Viktiga tangentbordsgenvägar

Det finns några terminalgenvägar som jag använder hela tiden. Jag hittar detta med alla mina verktyg – inklusive VS Code. Att försöka lära sig alla genvägar är slöseri med tid eftersom du inte kommer att använda dem tillräckligt mycket för att komma ihåg dem.

Här är några som jag använder regelbundet:

Det var det! Allt annat har jag förmodligen lärt mig och sedan glömt eftersom det aldrig får någon användning.

Konfigurera Git(Hub/Lab/Whatevs)

Git kommer på Ubuntu, så det krävs ingen installation. Du kan följa instruktionerna på din valfria källkontrollhoster för att få dina ssh-nycklar skapade och fungerande.

Bemärk att i Github-instruktionerna står det att du ska använda verktyget ”copy” för att kopiera din ssh-nyckel. Ubuntu har kommandot ”xcopy”, men det kommer inte att fungera här eftersom det inte finns någon interop mellan Linux och Windows när det gäller ett klippbräda.

Istället kan du bara använda Windows Clipboard executable och anropa det direkt från terminalen. Du måste hämta texten först med cat och sedan pipa den till Windows klippbord.

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

I Github-dokumentationen står det att du ska se till att ssh-agent körs. Det gör den inte. Du får se detta när du försöker lägga till din nyckel i agenten:

Du kan starta agenten, men nästa gång du startar om Windows eller WSL stoppas måste du starta den igen. Detta beror på att det inte finns något initialiseringssystem i WSL. Det finns inget systemd eller någon annan process som startar alla dina tjänster när WSL startar. WSL är fortfarande under förhandsgranskning och teamet arbetar på en lösning för detta.

Under tiden finns det, tro det eller ej, ett zsh-plugin för detta också. Det heter ssh-agent och är installerat med oh-my-zsh, så allt du behöver göra är att hänvisa till det i .zshrc-filen.

zsh-nvm zsh-autosuggestions ssh-agent git

Detta kommer att starta ssh-agenten automatiskt om den inte är igång första gången du startar WSL. Nackdelen är att den kommer att be dig om din lösenfras varje gång WSL startas på nytt. Det betyder i princip varje gång du startar om datorn.

VS Code och WSL

WSL har inget grafiskt gränssnitt, så du kan inte installera ett visuellt verktyg som VS Code. Det måste installeras på Windows-sidan. Detta innebär ett problem eftersom du har ett program som körs på Windows-sidan som får tillgång till filer på Linux-sidan, och detta kan resultera i alla möjliga konstigheter och ”permission denied”-problem. Som en allmän tumregel rekommenderar Microsoft att du inte ändrar filer på WSL-sidan med Windows-program.

För att lösa detta finns det ett tillägg för VS Code som heter ”Remote WSL”. Detta tillägg är gjort av Microsoft och gör att du kan utveckla i WSL, men inifrån VS Code.

När tillägget är installerat kan du koppla VS Code direkt till Ubuntusidan genom att öppna kommandopaletten (Ctrl + Shift + P) och välja ”Remote-WSL: New Window”.

Detta öppnar en ny instans av VS Code som gör att du kan arbeta som om du vore helt på Linuxsidan. Genom att göra ”File/Open” bläddrar du i Ubuntus filsystem istället för Windows.

Den integrerade terminalen i VS Code öppnar din vackert anpassade zsh-installation. Allt ”bara fungerar” som det ska när du har Remote WSL-tillägget installerat.

Om du öppnar kod från terminalen med code . kommer VS Code automatiskt att upptäcka att den öppnades från WSL och automatiskt koppla in Remote WSL-tillägget.

VS Code Extensions With Remote WSL

Remote WSL-tillägget för VS Code fungerar genom att du installerar en liten server på Linux-sidan och sedan ansluter till den från VS Code på Windows-sidan. Eftersom detta är fallet kommer de tillägg som du har installerat i VS Code inte automatiskt att visas när du öppnar ett projekt från WSL.

Till exempel har jag ett Vue-projekt öppet i VS Code. Trots att jag har alla rätt Vue-tillägg installerade för syntaxmarkering, formatering och liknande, beter sig VS Code som om den aldrig sett en .vue-fil förut.

Alla tillägg som du har installerat kan aktiveras i WSL. Det är bara att hitta det tillägg som du vill ha i WSL och klicka på knappen ”Install in WSL”.

Alla tillägg som är installerade i WSL kommer att visas i en egen sektion i vyn Extensions Explorer. Om du har många tillägg kan det vara lite irriterande att installera varje enskilt tillägg. Om du bara vill installera alla tillägg du har i WSL klickar du på den lilla molnnedladdningsikonen högst upp i avsnittet ”Local – Installed”.

Hur du konfigurerar dina Dev-kataloger

Detta är redan en åsiktsbaserad artikel, så här kommer en som du inte bad om om hur jag tycker att du ska strukturera dina projekt på ditt filsystem.

Jag håller alla mina projekt på Linuxsidan. Jag lägger inte mina projekt i ”Mina dokument” och försöker sedan arbeta med dem från WSL. Min hjärna klarar inte av det.

Jag skapar en mapp som heter /dev som jag lägger i roten av min /home-mapp i Linux. I den mappen skapar jag en annan mapp som har samma namn som min Github-repo: /burkeholland. I den mappen hamnar alla mina projekt – även de som inte skjuts till Github.

Om jag klonar en repo från ett annat Github-konto (t.ex. ”microsoft”) skapar jag en ny mapp i ”dev” som heter /microsoft. Jag klonar sedan repo:n till en mapp inuti den.

I grund och botten efterliknar jag samma struktur som källhanteringen på min lokala maskin. Jag tycker att det är mycket lättare att resonera om var projekten finns och vilka repos de är kopplade till bara genom deras placering. Det är enkelt, men det är mycket effektivt när det gäller att hjälpa mig att hålla allt organiserat. Och jag behöver all hjälp jag kan få.

Bläddring av filer från Windows Explorer

Det finns tillfällen då man behöver komma åt en fil i Linux från Windows-sidan. Det fina med WSL är att du fortfarande kan göra det.

Ett sätt är att komma åt WSL precis som en mappad enhet. Du kommer åt den med en \wsl$ direkt från Utforskaren:

\wsl$

Du kan göra detta av flera olika anledningar. Så sent som idag behövde jag till exempel ett Chrome-tillägg som inte finns i webbutiken. Så jag klonade repo:n i WSL, navigerade sedan till den som en ”Unpacked Extension” och laddade den i Edge.

En sak som jag gör med viss frekvens i Linux är att öppna katalogen som innehåller en fil direkt från terminalen. Du kan göra detta i WSL också genom att direkt anropa explorer.exe. Det här kommandot öppnar till exempel den aktuella katalogen i Windows Explorer.

$ explorer.exe .

Det här kommandot är dock lite omständligt. På Linux är det bara open .. Vi kan göra samma magi genom att skapa ett alias i ~/.zshrc.

alias open="explorer.exe"

Docker

När jag sa att alla verktyg ska finnas på Linux-sidan menade jag det. Det inkluderar Docker.

Det är här som gummit verkligen börjar möta vägen. Vad vi behöver här är Docker, som körs inuti Linux som körs inuti Windows. Det är lite av en rysk nischad docka när man skriver ner det i ett blogginlägg. I verkligheten är det ganska enkelt.

Du behöver rätt version av Docker för Windows. När detta skrivs är det WSL 2 Tech Preview.

När du kör installationsprogrammet frågar det dig om du vill använda Windows-containrar istället för Linux-containrar. Det vill du definitivt. Annars får du inte möjlighet att köra Docker i WSL.

Du kan nu aktivera Docker i WSL genom att klicka på objektet i systemfältet och välja ”WSL 2 Tech Preview”:

När du har startat tjänsten kan du använda Docker i WSL precis som du förväntar dig att kunna göra. Att köra Docker i WSL ger en ganska stor prestandaförbättring, liksom en förbättring av tiden för kallstart av containrar.

Må jag också rekommendera att du installerar Docker-tillägget för VS Code? Det sätter ett visuellt gränssnitt på din Docker-installation och gör det generellt sett bara lättare att arbeta med Docker eftersom du inte behöver komma ihåg alla dessa kommandoradsflaggor och alternativ.

Få mer Bash på Windows

I det här läget bör du ha fått en idé om hur du sätter Bash på Windows, och hur det fungerar när du väl har fått det där. Du kan anpassa din terminal i all oändlighet och det finns alla möjliga häftiga program som du kan lägga till för att göra saker som att automatiskt ställa in PATH-variabler, skapa alias, få en ASCII-ko i din terminal och mycket mer.

Att köra Bash på Windows öppnade upp ett helt nytt universum för mig. Jag kan kombinera Windows som jag älskar för produktivitetssidan och Linux som jag är beroende av som utvecklare. Det bästa av allt är att jag nu kan bygga appar för båda plattformarna med en och samma maskin.

Fortsatt läsning

Du kan läsa mer om Bash på Windows här:

• ”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

Särskilt tack till Brian Ketelsen, Matt Hernandez, Rich Turner och Craig Loewen för deras tålamod, hjälp och vägledning i samband med denna artikel.

(rb, dm, il)