discuss: GNU Linux Tools Summary


Previous by date: 12 Jul 2004 07:58:08 -0000 Re: LSM in Bordeaux], doug jensen
Next by date: 12 Jul 2004 07:58:08 -0000 Re: [Fwd: Re: LSM in Bordeaux], Jean-PhilippeGuérard
Previous in thread: 12 Jul 2004 07:58:08 -0000 Re: GNU Linux Tools Summary, Guru -
Next in thread: 12 Jul 2004 07:58:08 -0000 GNU Linux Tools Summary, Gareth Anderson

Subject: Re: GNU Linux Tools Summary
From: "Michael T Kerrisk" ####@####.####
Date: 12 Jul 2004 07:58:08 -0000
Message-Id: <24898.1089619061@www57.gmx.net>

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
####@####.####


Previous by date: 12 Jul 2004 07:58:08 -0000 Re: LSM in Bordeaux], doug jensen
Next by date: 12 Jul 2004 07:58:08 -0000 Re: [Fwd: Re: LSM in Bordeaux], Jean-PhilippeGuérard
Previous in thread: 12 Jul 2004 07:58:08 -0000 Re: GNU Linux Tools Summary, Guru -
Next in thread: 12 Jul 2004 07:58:08 -0000 GNU Linux Tools Summary, Gareth Anderson


  ©The Linux Documentation Project, 2014. Listserver maintained by dr Serge Victor on ibiblio.org servers. See current spam statz.