Kapitel 11. Program Skript Att köra program Interpreterande och kompilerande programspråk

Transkript

1 Kapitel 11 Program Ett datorprogram är en samling instruktioner som beskriver något som en dator ska utföra Skript Om man lägger flera skalkommandon efter varann i en fil blir det ju en samling instruktioner som beskriver något som en dator ska utföra. Detta kallar man ett skalskript (shell script). Man kan köra det genom att skriva bash filnamn eller sh filnamn. Genom att ge ett filnamn som argument till skalet (bash) talar man om att det ska hämta kommandon därifrån. (Standardnamnet för skalet i Unix är sh, men i GNU är det liktydigt med bash.) 11.2 Interpreterande och kompilerande programspråk De flesta program man kör är dock inte textfiler utan binärfiler. De innehåller då instruktioner i en maskinnära form (maskinkod) som kan utföras (exekveras, köras) direkt av datorn. Med datorprogram kan man avse både en sådan binärfil, och även källkoden, så som programmet skrivits i något programspråk i en eller flera textfiler. I de flesta programspråk skriver man instruktioner som ligger långt ifrån den typen av instruktioner som datorn kan utföra direkt. Det finns olika sätt att då få datorn att utföra instruktionerna i källkoden: kompilering och interpretering. Kompilering är att översätta källkoden till maskinkod. Översättningen sker med en kompilator ett särskilt program. Sen kör man den resulterande koden. (Källkoden behövs inte längre för att kunna köra programmet. Men om man behöver göra ändringar i programmet behöver man källkoden igen och får lov att kompilera om den efteråt.) Interpretering är att tolka källkoden bit för bit istället, så som skalet tolkar kommandon i ett skalskript. Ett särskilt program, en interpretator, läser och utför dessa instruktioner. (Det finns även mellanlägen mellan kompilering och interpretering.) 11.3 Att köra program Programmen är filer de också. Om man t. ex. kör bildbearbetningsprogrammet Gimp så är det filen /usr/bin/gimp man kör. Det skulle gå att skriva den fullständiga sökvägen /usr/bin/gimp för att köra det programmet, men det räcker med bara gimp. Om man skriver bara ett namn utan katalog så letar nämligen skalet efter en sådan fil i vissa kataloger (däribland bland annat /bin och /usr/bin). Om programfilen inte ligger i en av dessa kataloger måste man skriva ett längre filnamn där man tar med katalogen. Om programmet foo ligger i ens aktuella katalog är det kortaste sättet att skriva./foo med beteckningen. för aktuell katalog. För att man ska kunna köra en sådan programfil måste man ha rättigheter att köra filen (se avsnitt 1.10). Kompilatorer sätter den rättigheten automatiskt på de filer de skapar. Ett interpreterande program är en textfil och kan inte köras utan information om vilket språk den är skriven i, det vill säga vilken interpretator som ska tolka kommandona i den. 107

