Hoofdstuk 4. UNIX® beginselen

Het volgende hoofdstuk behandelt de basiscommando’s en functionaliteit van het FreeBSD besturingssysteem. Veel van dit materiaal is relevant voor elk UNIX® achtig besturingssysteem. Als de lezer reeds bekend is met het materiaal, hoeft dit hoofdstuk niet gelezen te worden. Lezer die nog niet eerder met FreeBSD te maken hebben gehad wordt aangeraden door te lezen.

Na het lezen van dit hoofdstuk weet de lezer:

FreeBSD kan op diverse manieren gebruikt worden. Één van deze manieren is het typen van commando’s in een tekstterminal. Veel van de flexibiliteit en kracht van een UNIX® besturingssysteem is gemakkelijk beschikbaar als je FreeBSD op deze manier gebruikt. Dit onderdeel beschrijft wat "terminals " en "consoles" zijn en hoe je deze kan gebruiken in FreeBSD.

FreeBSD, direct afgeleid van BSD UNIX®, is gebaseerd op verschillende belangrijke UNIX® concepten. Het meest bekende is dat FreeBSD een multi-user systeem is. Het systeem kan meerdere gebruikers behandelen die tegelijkertijd totaal verschillende dingen doen. Het systeem is verantwoordelijk voor het netjes delen en beheren voor aanvragen voor hardware, randapparatuur, geheugen en cpu tijd tussen elke gebruiker.

Omdat het systeem in staat is om meerdere gebruikers te ondersteunen, heeft alles wat door het systeem beheerd wordt een set van rechten die aangeeft wie mag lezen, schrijven en de bron mag uitvoeren. Deze rechten zijn opgeslagen in drie octetten, die weer in drie stukjes onderverdeeld zijn: één voor de eigenaar van het bestand, één voor de groep waar het bestand toe behoort en één voor de overigen. De numerieke weergave werkt als volgt:

De -l optie kan gebruikt worden met ls(1) om een lange lijst met de inhoud van een map te zien die een kolom heeft met informatie over bestandsrechten voor de eigenaar, groep en de rest. ls -l in een willekeurige map kan het volgende laten zien:

Zo ziet de eerste kolom van ls -l eruit:

Het eerste (meest linkse) karakter geeft aan of dit een reguliere bestand is, een map, een speciaal karakter component(!), een socket of een andere pseudo-file component(!). In dit geval betekent de - dat het een regulier bestand is. De volgende drie karakters, rw- in dit voorbeeld, geven de rechten voor de eigenaar van het bestand. De drie karakters r-- erna geven de rechten van voor de groep van het bestand. De overige drie karakters r-- tonen de rechten voor alle overige gebruikers. Een streepje betekent dat de rechten uitgeschakeld zijn. In het geval van dit bestand zijn de rechten zo ingesteld dat de eigenaar kan lezen en schrijven naar het bestand, de groep het bestand kan lezen, en alle overige gebruikers kunnen ook het bestand lezen. Volgens de tabel hierboven worden de rechten 644, waar de cijfers de drie stukjes van de rechten aangeven.

Dit is allemaal leuk en aardig, maar hoe controleert het systeem dan rechten voor apparaten? FreeBSD behandelt de meeste hardware apparaten als bestanden die door programma’s kunnen worden geopend en gelezen, en waar data naar toe kan worden geschreven, net zoals elk ander bestand. Deze speciale apparaat bestanden worden bewaard in de map /dev.

Mappen worden ook behandeld als bestanden. Ze hebben lees, schrijf en uitvoerbare rechten. De uitvoerbare vlag voor een map heeft een klein verschil qua betekenis dan die voor gewone bestanden. Als een map als uitvoerbaar gemarkeerd is, betekent het dat erin gekeken mag worden. Het is dus mogelijk om te wisselen naar de map met cd (wissel van map). Dit betekent ook dat in de map bestanden benaderd kunnen worden waarvan de naam bekend is. Dit is natuurlijk afhankelijk van de rechten op het bestand zelf.

In het bijzonder, om een lijst van de map te kunnen maken, moet een gebruiker leesrechten op de map hebben. Om een bestand te verwijderen zijn de naam van het bestand en schrijf en uitvoerrechten op de map nodig waarin het bestand zich bevindt.

Er zijn meer rechtenvlaggen, maar die worden slechts gebruikt in speciale gevallen, zoals bij setuid binaries en sticky mappen. Meer informatie over bestandsrechten en hoe die aangepast kunnen worden staat in chmod(1).

