Kommandoradsmiljön

I den här föreläsningen går vi igenom flera sätt att förbättra ditt arbetssätt när du använder skalet. Vi har arbetat med skalet ett tag nu, men främst fokuserat på att köra olika kommandon. Nu ska vi se hur man kör flera processer samtidigt och ändå håller ordning på dem, hur man stoppar eller pausar en viss process och hur man låter en process köra i bakgrunden.

Vi ska också lära oss olika sätt att förbättra skalet och andra verktyg genom att definiera alias och konfigurera dem med dotfiles. Båda delarna kan spara tid, till exempel genom att använda samma konfigurationer på alla maskiner utan att skriva långa kommandon varje gång. Vi tittar också på hur man arbetar med fjärrmaskiner via SSH.

Jobbstyrning

I vissa fall behöver du avbryta ett jobb medan det körs, till exempel om ett kommando tar för lång tid att bli klart (som en find över en mycket stor katalogstruktur). Oftast räcker det att trycka Ctrl-C så stoppas kommandot. Men hur fungerar det egentligen, och varför misslyckas det ibland att stoppa processen?

Döda en process

Ditt skal använder en UNIX-mekanism för kommunikation som kallas signal för att skicka information till processen. När en process får en signal avbryter den körningen, hanterar signalen och kan ändra körflödet utifrån informationen i signalen. Därför är signaler programvaruavbrott.

I vårt fall innebär Ctrl-C att skalet skickar signalen SIGINT till processen.

Här är ett minimalt exempel på ett Python-program som fångar SIGINT och ignorerar den, så att det inte längre stannar. För att döda programmet kan vi i stället använda signalen SIGQUIT genom att trycka Ctrl-\.

#!/usr/bin/env python
import signal, time

def handler(signum, time):
    print("\nI got a SIGINT, but I am not stopping")

signal.signal(signal.SIGINT, handler)
i = 0
while True:
    time.sleep(.1)
    print("\r{}".format(i), end="")
    i += 1

Här är vad som händer om vi skickar SIGINT två gånger till programmet, följt av SIGQUIT. Observera att ^ är hur Ctrl visas när det skrivs i terminalen.

$ python sigint.py
24^C
I got a SIGINT, but I am not stopping
26^C
I got a SIGINT, but I am not stopping
30^\[1]    39913 quit       python sigint.py

Även om SIGINT och SIGQUIT båda vanligtvis är kopplade till terminalrelaterade begäranden är en mer allmän signal för att be en process avsluta snyggt SIGTERM. För att skicka den kan vi använda kommandot kill, med syntaxen kill -TERM <PID>.

Pausa och bakgrundsköra processer

Signaler kan göra annat än att döda en process. Till exempel pausar SIGSTOP en process. I terminalen gör Ctrl-Z att skalet skickar signalen SIGTSTP, kort för Terminal Stop (dvs. terminalens variant av SIGSTOP).

Vi kan sedan fortsätta det pausade jobbet i förgrunden eller i bakgrunden med fg respektive bg.

Kommandot jobs listar de ofärdiga jobben kopplade till den aktuella terminalsessionen. Du kan referera till jobben med deras PID (du kan använda pgrep för att ta reda på den). Mer intuitivt kan du också referera till en process med procenttecken följt av jobbnumret (som visas av jobs). För att referera till det senast bakgrundskörda jobbet kan du använda den särskilda parametern $!.

Ytterligare en sak att känna till är att suffixet & i ett kommando kör kommandot i bakgrunden och ger tillbaka prompten, men kommandot använder fortfarande skalets STDOUT vilket kan vara störande (använd skalomdirigeringar i så fall).

För att bakgrundsköra ett redan körande program kan du trycka Ctrl-Z följt av bg. Observera att bakgrundsprocesser fortfarande är barnprocesser till terminalen och dör om du stänger terminalen (då skickas ännu en signal, SIGHUP). För att förhindra det kan du köra programmet med nohup (ett omslag som ignorerar SIGHUP), eller använda disown om processen redan har startats. Alternativt kan du använda en terminalmultiplexer, som vi ser i nästa avsnitt.

