[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Some technical suggestions
>> perhaps:
>> alias howto="lynx /usr/doc/howto/html/index.html"
>
>A bit more finesse would be required, we cannot assume that everyone
>has Lynx installed, they might use any nomber of alternatives such as
>Netscape, Amaya etc. In fact we cannot be sure what form the HOWTOs
>are stored in, text, compressed text, HTML etc.
I agree about the reader, but I think the majority of people will have the
HOWTOs in html format, as this is what the distributions I've used seem to
default to. This is an assumption I used while writing my program.
>> Maybe even a command like howto multidisk would fire up the multidisk
>> howto, (as could man howto multidisk?)
>
>First we have to let people know it exists and where, then I guess
>tey will be able to read it with the appropriate tool such as
>less, zless, lynx, amaya or whatever they have. If they have the docs
>as HTML then a simple link would be all thta would be required to go
>from the search to the actual documents.
Yep.
>> This could also update a file called update.howto on the local machine
>> that said when each file had last been updated.
>
>The idea is intersting but also rather difficult. Few install
>raw HOWTOs temselves but rather use .rpm or .deb packages, and
>directly manipulating parts of such packages would be messy.
>Also it would mean that the LDP would have to make the package
>files rather than the distributors and I am not sure what people
>would think of that. Do we have the capacity to take on that
>task (not yet I think), and what does the current packaging
>maintainers think?
Once the package had been installed (from .rpm .deb etc..), wouldn't it be
easier to provide a program that can download only the updated files,
rather than creating a program that packages up only the files that have
been updated since the user last updated his HOWTO files, then downloads
this package and installs the package on the users computer.
>> > HELP FILES
>> > ==========
>> >
>> > I believe we need to add a SMALL text file into /etc/skel/ so all
>> > beginners get a starting point. How about this:
>>
>> also, the line:
>> For information on how to get help, type "less help.txt"
>> could be added to the motd. That way people would notice the file, and
>> realise that they can use it to get help on getting help.
>
>I don't agree on this. The motd should be kept lean and be a
>message for everyone, not just the beginners. A message on
>first logging in or an automated mail message should do the
>same trick I think.
This would give the user the command only once, and it could be easily
forgotten. If you see it often, it is more likely to be remembered.
Perhaps, on the first login the user could be presented with the option to
display the line everytime the user logs in, on not to display it at all.
Or we could look at it like the user who doesn't need help is the one who
knows everything, and if they know everything, they should be able to
manually edit the motd.
Perhaps putting the line in the ~/.bashrc would be a better place.
>Perhaps the LDP could make some presentation material for
>people to use in the LUG meetings?
That is a good idea.
>> If you'd like me to give coding an example "howto" program ago, let me
>> know, I don't think it'd be too hard in shell script.
>
>It could be interesting but also difficult if you want to make it work
>on a wide range of platforms, spanning numerous file formats
>(.txt, .txt.gz, .txt.bz2, .html), numerous readers (lynx, amaya, mc),
>and also several file locations depending on file standard used
>( /usr/doc/HOWTO/ and /usr/share/doc/HOWTO/ ).
I got bored, so started coding it last night. I should have a mostly
finished product by tonight, as I've just got a few more things to sort
out.
I'd tar it in its current state, and post it, but, I'm at college, and the
prog isn't. So I'll sort it out tonight.
cog
--
Replies to [email protected], please.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]