De FreeBSD mappenstructuur is erg belangrijk om het systeem goed te leren kennen. Het belangrijkste concept om greep op te krijgen is die van de rootmap, "/". Deze map is de eerste die gekoppeld wordt tijdens het opstarten en bevat het basissysteem dat nodig is om het besturingssysteem gereed te maken voor multi-user taken. De rootmap bevat ook koppelpunten voor elk ander bestandssysteem dat misschien gekoppeld wordt.

Een koppelpunt is een map waar extra bestandssystemen aan het een bestandssysteem gekoppeld kunnen worden (meestal het root bestandssysteem). Dit wordt beschreven in Organisatie van schijven. Standaard koppelpunten zijn /usr, /var, /tmp, /mnt en /cdrom. Naar deze mappen wordt meestal verwezen in /etc/fstab, een tabel met bestandssystemen en koppelpunten ter referentie voor het systeem. De meeste bestandssystemen in /etc/fstab worden automatisch gekoppeld tijdens het opstarten door het script rc(8), behalve als de optie noauto gedefinieerd is. Details staan beschreven in Het bestand fstab.

Een complete beschrijving over het bestandssysteem staat in hier(7). Hier wordt volstaan met een overzicht van de voorkomende mappen.

De kleinste vorm van organisatie die FreeBSD gebruikt om bestanden te vinden is de bestandsnaam. Bestandsnamen zijn hoofdlettergevoelig, wat betekent dat readme.txt en README.TXT twee verschillende bestanden zijn. FreeBSD gebruikt de extensie niet (.txt) van een bestand om te bepalen of het bestand een programma, een document of een vorm van data is.

Bestanden worden bewaard in mappen. Een map kan leeg zijn of honderden bestanden bevatten. Een map kan ook andere mappen bevatten, wat het mogelijk maakt om een hiërarchie van mappen te maken. Dit maakt het veel makkelijker om data te organiseren.

Bestanden en mappen worden aangegeven door het bestand of de map aan te geven, gevolgd door een voorwaardse slash, /, gevolgd door andere mapnamen die nodig zijn. Als map foo de map bar bevat, die op zijn beurt het bestand readme.txt bevat, dan wordt de volledige naam of pad naar het bestand foo/bar/readme.txt.

Mappen en bestanden worden bewaard op een bestandssysteem. Elk bestandssysteem bevat precies één map op het hoogste niveau die de rootmap van het bestandssysteem heet. Deze rootmap kan op zijn beurt andere mappen bevatten.

Tot zover is dit waarschijnlijk hetzelfde als voor elk ander besturingssysteem. Er zijn een paar verschillen. MS-DOS® gebruikt bijvoorbeeld een \ om bestanden en mappen te scheiden, terwijl Mac OS® gebruik maakt van :.

FreeBSD gebruikt geen schijfletters, of andere schijfnamen in het pad. FreeBSD gebruikt geen c:/foo/bar/readme.txt.

Eén bestandssysteem wordt aangewezen als root bestandssysteem, waar naar wordt verwezen met /. Elk ander bestandssysteem wordt daarna gekoppeld onder het root bestandssysteem. Hoeveel schijven er ook aan een FreeBSD systeem hangen, het lijkt alsof elke map zich op dezelfde schijf bevindt.

Stel er zijn drie bestandssystemen met de namen A,B en C. Elk bestandssysteem heeft één root map die twee andere mappen bevat, A1 en A2 (zo ook voor de andere twee: B1, B2, C1 en C2).

A wordt het root besturingsysteem. Met ls, dat de inhoud van de map kan tonen, zijn de twee mappen A1 en A2 te zien. De mappenstructuur ziet er als volgend uit:

Een bestandssysteem moet gekoppeld worden in een map op een ander bestandssysteem. Als nu bestandssysteem B wordt gekoppeld onder de map A1 vervangt B``A1 en zien de koppelingen in B er als volgt uit:

Elk bestand dat in de mappen B1 en B2 aanwezig is, kan benaderd worden met het pad /A1/B1 of /A1/B2. Elk bestand dat in /A1 stond is tijdelijk verborgen en komt tevoorschijn als `B`is _ontkoppeld_van A.

Als B gekoppeld is onder A2 ziet de diagram er als volgt uit:

en de paden zouden dan respectievelijk /A2/B1 en /A2/B2 zijn.