Nedan är en exempelsession som visar några av dessa begrepp.

$ sleep 1000
^Z
[1]  + 18653 suspended  sleep 1000

$ nohup sleep 2000 &
[2] 18745
appending output to nohup.out

$ jobs
[1]  + suspended  sleep 1000
[2]  - running    nohup sleep 2000

$ bg %1
[1]  - 18653 continued  sleep 1000

$ jobs
[1]  - running    sleep 1000
[2]  + running    nohup sleep 2000

$ kill -STOP %1
[1]  + 18653 suspended (signal)  sleep 1000

$ jobs
[1]  + suspended (signal)  sleep 1000
[2]  - running    nohup sleep 2000

$ kill -SIGHUP %1
[1]  + 18653 hangup     sleep 1000

$ jobs
[2]  + running    nohup sleep 2000

$ kill -SIGHUP %2

$ jobs
[2]  + running    nohup sleep 2000

$ kill %2
[2]  + 18745 terminated  nohup sleep 2000

$ jobs

En särskild signal är SIGKILL, eftersom processen inte kan fånga den och den alltid terminerar processen omedelbart. Den kan dock ge otrevliga bieffekter, till exempel att efterlämna föräldralösa barnprocesser.

Du kan läsa mer om dessa och andra signaler här eller genom att skriva man signal eller kill -l.

Terminalmultiplexrar

När du använder kommandoraden vill du ofta köra mer än en sak samtidigt. Du kanske till exempel vill ha redigeraren och programmet igång sida vid sida. Det går att lösa genom att öppna nya terminalfönster, men en terminalmultiplexer är en mer flexibel lösning.

Terminalmultiplexrar som tmux låter dig dela upp terminalfönster i paneler och flikar så att du kan interagera med flera skalsessioner. Dessutom låter terminalmultiplexrar dig koppla loss en aktiv terminalsession och återansluta senare. Detta kan göra arbetsflödet mycket bättre när du arbetar med fjärrmaskiner eftersom du slipper nohup och liknande knep.

Den mest populära terminalmultiplexern i dag är tmux. tmux är mycket konfigurerbar, och med tillhörande tangentbindningar kan du skapa flera flikar och paneler och snabbt navigera mellan dem.

tmux förutsätter att du kan dess tangentbindningar, och de har formen <C-b> x vilket betyder (1) tryck Ctrl+b, (2) släpp Ctrl+b, och (3) tryck x. tmux har följande hierarki av objekt:

För vidare läsning finns här en snabb introduktion till tmux, och här en mer detaljerad förklaring som även täcker det ursprungliga kommandot screen. Du kan också vilja bekanta dig med screen, eftersom det är installerat i de flesta UNIX-system.

Alias

Det kan bli tröttsamt att skriva långa kommandon med många flaggor eller utförliga alternativ. Därför stöder de flesta skal alias. Ett skalalias är en kortform för ett annat kommando som skalet ersätter automatiskt. Ett alias i bash har till exempel följande struktur:

alias alias_name="command_to_alias arg1 arg2"

Observera att det inte får finnas några blanksteg runt likhetstecknet =, eftersom alias är ett skalkommando som tar ett enda argument.

Alias har många praktiska användningsområden:

# Skapa kortformer för vanliga flaggor
alias ll="ls -lh"

# Spara mycket skrivande för vanliga kommandon
alias gs="git status"
alias gc="git commit"
alias v="vim"

# Hjälp dig undvika felstavningar
alias sl=ls

# Skriv över befintliga kommandon för bättre standardvärden
alias mv="mv -i"           # -i frågar före överskrivning
alias mkdir="mkdir -p"     # -p skapar föräldrakataloger vid behov
alias df="df -h"           # -h skriver ut i läsbart format

