Att byta från Windows till UNIX/Koncept

Arbetet på boken har endast påbörjats. Vissa kapitel kan vara användbara, men helheten är mycket bristfällig.

Del III – Unix-koncept

X Window System

Den grafiska miljön i Unix tillhandahålls genom en uppsättning program skilda från operativsystemkärnan.

Kommunikationen med skärmkortet sköts av X Window System (ofta kallat X, eller X11 enligt versionsnumret), som har egna drivrutiner för detta. Program kan kommunicera med X-servern antingen över nätet eller genom olika lokala mekanismer. X påbjuder inga konventioner vad gäller själva användargränssittet.

Ett skillt fönsterhanteringsprogram sköter om att placera olika fönster på skärmen, rita ramarna runt fönstren, avgöra vilka fönster som skall vara i förgrunden och ge tangentbordsfokus åt de olika fönstren. Det finns ett otal olika fönsterhanteringsprogram med diverse avancerade funktioner.

Numera använder man i allmänhet en skrivbordsmiljö, som erbjuder en uppsättning program med enhetligt utseende (vilket kan väljas genom ett tema) och mer eller mindre enhetliga konventioner, olika mekanismer för kommunikation mellan programmen o.s.v. En skrivbordsmiljö erbjuder normalt ungefär vad en Windows-användare förväntar sig hitta på sin dator.

Ingenting hindrar att man installerar fler skrivbordsmiljöer eller använder program i kors mellan dessa. Konventionerna skiljer sig dock på flera punkter och användning i kors kan skapa åtminstone viss förvirring. Om en viss skrivbordsmiljö installerats med operativsystemet kan det löna sig att till att börja med hålla sig till denna i de sammanhang där god integration är viktig.

Det finns många grafiska program som inte skrivits för någon skrivbordsmiljö. De kan till utseendet skilja sig från den övriga miljön och följer sannolikt inte alla inställningar som görs via skrivbordsmiljöns verktyg. Samma kan gälla program skrivna för en annan skrivbordsmiljö. Detta är normalt inget problem och skall inte uppfattas som att systemet inte fungerar.

Kommandotolken

UNIX ger möjlighet att använda en mängd "kommandoradsverktyg". Bland UNIX-användare ses det ibland som en självklarhet att man kan hantera kommandoraden, medan det inte är lika självklart för den som är van med MS Windows. Kommandoraden finns tillgänglig i den grafiska miljön genom någon ikon eller något menyalternativ som heter "Terminal", "XTerm", "Console" eller liknande. Den nås också genom att logga in i icke-grafiskt läge.

Alla program som finns i ditt system, även de grafiska, kan startas via kommandoprompten. Grafiska program (eventuellt körda på en annan dator) kommer att fråga din X-server om de får öppna ett fönster på din dator, och om det är OK, så startas programmet med ett eget fönster.

Exempel 1 Program kan startas från kommandoraden, här firefox med en webbadress och anvisning om att kommandotolken inte skall vänta på att programmet kört slut utan direkt fortsätta ta emot nya kommandon:

firefox http://sv.wikibooks.org &

Exempel 2 Kommandoradsverktygen passar i synnerhet för att manipulera textsträngar. Här visas rader som inleds med textsträngen "20091007 " i "johans" datafiler från förra veckan (3–10 dagar gamla) i arbetskatalogen och dess eventuella underkataloger:

find . -iname *.dat -user johan -mtime -10 -mtime +3 \

-print0 | xargs -0 grep '^20091007 ' /dev/null

Mer avancerad kommandoradskod kräver erfarenhet eller användande av referensmanualen, men å andra sidan kan mycket komplicerade uppgifter ofta skötas med några rader kod, som vid behov kan återanvändas, direkt eller med de ändringar situationen kräver.

I det andra exemplet visas konceptet med "pipes": resultaten från ett kommando ges vidare åt nästa, vilket betyder att funktionaliteten i ett program lätt kan användas av andra. I det här fallet används filnamnen hittade med "find" som argument för programmet "grep", som i sin tur söker textsträngar (här behövs klisterprogrammet "xargs", för att "grep" inte skulle söka bland själva filnamnen, och flaggan -0 för att eventuella blankslag i filnamnen skall hanteras rätt). Resultatet kunde styras vidare till exempel för sortering. Istället för "grep" kunde man använda ett program som manipulerar de hittade filerna enligt givna regler.

Ofta används kommandotolken bakom kulisserna också vad gäller till exempel skrivbordsomgivningarna: en ikon kan vara kopplad till en kommandorad som i sin tur finns i klartext i en konfigurationsfil. Kommandoraden kan anpassa argumenten programmet startas med och modifiera programmets omgivning innan det startas, vid behov på komplicerade sätt.

Se vidare i Del IV – Kommandotolken

Filer

Det sägs ofta att allt i Unix är filer. ...

