next up previous contents
Vidare: Filsystemets uppbyggnad. Uppåt: Att använda Slackware Linux. Tillbaka: Att använda Slackware Linux.

Kommandoskalet.

I en grafisk miljö tillhandahålles gränssnittet av ett program, som skapar fönster, blädderlister, menyer o.s.v. I en kommandoradsmiljö tillhandahålles användargränssnittet såsom ett »skal« (kallas även kommandotolk), vilket tolkar kommandon och i största allmänhet gör saker och ting användbara. Omedelbart efter inloggning (som även skildras i detta kapitel), kommer användaren in i ett skal och tillåtes sköta sina angelägenheter där. Detta kapitel tjänar som introduktion till kommandoskalet och till det allra vanligaste skalet bland linuxanvändare -- Bourne Again Shell (bash). Närmare upplysningar om det, som behandlas i detta kapitel, finns på manualsidan bash(1).

Användare.

Inloggning.

Jaha, då har vi fått igång datorn, och nu stirrar vi på något i stil med detta:

   Welcome to Linux 2.2.16
   darkstar login:

Hmm …  ingen har sagt något om att logga in. Vad är förresten en darkstar? Ingen fara; det är antagligen inte så, att vi har råkat upprätta en radiolänk igenom hyperrymden till Imperiets konstgjorda måne. (Tyvärr stödjer linuxkärnan f.n. inte något protokoll för radiolänkar igenom hyperrymden.) Nej, darkstar är bara namnet på en av våra datorer, och alla nyinstallationer får namnet darkstar, om inget annat valts. Har man angivit något namn på sin dator, när man körde setup, så får man se detta namn i stället för darkstar.

Vad inloggningen anbelangar …  Om detta är första gången, så får man logga in såsom överanvändaren root. Har man valt ett lösenord för root, när man körde setup, så skriver man sedan in detta vid lösenordsprompten. Har man inte valt något sådant, kommer man in utan lösenord och behöver bara trycka på Retur. Saken är klar, nu är vi inne!

root: överanvändaren.

Jaha, vem eller vad är »root«? Och vad gör den/det med vårt system?

Nå, i Unix-världen och i unixliknande operativsystem (såsom Linux) är det skillnad på användare och användare. Vi skall gå närmare in på detta senare, men det, som nu är viktigt att känna till, är att root är en användare, som står över alla användare; root är allsmäktig och allvetande, och ingen trotsar root. Det är helt enkelt inte tillåtet. root är vad vi kallar en »överanvändare«, och det med all rätt. Och det bästa av allt är, att man själv får vara root.

Fint, vad?

Ifall det nu skulle råda något tvivel om den saken: ja, det är mycket bra. Haken är bara den, att root också kan knäcka vad som helst, om han så önskar. I detta sammanhang kan det nog vara nyttigt att hoppa fram till s. gif och läsa om, hur man lägger till användare; sedan kan man skapa en användare, logga in såsom denne och arbeta som denne. Den nedärvda klokskapen i detta är, att man helst bara skall bli överanvändare, när det är fullkomligt nödvändigt, så att man gör risken för att oavsiktligen råka knäcka någonting i systemet så liten som möjligt.

Förresten, om man skulle komma på tanken att vilja bli root, när man redan har loggat in som någon annan, så ställer det inte till med några besvärligheter. Man använder då kommandot su(1). Man avkräves därvid ett lösenord och skriver då in lösenordet för root; därefter får man vara root tills man lämnar rootinloggningen med kommandot exit eller logout. Man kan också tillfälligt uppträda som en annan användare med hjälp av kommandot su, under förutsättning att man vet denne användares lösenord: su logan skulle t.ex. göra läsaren till mig.gif

Kommandoraden.

Köra program.

Det är svårt att åstadkomma särskilt mycket utan att köra något program; kanske skulle man kunna ha datorn till bokstöd eller dörrhållare, och en del datorer avger ett vackert, surrande läte, men mycket mer än så får man inte ut av den. Vi tror, att vi alla kan vara överens om, att datorns användning såsom surrande dörrhållare inte är precis det, som har givit persondatorn den popularitet, den numera åtnjuter.