Bestandssystemen kunnen op elkaar worden gekoppeld. Doorgaand op het vorige voorbeeld kan het bestandssysteem C gekoppeld worden bovenop de map B1 in het bestandssysteem B. Dit resulteert in:

Of C kan direct onder het bestandssysteem A gekoppeld worden, onder de map A1:

Hoewel het niet gelijk is, lijkt het op het gebruik van join in MS-DOS®.

Beginnende gebruikers hoeven zich hier gewoonlijk niet mee bezig te houden. Normaal gesproken worden bestandssystemen gemaakt als FreeBSD wordt geïnstalleerd en er wordt besloten waar ze gekoppeld worden. Meestal worden ze ook niet gewijzigd tot er een nieuwe schijf aan een systeem wordt toegevoegd.

Het is mogelijk om één groot root bestandssysteem te hebben en geen andere. Deze benadering heeft voordelen en nadelen.

Bestandssystemen worden opgeslagen in partities. Dit betekent niet hetzelfde als de algemene betekenis van de term partitie (bijvoorbeeld, MS-DOS® partitie), vanwege FreeBSD’s UNIX® achtergrond. Elke partitie wordt geïdentificeerd door een letter van a tot en met h. Elke partitie kan slechts één bestandssysteem hebben, wat betekent dat bestandssystem vaak omschreven worden aan de hand van hun koppelpunt in de bestandssysteem hiërarchie of de letter van de partitie waar ze in opgeslagen zijn.

FreeBSD gebruikt ook schijfruimte voor wisselbestanden. Wisselbestanden geven FreeBSD virtueel geheugen. Dit geeft de computer de mogelijkheid om net te doen alsof er veel meer geheugen in de machine aanwezig is dan werkelijk het geval is. Als FreeBSD geen geheugen meer heeft, verplaatst het data die op dat moment niet gebruikt wordt naar de wisselbestanden en plaatst het terug als het wel nodig is (en zet iets anders in ruil daarvoor terug).

Aan sommige partities zijn bepaalde conventies gekoppeld.

Elke partitie die een bestandssysteem bevat is opgeslagen in wat FreeBSD noemt een slice. Slice is FreeBSD’s term voor wat meeste mensen partities noemen. Dit komt wederom door FreeBSD’s UNIX® achtergrond. Slices zijn genummerd van 1 tot en met 4.

Slicenummers volgen de apparaatnamen, voorafgegaan door een s die begint bij 1. Dus "da0_s1_" is de eerste slice op de eerste SCSI drive. Er kunnen maximaal vier fysieke slices op een schijf staan, maar er kunnen logische slices in fysieke slices van het correcte type staan. Deze uitgebreide slices zijn genummerd vanaf 5. Dus "ad0_s5_" is de eerste uitgebreide slice op de eerste IDE schijf. Deze apparaten worden gebruikt door bestandssystemen waarvan verwacht wordt dat ze een slice in beslag nemen.

Slices, "gevaarlijk toegewijde" (dangerously dedicated) fysieke drivers en andere drives bevatten partities, die worden weergegeven door letters vanaf a tot h. Deze letter wordt achter de apparaatnaam geplakt. Dus "da0_a_" is de a partitie op de eerste da drive, die "gevaarlijk toegewijd" is. "ad1s3_e_" is de vijfde partitie op de derde slice van de tweede IDE schijf.

Elke schijf op het systeem wordt geïdentificeerd. Een schijfnaam start met een code die het type aangeeft en dan een nummer dat aangeeft welke schijf het is. In tegenstelling tot bij slices, start het nummeren van schijven bij 0. Standaardcodes staan beschreven in Schijf apparaatcodes.

Bij een referentie aan een partitie verwacht FreeBSD ook dat de slice en schijf refereert naar die partitie en als naar een slice wordt verwezen moet ook de schijfnaam genoemd worden. Dit kan door de schijfnaam, s, het slice nummer en de partitieletter aan te geven. Voorbeelden staan in Voorbeeld schijf-, slice- en partitienamen.

In Conceptmodel van een schijf staat een conceptmodel van een schijflayout die een en ander verduidelijkt.

Voordat FreeBSD geïnstalleerd kan worden moeten eerst de schijfslices gemaakt worden en daarna moeten de partities op de slices voor FreeBSD gemaakt worden. Daarna wordt op elke partitie het bestandssysteem (of wisselbestand) gemaakt en als laatste wordt besloten waar het filesysteem gekoppeld wordt.

