discuss: Thread: GNU Linux Tools Summary

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Fri, 9 Jul 2004, Michael T Kerrisk wrote:

> You snipped a question of mine -- and I think it cuts to the heart 
> of the problem with this document.  To rephrase: what is your aim, 
> and how are you achieving it in the document?

I've been asking myself the same.  
As I feel it, the author's aim is to have this document published into 
TLDP.  But TLDP has all sorts of objections.  So why not make two 
versions, one that you can keep completely as it is on your own site, 
as you want it, and a _real_ summary for TLDP, stating that this is the 
summary of the summary?  

Tille.

- -- 

My Penguin, my freedom.		http://tille.soti.org

Buy my books at fultus.com, amazon.com, amazon.co.uk or barnesandnoble.com!

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFA7jUzsIIUbMXbBA8RAg2fAJ9NPBoAXkQjMEphTOer040oPR7bRgCfe2fj
B3KQikjmnXXg7813PT0yHd0=
=550J
-----END PGP SIGNATURE-----

Hi,

"
>I think the point here is that these are commands that _you_
>might use now and then, but they are not on the everyday list
>of tools used by people.  TO be useful, your document needs
>to be selective.  Otherwise it's only a more useful than
>typing "mak -k ."
"
Point taken, I will clean it up more, and I think I might end up making a 
editors cut or something similar for TLDP. (Depends on what I decide, either 
cut the document down a lot, which I'm more likely to do, or create 2 
versions, which I don't want to do).


"
>Going back -- I see one command in there that is regularly
>useful to me: seq(1), for constructing for loops in shell scripts.
<snip>
>See my comment above.  These are tools that _you_ might use, but they
>are not of general interest (IMO, but I don't think I'd be alone in that
>opinion).
"
Hmm, I was going to avoid bash programming commands, but I could add them 
(but I'm not too familiar with bash programming, and that would possibly be 
a section).
Would you want that under mathamtical tools? Didn't people say remove it?

"
>You snipped a question of mine -- and I think it cuts to the heart
>of the problem with this document.  To rephrase: what is your aim,
>and how are you achieving it in the document?
>
>Cheers,
>
>Michael
>
"
Sorry, must have over-snipped :).

My aim was originally to create a list of commands I found useful, I think I 
took the useful thing too far and rather than document whats practical I 
documented everything I considered useful.

So I guess I should be aiming to document commands which are
a) Useful or likely to become useful to the majority of users.
b) Used by many users daily.
Of course the decision will end up being my own, (yes everyone will have a 
different judgement on what is useful).

However what I would like is opinions on what is useful and what is not 
(well I think I'll be getting some from the reviewer, but if anyone has time 
to provide this kind of feedback it will be appreciated).

Regards,
Gareth

_________________________________________________________________
Protect your inbox from harmful viruses with new ninemsn Premium. Go to   
http://ninemsn.com.au/premium/landing.asp?banner=emailtag&referrer=hotmail

Hi Gareth,

> "
> >I think the point here is that these are commands that _you_
> >might use now and then, but they are not on the everyday list
> >of tools used by people.  TO be useful, your document needs
> >to be selective.  Otherwise it's only a more useful than
> >typing "mak -k ."
> "
> Point taken, I will clean it up more, and I think I might end up making a 
> editors cut or something similar for TLDP. (Depends on what I decide,
> either 
> cut the document down a lot, which I'm more likely to do, or create 2 
> versions, which I don't want to do).

Yes, I think the latter option is undesiarable also; conversely, I 
would support a lot of trimming ;-).

> "
> >Going back -- I see one command in there that is regularly
> >useful to me: seq(1), for constructing for loops in shell scripts.
> <snip>
> >See my comment above.  These are tools that _you_ might use, but they
> >are not of general interest (IMO, but I don't think I'd be alone in that
> >opinion).
> "
> Hmm, I was going to avoid bash programming commands, but I could add them 

I do not mean that you should.