2 11. PROGRAM I Unix låter man sådana textfiler börja med en rad med #! och en sökväg för att tala om vilket program det är som ska tolka instruktionerna i filen. Ett skalskript kan börja med #! /bin/sh där /bin/sh är en sökväg till skalet. Då sätts det programmet igång för att tolka instruktionerna i filen om den körs Att kompilera program För att kompilera ett program så kör man i de enklaste fallen en kompilator med källkodsfilen som argument. Kompilatorn skapar en ny fil som går att köra. Ett större program består normalt en mängd filer som använder sig av varandra på komplicerade sätt, och för att kompilera detta kan det krävas flera steg. I Unix-världen används oftast ett program make för att göra detta. Den kör alla dessa steg i rätt ordning för att tillverka vissa filer. I en fil Makefile finns regler som talar om för den vad den ska göra Att installera program På en GNU-dator som man själv administrerar är det i allmänhet enklast att inte kompilera program man ska använda själv, utan istället installera färdigkompilerade program med en särskild pakethanterare. Programmet med sin dokumentation och alla andra filer hamnar på rätt ställen på disken direkt. Detta förutsätter att någon har gjort ett sådant paket som passar till ens system, men är det ett välanvänt program så är det antagligen så. Ett system som många system, bl. a. vårt, använder är paketsystemet RPM. Men som vanlig användare utan administratörsrättigheter så kan du oftast inte använda dig av sådant eftersom du inte har rätt att lägga filerna på de centrala ställen där de då är tänkta att hamna. Då får du oftast lov att installera program genom att kompilera dem själv. (Så kan det också vara för att ingen har gjort nåt behändigt paket av just det programmet.) Programmen distribueras då i allmänhet i form av ett (komprimerat) filarkiv som källkoden finns i. Du börjar med att packa upp detta filarkiv och sen se efter om det bland filerna finns någon fil README med allmänna instruktioner eller kanske en fil INSTALL med instruktioner om hur du ska installera programmet Att installera med make I GNU har det utarbetats en standard för hur installationen går till. Med distributionen av programmet följer det med ett skalskript configure som man börjar med att köra. Då skapas en fil Makefile som är särskilt anpassad för det system man kör på. Efter det kan man kompilera programmet med make och sedan installera det med make install. Bland uppgifterna för configure hör att anpassa installationen för den variant av operativsystemet som det kör på just nu. Det gör en mängd tester av vad som finns installerat och inte och hur saker fungerar som fungerar lite olika på olika system. I anropet till configure kan man dessutom tala om olika saker om hur detta program ska kompileras och installeras just denna gång i form av långa väljare. En standardiserad sådan som man har användning för om man inte installerar program centralt på systemet är --prefix katalognamn för att tala om var programmet och alla dess filer ska installeras. Normalt läggs program i /usr/local/bin/, man-sidor i /usr/local/man/ och diverse andra filer i några andra underkataloger till /usr/local. Men där har vanliga användare inte rätt att lägga filer! Med --prefix ersätter man detta med något annat, så med t. ex. --prefix ~/pgm installeras själva programmen i ~/pgm/bin/ osv. Man kan förstås använda en annan katalog under ens hemkatalog, eller hemkatalogen själv. Med --prefix ~ hamnar själva programmen i ~/bin osv. 1 Ett sådant skript configure har inte använts traditionellt i Unix-världen, så många program har inte något sådant. Kanske funkar make all direkt ändå. Kanske behöver man göra vissa anpassningar för hand innan. Förhoppningsvis finns det en fil README eller INSTALL eller liknande som ger anvisningar. 1 Tidigare har jag skrivit att det normala sättet att ge argument till långa väljare är med ett likamedtecken, som --prefix=~/pgm, men just i detta fall ställer det till problem eftersom skalet bara ersätter ~ med ens hemkatalog när det står först i ett argument. 108

