discuss: Review of GNU/Linux Tools Summary
Subject:
RE: Review of GNU/Linux Tools Summary
From:
"Guru -" ####@####.####
Date:
14 Dec 2003 06:47:58 -0000
Message-Id: <Sea2-F58R7CPRFMh7Yo00006b36@hotmail.com>
Hi rahul and everyone else,
>consistency: The document should state the syntax first and example
>second of vice versa for every command. If the command has a complicated
>syntax
>a simplified one can be presented. I find some commands has only example,
>some
>has only syntax and some has neither.
Yes, I realise this I haven't being able to create any kind of useful
example for commands.
I haven't decided whether I should keep both command syntax and example or
just replace the command-syntax wth example because the syntax is quite
generic and doesn't really change much from command to command.
You could get the same information from reading the first paragraph of a man
page on the command.
Any comments?
>
>References
>
>If there are other documents related to the topic the links should be
>presented
>within the section itself
Yes thats a good idea, I'll try and fit them in somewhere. The problem is
that often I don't know any good references (I was hoping people would
suggest some along with hyperlinks and short descriptions).
>Order and Grouping
>
>I find the order and grouping to be sub optimal. The commands which are
>more
>used should come first and they should be grouped with similar commands
>within
>the same section ex) netstat and nmap . In certain cases, it is not
>possible to
>determine which commands are used more and it can done arbitrarily while
>taking
>care of grouping only.
I've changed order and grouping many many times.
I'll try again to re-arrange them thats not a bad idea.
>1.1
>The introduction part to assume that the user is fairly technical. It would
>be
>better to avoid using technical terms as much as possible in the
>introduction
>especially so if the terms are explained within the documentation itself.
I'll try and work on it.
>It is not clear to me whether the document is meant for end users who want
>to
>understand the command line or newbie system administrators or somewhere in
>between.
Intermediate users, users with a basic understanding of the CLI and newbie
admins.
>1.2
>The audience section seems to overlap the introduction. For example the
>idea
>that it is not possible to list everything is expressed in both. While this
>is
>entirely true I find it redundant.
Yes, I've put it twice because people just don't get to seem the point.
I'll try make it a little better though.
>1.7
>
>It has explanations of package management starting with mandrake,
>redhat and then debian. It seems that redhat, debian and mandrake along
>with
>slackware is more appropriate based on popularity
>
>If the audience is a newbie it would be good to have a explanation of what
>a
>package manager does in a short manner
>
>For example " A package manager is a utility for centrally managing the
>installation, upgradation, removal and querying of software in the system"
>
>Also appropriate is an explanation of apt-get and yum(fedora).
I'll try and do apt-get and yum when I get time, this will require yet more
research... Ie. this could be a long time before I get around to it.
The re-ordering I can do fairly easily.
>There should be a differentiation between package management and dependency
>resolving tools.
How would you define a dependency resolving tool? Are you referring to
apt-get? and urpmi? and yum?
>2.Legal
>You have choosen the GNU FDL as the license. Here are some issues to
>consider
>http://www.google.co.in/search?q=cache:SErldDCN1KMJ:people.debian.org/~srivasta/
>Position_Statement.html+debian+fdl+position+&hl=en&ie=UTF-8
>
>Alternatives include the OPL(without restrictions) and Creative commons
>share
>alike license.
I'm waiting for the debate about licenses to finish before I do anything
about the license.
>3. The Unix tools philosophy
>
>It would be better to call it design rather than philosophy when it talking
>a
>hands on approach. Instead of using the word "Unix based" a better wording
>would
>be "Unix-like". Also acknowledge any trademarks as such.
Unix based is not always the correct word for it, its Unix-like not a copy
of Unix source.
>4. Shell tips
>
>You have used the word cntrl to specify control keys. I find ^ and ctrl to
>be
>more common usage. Considering using them instead if not specify the word
>"control" itself each time. This would make the document lend itself better
>as a
>reference.
I tihink cntrl vs ctrl is very minor although using the "^" symbol wouldn't
be a bad idea. I've seen it used more in techincal manuals so I might as
well start using it here. (I've seen the '-' used in many other places too),
also a minor issue...
>You can include a section about using back quotes too.
I already have one, section 6.3 "command substitution".
>4.1 Virtual terminals
>
>The explanation could include the difference between x the protocol and
>Xfree86
>the implementation (foot notes or references where appropriate).
Yes that might be a good idea, but thats starting to push outside the scope
of the document. So I don't think I'll add that.
>5.Help
>
>apropos is a alternative for man -k. It does not search whatis strings?
>A section on using konqueror and nautilus to view man and info pages might
>be
>considered even though this document is entirely about command line tools.I
>personally find konqueror to be a handy tool even when relying on the
>command
>line stuff to do the actual task. This way you can use info and man pages
>without relearning key bindings.
I'm not sure how you do it in Konqueror and nautilus, if you do know than
please tell me because I don't have enough space to install them on this
computer at the moment. And I don't have enough time to research everything
myself.
>8.Finding information about the system
>
>"(note: advanced, confusing and powerful command). " has been put up before
>xargs. I would find it more natural if this is including as a gentle
>warning
>within the body as the second sentence
Yes, point taken, or I could convert it to a warning or caution admonition.
>9.Controlling the system
>
>Echo command seems the odd man here. It is better to explain this along
>with cat
>as text manipulation. sed and awk can be included too.
Yes I probably overlooked moving it when I restructured the document for the
millionth time.
>9.2 Shutting down
>
>halt can be explained first followed by shutdown commands.poweroff can be
>included too.
I'm not familiar with poweroff, I'll have to check whether it exists on my
mandrake system.
>9.3 Controlling Processes
>
>ps aux | grep is a fairly common usage.
Yes I use it all the time, I think it might be listed under the ps section.
>kill -9 can be explained here.
Didn't I explain that under the description of kill?
>9.4 Controlling services
>
>service start, status and restart can be explained here
>update-rc.d is the debian equivalent?
>slackware?
Yes I'll check out the debian equivalent, this is the kind of feedback I
need. :)
>11. Text related tools
>
>Pico or nano might be appropriate for new user
Yes I could probably mention them I guess....(without starting some kind of
text-editor war on which ones should and shouldn't be mentioned).
>11.2 Text based tools
>
>The order of listing can be changed according the common usage.
>
>cat
>less
>tail (-f option is very common for real time lookups)
>sort
>.....
I'll try it.
But I'm not entirely sure on what order they are most often used in.
>11.3 Text manipulation utilities
>
>Again the order of listing can be changed.
Maybe people should start suggesting the new order... Because I'm not a
system admin, I'm a student and I don't use all these tools that often, only
occasionly.
>13.mathematical tools
>
>Python can come first here.
>
>An example of mathematical operation in python is appropriate.
Ok.
>15.Network commands
>
>Order and grouping can be changed.
How? I'm not sure what is used more often so I'll just be guessing.
>17.2 compression
>
>tar zxvf and tar jxvf are commonly used but not explained here.
>bzip2 is generally more efficient and should be mentioned.
I've should probably add them. bzip2 is mentioned! along with gzip!
>24. Mini guides
>
>Rpm is explained but debian and slackware systems could be added.
Yes but I don't know how they work and I'm not sure whether to keep the RPM
section or not...
Because there are a lot of tutorials written already on RPM, Debian,
slackware package management.
>links to more comprehensive documentation like maxrpm guide and debian
>guides
>could be added.
Yes, if you could see the notes (only avaliable when viewing the document in
LyX), I need links to guides like that because I haven't read them, I don't
know where they are and I don't know what there called.
Regards,
Gareth
_________________________________________________________________
E-mail just got a whole lot better. New ninemsn Premium. Click here
http://ninemsn.com.au/premium/landing.asp