> (but I'm not too familiar with bash programming, and that would possibly
> be a section).
> Would you want that under mathamtical tools? Didn't people say remove it?

It's not essential.  I was really just emphasising that there is only 
one of those commands that I regulalrlyuse, and that was seq(1), and 
as you see, it's only for shell scripting.  I think it is right that 
you avoid that.  And yes, i said take out the math tools -- I don't 
know if anyone else also expressed such an opinion.

> "
> >You snipped a question of mine -- and I think it cuts to the heart
> >of the problem with this document.  To rephrase: what is your aim,
> >and how are you achieving it in the document?
> "
> Sorry, must have over-snipped :).
> 
> My aim was originally to create a list of commands I found useful, I think
> I took the useful thing too far and rather than document whats practical I

> documented everything I considered useful.
> 
> So I guess I should be aiming to document commands which are
> a) Useful or likely to become useful to the majority of users.
> b) Used by many users daily.

Well, frequently at least.

> Of course the decision will end up being my own, (yes everyone will have a
> different judgement on what is useful).

And that judegment should be based on experience and observation 
of what many people do.  See below.

> However what I would like is opinions on what is useful and what is not 
> (well I think I'll be getting some from the reviewer, but if anyone has
> time to provide this kind of feedback it will be appreciated).

Well, I think you've been getting some of that already?

Now, someone already did something like this in this thread, but 
I'll do my own version.  I like to keep a nice long history -- 10000
lines or so -- so let's filter it a bit:

history | sed -e 's/^ *[0-9]* *//' | tr '|' '\012' | \
    awk '{print $1}' | grep '^[a-zA-Z]' | sort | uniq -c | \
    sort -k1nr > h

Then I edited 'h' to remove some of my aliases and other 
irrelevant stuff, and pulled off the top 70 or so commands:

   1780 grep
   1239 cat
   1065 cd
    939 vi
    930 ls
    812 fg
    700 man
    407 wc
    405 cc
    230 make
    181 sed
    180 less
    174 for
    168 cp
    149 su
    142 rm
    122 sort
    119 find
    113 jobs
    102 mv
     92 telnet
     89 chmod
     81 diff
     81 egrep
     76 tar
     66 ps
     62 ssh
     58 bg
     54 mkdir
     50 netstat
     38 history
     37 df
     35 pwd
     32 od
     32 touch
     30 comm
     30 du
     30 tr
     30 uniq
     28 kill
     26 awk
     26 halt
     26 ping
     23 echo
     23 jobs
     21 file
     19 strace
     16 bunzip2
     16 gdb
     16 rpm
     15 scp
     14 stty
     12 sleep
     12 uname
     10 bc
      9 mount
      7 head
      7 tee
      6 alias
      6 script
      6 whereis
      5 ln
      5 umount
      4 rmdir
      4 sh
      3 date
      3 edit
      3 killall
      3 nice
      3 tail
      3 which
      3 yes

Looking at that list immediately reveals some of my biases:

1. I do a lot of C programming, so 'cc' (and probably 'vi' are 
   high on the list).

2. I not only read lots of man pages, I also patch them, so 'man' 
   is very frequent.

3. I grew up in the days before windowed workstations, so I 
   probably know and use job control much more than the average user.
   (fg, bg, jobs).

4. I'm always looking at other people's source code (grep, 
   find, cat).

Of course the above list doesn't include use keyboard keys like ^Z, 
^C, etc.

Now I don't claim the above list as being generally 
representatitive, but I think it should be a start -- especially 
if you could see what many other people's lists like this looked 
like.

There is still the question: what differentiates your document 
from existing HOWTOs?

I'll tell you one document that might have helped me a 
little when I first started out: a selected list of 
useful commands (not too long, but also not too short!), with a
brief explanation of what each does, and maybe one or two 
examples.  This might have more rapidlly given me an idea of
just what range of tools is available (gosh, the combination of
sort(1), grep(1), uniq(1), comm(1), is incredibly useful, and 
even more so when you throw sed and awk (or perl if you must), 
into the mix)and why I might use them, and then left me 
inspired to look at the relevant man pages.  (When I was 
starting out, I used to look at all the one line headers from 
man pages many times, just to get an idea of what was out there.)