3 11.6. Upphovsrätt och licenser Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the Software ), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUD- ING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Figur 11.1: Exempel på en licens som följer med ett fritt program 11.6 Upphovsrätt och licenser Upphovsrätt gäller för program, både för källkod och maskinkod, precis som för litterära och konstnärliga verk. Inga som har skrivit program för moderna datorer har dock varit döda i sjuttio år så att upphovsrätten har gått ut för deras verk, så som t. ex. skett för t. ex. Strindbergs och Lenngren. 2 Trots det finns det en mängd program som det står en fritt att använda, kopiera och sprida, eftersom programmens författare uttryckligen givit en tillstånd till detta. Sådant sker i form av en licens där upphovsrättsinnehavarna talar om vad de tillåter. Ett exempel på en enkel sådan licens finns i figur I synnerhet är hela operativsystemet GNU sådan»fri programvara«, men för att komma till GNU tar vi först en kort Unixhistoria: Unix Operativsystemet Unix skapades i slutet av 60-talet på Bell Labs i USA. I mitten av 70-talet började det spridas utanför Bell Labs. Det såldes rätt billigt (speciellt till universitet) och gick att köra på relativt billiga datorer (vid en tid när datorer var stora och dyra), vilket bidrog till dess popularitet. Dessutom följde källkoden med så att man kunde se precis hur det fun- 2 Detta är förstås är skälet till att texter av dessa figurerat i tidigare övningar, men inte senare författare. gerade och även införa egna ändringar i systemet. Det ökade populariteten ännu mer i den akademiska världen, där en mängd universitet använde Unix i undervisningen i datorvetenskap. Möjligheten att göra ändringar i koden ledde till att det uppstod en stor mängd varianter av Unix. En viktig variant var BSD (Berkeley Software Distribution) från University of California, Berkeley. Berkeley spred sina tillägg och förändringar fritt, och många använde dessa. På 80-talet tillverkade flera företag olika enanvändardatorer med Unix arbetsstationer. De var mycket kraftfullare och dyrare än den tidens vanliga persondatorer, och innehöll alla lite olika versioner av Unix. De olika tillverkarna skickade med olika tillägg från BSD och andra håll, och skrev också mycket egna tillägg (som inte spreds fritt), så de olika Unix-systemen skilde sig åt så pass mycket så att det inte alltid gick rakt av att flytta ett program från ett system till ett annat, trots att alla var Unix i grunden. En viktig del var fönstersystemet X som spreds fritt från MIT där det var skrivet. Även till detta lade de olika tillverkarna till olika nya finesser GNU och fri programvara När Unix var nytt hade de flesta av dess användare möjlighet att läsa koden för att lära sig hur den fungerade och även möjlighet att införa egna ändringar för att få delar av systemet att bete sig annorlun- 109

4 11. PROGRAM da. Med tiden hade det blivit allt ovanligare. De flesta Unix-användare kom att sitta vid arbetsstationer som till stora delar var som svarta lådor som man inte hade insyn i. Det uppfattades av många som frustrerande vid en tid när en stor del av datoranvändarna var programmerare själva utannonserade Richard M. Stallman på MIT planer på att skriva ett fritt operativsystem och det skulle få namnet GNU. Eftersom Unix redan då hade en så stark ställning så valde han att det skulle vara Unix-kompatibelt, dvs. bete sig som Unix trots att det inte var Unix. GNU stod för GNU s Not Unix. Snart startades en särskild stiftelse, Free Software Foundation (FSF), för att hålla i projektet och även i övrigt verka för fria program. En del program som redan fanns och som var fria kunde användas. T. ex. bestämde Stallman tidigt att man inte behövde skriva ett nytt fönstersystem eftersom fönstersystemet X var fritt. En del tillägg till Unix som skrivits på Berkeley och andra ställen var också möjliga att återanvända. Men den största delen av koden fick man skriva själva Linux Många delar av GNU kom snabbt på plats, och användes som separata delar på andra Unix-system, men en viktig del som kom på efterkälken var den mest centrala delen av operativsystemet, kärnan. Utan den var det inte möjligt att sätta ihop ett helt GNU-system offentliggjordes Linux av den finlandssvenske studenten Linus Torvalds. Det var ett litet Unixliknande system, framförallt inspirerat av Minix, ett tidigare minimalt Unixliknande system, gjort särskilt för undervisning i operativsystem av Andrew S. Tanenbaum i Holland. Inom kort sattes hela GNU/Linux-system samman som använde Linux som operativsystemskärna istället för HURD som var den fortfarande bara halvfärdiga kärna som skrevs specifikt för GNU. Oftast kallas sådana system bara för Linux-system, efter den kärna som används. Detta gick att köra på vanliga persondatorer, som annars oftast körde MS-DOS från Microsoft. Persondatorerna hade med tiden blivit så pass kraftfulla att de kunde klara ett mer krävande system Unix och Unix-liknande system idag En stor del av Unix-liknande system idag är fri programvara. Det finns nu en mängd olika distributioner av GNU/Linux som publiceras av olika företag och organisationer. Dessa skiljer sig åt mer eller mindre mycket beroende på vilka val distributörerna har gjort angående vilka program som ska vara med och inte vara med. Några av de populäraste distributionerna är Debian GNU/Linux, Ubuntu, Red Hat Enterprise Linux, Fedora, SUSE Linux och Gentoo. Dessutom finns det fria Unix-liknande system som baserar sig på BSD. På Berkeley fortsatte man nämligen att utveckla koden, och så småningom hade man bit för bit ersatt så många delar med nyskriven kod så att det inte fanns mycket kvar av ursprunglig kod från Bell Labs. Då gjorde man en ansträngning att ersätta även de kvarvarande delarna, så i början av 90-talet kunde man släppa ett nästan komplett operativsystem som var fritt. Fria system som bygger på den koden är FreeBSD, OpenBSD och NetBSD. De vanligaste kommersiella Unix-versionerna är idag AIX, HP-UX, MacOS X och Solaris. Apple har sedan MacOS X (version 10) byggt på ett Unixliknande system från BSD-familjen. Alla dessa system liknar varandra i stora drag i grunden. Ibland skriver man Un*x för att visa att man menar nåt Unix-liknande system i allmänhet och inte något specifikt, eller ens nödvändigt något som verkligen är Unix, 3 utan kanske bara beter sig som Unix, dvs. är Unix-kompatibelt. De olika Unix-liknande systemen skiljer sig åt på en mängd små sätt. Det har gjorts flera försök att få dem att närma sig varandra för att underlätta flyttandet av program från ett system till ett annat, och bland annat genom standarderna POSIX och Single Unix Specification (och genom att en del kommersiella system slagits ut på marknaden) är dagens Unix-system mycket mer lika varandra än hur det var för ett par decennier sedan Gratis och fri De som talar om free software menar inte free i betydelsen gratis, utan fri, och mer specifikt talar man 3 Dvs. som är licensierat att använda varumärket Unix, som ägs av The Open Group. 110

