lesson four

One of the tools Michiel has given me to help me learn is a book; “Linux Start Up Guide” by Fred Hantlemann. I’ve been reading some of it before i went to bed the last few nights (to be truthfully honest, mostly because reading just a couple of pages has me snoring before i know it. Its not boring or anything, more that.. well, mention words like “variables” and my eyes start closing of their own accord. annoying, really), and finally got to the point where, really, i had to start trying some of what i was reading if i was to make any sense of it (you know, the old “Tell Me I will forget, Show Me I will remember, Involve Me I will understand!”).

So Chapter 3 (”Operating Linux”) so far has had me using the whoami, the who am i, the id and the set commands, the ps -al command, the ls one (which i knew already) and ls /usr/bin | more, and more /var/log/debug which gave me a rude reply about not having access. well to you too matey.

It then went into detail about how to move and copy files, using the cp and mv commands, and how to make a directory (mkdir).

Then it started in on Vi. Now, this i’d heard of: Michiel had gone to some effort to explain to me why emacs = bad and Vim (the uptodatebigbrother verson of Vi) is good. not that i was any the wiser, then, as i didn’t really understand what an editor was. to me, an editor is the person in charge of a magazine. So i went looking on the intertubewebthingie to see if i could understand it a bit better. Wikipedia was a start: it led me to a page on why Vi (pronounced Vee-eye, not Vie) was the greatest gift to man, and why some nutheads use Vi/Vim. (at which point i turned to Michiel and asked him, is Vi/Vim good? he said yes. so emacs is bad. at least, from his perspective. Do i agree? no idea. yet. :D) so i think i understand now, what an editor is. its a program that lets you write. you can write normal text (although you’d be better off using a word processor or something if that was all you wanted to do) but you can also write programs. However, there’s a catch. in order to execute (i.e. run) your new program you either have to use the command interpreter to execute the contents of it, or you can mark the file as an executable.

huh? okay.. whats the Command Interpreter? (reading these things is frustrating: you understand one thing and get 20 more questions). Well, that was the next bit of the book, funnily enough, and the bit that sent me back to the intertubesfount-of-all-info. According to the book, the job of a Command Interpreter is “to analyse, or interpret command lines entered by the user and start any programs cited”. well, hey, that sounds like konsole, which is what Michiel tells me to use when he wants me to do something (and i’m slowly getting less scared of). and this goes back to another conversation we had, where he tried (and failed, although not his fault) to explain the difference between konsole and Bash (as an example of a Command Interpreter). Wikipedia was my starting point (Its not for nothing i’m known as wikislut), although not terribly illuminating, it was thinking about what i’d read in the book and everything else i’d learned that finally clued me in: Bash will do a lot of the things Konsole does, but Bash does more than Konsole does too. Konsole will only run or execute files, Bash will do the analyzing part as well.

So.. to make a program you have to write it first in an editor like Vim (or the much hated emacs), then use a command interpreter to analyse it and get it to run. analyse.. meaning check it works? Maybe i’ve got my understanding totally wrong, but it seems like a terribly long winded way to go about it. why not one program that will do everything: write the code, check it for bugs, then execute it?

hmmmm. see what i mean? … understand something.. get more questions.. argh!!!

I’m going to go have a bath and think this through some more.