But that's just me of course -- it's unclear to me quite if that's 
what you mean to do.  But I see that as one possible differentiator
from other HOWTOs.  Of course it would be quite a bit of work.

Cheers,

Michael

-- 
Michael Kerrisk
####@####.####

Hi,

For those who remember me, I'm back after probably one year or more of no
contact on the list :P.
I know many members disagreed and will continue to disagree with the way I
have written the GNU Linux Tools Summary or the contents itself.

I am simply writing to say that as far as I am concerned, I have completed
my work on it. I'm considering a little bit of work (like cleaning up that
new automatically generated index) but I'm unlikely to make further
modifications unless someone points out an error or something.

I have attempted to address previous criticisms as best I can, but like
anyone who devotes some spare time to voluntary work, I am no longer
motivated to continue work on this.

The (hopefully) final version of the document is currently sitting on Chris
Karakas's site (thanks Chris!):
http://karakas-online.de/gnu-linux-tools-summary/

If the TLDP is interested in hosting the document please contact me (I'm
still subscribed to the lists for now but I may unsubscribe in the future so
please CC me :)).
If anyone is interested in working on this (although I doubt anyone is),
I've being using Chris's lyxtox scripts which I know have setup on my
computer :). So editing the lyx file would be the smartest way to continue
working on this (contact me for more info). You'll find the scripts here:
http://karakas-online.de/mySGML/

If TLDP is interested in hosting this that would be great :). I'd probably
count this as more of a guide that a howto but the classification is the
choice of TLDP.

If TLDP is not interested thats also ok, the document is currently living on
Chris's site where it will likely stay for a while. Please have a look when
you have time and tell me what you think.

I've also found linuxtopia hosting this document, on a side-note does anyone
know how to contact them? They are hosting a version that is very out-of
date:
http://www.linuxtopia.org/online_books/gnu_linux_tools_guide/
 The only article I found about them said the webmaster was trying to sell
it back in the year 2000 (I've emailed webmaster(at)linuxtopia.org).

Anyway, thats all I really wanted to say, sorry about the length (as
always).

I wish all TLDP authors and everyone who has worked with the guide in the
past the best of luck in the future. Its fantastic to see people contribute
to open-source projects and I enjoyed my attempts to contribute something
back :). I hope TLDP continues to find new authors and contributors, things
seem to have gone a little quiet in the past 6-12months.
 I am hoping to contribute to Chris's lyxtox scripts if I get spare time
(I'm a full-time consultant now so time is more limited than a uni student
:)), this way technical documentation would be easier to create and the TLDP
could keep using docbook :).
 I am hoping that one day there will be an easier way to get things
installed (like lyxtox and its various requirements) and new TLDP authors
would not be forced to learn docbook.

Good luck to everyone,
Gareth

Hi,

For those who remember me, I'm back after probably one year or more of no
contact on the list :P.
I know many members disagreed and will continue to disagree with the way I
have written the GNU Linux Tools Summary or the contents itself.

I am simply writing to say that as far as I am concerned, I have completed
my work on it. I'm considering a little bit of work (like cleaning up that
new automatically generated index) but I'm unlikely to make further
modifications unless someone points out an error or something.

I have attempted to address previous criticisms as best I can, but like
anyone who devotes some spare time to voluntary work, I am no longer
motivated to continue work on this.

The (hopefully) final version of the document is currently sitting on Chris
Karakas's site (thanks Chris!):
http://karakas-online.de/gnu-linux-tools-summary/

If the TLDP is interested in hosting the document please contact me (I'm
still subscribed to the lists for now but I may unsubscribe in the future so
please CC me :)).
If anyone is interested in working on this (although I doubt anyone is),
I've being using Chris's lyxtox scripts which I know have setup on my
computer :). So editing the lyx file would be the smartest way to continue
working on this (contact me for more info). You'll find the scripts here:
http://karakas-online.de/mySGML/