5 11.6. Upphovsrätt och licenser om fyra friheter för programmens användare: Friheten att köra programmet, oavsett syfte Friheten att studera hur programmet fungerar, och anpassa det till ens egna behov Friheten att sprida programmet till andra Friheten att förbättra programmet och sprida även förbättringarna till andra Det finns många program som är gratis, men som inte är fria enligt detta. 4 Det kan vara till exempel program som man får använda gratis men bara i vissa ändamål (t. ex. bara för undervisning och/eller forskning), eller program som bara sprids i kompilerad form så att andra inte har möjlighet att göra ändringar i det. Ofta är det bara indirekt som man har nytta av dessa friheter. Även om man själv inte har kunskaper nog för att själv ändra i programmet så kan man ha indirekt nytta av att andra har rätt att sprida sprida dessa ändringar, istället för att en part har monopol på det. Och även om man själv inte ska använda ett program för kommersiella ändamål så är det t. ex. en fördel om man använder ett distrubition från ett företag som Red Hat ifall de hade rätt att skicka med programmet från början istället för att man ska behöva installera det själv, osv GNU GPL och»copyleft«skrivandet av operativsystemet GNU påbörjades av Richard Stallman av ideologiska skäl. Han och de Figur 11.2: Copyleft-tecknet har bildats genom att spegelvända copyright-tecknet. 4»Freeware«används ibland som namn på gratisprogram, så det är skillnad på det och»free Software«. som förenade sig med honom ville att alla program skulle vara fria och såg ett fritt operativsystem som det naturliga första steget till detta. Man ville inte använda en lika tillåtande licens som t. ex. BSD gjorde. Skälet var att det ofta gjordes modifierade versioner av sådan kod som spreds som icke-fria program eller stoppades in i icke-fria program. Så var det i de olika kommersiella Unixversioner som uppstått vid denna tid som ofta hade delvis utgått från BSD-kod men lagt till sina egna förbättringar till den. Likadant var det med fönstersystemet X från MIT som spreds som fri programvara med en liknande licens. Många av de olika Unix-versionerna hade lagt till sina egna förbättringar av X, men dessa förbättringar kom bara just det företagets kunder till godo och kunde inte tas över av de andra företagen också. Den som använde en arbetsstation med Unix på 80-talet hade oftast inte möjlighet att läsa källkoden till program som de körde, även när den koden ursprungligen skrivits som fri programvara. För att de program som skrevs för GNU skulle fortsätta att vara fria för alla som använde dessa program skrev man en ny licens, GNU GPL (General Public License), där en av de viktigaste nyheterna var något som man kallade för copyleft. Det innebär att man inte tillåter att någon sprider modifierade versioner av programmet om inte dessa ändringar också sprids med samma villkor. Den som delar med sig av program enligt GPL till en grupp människor försäkrar sig alltså inte bara att programmet är fritt för den gruppen, utan även för dem som den gruppen i sin tur sprider vidare programmet till. Med tiden har det skapats fler licenser för fri programvara med lite olika egenskaper, men GPL är den klart vanligaste inte bara för sådant som skrivits direkt för GNU, utan även för t. ex. kärnan Linux och webbläsaren Firefox. Det går förstås att formulera vilka villkor man själv vill, men i allmänhet använder man någon av de licenser som redan har formulerats. Ett skäl är att det underlättar mycket för den som vill använda programmet om en välkänd licens som man redan känner till har använts. Ett annat är att det underlättar återanvändning av delar av programmet tillsammans med delar av andra program som använder samma licens. Licenser för icke-fria program är i allmänhet avtal eller överenskommelser mellan två parter. För att få komma åt programmet så förbinder man sig till att uppfylla vissa villkor. En licens som GNU 111

