discuss: GNU Linux Command Line Tools Summary Ready for inclusion


Previous by date: 22 Feb 2005 12:37:31 -0000 Re: Preview of categories, Rahul Sundaram
Next by date: 22 Feb 2005 12:37:31 -0000 Re: Preview of categories, Stein Gjoen
Previous in thread: 22 Feb 2005 12:37:31 -0000 Re: GNU Linux Command Line Tools Summary Ready for inclusion, Gareth Anderson
Next in thread: 22 Feb 2005 12:37:31 -0000 Re: GNU Linux Command Line Tools Summary Ready for inclusion, Gareth Anderson

Subject: Re: GNU Linux Command Line Tools Summary Ready for inclusion
From: "Michael T Kerrisk" ####@####.####
Date: 22 Feb 2005 12:37:31 -0000
Message-Id: <12597.1109075824@www73.gmx.net>

Hello Gareth,

> > I just now reviewed the part on the vi and emacs editor.  It fails.  
> > vim
> > is not very difficult to learn if one learns only a small number of
> > commands.  
> 
> I will re-word it if I feel it is necessary (undecided for now).
> 
> >You say to search for other text editors on the Internet and
> > provide a link to sourceforge.  I used the link to sourceforge and
> > searched for "text editors".  Nothing found.  "vulnerable" should be
> > "venerable".
> 
> I will remove those links then.
> I believe I meant vulnerable but I could use a better word.

You better look up "vulnerable" in a dictionary.

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

> > Now don't just fix the 1% I've sampled.  Fix the other 99% too.  You
> > need to test out all examples to see it they work right.  You need to
> > read the man pages and search the Internet to see if you've got it
> > right.  I don't think you've done this.  Sorry to have to be so blunt
> > about it but I want to see good quality docs in LDP.
> 
> I will not dignify those comments with a reply.

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.

===

<<

Your explanation of the use of this operator completely misses 
the main point: it is for use in shell scripts. 

(The end-of-file word is not the same as typing control-D.)

===

Section 6.3.2

The notation:

    command_1 $command_2

for command substitution is simply wrong!  $command_2 will 
be treated as a *VARIABLE NAME*.  You must write:

    command_1 $(command_2)

I pointed this out in July 2004, when you first submitted 
this HOWTO to the list.

====

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.

===
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.

===

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.

===

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.

===

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.

===

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"

===

> I'll leave the decision upto the other 99% of people who make up the 
> TLDP.

As far as tldp is concerned, I carry no weight at all -- I'm 
just another subscriber on this list.  However, what I see 
is the following:

1. The scope of this document is far too great, and its focus 
is weak.

2. The document cannot be read in any useful way sequentially.
(Do you intend that it should readable in this manner?)

3. It contains many technical errors, and certainly would
need *much* more technical review, **after its scope was 
pruned down**.

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.

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.

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
)

Sorry, but I think this document needs *a lot* of work before 
it would be suitable in tldp.

Cheers,

Michael

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

DSL Komplett von GMX +++ Supergünstig und stressfrei einsteigen!
AKTION "Kein Einrichtungspreis" nutzen: http://www.gmx.net/de/go/dsl

Previous by date: 22 Feb 2005 12:37:31 -0000 Re: Preview of categories, Rahul Sundaram
Next by date: 22 Feb 2005 12:37:31 -0000 Re: Preview of categories, Stein Gjoen
Previous in thread: 22 Feb 2005 12:37:31 -0000 Re: GNU Linux Command Line Tools Summary Ready for inclusion, Gareth Anderson
Next in thread: 22 Feb 2005 12:37:31 -0000 Re: GNU Linux Command Line Tools Summary Ready for inclusion, Gareth Anderson


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