If TLDP is interested in hosting this that would be great :). I'd probably
count this as more of a guide that a howto but the classification is the
choice of TLDP.

If TLDP is not interested thats also ok, the document is currently living on
Chris's site where it will likely stay for a while. Please have a look when
you have time and tell me what you think.

I've also found linuxtopia hosting this document, on a side-note does anyone
know how to contact them? They are hosting a version that is very out-of
date:
http://www.linuxtopia.org/online_books/gnu_linux_tools_guide/
 The only article I found about them said the webmaster was trying to sell
it back in the year 2000 (I've emailed webmaster(at)linuxtopia.org).

Anyway, thats all I really wanted to say, sorry about the length (as
always).

I wish all TLDP authors and everyone who has worked with the guide in the
past the best of luck in the future. Its fantastic to see people contribute
to open-source projects and I enjoyed my attempts to contribute something
back :). I hope TLDP continues to find new authors and contributors, things
seem to have gone a little quiet in the past 6-12months.
 I am hoping to contribute to Chris's lyxtox scripts if I get spare time
(I'm a full-time consultant now so time is more limited than a uni student
:)), this way technical documentation would be easier to create and the TLDP
could keep using docbook :).
 I am hoping that one day there will be an easier way to get things
installed (like lyxtox and its various requirements) and new TLDP authors
would not be forced to learn docbook.

Good luck to everyone,
Gareth

P.S. whats with the very dodgy looking email verification program? It looks
like spam...

Hi,

For those who remember me, I'm back after probably one year or more of no
contact on the list :P.
I know many members disagreed and will continue to disagree with the way I
have written the GNU Linux Tools Summary or the contents itself.

I am simply writing to say that as far as I am concerned, I have completed
my work on it. I'm considering a little bit of work (like cleaning up that
new automatically generated index) but I'm unlikely to make further
modifications unless someone points out an error or something.

I have attempted to address previous criticisms as best I can, but like
anyone who devotes some spare time to voluntary work, I am no longer
motivated to continue work on this.

The (hopefully) final version of the document is currently sitting on Chris
Karakas's site (thanks Chris!):
http://karakas-online.de/gnu-linux-tools-summary/

If the TLDP is interested in hosting the document please contact me (I'm
still subscribed to the lists for now but I may unsubscribe in the future so
please CC me :)).
If anyone is interested in working on this (although I doubt anyone is),
I've being using Chris's lyxtox scripts which I know have setup on my
computer :). So editing the lyx file would be the smartest way to continue
working on this (contact me for more info). You'll find the scripts here:
http://karakas-online.de/mySGML/

If TLDP is interested in hosting this that would be great :). I'd probably
count this as more of a guide that a howto but the classification is the
choice of TLDP.

If TLDP is not interested thats also ok, the document is currently living on
Chris's site where it will likely stay for a while. Please have a look when
you have time and tell me what you think.

I've also found linuxtopia hosting this document, on a side-note does anyone
know how to contact them? They are hosting a version that is very out-of
date:
http://www.linuxtopia.org/online_books/gnu_linux_tools_guide/
 The only article I found about them said the webmaster was trying to sell
it back in the year 2000 (I've emailed webmaster(at)linuxtopia.org).

Anyway, thats all I really wanted to say, sorry about the length (as
always).

I wish all TLDP authors and everyone who has worked with the guide in the
past the best of luck in the future. Its fantastic to see people contribute
to open-source projects and I enjoyed my attempts to contribute something
back :). I hope TLDP continues to find new authors and contributors, things
seem to have gone a little quiet in the past 6-12months.
 I am hoping to contribute to Chris's lyxtox scripts if I get spare time
(I'm a full-time consultant now so time is more limited than a uni student
:)), this way technical documentation would be easier to create and the TLDP
could keep using docbook :).
 I am hoping that one day there will be an easier way to get things