6 11. PROGRAM GPL fungerar inte så, utan är helt enkelriktad. Det finns ingenting som man behöver gå med på för att använda ett GPL:at program. Allt licensen gör är att ge andra rätt att göra vissa saker som annars inte hade varit tillåtet på grund av upphovsrätten Öppen källkod = Open source Medan rörelsen för fri programvara har ett ideologiskt ursprung och gärna talar om»frihet«betonas i andra sammanhang istället tekniska frågor, som att en ökad tillgänglighet av källkoden till program kan leda till förbättrade program genom att fler har möjlighet att hitta fel eller bidra med fixar. I sådana sammanhang talar man oftast om öppen källkod (open source) istället, och ser det som ett medel till att nå bättre resultat snarare än som ett mål i sig, även om vilka program som är fri programvara och vilka som är öppen källkod i praktiken oftast räknas nästan likadant Annat än program Programförfattares fria spridande av sina program har varit en inspiration även för fritt spridande av andra upphovsrättsligt skyddade verk, som texter, bilder och musik. Ett exempel är ett stort samarbetsprojekt som encyklopedin Wikipedia. Organisationen Creative Commons har gjort en mängd olika licenser som är till för att upphovsrättsinnehavare ska kunna ge en del av sina rättigheter till allmänheten utan att släppa all kontroll. Dessa används rätt ofta vid spridande av texter, musik, bilder osv. och en del av dessa licenser är»fria«i den betydelse som används inom fri programvara. En del har även en copyleft-klausul, som där kallas för Sharealike Att rapportera buggar och problem När man rapporterar buggar eller andra problem i program så är det några saker att tänka på för att ens rapport ska vara användbar för den som tar emot rapporten. Detta gäller både när du rapporterar saker till Per här och när du stöter på buggar i diverse program. 1. Tala om vad du gjort! Skriv t. ex. inte bara»utskrifter funkar inte«om du har problem med en utskrift, utan tala mer specifikt om vad du gjort som inte fungerar på ett sätt som går att härma. Skriv t. ex. Jag öppnade filen ~ellen/foo.pdf från filhanteraren, tryckte Ctrl-P för utskrift, och tryckte sedan Print när punkt stod som vald skrivare. om det var det du gjorde. Kanske är det något med just den filen som ställer till problem. Kanske är det nåt med just det pdf-visarprogrammet som ställer till problem. Kanske är det just skrivaren punkt det är problem med. Det vet du förmodligen inte, så tala om alla detaljer. Annars är det stor risk att den du rapporterat till provar nåt annat och inte upptäcker något problem. Målet är att den som man hoppas ska kunna lösa problemet ska kunna återskapa problemet! Om det inte är lokal felrapportering så tala om vilken version av programmet du använder också! Kanske uppstår problemet bara i vissa versioner. 2. Tala om vad som händer! Skriv t. ex. inte bara»utskrifter funkar inte«, utan tala om på vilket sätt. Du kanske får ett felmeddelande när du ger kommandot för att skriva ut? Det kanske inte kommer någon utskrift alls och det dyker upp ett meddelande på skrivarens display? Det kanske kommer en utskrift som är fel på något sätt? Detta hjälper till för att bekräfta för dem som läser rapporten att de får fram samma beteende. Om du får ett felmeddelande, så återge det! 3. Tala om vad du väntade dig skulle hända istället Det finns fall där detta är helt självklart, men om det inte är det, så ta med det också. Kanske har du missuppfattat vad som skulle hända. Då är det bra om det framgår direkt. Kanske är den du rapporterar till inte så insatt i just detta program. Då hjälper det att få veta vad som skulle ske för att bekräfta att en lösning man kommit på tycks fungera. En del av ovanstående är kanske självklart, men ändå skrivs det ganska många dåliga buggrapporter som tycks vänta sig att det som läser dem är tankeläsare, så det kan vara värt att sägas ändå. 112