# Alias kan byggas på varandra
alias la="ls -A"
alias lla="la -l"

# För att ignorera ett alias, kör kommandot med \ först
\ls
# Eller stäng av aliaset helt med unalias
unalias la

# För att visa aliasdefinitionen, anropa det med alias
alias ll
# Skriver ut ll='ls -lh'

Observera att alias inte är beständiga mellan skalsessioner som standard. För att göra ett alias beständigt behöver du lägga det i skalets uppstartsfil, som .bashrc eller .zshrc, vilket vi introducerar i nästa avsnitt.

Dotfiles

Många program konfigureras med vanlig text i filer som kallas dotfiles (eftersom filnamnen börjar med ., t.ex. ~/.vimrc, så att de är dolda i kataloglistningen ls som standard).

Skal är ett exempel på program som konfigureras med sådana filer. Vid uppstart läser skalet många filer för att ladda sin konfiguration. Beroende på skal, och om du startar en inloggningssession och/eller en interaktiv session, kan hela processen vara ganska komplex. Här finns en utmärkt resurs om ämnet.

För bash fungerar det i de flesta system att redigera .bashrc eller .bash_profile. Här kan du lägga in kommandon du vill köra vid uppstart, som aliasen vi just beskrev eller ändringar av miljövariabeln PATH. Faktum är att många program ber dig lägga till en rad som export PATH="$PATH:/path/to/program/bin" i din skalkonfigurationsfil så att deras binärer kan hittas.

Några andra verktyg som kan konfigureras via dotfiles är:

Hur bör du organisera dina dotfiles? De bör ligga i en egen mapp, vara versionshanterade och symboliskt länkas på plats med ett skript. Det ger fördelar som:

Vad ska du lägga i dina dotfiles? Du kan lära dig verktygets inställningar genom att läsa dokumentation på nätet eller manualsidor. Ett annat bra sätt är att söka efter blogginlägg om specifika program där författare berättar om sina favoritinställningar. Ytterligare ett sätt är att titta i andras dotfiles: det finns mängder av dotfiles-kodförråd på GitHub — se det mest populära här (vi rekommenderar dock att du inte kopierar konfigurationer blint). Här finns ännu en bra resurs om ämnet.

Alla kursens lärare har sina dotfiles publikt tillgängliga på GitHub: Anish, Jon, Jose.

Portabilitet

Ett vanligt problem med dotfiles är att konfigurationerna kanske inte fungerar när du arbetar på flera maskiner, t.ex. om de har olika operativsystem eller skal. Ibland vill du också att viss konfiguration bara ska gälla på en viss maskin.

Det finns några knep som gör detta enklare. Om konfigurationsfilen stöder det, använd motsvarigheten till if-satser för att tillämpa maskinspecifika anpassningar. Till exempel kan ditt skal innehålla något i stil med:

if [[ "$(uname)" == "Linux" ]]; then {do_something}; fi

# Kontrollera innan du använder skalspecifika funktioner
if [[ "$SHELL" == "zsh" ]]; then {do_something}; fi

# Du kan också göra det maskinspecifikt
if [[ "$(hostname)" == "myServer" ]]; then {do_something}; fi

Om konfigurationsfilen stöder det, använd includes. Till exempel kan ~/.gitconfig ha inställningen:

[include]
    path = ~/.gitconfig_local

Och på varje maskin kan ~/.gitconfig_local innehålla maskinspecifika inställningar. Du kan till och med versionshantera dem i ett separat kodförråd för maskinspecifika inställningar.

Samma idé är användbar om du vill att olika program ska dela viss konfiguration. Till exempel, om du vill att både bash och zsh ska dela samma uppsättning alias kan du skriva dem i .aliases och ha följande block i båda:

# Testa om ~/.aliases finns och läs in den
if [ -f ~/.aliases ]; then
    source ~/.aliases