installed (like lyxtox and its various requirements) and new TLDP authors
would not be forced to learn docbook.

Good luck to everyone,
Gareth

P.S. whats with the very dodgy email verification program? It looks like
spam to me when I emailed this list from another address of myn....

Hi,

Apologies if you have received this email, I did not get a copy of this even
though I am getting the other TLDP emails on the list (please email if you
did get this before). I'm re-sending only to make sure its getting through.
I did not receive any replies to my last posting...

For those who remember me, I'm back after probably one year or more of no
contact on the list :P.
I know many members disagreed and will continue to disagree with the way I
have written the GNU Linux Tools Summary or the contents itself.

I am simply writing to say that as far as I am concerned, I have completed
my work on it. I'm considering a little bit of work (like cleaning up that
new automatically generated index) but I'm unlikely to make further
modifications unless someone points out an error or something.

I have attempted to address previous criticisms as best I can, but like
anyone who devotes some spare time to voluntary work, I am no longer
motivated to continue work on this.

The (hopefully) final version of the document is currently sitting on Chris
Karakas's site (thanks Chris!):
http://karakas-online.de/gnu-linux-tools-summary/

If the TLDP is interested in hosting the document please contact me (I'm
still subscribed to the lists for now but I may unsubscribe in the future so
please CC me :)).
If anyone is interested in working on this (although I doubt anyone is),
I've being using Chris's lyxtox scripts which I know have setup on my
computer :). So editing the lyx file would be the smartest way to continue
working on this (contact me for more info). You'll find the scripts here:
http://karakas-online.de/mySGML/

If TLDP is interested in hosting this that would be great :). I'd probably
count this as more of a guide that a howto but the classification is the
choice of TLDP.

If TLDP is not interested thats also ok, the document is currently living on
Chris's site where it will likely stay for a while. Please have a look when
you have time and tell me what you think.

I've also found linuxtopia hosting this document, on a side-note does anyone
know how to contact them? They are hosting a version that is very out-of
date:
http://www.linuxtopia.org/online_books/gnu_linux_tools_guide/
 The only article I found about them said the webmaster was trying to sell
it back in the year 2000 (I've emailed webmaster(at)linuxtopia.org).

Anyway, thats all I really wanted to say, sorry about the length (as
always).

I wish all TLDP authors and everyone who has worked with the guide in the
past the best of luck in the future. Its fantastic to see people contribute
to open-source projects and I enjoyed my attempts to contribute something
back :). I hope TLDP continues to find new authors and contributors, things
seem to have gone a little quiet in the past 6-12months.
 I am hoping to contribute to Chris's lyxtox scripts if I get spare time
(I'm a full-time consultant now so time is more limited than a uni student
:)), this way technical documentation would be easier to create and the TLDP
could keep using docbook :).
 I am hoping that one day there will be an easier way to get things
installed (like lyxtox and its various requirements) and new TLDP authors
would not be forced to learn docbook.

Good luck to everyone,
Gareth

P.S. whats with the very dodgy email verification program? It looks like
spam to me when I emailed this list from another address of myn....

Gareth Anderson wrote:

>Hi,
>
>Apologies if you have received this email, I did not get a copy of this even
>though I am getting the other TLDP emails on the list (please email if you
>did get this before). I'm re-sending only to make sure its getting through.
>I did not receive any replies to my last posting...
>
>  
>
Got the mail. My take on it is that LDP should accept and host the 
document and improve it incrementally rather than refuse to accept it.

>If TLDP is not interested thats also ok, the document is currently living on
>Chris's site where it will likely stay for a while. Please have a look when
>you have time and tell me what you think
>  
>
I have send in comments before and I will continue to look at it and 
send feedback when I get time.

> I am hoping to contribute to Chris's lyxtox scripts if I get spare time
>(I'm a full-time consultant now so time is more limited than a uni student
>:)), this way technical documentation would be easier to create and the TLDP
>could keep using docbook :).
>  
>
Congrats on that.