7 11.7. Att rapportera buggar och problem Exempel på buggrapport I uppgift 1.14 med stavningskontroll i Emacs upptäckte Nicole att när man ska skriva en siffra för att tala om vilket alternativ som var det rätta så går det inte att använda tangenterna på det numeriska tangentbordet. En buggrapport om detta skulle kunna se ut så här: In GNU Emacs * What I did: Started emacs. Wrote: teh Tools->Spell Checking->Spell-Check Buffer Pressed 0 on the numerical keypad * Result: I got "Spell-checking suspended; use C-u M-$ to resume". * Expected result: Exchange "teh" with "the", like if I had pressed normal "0". (Per skickade in en liknande rapport, fast med en fix också, så i nästa version kommer detta att vara fixat.) 113

8 Laboration 11: Program Redovisning Checka in svar på frågorna i en fil ids11.txt i den versionskontrollerade katalog som heter som ditt användarnamn och som du har sedan tidigare. Gör en incheckning redan efter första labbpasset tisdagen den 24/11 och en ny efter passet torsdagen den 26/11 (och gärna andra vid andra tillfällen också). Ha allt klart före passet tisdag eftermiddag den 1 december, då du också ska ha utfört övriga instruktioner. Versionskontroll igen Gå tillbaks till katalogen alla som du skapat tidigare som kontrolleras av Subversion. Tidigare har du sett hur du kan ändra i existerande filer och lägga till nya filer. Du använde även svn update för att uppdatera din arbetskatalog. Det finns en mängd olika Subversionkommandon som man ger på det sättet som argument till kommandot svn. Prova kommandot svn status. Det ger en översikt över hur din arbetskatalog skiljer sig från vad som finns i repositoriet. Kommandot listar de filer som skiljer sig med ett först på raden som visar vad som gäller för just den filen. Du borde bland annat ha med rader som? sagobok.aux? sagobok.pdf och några till eftersom LaTeX skapade de filerna när du TeXade sagobok.tex, men Subversion inte vet något om dessa filer. Det är helt i sin ordning. Dessa filer bör inte checkas in, eftersom de skapas automatiskt från andra. Ett M står för modified, så om du har en rad som M 114 sagobok.tex betyder det att du har gjort ändringar i den filen som du inte har checkat in! Ett A står för added, så om du haft en rad som A groda.png skulle det betytt att du har registrerat den filen i Subversion, men sen inte checkat in den ännu. Uppgift 11.1 Ta bort filen sagobok.tex och ge svn status igen. Att en fil som borde finnas saknas i din arbetskatalog vill Subversion verkligen uppmärksamma dig på. Vad använder den för tecken för att markera sådana filer? Eftersom filen var versionskontrollerad kan du hämta tillbaka den från repositoriet igen. Gör svn update så får du den senaste versionen. Per har varit inne och ändrat lite i den. Ändra du också, genom att ändra rubriken för din saga från ditt användarnamn till nåt som har med innehållet att göra och checka sedan in din ändring. Att kompilera Gör även svn update i den andra Subversionkatalogen du har, dvs. den som heter som ditt användarnamn. Det visar sig att en ny fil dyker upp trappa.c. Det är ett litet program i programspråket C. Kompilera programmet med cc trappa.c. (cc är C-kompilatorn.) Det skapas då en ny fil med det körbara programmet. Uppgift 11.2 Vad heter den fil som då skapas? Kör detta program med /local/texts/ jabberwocky som input. (Programmet accepterar inga argument, så du får lov att använda omdirigering.) Rättat från cvs till svn

