Subject:
Re: GNU Linux Command Line Tools Summary Ready for inclusion
From:
"Michael T Kerrisk" ####@####.####
Date:
28 Feb 2005 02:40:03 -0000
Message-Id: <12188.1109558375@www33.gmx.net>
Hello Gareth,
[...]
> > > > Then I looks at "xargs". It was terrible. Your explanation is
> > > > wrong
> > > > and and the example with grep doesn't do what you claim. To
> > > > do what you
> > > > claim it does, one doesn't need to use xargs. Just type ls | grep
> > > > work. It's not hard to understand xargs but you claim
> > > > otherwise and fail to
> > > > explain what xargs does.
> > >
> > > I think I will remove xargs, for some reason I decided to leave it
> > > before.
> >
> > And yet xargs is rather more useful than much other stuff that you
> > do have in this document...
> >
>
> Please find me a suitable explanation of xargs. I've read 2-3 and they
> have not being very useful!
> I found them very confusing, attempting to re-write the explanations
> using manual pages and those references did not work well, as you have
> worked out by reading the explanations.
> People are welcome to contribute a better description if you think you
> can.
> Or I can reference one (link to it) if you can give me a URL.
This is part of the problem that I refer below, when I say you
are writing "beyond the limits of your knowledge". You do not
seem to know whether or not xargs is important enough to include,
and you have included it in the document without understanding
how it works.
> > Well you should. There are many errors in your document.
> >
> > Here's a sampling from a quick look at the document (I'm sorry, but
> > I am sure there are many more errors...):
> >
> > (Below, your text is enclosed in [[ ]] )
> >
> > ===
> >
> > Section 6.2
> >
> > [[
> > tr [A-Z] [a-z] < fileName.txt > fileNameNew.txt
> > ]]
> >
> > This example won't work because the arguments of tr are not
> > quoted.
>
> Then why does it work on my Mandrake, 9.1 and 10.1 box?
> Would it make you happier that I quote the arguments?
> And yes it WAS TESTED, like many of the commands listed.
Yes, but as pointed out by others, tested on the basis of
incomplete understanding.
By the way, in my quick glance earlier, I overlooked the fact
that the '[]' here is completely irrelevant. Again, you have
misunderstood how 'tr' works.
[...]
> > Section 7.
> >
> > [[
> > Examples for ls -d:
> >
> > ls -d */
> >
> > Lists all subdirectories of current directory.
> >
> > ls -d string*
> >
> > Lists directories that start with "string".
> > ]]
> >
> > The above explanations are simply wrong: ls -d means "display
> > information about the directory itself, rather than the files
> > it contains". ls -d does NOT limit the display to just
> > directories.
> >
>
> Unfortunately I could not find useful information on what exactly that
> option means, after looking in the man page.
So how did you come to choose to put this option in your
document?
> > Section 7
> >
> > [[
> > To remove files with special characters, for example, "da*d" type:
> >
> > rm -- da*d
> >
> > After the "--" it uses everything literally instead of using them as
> > standard wildcards. This may be useful when you need to delete a
> > filename
> > containing weird symbols (this also works on other tools...).
> > ]]
> >
> > The explanation of "--" is wrong. It means: "do not
> > interpret any of the following words that begin with "-"
> > as options"; it has no effect on wildcards.
>
> I stand corrected, the source from which that information came from
> must have being incorrect.
Or you misread it?
> > 11.7
> > [[
> > fgrep
> >
> > This version of grep calls grep with the -F option. This will look
> > for
> > literal strings only, it won't use or expand any kind of regular
> > expression.
> >
> > For example you could type:
> >
> > fgrep a$*b? file.txt
> > ]]
> >
> > The fgrep command above will fail because of lack of quoting.
>
> Correct again, my mistake, I likely used this information from a
> source without testing it correctly.
probably.
> > 16
> > [[
> > umask
> >
> > The umask is a value set by the root user of the system. It
> > controls the default permissions of any file created.
> >
> > It has an unusual way of doing things ...to set the umask you must
> > describe file permissions by saying what will be disabled.
> >
> > You can do this by doing 777 minus the file permissions you want.
> > Note that umask works with numbers only.
> >
> > Example:
> >
> > You want the default to be equivalent to chmod 750 (user has r/w/x,
> > group has r/x and other has no permissions), then the command you would
> > use would be:
> >
> > umask 027
> > ]]
> >
> > You do not understand umask. It is a per-process value.
> > Any user can set it in their shell session, and it will affect
> > commands executed by that shell session.
>
> I will attempt to fix this too.
>
> > Section 16.2
> >
> > [[
> > sticky bit
> >
> > Only the person who created the file may delete it, even if other
> > people have write permission
> > ]]
> >
> > No! The sticky bit only has a meaning like this for files
> > within a directory, and the bit is set on the directory itself.
> >
> Oops, my wording is very bad there.
>
> > Section 16.2
> >
> > [[
> > suid
> >
> > Allow SUID/SGID (switch user ID/switch group ID) access. You would
> > normally use chmod to turn this on or off for a particular file, suid
> > is generally considered a security hazard so be careful when using
> > this.
> >
> > Example:
> >
> > chmod a+s file_name
> >
> > This will give everyone permission to execute the file with the
> > permissions of the user who set the +s switch.
> > ]]
> >
> > No, the correct command here would be "chmod u+s"
> >
> My mistake, I don't know how that one slipped in.
>
> > 1. The scope of this document is far too great, and its focus
> > is weak.
>
> I don't agree with this, but I'm not sure I want to debate it again.
But (IMO) if you want to get acceptance into a peer-reviewed
documentation set, you do need to argue your position.
> > 2. The document cannot be read in any useful way sequentially.
> > (Do you intend that it should readable in this manner?)
>
> No its not designed to be read from start-to-finish. I was hoping that
> people would read the Introduction then jump to sections they wanted.
>
> > 3. It contains many technical errors, and certainly would
> > need *much* more technical review, **after its scope was
> > pruned down**.
>
> Scope will not be pruned.
And therein lies part of the problem. You have some knowledgeable
reviewers pointing out some defects, and you are saying: "I will
not listen".
Your document contains many more errors than David Lawyer and I
so far pointed out. I suspect David's response was similar to
mine: there are far too many errors to point them out without
consuming an enormous amount of his (my) time. Therefore,
point out a few, and note that this was was just a smapling, to
illustrate the greater problem.
> > 4. Many irrelevant commands are covered: in places the document
> > seems to be a random hodge-podge of things that you happen
> > to have encountered.
>
> I will likely disagree with your idea of what commands are relevant.
Yes, but see comments on peer review above.
> > 5. The nature of some of the errors I describe above (e.g., in
> > Section 16) makes it clear that in some places you are writing
> > past the limits of your knowledge.
>
> Yes, I am still learning GNU/Linux and finding a technical reviewer
> with a lot of skill is incredibly difficult.
Yes. And the problem is that the gap between "98% correct" and
"what you have so far learbed from your research" is still far
too great.
I leave aside the 2%, because that is what a technical
review might reasonably be expected to help you fix. As
the document stands, (IMO) the number of errors to fix
is simply too great for someone to devote the necessary
time to fix them.
> Knowledge is something aquired, I don't understand what you mean by
> "limts" of my knowledge. I did attempt to research things so I
> understood, obviously not enough is some areas.
I mean, you are attempting to produce a document that is in
some sense "authoritative", and to have it committed to a
peer-reviewed documentation set, without having sufficient
knowledge of the topic area you are describing. At least
two of your peers in this group are saying that this is not
sufficient. I have so far not heard anyone with a thorough
knowledge of the topic area who has taken a long look at your
document and said that it passes in all respects the
requirements for admission to TLDP.
> > 6. As I long ago said, I still don't really understand
> > what the purpose of this document is, and how it differentiates
> > itself from other similar documents already in the tldp set.
> > (e.g., "Introduction to Linux"
> > http://www.tldp.org/LDP/intro-linux/html/
> > and the "Bash Guide for Beginners"
> >
>
http://www.tldp.org/LDP/Bash-Beginners-Guide/html/Bash-Beginners-Guide.html
> > )
> >
> Do either of these documents have a large reference to useful commands
> which you may like to know about?
> Do they attempt to describe in detail the commands in a simple fashion?
But your document does NOT deal in detail. It picks bits out
here and there. And in many cases, it is not clear why you
included some seemingly unimportant topics, while leaving
out other important topics. And the document contains too
many errors.
> That's the aim of my howto.
>
> Both are great documents, Bash Guide for Beginners seems to look at
> shell scripting in particular.
> Intro to Linux is aimed towards teaching the basics of Linux.
> Including basic commands, not a large variety of commands which they
> may later come across or wish to use.
>
> I would like a vote from TLDP subscribers whether I should continue
> work to get this document into TLDP.
I'm not sure that's how the TLDP works.
> I am happy for it to continue to be hosted on Chris Karakas's website
> otherwise, http://www.karakas-online.de/
>
> And if TLDP is willing to allow this document, I will be looking for a
> technical reviewer to find errors.
I think the process rather works like this: reviewers offer input
on the document, and then the TLDP accepts the document. You seem
to imply the converse.
> I have tried many times to find all errors in the document, but I
> always miss them, its pointless me reviewing my own document again as
> I can't really find my own errors here.
>
> And I am asking whether TLDP will accept the document as is with any
> errors repaired.
I don't think it should: there are simply far too many errors.
But this is just my opinion.
> I will not cut huge numbers of commands out of the document because
> some people consider them irrelevant.
Again, please see my comments on peer review above. I'm not
saying that you must *necessarily* make the changes I suggest.
But your some of your responses seem to indicate that you
won't listen to reviewer feedback.
Cheers,
Michael
--
Michael Kerrisk
####@####.####
Lassen Sie Ihren Gedanken freien Lauf... z.B. per FreeSMS
GMX bietet bis zu 100 FreeSMS/Monat: http://www.gmx.net/de/go/mail