Het bestandssysteem wordt het best weergegeven als een boom, met de stam als /. /dev, /usr en de andere map in root zijn takken die weer hun eigen takken kunnen hebben, zoals /usr/local, etc.

Er zijn verschillende redenen om sommige van deze mappen op aparte bestandssystemen te plaatsen. /var bevat de mappen log/, spool/ en verschillende types tijdelijke bestanden en kan volraken. Het laten vollopen van het root bestandssysteem is geen goed idee, dus het splitsen van /var van / is vaak de favoriet.

Een andere vaak voorkomende reden om bepaalde mapbomen op aparte bestandssystemen te plaatsen, is om ze op verschillende fysieke schrijven te zetten of gescheiden virtuele schijven zoals gemounte Netwerk bestandssystemen of cd-rom drives.

FreeBSD is een multi-tasking besturingssysteem. Dit betekent dat het lijkt alsof er meer dan één proces tegelijkertijd draait. Elk programma dat draait wordt een proces genoemd. Elk commando dat wordt uitgevoerd start op zijn minst één nieuw proces en er zijn systeemprocessen die continu draaien om het systeem functioneel te houden.

Elk proces wordt geïdentificeerd door een nummer dat process ID of PID heet, en net zoals bij bestanden heeft elk proces één eigenaar en groep. De eigenaars- en groepsinformatie wordt gebruikt om te bepalen welke bestanden en apparaten het proces mag openen, waarbij gebruik wordt gemaakt van de bestandsrechten die eerder zijn behandeld. Veel processen hebben ook een ouderproces (parent process). Een ouderproces is een proces dat het nieuwe proces heeft gestart. Als commando’s in een shell worden ingevoerd, start de shell een proces en elk commando dat draait is ook een proces. De uitzondering hierop is het speciale proces init(8). init is altijd het eerste proces, dus het PID is altijd 1. init wordt automatisch gestart door de kernel als FreeBSD opstart.

Twee commando’s die erg handig zijn om te zien welke processen er draaien zijn ps(1) en top(1). ps wordt gebruikt om een statische lijst op te vragen van de processen die op het moment van uitvoeren draaien en kan hun PID, geheugengebruik, de startende commandoregel, enzovoort, tonen. top geeft alle draaiende processen weer en werkt de status elke paar seconden bij zodat interactief wordt weergegeven wat een computer aan het doen is.

Standaard laat ps alleen zien welke commando’s draaien waarvan de gebruiker die het uitvoert de eigenaar is:

In het bovenstaande voorbeeld is de uitvoer van ps(1) georganiseerd in een aantal kolommen. PID is het proces ID. PIDs worden toegekend vanaf 1 en lopen op tot 99999. Als ze allemaal zijn gebruikt, worden ze hergebruikt. (een PID wordt niet hergebruikt als deze reeds in gebruik is). De TT kolom toont de tty vanwaar het programma draait en wordt nu buiten beschouwing gelaten. STAT toont de huidige staat van het programma en ook deze kolom wordt buiten beschouwing gelaten. TIME is de hoeveelheid tijd die het programma gedraaid heeft op de CPU. Dit is meestal niet de verstreken tijd vanaf het moment dat het programma is gestart. Veel programma’s wachten omdat er alleen gebruik wordt gemaakt van de CPU als er iets voor het programma te doen is. Als laatste is COMMAND de commandoregel die gebruikt is om het programma te starten.

ps(1) ondersteunt een aantal opties die de informatie wijzigen die wordt weergegeven. Één van de meest nuttige combinaties is auxww. De optie a toont informatie over alle draaiende processen, niet alleen die van de gebruiker die is aangemeld. De optie u toont de gebruikersnaam van de proceseigenaar, evenals geheugengebruik. De optie x toont informatie over daemonprocessen en met de optie ww laat ps(1) de volledige commandoregel zien voor elk proces, in plaats van een mogelijk afgekorte regel omdat die te lang is om op het scherm te passsen.

De uitvoer van top(1) is hetzelfde:

De uitvoer is gesplitst in twee secties. De kop (de eerste vijf regels) toont het laatst uitgegeven PID, de gemiddelde systeembelasting (hoe druk is een systeem), de uptime van het systeem (tijd verstreken sinds laatste reboot) en de huidige tijd. De andere cijfers in de kop tonen hoeveel processen er draaien (in dit geval 47) , hoeveel geheugen en swap er gebruikt wordt en hoeveel processortijd het systeem besteed aan verschillende taakgroepen.

