On Dec 19, 2008, at Dec 19, 2008 -2:42 PM, Alan McKinnon wrote: > On Friday 19 December 2008 15:28:40 Anselm Lingnau wrote: >> Here's another one of those »how much« questions. >> >> (I'm currently working on the RE part of our introductory docs. So >> far we >> have covered sed fairly extensively in the »shell programming« >> manual (the >> third in our old sequence), which according to our present planning >> is in >> LPI-102 territory. In the previous issue of our docs this wasn't as >> much of >> an issue as we didn't market the first two manuals as sufficient to >> pass >> LPI-101, which we intend to do now. I'd much rather not load the >> introductory manual with the sed chapter. I'd also rather avoid >> splitting >> the sed content in two. What to do?) > > I've never subscribed to the (in my opinion erroneous) common belief > that the > exam Objectives somehow represent a comprehensive curriculum to > teach Linux. > Somebody applied a Gordian knot and chopped the list of examinable > LPIC-1 > objectives in half to produce two exams of managebale length.
Hear hear, I agree with this, only I use the analogy of the entirety of the objectives being like that sausage that Belushi whacks in two in the SNL skit "Samurai Delicatessen", it's all just too much for a single exam so it had to be come two exams. Initially the order of topics on the exams were quite random, with things like X in the first exam, now they are more reasonable and sensible in what appears in each exam. > I would put the sed chapter wherever it makes the most sense in your > *teaching* plan and to hell with how this maps to the objectives. > Besides, > your students are not going to come to class, read the manuals and > be able to > pass right there and then. What they will do is use the material and > at some > time in the future achieve enough expertise to pass both LPIC-1 > exams, and my > observation is that they achieve this for 101 and 102 at roughly the > same > time. So it doesn't matter where you put sed as long as it's there > and is > comprehensible to the student when he reads it, and that the > prerequisites to > even understanding sed are already in place. if you don't do this, > you are no > longer teaching but have gone over to the dark side where the MCSEs > live. Alan, you make good sense here, I usually teach them sed as a more complex and powerful version of the searching they already learned in VI, (you know :s/this/that/g) that way it's a next level up discussion, not a cold hard "you will learn sed or fail the exam" type of discussion. You are spot on with the students having to learn a certain amount before they can pass either exam, and usually by the time they are ready for 101, they're 50% or more ready for 102. Having taught bootcamps where they _will_ be passing or punting the exam that week, I can definitively say that you can teach them 101 and 102, but you have to do it in such a way that you teach them how to use Linux, and be a sysadmin, not by the objectives. In my Examcram, I refused to even list out the objectives, but based the chapters on each topic, and didn't care if I taught them Regex's early on in the game, it just had to make sense and be in context. > having said that, I think the intended purpose of the objective is > to keep > things at a basic level, similar to shell history as discussed > recently. I > gauge this around what the user will expect to find in shell and init > scripts. This is unavoidable whereas him actually *using* it is > avoidable, > even if he has to resort to nano :-) I usually show (and humorously threaten them with having to read) the Sed and Awk O'Reilly book and then offer to shortcut the process by just talking about it, a "CLEP" option for sed if you will. I put it roughly this way: "sed is a string editor, it's designed to make changes to a string, or a line of text, and it performs whatever action you tell it to on a single line, or all lines in the file, one after the other. You can put multiple beads on the string with the -e option. So sed goes from left to right, just like you putting a bead on a string and sliding it along the string, whereas awk at a very basic level rearranges the order of things, and effectively goes up and down, or in columns, such as you deciding what fields you want to take from a file and make a new file out, and in what order." That's the basic premise, and I have had very good success getting people to use sed once they understand it in context. I usually do a lot of demo'ing of what it does at that point, using the watchdog.txt file. I also find that literally drawing a line and talking about how sed makes the changes helps, because you expand that to multiple lines with "g" and then draw awk lines to chop up the sed lines into fields, and they'll be nodding in comprehension in no time. > My definition of minimum expertise with sed (from trawling some > decent scripts > written by others is: > > searching text from stdin with s/ > search and replace text from stdin with s/.../... > use of 'g' in replace function > use of -f parameter > use of -e parameter > use of -r parameter, but only if extended regexes is part of some > other > objective > addresses, especially from line x to line y > the Red Hat training materials give examples of regexes in the address > definition, which is very useful and I would argue for it's > inclusion here. > > -- > alan dot mckinnon at gmail dot com > _______________________________________________ > lpi-examdev mailing list > [email protected] > http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev _______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