De flesta enheter finns i Unix filträd i form av speciella filer, vanligen under /dev. Dessa motsvarar LPT & co under Windows, men själva namnet är inte magiskt i Unix. Också katalogerna är i princip vanliga filer, som innehåller en lista på filnamn, pekare i form av inod-numret och eventuellt information om filtypen.

Filträdet

Unix använder bara ett enhetligt filträd. Alla filer finns under roten, som betecknas ”/”. Olika enheter kan anslutas var som helst i filträdet, med en katalog som anslutningspunkt (varvid katalogens eventuella innehåll blir otillgängligt). Enhetsbokstäver används inte.

Användarna har var sin hemkatalog och behöver i allmänhet inte bry sig om resten av filträdet, utom vad gäller tillfälligt anslutna enheter och eventuella speciella datakataloger, såsom för en lokal webbservers www-filer. I hemkatalogen finns ”dolda” konfigurationsfiler för olika program (skrivbordsmiljöerna och vissa andra Windows-inspirerade program har dolda filträd med mycket innehåll som inte direkt är konfigurationsdata). I övrigt får användaren fritt strukturera innehållet i hemkatalogen.

Det övriga filträdet följer till största delen väl etablerade standarder, med en klar arbetsfördelning mellan de olika katalogerna. Strukturen kan te sig onödigt komplicerad, men har dels en del historisk barlast, dels är den avsedd att kunna fungera i helt olika typer av miljöer. En del kataloger kan finnas på filservrar och därmed vara gemensamma för flera olika datorer, ibland med olika operativsystem, en del kataloger är avsedda att kunna vara skrivskyddade och en del skall kunna ha filsystem anpassade för speciell användning.

Här förklaras de viktigaste katalogerna enligt GNU/Linux' File Hierarchy Standard. De flesta Unix-system följer i princip samma logik men en del kataloger eller filer kan finnas på helt andra ställen.

Direkt under roten finns de filer som skall vara tillgängliga genast vid uppstart och i problemsituationer. Till dessa hör /etc med konfigurationsfiler, /dev med filer som representerar fysiska (och vissa andra) enheter, t.ex. hårddiskar och konsol, /bin och /sbin med central programvara, /lib med nödvändiga programbibliotek och root-användarens hemkatalog /root. /boot, med operativsystemkärna och andra filer som behövs för att överhuvudtaget få igång systemet, finns ofta på en skild partition som inte nödvändigtvis behöver vara ansluten vid normaldrift.

/home innehåller användarnas hemkataloger, i större system ofta i underkataloger (t.ex. enligt användarnamnets första bokstav) för att hålla de enskilda katalogerna hanterliga. En vanlig användare behöver sällan bry sig om filer utanför hemkatalogen. Hemkatalogen är ofta gemensam för de flesta Unix-maskiner på en institution, också då flera Unix-varianter används.

/usr innehåller det mesta av operativsystemet i ett antal underkataloger. /usr/bin innehåller programfilerna, /usr/sbin programfiler som normalanvändare inte behöver (grafiska administrationsprogram etc.), /usr/lib programbibliotek och liknande, /usr/share filer som kan delas mellan olika datorarkitekturer, t.ex. /usr/share/man för referensmanualen och /usr/share/doc för diverse dokumentation. /usr/local innehåller i princip filer lokala för maskinen ifråga, men i praktiken filer som inte hör till operativsystemet, i synnerhet programvara som kompilerats lokalt men skall kunna användas av mer än enskilda användare.

/opt används i en del system för större programhelheter som inte hör till operativsystemet, till exempel kommersiell tredjepartsprogramvara. Enskilda programpaket installeras i allmänhet i egna kataloger (à la /opt/matlab för Matlab), medan /opt/bin innehåller de länkar som behövs för att kunna köra programmen utan att bry sig om de enskilda katalogerna.

/var innehåller kataloger som inte kan hållas skrivskyddade. Här finns köer för olika servrar (/var/mail för e-post, /var/spool/lp för skrivarjobb), /var/games för bl.a. bästa resultat i spel, /var/cache för diverse mellanlagring, /var/lib för olika programs statusfiler, /var/run för servrars processnummer o.s.v.

/tmp och /var/tmp innehåller tillfälliga filer. Alla har rätt att skriva här, men inte att stryka varandras filer. Användare behöver sällan bry sig om dessa kataloger, men om utrymmet inte räcker till kan man styra /tmp-användningen till en annan katalog genom omgivningsvariabeln TMP. Ibland är /tmp ett virtuellt filsystem i primärminnet.

/dev, /proc, /sys och ett antal andra kataloger kan genereras av operativsystemkärnan eller andra system enligt behov och alltså vara utan koppling till fysiska hårddiskar. Förutom /dev, som motsvarar vad som finns på rotpartitionen kompletterat med upptäckt hårdvara, varierar innehållet kraftigt från system till system.