Daaronder staat een serie van kolommen die soortgelijke informatie bevatten als de uitvoer van ps(1). Zo zijn het PID, de gebruikersnaam, de hoeveelheid processortijd en het commando dat gebruikt is om het proces te starten te zien. top(1) laat standaard ook zien hoeveel geheugen er gebruikt wordt door een proces. Dit staat in twee kolommen waarbij in de eerste kolom het maximale geheugengebruik wordt getoond en in de tweede kolom het huidige geheugengebruik. Maximale gebruik is de hoeveelheid geheugen die het proces nodig had in de tijd dat het bestaat en het residente gebruik is hoeveel er op het moment van weergeven gebruikt wordt. In dit voorbeeld is zichtbaar dat getenv(3) bijna 30 MB RAM nodig had, maar op het moment van uitvoeren 9 MB verbruikt.

top(1) werkt het beeld automatisch iedere twee seconden bij. Dat kan gewijzigd worden met de optie s.

Als een gebruiker een editor draait is het makkelijk om de editor te besturen, te vertellen om bestanden te openen, etc. Dit kan omdat de editor de mogelijkheden geeft om dat te doen en omdat de editor gekoppeld is aan een terminal. Sommige programma’s zijn niet ontworpen om te draaien met continue gebruikersinvoer, dus als zij de kans krijgen ontkoppelen zij zich van de terminal. Een webserver reageert bijvoorbeeld de hele dag op webaanvragen en heeft eigenlijk geen input van een lokale gebruiker nodig. Programma’s die email van locatie naar locatie transporteren zijn een ander voorbeeld.

Deze programma’s heten daemons. Daemons waren karakters in de Griekste mythologie, goed noch slecht, ze waren dienende geesten die op grote schaal nuttige dingen deden voor de mensheid. Net zoals de huidige webservers en mailservers nuttige dingen doen. Dit is waarom de mascotte voor BSD al lang een vrolijk kijkende daemon met puntoren en een drietand is.

Er is een overeenkomst om programma’s die meestal draaien als daemon te voorzien van het achtervoegsel "d". BIND is de Berkeley Internet Name Domain (het echte programma heet named), de Apache webserver heet httpd, de printerspooldriver heet lpd, etc. Deze overeenkomst geldt niet altijd. De hoofd maildaemon voor Sendmail heet bijvoorbeeld sendmail en niet maild.

Soms is communicatie met een daemon nodig. Een manier om dit te doen is het versturen van een signaal (signals). Er zijn een verschillende signalen. Sommige hebben een specifieke bedoeling, andere worden geïntrepeteerd door de applicatie. In de documentatie van de applicatie staat hoe de applicatie signalen intrepeteert. Er kan alleen een signaal naar een proces gezonden worden waar de uitvoerende gebruiker eigenaar van is. Als met kill(1) of kill(2) een signaal naar een proces van een andere gebruiker wordt gestuurd, wordt de toegang geweigerd. De enige uitzondering hierop is de root gebruiker, die signalen naar processen van alle gebruikers kan sturen.

FreeBSD stuurt soms ook signalen naar applicaties. Als een applicatie slecht geschreven is en hij probeert geheugen te benaderen waar hij niet naartoe mag, stuurt FreeBSD het proces een Segmentation Violation signaal (SIGSEGV). Als een applicatie de systeemaanroep alarm(3) heeft gebruikt om na een bepaalde periode een alarm te ontvangen, wordt er een Alarm signaal heen gestuurd (SIGALRM), etc.

Twee signalen kunnen gebruikt worden om een proces te stoppen: SIGTERM en SIGKILL. SIGTERM is de nette manier om een proces te killen. Het proces kan het signaal afvangen, begrijpen dat de eigenaar wil dat het wordt afgesloten, wellicht logboekbestanden sluiten die geopend zijn en alle onderhanden activiteiten afhandelen. In een aantal gevallen kan een proces SIGTERM negeren: als het midden in een taak zit die niet beëindigd kan worden.

SIGKILL mag niet worden genegeerd door een proces. Dit is het "Wat je ook aan het doen bent, stop er nu mee" signaal. Na een SIGKILL stopt FreeBSD het proces meteen.

Andere veelgebruikte signalen zijn SIGHUP, SIGUSR1 en SIGUSR2. Dit zijn algemeen bruikbare signalen en verschillende applicaties zullen verschillend reageren als ze verstuurd worden.