Vi påminner oss, att allting i Linux är filer. Nå, detta gäller även program. Vartenda kommando, man kör (som inte är inbyggt i skalet), ligger i en fil någonstans. Man kör ett program genom att ange hela dess sökväg.

Ett exempel på detta är kommandot su från föregående avsnitt. Det finns faktiskt i katalogen /bin: /bin/su utför detta.

Vad är det då som gör, att det räcker med att knappa in su? Vi har ju inte talat om, att det ligger i /bin. Det skulle kunnat vara i /usr/local/share, eller hur? Hur kunde det veta, att vi kallade på det? Svaret ligger i miljövariabeln PATH; de flesta skal har endera PATH eller någonting, som är mycket likt PATH. Det innehåller en förteckning över kataloger, som skall genomsökas efter program, man försöker köra. Så när vi körde su, genomsökte skalet sin kataloglista och letade därvid efter en körbar fil vid namn su; den första med detta namn, det träffade på, kördes. Detta inträffar var gång, man kallar på ett program utan att ange dess fullständiga sökväg; om man får felmeddelandet Command not found, finns det sökta programmet inte i PATH. (Det gäller förstås även, om programmet inte alls finns till … ) Vi skall gå djupare in på miljövariabler i avsnittet om The Bourne Again Shell (bash) på s. gif.

Man skall även komma ihåg, att ».« är en förkortning för »den katalog, jag befinner mig i«, så om man hade råkat befinna sig i /bin, så skulle ./su ha fungerat som fullständig sökväg.

Jokertecken (wildcards).

Nästan alla skal erkänner vissa tecken såsom ersättningar eller förkortningar för »vad som helst kan stå här«. Sådana tecken kallas lämpligt nog för »jokertecken« (»wildcards«); de vanligaste är * och ?. Frågetecknet ? står vanligen för ett enstaka tecken. Vi kan t.ex. anta, att en katalog innehåller tre filer: ex1.txt, ex2.txt och ex3.txt. Alla dessa filer vill vi kopiera (med kommandot cp, som vi behandlar i avsnittet cp på s. gif) till en annan katalog, låt oss säga /tmp. Att slå cp ex1.txt ex2.txt ex3.txt /tmp är alldeles för arbetsamt. Det är mycket lättare att slå cp ex?.txt /tmp; frågetecknet ? passar in på vart och ett av tecknen »1« »2« och »3«, så att de i tur och ordning ersätter frågetecknet.

Är detta också för arbetsamt? Riktigt. Det är upprörande; vi har väl arbetarskyddslagar till att bevara oss ifrån dylikt. Lyckligtvis har vi även stjärnan (asterisken) *. Såsom tidigare nämnts, träffar * »vilket antal tecken som helst« inberäknat noll. Vore de tre filerna ensamma i katalogen, så skulle vi ha kunnat kommendera cp * /tmp och hade då svept allesamman i ett drag. Antag emellertid, att katalogen även innehållit filen exempel.txt och filen hejaz.txt. Vi ville kopiera exempel.txt men inte hejaz.txt; cp exempel* /tmp skulle utföra detta.

Omdirigering av inmatning/utmatning; rörledning.

 

(Här kommer något finurligt.)

   $ ps > blargh
Här kör vi ps för att se vilka processer, som är igång; ps behandlas på s. gif. Nu är det inte det, som är så listigt. Det finurliga är > blargh, vilket ungefär betyder »ta utmatningen ifrån ps och skriv den till en fil vid namn blargh«. Vänta bara, det blir ännu finurligare.

   $ ps | less
Detta kommando tar utmatningen ifrån ps och »trattar« in det i en rörledning (pipe) till less, så att vi bekvämt kan bläddra framåt och bakåt i den.

   $ ps >> blargh
Denna omdirigering kommer på tredje plats ibland de vanligaste; den gör samma sak som »>« förutom det, att »> >« lägger till utmatningen ifrån ps på slutet i filen blargh, om nämnda fil finns till. Om den inte redan finns, så skapas den, liksom i fallet med »>«. (»>« skulle skriva över innehållet i blargh med nytt innehåll.)

Det finns även ett »<«, som betyder »hämta inmatning ifrån det, som följer här efter«, men detta tecken användes inte så ofta.

   $ fromdos < dosfile.txt > unixfile.txt