fi

Fjärrmaskiner

Det har blivit allt vanligare att programmerare använder fjärrservrar i det dagliga arbetet. Om du behöver fjärrservrar för att driftsätta backend-programvara, eller behöver en server med högre beräkningskapacitet, kommer du att använda Secure Shell (SSH). Som de flesta verktyg vi tar upp är SSH mycket konfigurerbart, så det är värt att lära sig.

För att logga in med ssh på en server kör du ett kommando enligt följande:

ssh foo@bar.mit.edu

Här försöker vi logga in via ssh som användaren foo på servern bar.mit.edu. Servern kan anges med en URL (som bar.mit.edu) eller en IP-adress (något som foobar@192.168.1.42). Senare ser vi att om vi ändrar ssh-konfigurationsfilen kan du ansluta med något i stil med ssh bar.

Köra kommandon

En ofta förbisedd funktion i ssh är möjligheten att köra kommandon direkt. ssh foobar@server ls kör ls i hemkatalogen för foobar. Det fungerar med rör, så ssh foobar@server ls | grep PATTERN kör grep lokalt på fjärrutdata från ls, och ls | ssh foobar@server grep PATTERN kör grep på servern på lokal utdata från ls.

SSH-nycklar

Nyckelbaserad autentisering använder publik nyckelkryptografi för att bevisa för servern att klienten äger den hemliga privata nyckeln utan att avslöja nyckeln. På så sätt behöver du inte skriva lösenord varje gång. Den privata nyckeln (ofta ~/.ssh/id_rsa och på senare tid ~/.ssh/id_ed25519) är i praktiken ditt lösenord, så hantera den därefter.

Generera nycklar

För att generera ett nyckelpar kan du köra ssh-keygen.

ssh-keygen -a 100 -t ed25519 -f ~/.ssh/id_ed25519

Du bör välja en lösenfras för att förhindra att någon som får tag i din privata nyckel kommer åt auktoriserade servrar. Använd ssh-agent eller gpg-agent så att du inte behöver skriva lösenfrasen varje gång.

Om du någon gång har konfigurerat push till GitHub med SSH-nycklar har du sannolikt redan gjort stegen som beskrivs här och har ett giltigt nyckelpar. För att kontrollera om du har en lösenfras och verifiera den kan du köra ssh-keygen -y -f /path/to/key.

Nyckelbaserad autentisering

ssh tittar i .ssh/authorized_keys för att avgöra vilka klienter som ska släppas in. För att kopiera över en publik nyckel kan du använda:

cat .ssh/id_ed25519.pub | ssh foobar@remote 'cat >> ~/.ssh/authorized_keys'

En enklare lösning där det finns stöd är ssh-copy-id:

ssh-copy-id -i .ssh/id_ed25519 foobar@remote

Kopiera filer över SSH

Det finns många sätt att kopiera filer över ssh:

Portvidarebefordran

I många scenarier stöter du på program som lyssnar på specifika portar på en maskin. När det sker på din lokala maskin kan du skriva localhost:PORT eller 127.0.0.1:PORT, men vad gör du med en fjärrserver som inte exponerar sina portar direkt via nätverket/internet?

Detta kallas portvidarebefordran (port forwarding) och finns i två varianter: lokal portvidarebefordran (local port forwarding) och fjärrportvidarebefordran (remote port forwarding) (se bilderna för mer detaljer; bildkredit från detta StackOverflow-inlägg).

Lokal portvidarebefordran Lokal portvidarebefordran

Fjärrportvidarebefordran Fjärrportvidarebefordran

Det vanligaste scenariot är lokal portvidarebefordran, där en tjänst på fjärrmaskinen lyssnar på en port och du vill koppla en port på din lokala maskin till den fjärrporten. Om vi till exempel kör jupyter notebook på fjärrservern och den lyssnar på port 8888, kan vi vidarebefordra den till lokal port 9999 med ssh -L 9999:localhost:8888 foobar@remote_server och sedan öppna localhost:9999 på vår lokala maskin.

