discuss: GNU/Linux Command-Line Tools Summary needs either reviewing or acceptance
Subject:
Re: GNU/Linux Command-Line Tools Summary needs either reviewing or acceptance
From:
David Lawyer ####@####.####
Date:
14 Dec 2003 18:44:47 -0000
Message-Id: <20031214184402.GA450@lafn.org>
> (quoting David Lawyer)
> ">I took a quick look at it and would reject it due to it's scope. The
> >language seems good and it seems to be technically correct. But it
> >needs many more references and links, and needs to remove some tools
> >while adding many others"
On Sat, Dec 13, 2003 at 06:48:48PM +1100, Guru - wrote:
> Remove which ones? Add what? Its useless making comments like that, its the
> same as me looking at a HOWTO and saying, language could be better oh and
> remove stuff/add stuff, useless comments.
I'm not going to help you revise the document because:
1. I don't have time
2. I'm not qualified to write such a document
3. Even if I gave you a lot of help and became a coauthor, I would not
recommend the doc for the LDP collection. That is, unless we spent
hundreds of hours researching the topic further.
A major problem is that of scope. A major consideration is that what
you cover is already covered in many other documents: in man pages, in
info pages, in howtos on the Bash shell, in System Admin guides
(including Debian's) and in most HOWTOs. In Linux, one first learns the
basic commands. Then if one decides to say, set up a network, they go to
documentation about networks and learn more commands there concerning
networks. It's like this for other tasks too. Just taking a small
subset of commands (some elementary, some advanced) and writing about
them doesn't make a very useful HOWTO.
So what I suggest is that you just cover basic commands (and
change the name to reflect that). Check first to see if there is
already free documentation on this topic. Then you might mention some
more advanced commands but refer to other documentation on how to use
them. This would be intended to be read by a newbie or by someone who
wants to review the basic commands. You might look at print books on
Linux and see what commands they consider to be the most important.
However, referencing an out-of-date HOWTO isn't a good idea, so you need
to evaluate what you reference.
>
> ">One especially egregious error was only mentioning tar as the only
> >backup tool. Today tar is one of the worst backup tools and a number of
> >better ones are available. So to do it right, one needs to study and
> >compare all the numerous backup and mirroring programs and compare them
> >-- a considerable task. The result could be a HOWTO on backup."
> I was hoping that people would write these parts, I don't need a
> full-guide to backing stuff up only a mention of the tool and very
> rough syntax, usually within less than ten lines. I could *rename*
> that section. If there looking for a backup howto then they will look
> for one, they are not going to look only at my HOWTO.
Unfortunately, I don't think we have a satisfactory backup howto. So
you need to reference various man pages and provide an annotated list
of the various backup programs. Quite a job.
> My howto is not supposed to superseed all other documentation only
> point the user in a direction.
>
> >There are many thousands of command line tools (especially since the
> >author has classified editors as tools which is likely correct). To
> >cover tools adequately would take thousands of pages. But a more brief
> >overview would select only the most important tools. But this hasn't
> >been done. Space is devoted to module tools, but handling modules is
> >supposed to be automatic and this isn't explained.
> Yes I've been considering removing that section for a long time, I'll
> get around to it next release. I have only chosen tools which would
> have a purpose, I'm not trying to document every existent tool as
> stated in the abstract and introduction.
>
> >Thus I think that about 10 times more work is needed to create a good
> >command line tools howto.
> Well feel free to create one if you think you can do that kind of job.
> I'll just stick with my own work. Oh and if your talking about
> references, why not suggest some? Try to avoid anything controversial
> though.
I've answered this previously. But thanks for your efforts and I hope a
really good HOWTO is the final result.
David Lawyer