Omdirigeringen blir riktigt skojig, när man radar upp kommandon och argument:

   $ ps | tac > > blargh
Detta kör ps, kastar om inmatningen och lägger den till filen blargh. Man kan stapla så många sådana led ovanpå varandra, som man önskar; man skall bara vara noga med att komma ihåg, att de tolkas ifrån vänster till höger.

Se manualsidan för bash(1) beträffande närmare upplysningar om omdirigering.

Bash (Bourne Again Shell).

 

Miljövariabler.

 

Ett linuxsystem är en invecklad skapelse; där är mycket att hålla reda på och en mängd smådetaljer, som sättes igång vid vår vanliga samverkan med olika program (varav man inte ens är medveten om en del). Ingen människa vill väl använda en rad växlar (flaggor) till vartenda program, som skall köras, eller behöva tala om för det vilken slags terminal, man använder, datorns värdnamn, hur prompten skall se ut … 

För att hantera detta har användaren det, som kallas omgivning eller miljö (environment). Miljön avgränsar de villkor, varunder programmen skall köras, och en del av denna avgränsning är variabel; användaren kan ändra den och leka med den, som sig bör i ett linuxsystem. Nästan vartenda skal har miljövariabler (i annat fall är det förmodligen inget särskilt användbart skal). Här skall vi lägga fram en översikt över de kommandon, som bash tillhandahåller för manipulering av sina miljövariabler.

   $ set
set utan flaggor (växlar) visar alla miljövariabler, som är satta, såväl som deras värden. Såsom det är vanligt med inbyggda kommandon i bash kan det även mycket annat (med parametrar); vi överlämnar dock åt manualsidan för bash(1) att täcka det. Ett utdrag ur utmatningen ifrån set på en av våra datorer ser ut så här:

   PATH=/usr/local/lib/qt/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:
   /usr/openwin/bin:/usr/games:.:/usr/local/ssh2/bin:/usr/local/ssh1/bin:
   /usr/share/texmf/bin:/usr/local/sbin:/usr/sbin:/home/logan/bin
   PIPESTATUS=([0]="0")
   PPID=4978
   PS1='\h:\w\$ '
   PS2='> '
   PS4='+ '
   PWD=/home/logan
   QTDIR=/usr/local/lib/qt
   REMOTEHOST=ninja.tdn
   SHELL=/bin/bash

Lägg märke till den tidigare omtalade variabeln PATH; Vi kan köra vad som helst i de angivna katalogerna genom att enbart knappa in filnamnet.

   $ unset VARIABEL
unset avlägsnar variabler och tar därvid bort såväl variabel som dess värde; bash glömmer, att variabeln någonsin funnits till. (Ingen fara. Om det inte gäller någon variabel, man uttryckligen definierat i under körningen av skalet, så kommer den variabeln förmodligen att definieras på nytt i vilken annan körning som helst.)

   $ export VARIABEL=något_värde
Det är behändigt att exportera. När man gör detta, så ger man variabeln VARIABEL värdet »något_värde«; om VARIABEL inte redan finns, så skapas den. Om VARIABEL redan hade haft ett värde, så är det gamla värdet nu borta. Det är inte så bra, om man försöker lägga till en katalog i variabeln PATH. I så fall vill man förmodligen hellre göra något i stil med detta:

   $ echo $PATH
   /usr/local/lib/qt/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:
   /usr/openwin/bin:/usr/games:.:/usr/local/ssh2/bin:/usr/local/ssh1/bin:
   /usr/share/texmf/bin:/usr/local/sbin:/usr/sbin:/home/logan/bin

Tabulatorkomplettering.

(Här kommer ytterligare något finurligt.)

  1. Ett kommandoradsgränssnitt medför, att man måste skriva en hel del.
  2. Det är arbetsamt att skriva.
  3. Ingen tycker om att arbeta.

Av punkterna 3 och 2 drar vi slutsats 4, att ingen tycker om att skriva. Lyckligtvis räddar oss bash ifrån punkt 5 (att ingen tycker om kommandoradsgränssnitt).

Hur fullgör bash denna underbara bedrift, frågar man sig? Svaret är, att bash förutom det ovan skildrade utnyttjandet av jokertecken dessutom innehåller »tabulatorkomplettering«.