Stel dat het bestand met instellingen voor de webserver is aangepast. Dan moet aan de webserver verteld worden dat die de instellingen opnieuw moet lezen. Hiervoor zou httpd gestopt en gestart kunnen worden, maar dit resulteert in een korte onderbreking van de webserverdienst, wat ongewenst kan zijn. De meeste daemons zijn geschreven om te reageren op het SIGHUP signaal door het opnieuw inlezen van het instellingenbestand. Dus in plaats van het stoppen en herstarten van httpd kan het SIGHUP signaal gezonden worden. Omdat er geen standaard manier is om op deze signalen te reageren, reageren verschillende daemons anders. Het is verstandig eerst de documentatie van de daemon in kwestie te lezen.

Zoals onderstaand voorbeeld laat zien, worden signalen door kill(1) verzonden.

Andere signalen versturen werkt bijna hetzelfde door TERM of KILL op de commandoregel te vervangen door wat nodig is.

In FreeBSD wordt een groot deel van het alledaagse werk gedaan vanuit een omgeving met een commandoregel die shell heet. De grootste taak van een shell is om commando’s van het invoerkanaal op te vangen en deze uit te voeren. Veel shells hebben ook functies ingebouwd om mee te helpen om alledaagse taken zoals bestandsbeheer, bestandsglobbing, bestanden wijzigen vanaf de commandoregel, commandomacro’s schrijven en uitvoeren en omgevingsvariabelen instellen en wijzigen. FreeBSD heeft een aantal shells bijgeleverd zoals sh, de Bourne Shell en tcsh, de verbeterde C-shell. Er zijn veel andere shells beschikbaar in de FreeBSD Portscollectie zoals zsh en bash.

Welke shell gebruiken? Dit is een kwestie van smaak. Een C-programmeur voelt zich misschien prettiger bij een C-achtige shell, zoals tcsh. Een voormalig Linux® gebruiker of iemand die niet veel ervaring heeft met een UNIX® commandoregel interface wil misschien bash proberen. Elke shell heeft zijn eigen unieke eigenschappen die wel of niet werken voor een bepaalde gebruiker.

Een standaard optie in een shell is bestandsnaam completie. Door het intikken van de eerste paar letters van een commando of bestandsnaam, kan de shell opdracht gegeven worden om automatisch de rest het commando of bestandsnaam toe te voegen met de Tab toets op het toetsenbord. Stel dat er twee bestanden zijn met de namen foobar en foo.bar en foo.bar moet verwijderd worden. Dan kan op het toetsenbord rm fo[Tab].[Tab] ingevoerd worden.

De shell geeft rm foo[BEEP].bar weer.

De [BEEP] geeft aan dat de shell in staat was om de bestandsnaam te completeren omdat er meer dan één soortgelijk bestand was. foobar en foo.bar beginnen met fo, maar het was in staat om het af te maken tot foo. Na het invoeren van een . en daarna Tab, is de shell in staat om de rest van de bestandsnaam aan te vullen.

Een andere optie van de shell is het gebruik van omgevingsvariabelen. Omgevingsvariabelen zijn variabele sleutelparen die opgeslagen zijn in de omgevingsruimte van een shell. Deze ruimte kan uitgelezen worden door elk programma dat door de shell wordt uitgevoerd en bevat dus veel programmainstellingen. Hieronder staat een lijst van standaard omgevingsvariabelen en wat ze betekenen:

Het instellen van omgevingsvariabelen verschilt van shell tot shell. In de C-achtige shells zoals tcsh en csh moet setenv gebruikt worden om omgevingsvariabelen in te stellen. In Bourne-shells zoals sh en bash moet export gebruikt worden om de omgevingsvariabelen in te stellen. Om bijvoorbeeld de omgevingsvariabele EDITOR te wijzigen naar /usr/local/bin/emacs onder csh of tcsh moet het volgende gedaan worden:

In Bourne shells is dat:

Met de meeste shells kunnen de omgevingsvariabelen ook weergegeven worden door een $ karakter voor de variabelenaam te plaatsen op de commandoregel. echo $TERM zou weergeven wat er in $TERM gezet is, omdat de shell $TERM uitbreid en het resultaat doorgeeft aan echo.

