Subject:
Re: GNU Linux Command Line Tools Summary Ready for inclusion
From:
Gareth Anderson ####@####.####
Date:
24 Feb 2005 23:43:45 -0000
Message-Id: <95da2288050224154378082442@mail.gmail.com>
Hi Michael, everyone else,
> > >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.
It will be fixed, the dictionary I used didn't ave such a clear
definition as what Emma showed me.
> > > 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.
> 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.
> ===
>
> <<
>
> 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.)
Yes, this can be fixed.
> 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.
And I did re-word it a little, but obviously not enough.
> 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.
> 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.
> 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.
> 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.
> 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.
> 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.
> 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.
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.
> 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?
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 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 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 will not cut huge numbers of commands out of the document because
some people consider them irrelevant.
Regards,
Gareth
Note: I can always take my documentation elsewhere if TLDP is just not
interested.