9 Exekverbara filer Uppgift 11.3 Hur skrev du kommandot för att göra detta? Normalt skulle man vilja att detta program vars källkod ligger i trappa.c skulle heta trappa istället. Det finns väljare till cc för att göra så istället, men tillverka istället en sådan fil trappa med hjälp av ett kommando make. Kör alltså make trappa. Det skriver ut vilket kommando det i sin tur utför. Uppgift 11.4 Vilken väljare till cc använde make för att tala om vad det kompilerade programmet skulle heta? Uppgift 11.5 Om du gör make trappa igen vad får du du för meddelande från make? Såg du vad programmet gjorde med textfilen? Antagligen kan du inte C, men öppna ändå källkoden med Emacs och se om du kan gissa en del av hur programmet fungerar. Indent betyder indrag. Uppgift 11.6 Vissa delar av programmet är kommentarer de har ingen effekt på vad programmet gör, utan finns där för att underlätta läsningen och förståelsen av programmet. Vad skriver man tydligen före respektive efter kommentarer i C? Ändra i trappa.c så att den gör indrag med mellanrum istället för med understrykningstecken. Skriv make trappa för att kompilera om programmet och provkör det för att se att det stämmer, och checka sedan in den ändring du har gjort. DSSO I tidigare uppgifter har ni använt Den stora svenska ordlistan, men inte i den form som den distribueras. Gå till på webben och hämta dit den senaste versionen av denna. Det är förmodligen dsso-1.40.txt, för det är det när jag skriver detta i alla fall. Det finns även versioner av ordlistan som är anpassade för att användas av vissa särskilda program, men hämta själva textfilen bara. Uppgift 11.7 Vilken licens sprids den ordlistan med och vilken teckenkodning använder den filen? Filen du har hämtat innehåller ordlistans information på ett särskilt textformat. Du får se efter själv hur innehållet i filen är upplagt. Några saker: Det är bara rader med < och > som innehåller ordformer. Själva ordformerna står efter >, avdelade med»:«och», «. Nu ska du skriva ett skalskript dsso.sh så att om du ger kommandot bash dsso.sh skapas en fil ordformer.txt som innehåller en UTF8-fil med en ordform per rad. Ta inte med flerordsuttryck från filen som»au pair«och»science fiction«. Använd gärna flera skalkommandon i rad och lagra mellanresultat i filer som du tar bort i slutet av skalskriptet. Det första skulle t. ex. kunna vara ett kommando som skapar en fil dsso-u8.txt som är likadan som originalet, men omvandlad till UTF8. Senare i skalskriptet skulle du i så fall göra rm dsso-u8.txt för att rensa upp efter dig. Tips: Fokusera inte på att det ska bli ett skalskript till att börja med, utan försök bara hitta kommandon för att lösa uppgiften. Sen kan du stoppa in dem i ett skript. Exekverbara filer Uppgift 11.8 Vad finns det för filer i din kurskatalog som du har rättighet att köra (x-rättighet)? Uppgift 11.9 En av dessa är en textfil. Vilken? Den börjar med en sån där rad som talar om vilket program som ska tolka dess innehåll. Hur lyder den raden? Installera Link Grammar På har du råkat få nys på ett program som du tänker att du skulle behöva använda här. Du skulle kunna be systemadministratören, men du har en känsla av att han är så upptagen med undervisning så det är nog bäst att installera det själv istället. Uppgift Vad heter filen som du hämtar hit som programmet distribueras i? Lägg filen i din kurskatalog och cd:a till samma katalog i ditt skal. Uppgift Ge ett kommando för att packa upp detta filarkiv. Hur lyder ditt kommando? 115