Tabulatorkomplettering fungerar ungefär på följande vis: Man skriver ett filnamn. Kanske finns det i PATH, kanske skriver man ut hela namnet med fullständig sökväg. Man behöver då endast skriva tillräckligt mycket av filnamnet, för att det skall vara unikt identifierbart. Därefter slår man an tabulatortangenten. Då funderar bash ut, vad man vill, och skriver ut resten av filnamnet!

Exempel: /usr/src innehåller två underkataloger: /usr/src/linux och /usr/src/sendmail. Vad finns i då i /usr/src/linux?

Vi skriver ls /usr/src/l och slår an tabulatortangenten, så ger bash oss ls /usr/src/linux.

Antag nu, att det finns två underkataloger, som heter /usr/src/linux och /usr/src/linux-old; Om vi skriver /usr/src/l och slår an tabulatortangenten, så fyller bash i återstoden, så att vi får /usr/src/linux. Vi kan stanna där, eller också kan vi slå an tabulatortangenten en gång till, så att bash visar en förteckning över de kataloger, vars namn passar in på det, som hittills matats in.

Mindre knappande, således (och följaktligen kan folk tycka om kommandoradsgränssnitt).

Virtuella terminaler.

Man är mitt uppe i arbetet och inser, att man behöver göra något annat. Man skulle kunna släppa, vad man har för händer, och börja på något annat, men vi arbetar ju i ett fleranvändarsystem, eller hur? Då kan väl en viss användare också logga in flera gånger, om han så vill? Varför skulle man då behöva göra endast en sak åt gången?

Det behöver man inte. Vi kan inte alla ha flera tangentbord, möss och bildskärmar till varenda maskin; antagligen vill de flesta av oss heller inte ha det så. Lösningen ligger således inte i maskinvara. Återstår programvaran, och Linux visar en av sina starka sidor här genom att tillhandahålla »virtuella terminaler« (VT).

Genom att trycka på tangenten Alt och någon av funktionstangenterna, kan man växla mellan virtuella terminaler; var funktionstangent motsvarar en virtuell terminal. Slackware är förinställt för inloggningar på 6 VT. Med Alt+F2 kommer man till den andra, Alt+F3 till den tredje o.s.v. upp till F6.

Återstående funktionstangenter är förbehållna X-sessioner. Var X-körning använder en VT med början på den sjunde (Alt+F7) och uppåt. När man är inuti X, så ersättes därvid kombinationen Alt+Funktionstangent med Ctrl+Alt+Funktionstangent; om man är i X och vill komma tillbaka till textinloggningen (utan att stänga X-körningen), så kommer man till tredje textinloggningen med Ctrl+Alt+F3. Med Alt+F7 kommer man in i X igen, förutsatt att det är första X-sessionen, som användes.

Sammanfattning.

Detta kapitel har behandlat användare, skalet, kommandoraden och virtuella terminaler. Man bör nu finna sig väl till rätta med arbete på kommandoraden, med att köra program samt använda rörledningar (piping) och omdirigeringar till att kombinera kommandon. Slutligen bör man ha en uppfattning om rootanvändarens makt, och varför det är dåligt att alltid köra som root.


next up previous contents
Vidare: Filsystemets uppbyggnad. Uppåt: Att använda Slackware Linux. Tillbaka: Att använda Slackware Linux.


Denna översättning ifrån engelskan är utförd av Erik Jonsson <[email protected]> efter Slackware Linux Essentials, officiell handbok för Slackware Linux.

Denna översättning tillhandahålles liksom engelskspråkiga originalet enligt villkoren i GNU General Public License (GPL).
Uppgifterna om författarnas och översättarens namn får ej avlägsnas, utplånas eller eljest göras oläsliga.
Förvaras åtkomligt.
Bäst före: senaste ändringsdatum.
Äldre versioner bör förstöras.
Senast ändrad Tue Oct 24 09:36:13 CEST 2000

Hela boken finns här även beredd för utskrift i PDF-filen slwhbk.pdf.

http://www.slackware.com/http://www.sslug.dk/Ser bra ut i vilken vävläsare som helst.


Generaldepoten — Emil Tusens Kulturpalats.
Om goda kagor och torra kakor (»cookies«).

Innehåll:

Litteraturförteckning

Om goda kagor och torra kakor (»cookies«).