Shells kennen veel speciale karakters, die meta-karakters heten, als speciale weergaves van data. De meest voorkomende is het karakter * karakter, dat elk karakter in een bestandsnaam voorstelt. Deze speciale meta-karakters kunnen gebruikt worden om bestandsnaamglobbing te doen. Door bijvoorbeeld echo * in te voeren, is het resultaat bijna hetzelfde als door het uitvoeren van ls, omdat de shell alle bestanden die van toepassing zijn aan echo geeft om ze daarna te tonen.

Om te voorkomen dat de shell deze speciale tekens verwerkt, kunnen ze uitgeschakeld worden door er het backslash karakter (\) voor te plaatsen. echo $TERM print de inhoud van TERM naar het scherm. echo \$TERM print $TERM zoals het geschreven is.

Een groot deel van de instellingen in FreeBSD wordt gemaakt door het bewerken van tekstbestanden. Hierdoor is het een goed idee om bekend te zijn met een tekstverwerker. FreeBSD heeft er een paar in het basissysteem en veel anderen zijn beschikbaar via de Portscollectie.

De makkelijkste en simpelste editor om te leren is de editor ee, wat "easy editor" betekent. Om ee te starten, moet op de commandoregel ee bestandsnaam ingevoerd worden, waar bestandsnaam de naam is van het bestand dat bewerkt moet worden. Om bijvoorbeeld /etc/rc.conf te bewerken, wordt ee /etc/rc.conf ingegeven. Eenmaal in ee worden alle manipulatie commando’s die de editor heeft weergegeven aan de bovenkant van het scherm. Het karakter dakje ^ staat voor de toets CTRL op het toetsenbord, dus ^e vormt de toetscombinatie Ctrl+e. Om uit ee te komen wordt op de toets Esc gedrukt en daar kan gekozen worden om de editor te verlaten. De editor vraagt dan of de wijzigingen bewaard moeten worden als het bestand veranderd is.

FreeBSD heeft ook uitgebreidere tekstverwerkers, zoals vi, in het basissysteem en andere editors als Emacs en vim maken onderdeel uit van de FreeBSD Portscollectie (editors/emacs en editors/vim). Deze editors leveren veel meer functionaliteit en kracht maar zijn lastiger om te leren. Als echter veel met tekstverwerking gedaan wordt, is het leren van een krachtige editor als vim of Emacs verstandig omdat deze uiteindelijk veel tijd kan besparen.

Veel applicaties die bestanden wijzigen of getypte invoer nodig hebben zullen automatisch een tekstverwerker openen. Om de tekstverwerker te wijzigen die standaard wordt gebruikt, stelt u de omgevingsvariabele EDITOR in. Zie de sectie shells voor meer details.

Apparaat is een term die meestal wordt gebruikt voor hardwareonderdelen in een systeem, zoals schijven, printers grafische kaarten en toetsenborden. Als FreeBSD opstart laat het vooral zien welke apparaten gedetecteerd worden. Deze opstartmeldingen kunnen nagekeken worden door het bestand /var/run/dmesg.boot te bekijken.

acd0 is bijvoorbeeld de eerste IDE cd-rom drive, terwijl kbd0 staat voor het toetsenbord.

Veel van deze apparaten moeten in een UNIX® besturingssysteem benaderd worden via speciale bestanden die apparaatnodes heten en te vinden zijn in de map /dev.

Om te kunnen begrijpen waarom FreeBSD gebruik maakt van het elf(5) formaat, is het belangrijk op de hoogte zijn van de drie "dominante" uitvoerbare formaten voor UNIX®:

FreeBSD komt uit het "klassieke" kamp en gebruikt het a.out(5) formaat, een technologie die zich bewezen heeft door meerdere generaties van BSD versies heen, tot het begin van de 3.X versies. Alhoewel het al mogelijk was om ELF programma’s en kernels te bouwen en te draaien op een FreeBSD systeem , verzette FreeBSD zich eerst tegen de druk om over te schakelen naar ELF als standaard formaat. Waarom? Toen het Linux® kamp hun pijnlijke wissel maakte naar ELF, was dat niet zozeer om van het a.out formaat af te komen, maar meer omdat van het op de inflexibele jump-tabel gebaseerde gedeelde bibliotheekmechanisme af te komen, die het maken van gedeelde bibliotheken erg moeilijk maakte voor bedrijven en ontwikkelaars. Omdat de ELF hulprogramma’s een oplossing voor het gedeelde bibliotheek probleem waren en algemeen gezien werden als een "stap vooruit", werd de migratie geaccepteerd als noodzakelijk kwaad en werd de wissel uitgevoerd. Het gedeelde bibliotheek mechanisme van FreeBSD is meer gebaseerd op het gedeelde bibliotheek mechanisme van Sun’s SunOS™ en daardoor erg makkelijk te gebruiken.