10 LABORATION 11: PROGRAM Uppgift I en fil där ges licensen enligt vilket programmet skrivs. Vad heter den filen? Uppgift Är den licensen en»copyleft«- licens? Hur framgår det? Läs instruktionerna för hur man ska installera och köra det programmet, och gör så. Uppgift Hur gjorde du? När man kör igång det får man en prompt linkparser> till vilken man dels kan ge särskilda kommandon, men också skriva engelska meningar för att få dem analyserade av programmet. Uppgift Hur ser den analys ut som programmet ger av meningen»your logic does not resemble our Earth logic.«? Buggar i grep Under tidigare labbar har två buggar i grep märkts av. 1. På s. 84 skrev jag att \w betyder samma sak som [[:alnum:]] i reguljära uttryck i grep. Så står det nämligen i dokumentationen till grep. Men det betyder faktiskt inte riktigt samma sak! Med \w inkluderas även understrykningstecknet _ som inte räknas med i [[:alnum:]]! Antingen är det programmet som gör fel eller så står det fel i dokumentationen. Någonstans är det en bugg hursomhelst. 2. Vid en demo råkade jag oavsiktligt stöta på en grep-bugg, trots att jag kände till den innan. Ankring i början av något funkar inte så bra tillsammans med grep -o. $ echo hej grep -o '^.' h e j Det tycks som att när h först har hittats så skalas strängen ner till ej och därmed finns e först på raden i resten, osv. Tänk om man skulle göra programutvecklarna en tjänst och rapportera dessa buggar. Men då bör man först se efter om de redan har fixats i den senaste versionen av grep. Uppgift Vilken version av grep kör vi här? Hur tog du reda på det? Vilken är den senaste publicerade versionen av GNU grep? Var på webben hittade du det? Hämta den senast publicerade på nätet och kompilera och installera den för att se om den har samma fel. Använd hela det normala GNU-sättet för att installera program, och ange din hemkatalog som prefix. Uppgift Hur körde du då configure? Uppgift Vilka kommandon gav du sen? Uppgift I vilken katalog hamnade nu det nyinstallerade programmet grep? Hur kan du enklast skriva för att köra det? Uppgift Har den senaste versionen kvar bugg 1 ovan? Om den har det så formulera en buggrapport om detta. Om inte, så tala om hur du såg det. Uppgift Har den senaste versionen kvar bugg 2 ovan? Om den har det så formulera en buggrapport om detta. Om inte, så tala om hur du såg det. Om det vore på riktigt skulle du skriva på engelska eftersom det är vad programmets författare förstår, men om du vill kan du skriva på svenska istället. Ge korta exempel på något som ger fel resultat som de skulle kunna göra efter. Skicka inte in någon buggrapport på riktigt! (Om det behövs så är det redan gjort.) När du kompilerade programmet så skapades en massa filer som inte längre behövs. En del var bara mellanresultat, och de som var det resultat som du var ute efter har kopierats till en annan katalog när du installerade. Uppgift Läs i INSTALL för att se vad du kan ge för make-kommando för att rensa bort de filer där som inte längre behövs och ge det kommandot. Vad var det? 116