CD-skivor och USB-minnen

Tillfälligt anslutna enheter, såsom CD-skivor och USB-minnen, ansluts nuförtiden ofta automatiskt till kataloger som skapas i /media. Traditionellt har /mnt eller kataloger under /mnt använts. Också kataloger direkt under roten förekommer (/cdrom eller dylikt).

För att en enhet skall kunna anslutas måste administratören ha bestämt var, hur och av vem den får anslutas. I en del system sköter installationsprogrammet om vettiga förval för de flesta situationer, i andra måste detta skötas helt för hand.

Programfiler

Programfilerna eller länkar till programfilerna finns oftast i ett litet antal kataloger. Dessa kataloger är uppräknade i omgivningsvariabeln PATH och program i katalogerna kan köras vid namn, utan att man bryr sig om i vilken av katalogerna de finns. Typiska sådana kataloger är /bin, /usr/bin, /usr/local/bin, /opt/bin och ~/bin. Om man vill köra ett program som inte finns i någon av dessa kataloger kan man antingen ange katalogen explicit då man kör programmet eller lägga till katalogen i PATH, tillfälligt eller genom lämplig konfigurationsfil.

Ibland finns fler program med samma namn. I så fall kan man antingen ändra ordningen i PATH eller ange katalogen explicit då man enstaka gånger vill använda en viss version. Man kan också lägga en symbolisk länk i sin egen ~/bin och se till att den katalogen finns tidigt i PATH. Sådana länkar kan användas också för enskilda administrationsprogram man behöver

Det finns flera typers programfiler i Unix och dessa känns igen på ett magiskt nummer i början av filen. Normalt är två typer av intresse: kompilerade program och skript. De senare är textfiler i ett format som förstås av ett egentligt program, till exempel av någon kommandotolk eller någon tolk för ett programspråk såsom perl eller python.

För att ett program skall uppfattas som ett program skall det finnas i en viss katalog eller anropas med katalogen angiven (för program i arbetskatalogen skriver man "./filnamn") och man måste ha rätt att exekvera filen. Ifråga om skriptfiler skall de i de flesta fall inledas med den magiska sekvensen ”#!” följd av en angivelse av den kommandotolk som skall användas. Extensioner à la .EXE används sällan och påverkar inte programmets status.

Konfigurationsfiler

Konfigurationsfiler kan mycket olika. Det finns ändå vissa konventioner och ofta använd praxis.

Vad som i Windows konfigureras i registret konfigureras i Unix i små textfiler, till största delen under /etc. Många av filerna, i synnerhet de som sköter uppstarten av systemet är skript för kommandotolken (oftast /bin/sh). En del filer innehåller värdetilldelning för olika variabler som sedan används av de egentliga skripten.

...

Textfiler

Det finns en uppsjö små verktygsprogram avsedda att användas via kommandotolken. Dessa hanterar ofta datat rad för rad och är i första hand tänkta för data i textformat. Så snart något kan uppfattas som en textfil kan det manipuleras mycket enkelt och mångsidigt. Därför undviker man binärfiler, utom då sådana är klart mer ändamålsenliga.

Själva operativsystemkärnan gör inte skillnad mellan textfiler och binärfiler. Windows har en del magi vad gäller radbyte och filslut. I Unix slutar en rad med nyrad (ASCII LF), inte med nyrad och vagnretur och nyrad (ASCII CR+LF) som i Windows. CTRL-Z (ASCI SUB) har ingen speciell betydelse i Unix-filer.

Filers väsen

Filer har en annan uppbyggnad i Unix än Windows-användare är vana vid. Skillnaderna har inte nödvändigtvis betydelse för vanlig användning, men kan vara mycket förvirrande då de ger sig till känna.

En fils namn anges i de kataloger där filen finns. Övrig metainformation, såsom filtyp, ägare, storlek och pekare till datablocken finns i en inod (eng. i-node). Filoperationer görs via i-noden och det är i princip omöjligt att ta reda på en fils namn utgående från inod-numret: filen kan ha döpts om, den kan förekomma under flera namn eller den kan ha strukits ur alla kataloger.

En fil försvinner inte från filsystemet då den stryks ur en katalog, först då inga referenser till den längre förekommer. Det betyder att en fil kan ersättas med en ny version utan att störa program som redan öppnat filen. De fortsätter att använda versionen de öppnat. Det finns alltså en subtil men väsentlig skillnad mellan att ersätta en fil med en annan och att ändra i filens innehåll.

Programinstallation

Till distributionen hörande programvara

...

Gratisprogram och fri programvara

