On Friday 19 December 2008 15:28:40 Anselm Lingnau wrote: > Here's another one of those »how much« questions. > > Objective 103.7 mentions »sed« (and used to in the previous version) under > the heading of »Search text files using regular expressions«. The objective > heading does not appear to cover anything other than searching, in which > case > > $ sed -n /foo/p file1 file2 file3 > > does pretty much what > > $ grep foo file1 file2 file3 > > gives you already (modulo differences in RE syntax and expressive power). > If that is so, then what *other* uses of sed did the authors of the > objective have in mind to warrant its inclusion? The objective text does > say »manipulate files and text data using regular expressions« even though > the title only mentions searching. Does that mean »sed > s/.../.../«? »sed /.../c...?«? > > (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. 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. 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 :-) 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 lpi-examdev@lpi.org http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
