Subject:
Re: GNU Linux Command Line Tools Summary Ready for inclusion
From:
David Lawyer ####@####.####
Date:
25 Feb 2005 06:48:58 -0000
Message-Id: <20050225014648.GA1376@lafn.org>
On Fri, Feb 25, 2005 at 10:43:18AM +1100, Gareth Anderson wrote:
> Hi Michael, everyone else,
>
>
> > > > Then I looked 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!
They seem to be very useful except for one point. While the man page
does explain under what conditions the command after xargs gets executed
more than once, it doesn't seem to work exactly this way. You have to
experiment and check the Internet. I experimented and it seems that the
-i option allows the command to be repeated for each line of
arguments. But another option can override this. This should be
reported as a bug. So you should submit a bug report on the man page to
your distribution.
> 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 work you should do. Thus, to do it right takes a lot of work.
>
> > 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.
It works on my Debian with no quotes. But quotes are sometimes needed
to prevent expansion by the shell.
> >
> > 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/
From the sampling of it, it still need a lot of work. I would like to
see you continue to work on it.
> 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.
You might compare what you've written to printed books, the man pages,
etc.
> And I am asking whether TLDP will accept the document as is with any
> errors repaired.
I would vote to accept it if most all errors are found and fixed. But
that's a big task.
>
> 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.
Where would this be? Since the demise of the Open Source Writers Group
I don't think that there has been a competitor to LDP.
David Lawyer