SSH-konfiguration

Vi har gått igenom många argument som kan skickas till ssh. Ett lockande alternativ är att skapa skalalias som ser ut så här:

alias my_server="ssh -i ~/.id_ed25519 --port 2222 -L 9999:localhost:8888 foobar@remote_server"

Det finns dock ett bättre alternativ: ~/.ssh/config.

Host vm
    User foobar
    HostName 172.16.174.141
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    LocalForward 9999 localhost:8888

# Konfigurationen kan också använda jokertecken
Host *.mit.edu
    User foobaz

En ytterligare fördel med ~/.ssh/config jämfört med alias är att andra program som scp, rsync, mosh, &c också kan läsa filen och omvandla inställningarna till motsvarande flaggor.

Observera att ~/.ssh/config kan ses som en dotfile, och i allmänhet är det helt okej att ha den tillsammans med resten av dina dotfiles. Men om du gör den publik bör du tänka på vilken information du potentiellt ger främlingar på internet: adress till servrar, användare, öppna portar, &c. Det kan underlätta vissa typer av attacker, så var eftertänksam med att dela din SSH-konfiguration.

Konfiguration på serversidan anges vanligtvis i /etc/ssh/sshd_config. Här kan du göra ändringar som att stänga av lösenordsautentisering, ändra ssh-portar, aktivera X11 forwarding, &c. Du kan ange konfigurationsinställningar per användare.

Övrigt

Ett vanligt problem vid anslutning till fjärrserver är avbrott när datorn stängs av, går i vila eller byter nätverk. Dessutom kan ssh bli frustrerande om anslutningen har märkbar fördröjning. Mosh, mobile shell, förbättrar ssh genom att tillåta roaming-anslutningar, intermittent uppkoppling och intelligent lokalt eko.

Ibland är det praktiskt att montera en fjärrkatalog. sshfs kan montera en katalog på en fjärrserver lokalt, så att du kan använda en lokal redigerare.

Skal och ramverk

I avsnitten om skalverktyg och skriptning använde vi skalet bash eftersom det är överlägset mest utbrett och standardval på de flesta system. Det är dock inte det enda alternativet.

Till exempel är skalet zsh en övermängd av bash och erbjuder många praktiska funktioner direkt:

Ramverk kan också förbättra ditt skal. Några populära generella ramverk är prezto och oh-my-zsh, samt mindre ramverk som fokuserar på specifika funktioner, till exempel zsh-syntax-highlighting eller zsh-history-substring-search. Skal som fish inkluderar många av dessa användarvänliga funktioner som standard. Några sådana funktioner är:

En sak att notera när du använder sådana ramverk är att de kan göra skalet långsammare, särskilt om koden de kör inte är väloptimerad eller om det blir för mycket kod. Du kan alltid profilera och stänga av funktioner du sällan använder eller inte prioriterar högre än hastighet.

Terminalemulatorer

Utöver att anpassa skalet är det värt att lägga lite tid på val av terminalemulator och dess inställningar. Det finns väldigt många terminalemulatorer där ute (här är en jämförelse).

Eftersom du kan komma att tillbringa hundratals till tusentals timmar i terminalen lönar det sig att undersöka inställningarna. Några aspekter du kan vilja ändra i terminalen är:

Övningar