Då en stor del av Unix-användarna varit programmeringskunniga, kompilator och programmeringsverktyg varit standardkomponenter och de olika Unix-varianterna inte är binärt kompatibla så är det normalt att användarskapad programvara distribueras som källkod. Mottagaren har ansvar för att anpassa programmet till den egna omgivningen, om denna inte redan stöds automatiskt, och kan lägga in förbättringar han eller hon behöver. Många av förbättringarna införlivas i den ursprungliga versionen.

Med rörelsen för fri programvara har denna tradition stärkts än mera. Många, i synnerhet avancerade användare, drar sig för att installera program de inte har kontroll över. Denna skepsis och problemet att anpassa ett program till många plattformer man inte själv har tillgång till innebär att av amatörer skriven gratis programvara utan källkod (freeware) är mycket sällsynt i Unix.

Den som skrivit ett program tillhandahåller ofta färdigkompilerade versioner för ett antal olika plattformer och Linux-distributionerna tillhandahåller likaså färdigt kompilerade paket. Källkoden finns dock nästan alltid tillgänglig för icke-kommersiell (och ofta också för kommersiell) programvara.

Några större gratisprogram värda att nämna är Opera, Adobes Acrobat och Macromedia Flash (numera också Adobes). Java är delvis, men ännu inte helt, fri programvara. Fria webbläsare och PDF-program finns det gott om. Däremot är de fria alternativen för Java och Flash ännu inte färdiga; de kan användas för en del ändamål, men motsvarar inte de slutna versionerna.

Andra kategorier av ofria gratisprogram är drivrutiner för hårdvara samt ...

Kommersiell programvara

Det finns en hel del kommersiell programvara för Unix. ...

Kompilering

Programvara för Unix är ofta anpassad att enkelt kunna kompileras för ett antal olika plattformar. Att göra mindre ändringar och därefter själv kompilera programvaran kräver – om den egna plattformen stöds – i allmänhet inte större färdigheter. Kompilator och andra verktyg är standardkomponenter i de flesta system.

Källkod och fri programvara

Unix har sina rötter i olika forskningsinstitutioner. Den första tiden hade normalt alla användare tillgång till källkoden till alla program och möjlighet att utveckla dem enligt lokala behov.

Förhållandena ändrades då Unix blev en kommersiell produkt, men fortfarande var Unix-administratörer vana att själva kunna lösa många problem i programvaran. Också bland vanliga användare var en stor del programmeringskunniga och det var vanligt att dela med sig av sina program.

Eftersom Unix kördes på många olika typers maskiner var det inte ändamålsenligt att sprida egna program i binärformat, färdiga att köras, utan spridningen skedde som källkod, som måste kompileras före användning. Före kompileringen måste man ofta anpassa koden till egenheterna på den egna maskinen och att senare införa förbättringar och kompilera om koden var enkelt och naturligt.

Med rörelsen för fri programvara, som uppstod i början av 1980-talet med Richard M. Stallman och Free Software Foundation, blev det åter möjligt att ha källkod till de flesta program man använde. Versionerna utvecklade av FSF var ofta mångsidigare än versionerna som kom med operativsystemet och användes allmänt också av helt pragmatiska skäl. Programmeringsverktygen från FSF gav också mycket gott stöd för portning, så att fri programvara har spridits till en mängd exotiska plattformar, som annars aldrig haft ett motsvarande programutbud.

Filosofin kring och fördelarna med fri programvara kändes mycket naturliga i Unix-kretsarna. Gratisprogram, i den mening de florerar i Windowsvärlden, har förblivit främmande för de flesta Unix-användare.

Språk- och landsinställningar

Unix är ett månganvändarsystem och användarna kan befinna sig i olika delar av världen. Därför används UTC för systemklockan och program installeras inte normalt i olika språkversioner. Språk och tidszon hanteras genom inställningar som kan ändras enligt användarnas godtycke.

Systemets tidszon och språk och förval för användarna anges skillt i konfigurationsfilerna. Vad som gäller för ett visst program bestäms av värdet på vissa miljövariabler då programmet startas. Olika sessioner av ett program kan alltså ha olika inställningar.

Skrivarsystemet

[utökas och skrivs om]

Eftersom Unix är ett fleranvändarsystem måste skrivaren hanteras av en serverprocess. Denna har traditionellt tagit emot skrivarjobben, lagt dem i en kö och skickat dem till skrivaren i tur och ordning, samtidigt som den hanterar fakturering för jobben etc. Jobben skickades till skrivarservern i en form som skrivaren kunde tolka, sedan länge postscript. De enskilda tillämpningsprogrammen måste alltså sköta konverteringen till detta format. Valet av postscript innebär att postscript och pdf är väl stödda på Unix.

Skrivarna behöver inte vara kopplade till den dator skrivarservern finns på utan servrarna skickar servrarna jobben till varandra. Numera klarar skrivarservern ofta av att vid sidan av postscript förvandla många andra format till det skrivaren förstår.

• System V: lp
• BSD: lpr, lprng
• Nytt: CUPS/ipp