> I am hoping that one day there will be an easier way to get things
>installed (like lyxtox and its various requirements) and new TLDP authors
>would not be forced to learn docbook.
>  
>
I dont think anyone is forced to learn docbook now. You can continue to 
use any format you like and volunteers can help convert into Docbook if 
needed. We just care about the final format froma  single source.

Rahul

> Von: Rahul Sundaram ####@####.####
> 
> Gareth Anderson wrote:
> 
> >Hi,
> >
> >Apologies if you have received this email, I did not get a copy of this
> >even
> >though I am getting the other TLDP emails on the list (please email if
> >you
> >did get this before). I'm re-sending only to make sure its getting
> >through.
> >I did not receive any replies to my last posting...
> >
> Got the mail. My take on it is that LDP should accept and host the 
> document 

I thought the accepted practice in tldp was review *then* acceptance,
rather than the converse?  (The converse practice in the past has
resulted in some fiascos.)

> and improve it incrementally rather than refuse to accept it.

The document is enormous.  Therefore, I'm not sure if there is 
a notion of improving it incrementally, especially when the 
author has indicated that he is unlikely to do much further 
work on it.

Cheers,

Michael

-- 
Michael Kerrisk
####@####.####

"Feel free" mit GMX FreeMail!
Monat für Monat 10 FreeSMS inklusive! http://www.gmx.net

Hi,

Its great to see people are getting my messages on list, for some reason I
did not receive the original message I sent :( (I do receieve other peoples
messages that are sent to discuss excluding from the posts I have sent...).

In other words Please keep CC'ing me :).

I thought the accepted practice in tldp was review *then* acceptance,
> rather than the converse?  (The converse practice in the past has
> resulted in some fiascos.)


The problem is there were several partial reviews of this document. This
document is huge and having a single person review it is simply too
difficult. Excluding of course, myself who has reviewed it so many times I
can't count them :P

I do welcome a review but making changes would be difficult for me (unless
the reviewer has enough time to say "replace sentence XXX" with "sentence
YYY", which is probably not realistic. There is also the fact that different
reviewers have different opinions on how things should look, so one reviewer
may be happy with the current way it is while another will request changes.

Oh, I should mention that a number of people did previously say the document
will be accepted when finished after they did their reviews, in other words
it was accepted (off list if I recall correctly), but it has changed and
those people may have moved on from TLDP.

That was a long time ago, and others dis-agreed with adding the document at
all (a long story), I've attempted to fix the complaints from those who said
it should not be added as best as I could.

The document is enormous.  Therefore, I'm not sure if there is
> a notion of improving it incrementally, especially when the
> author has indicated that he is unlikely to do much further
> work on it.
>

Yes, there's another major problem. I'm sure if you have a quick read:
http://karakas-online.de/gnu-linux-tools-summary/

You will see the document is of a high quality, but not perfect, as I'm sure
no document is.

I have carefully stated in the "Who would want to read this guide" section:
"This guide is aimed at beginners to intermediate users who want to learn
about the commandline tools available to them. Advanced users may wish to
use it as a command reference, however this document aims to list
*****commands of interest, as judged by the authors opinion, it is not
designed to be completely comprehensive*****, see the appendix, Section
A.2.1<http://karakas-online.de/gnu-linux-tools-summary/further-reading.html#GENERAL-FURTHER-READING>for
further information."

If you see the sentence enclosed in ******'s, you will see that this is how
the document was written and it was a major point of concern in previous
reviews and debate.

If you do intend to review the document, I would recommend you review the
general style of the document rather than try to review the entire thing (I
know the normal procedure is to review the entire document, but I don't
think it is realistic unless we break into into parts and have lots of
people with spare time and motivation to review it).

Also I would like everyone to keep in mind that I haven't really seen any
documentation like this so you may like to keep that in mind when you review
it...

Regards,
Gareth