Jobbstyrning

  1. Av det vi har sett kan vi använda kommandon som ps aux | grep för att få fram PID för jobb och sedan döda dem, men det finns bättre sätt. Starta ett jobb sleep 10000 i en terminal, lägg det i bakgrunden med Ctrl-Z och fortsätt körningen med bg. Använd sedan pgrep för att hitta dess PID och pkill för att döda det utan att någonsin skriva PID direkt. (Tips: använd flaggorna -af).

  2. Säg att du inte vill starta en process förrän en annan är klar. Hur skulle du göra det? I den här övningen är den begränsande processen alltid sleep 60 &. Ett sätt att lösa det är att använda kommandot wait. Testa att starta sleep-kommandot och låta ett ls vänta tills bakgrundsprocessen är klar.

    Den här strategin fallerar dock om vi startar i en annan bash-session, eftersom wait bara fungerar för barnprocesser. En funktion som vi inte tog upp i anteckningarna är att kill-kommandots exit-status är noll vid framgång och skild från noll annars. kill -0 skickar ingen signal men ger en exit-status skild från noll om processen inte finns. Skriv en bash-funktion pidwait som tar en PID och väntar tills den processen är klar. Du bör använda sleep för att undvika onödig CPU-förbrukning.

Terminalmultiplexrar

  1. Följ den här tmux-guiden och lär dig sedan några grundläggande anpassningar enligt dessa steg.

Alias

  1. Skapa ett alias dc som blir cd för när du skriver fel.

  2. Kör history | awk '{$1="";print substr($0,2)}' | sort | uniq -c | sort -n | tail -n 10 för att få dina 10 mest använda kommandon och överväg att skriva kortare alias för dem. Obs: detta fungerar för Bash; om du använder ZSH, använd history 1 i stället för bara history.

Dotfiles

Nu ska vi få upp farten med dotfiles.

  1. Skapa en mapp för dina dotfiles och sätt upp versionshantering.
  2. Lägg till konfiguration för minst ett program, t.ex. ditt skal, med någon anpassning (för att börja enkelt kan det räcka att anpassa skalprompten genom att sätta $PS1).
  3. Sätt upp en metod för att snabbt (och utan manuellt arbete) installera dina dotfiles på en ny maskin. Det kan vara så enkelt som ett skalskript som anropar ln -s för varje fil, eller så kan du använda ett specialiserat verktyg.
  4. Testa installationsskriptet på en ny virtuell maskin.
  5. Migrera alla dina nuvarande verktygskonfigurationer till ditt dotfiles-kodförråd.
  6. Publicera dina dotfiles på GitHub.

Fjärrmaskiner

Installera en Linux-virtuell maskin (eller använd en befintlig) för den här övningen. Om du inte är bekant med virtuella maskiner, titta på den här guiden för att installera en.

  1. Gå till ~/.ssh/ och kontrollera om du har ett par SSH-nycklar där. Om inte, skapa dem med ssh-keygen -a 100 -t ed25519. Det rekommenderas att du använder ett lösenord och ssh-agent, mer info här.

  2. Redigera .ssh/config så att den har en post enligt följande

     Host vm
     User username_goes_here
     HostName ip_goes_here
     IdentityFile ~/.ssh/id_ed25519
     LocalForward 9999 localhost:8888
  3. Använd ssh-copy-id vm för att kopiera din ssh-nyckel till servern.
  4. Starta en webbserver i din VM genom att köra python -m http.server 8888. Kom åt VM:ens webbserver genom att öppna http://localhost:9999 på din maskin.
  5. Redigera din SSH-serverkonfiguration med sudo vim /etc/ssh/sshd_config och stäng av lösenordsautentisering genom att ändra värdet på PasswordAuthentication. Stäng av root-inloggning genom att ändra värdet på PermitRootLogin. Starta om ssh-tjänsten med sudo service sshd restart. Försök logga in med ssh igen.
  6. (Utmaning) Installera mosh i VM:en och upprätta en anslutning. Koppla sedan från nätverksadaptern för servern/VM:en. Kan mosh återhämta sig korrekt?
  7. (Utmaning) Ta reda på vad flaggorna -N och -f gör i ssh och hitta ett kommando för att åstadkomma portvidarebefordran i bakgrunden.

Edit this page.

Licensed under CC BY-NC-SA.