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).
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!
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. 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.
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. .
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.
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. ) 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.
(Här kommer något finurligt.)
$ ps > blarghHär kör vi ps för att se vilka processer, som är igång; ps behandlas på s. . 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 | lessDetta 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 >> blarghDenna 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.txtOmdirigeringen blir riktigt skojig, när man radar upp kommandon och argument:
$ ps | tac > > blarghDetta 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.
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.
$ setset 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 VARIABELunset 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ärdeDet ä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
(Här kommer ytterligare något finurligt.)
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).
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.
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.
Om goda kagor och torra kakor (»cookies«).
Om goda kagor och torra kakor (»cookies«).