On 16/10/2017 01:40, Anselm Lingnau wrote:
> Bryan Smith wrote:
>
>> I think it's more important to get away away from "choice" and
>> "opinion," and first try to define what the LPI Objectives should be
>> focused on -- before even attempting to evaluate the tools.
>
> I'm 100% in favour of getting rid of editors altogether in LPIC-1, on the
> grounds that:
>
> (a) there is no clear consensus on which editor(s) should be covered, and
> there is certainly no consensus of any kind as to which specific editor
> is “best” for day-to-day use on Linux,
>
> (b) it is easy to pick up enough practical knowledge of any editor to be
> able to use it for basic tasks, either through something like “vimtutor”
> or by simply using something more intuitive such as pico or nano for
> a while,
>
> (c) having separate exam questions for a basic skill which is crucial
> to getting anywhere with huge swathes of the rest of the subject matter
> (anything that involves editing files) is a waste of exam questions
> that could be used more profitably elsewhere, and
>
> (d) exam questions on editors tend to look silly, anyway.
>
> Having said that, I could live with a weight-1 objective that basically
> covered awareness of different types of editors (stream-based,
> terminal-based,
> GUI, IDE, …) and their relative strengths and weaknesses but not how to use
> any particular editor.
>
> It is reasonable to assume that class instructors will, if necessary, spend
> some time getting participants familiar with a suitable editor even if that
> editor is not specifically part of the examined content, simply because being
> able to use *some* editor is necessary for other things. When I was a Linux
> instructor I would simply let people play around with “vimtutor” for half an
> hour, which gave me time to read the newspaper. This makes sense whether or
> not the exam contains actual questions on vi, but not having questions on vi
> in the first place enables an instructor to pick the editor that is best
> suited to the requirements of their class (which might well end up being vi
> but then again might not).
You could then argue that LPI coverage of vi{,m} reduces to two things:
- how to change EDITOR to whatever you choose to use
- How to exit vi{,m} when invoked (often via EDITOR)
Everything else can be worked around.
Coming back to your weight=1 statement, that could work. Lump ex, sed,
vi and others all into the same category and test elements that are
often found in scripts such as the venerable s/.../.../g
--
Alan McKinnon
[email protected]
_______________________________________________
lpi-examdev mailing list
[email protected]
http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