Waarom zijn er zoveel verschillende formaten?

In het duistere donkere verleden was er simpele hardware. Deze simpele hardware ondersteunde een simpel klein systeem. a.out was volledig adequaat voor de taak om binaire bestanden op dat simpele systeem te vertegenwoordigen (een PDP-11). Toen mensen UNIX® van deze machine gingen porten, behielden ze het a.out formaat omdat het voldeed voor de vroege ports van UNIX® naar architecturen als Motorola 68k, VAXen, enzovoort.

Toen besloot een slimme hardware engineer dat als hij de software kon forceren om wat simpele truckjes te doen, hij in staat was om een paar onderdelen van het ontwerp af te schaven, waardoor zijn processorcore sneller kon draaien. Terwijl men probeerde om het met deze nieuwe vorm van hardware te laten werken (vandaag de dag beter bekend als RISC), was a.out te beperkt voor deze hardware. Dus werden er vele formaten ontworpen om betere prestaties te krijgen uit deze hardware dan het simpele formaat a.out kon leveren. Toen werden COFF, ECOFF en een paar andere duistere formaten uitgevonden en werden de limieten verkend, waarna men besloot om zich te richten op ELF.

Daarnaast werden programma’s groter en bleven schijven (en fysiek geheugen) relatief klein, zodat het concept van een gedeelde bibliotheek werd geboren. Het VM systeem werd ook meer verfijnd. Terwijl al deze verbeteringen bereikt werden door het a.out formaat, werd het nut met elke nieuwe eigenschap verder uitgerekt. Daarnaast wilde men dingen dynamisch laden tijdens het starten of delen weggooien nadat het programma zijn intiële code had gedraaid om te blijven hangen in het hoofdgeheugen en in de wisselbestanden. Talen werden verder verfijnd en men wilde dat code automatisch werd aangeroepen voor main. Er werden veel hacks gedaan in het a.out formaat om alles mogelijk te maken en dit werkte ook enige tijd. Na verloop van tijd was a.out niet meer in staat om alle problemen te adresseren zonder toenemende overhead in code en complexibiliteit. Hoewel ELF veel van deze problemem verhielp, was het moeilijk om te wisselen naar een systeem dat compleet anders werkte. Dus moest ELF wachten totdat het pijnlijker was om a.out te behouden dan het te migreren naar ELF.

Met het verstrijken van de tijd, werden de bouwprogramma’s die FreeBSD heeft afgeleid van hun bouwprogramma’s (vooral de assembler en de loader) ontwikkeld in twee parallel lopende takken. De FreeBSD tree voegde gedeelde bibliotheken toe en heeft wat bugs opgelost. De mensen van GNU die deze programma’s hebben geschreven, hebben ze herschreven en simpelere ondersteuning toegevoegd voor het bouwen van cross-compilers, waarbij verschillende formaten zo nodig ingevoegd konden worden, enzovoort. Omdat veel mensen cross-compilers wilden bouwen die gericht waren op FreeBSD, hadden die pech, omdat de oudere broncode van FreeBSD voor as en ld niet opgewassen was tegen deze taak. De nieuwe GNU programmaketen (binutils) ondersteunt cross-compiling, ELF, gedeelde bibliotheken, C++ extensies, enzovoort. Daarnaast leveren veel leverancierds ELF binaire bestanden en is het goed voor FreeBSD om het te draaien.

ELF heeft meer expressiemogelijkheden dan a.out en geeft meer uitbreidingsmogelijkheden aan het basissysteem. De ELF hulpprogramma’s worden beter onderhouden en geven de mogelijkheid tot ondersteuning voor cross compilatie, wat voor veel mensen belangrijk is. ELF is misschien iets trager dan a.out, maar het meten daarvan kan vrij lastig zijn. Er zijn ook ontelbare verschillen tussen de twee in hoe ze pages opslaan, initiële code verwerken, enzovoort. Geen van allen zijn ze erg belangrijk, maar er zijn verschillen. Na verloop van tijd verdwijnt de ondersteuning voor a.out uit de GENERIC kernel en uiteindelijk ook helemaal uit de kernel als de noodzaak voor a.out gebaseerde programma’s voorbij is.