On Tue, Aug 21, 2007 at 08:59:28PM +0200, Vincent Lefevre wrote:
On 2007-08-21 13:23:53 -0400, Michael Stone wrote:
No. It's fundamental to how unix systems behave, and is not useful to
document on every man page.
If it's so fundamental, why don't the ls and stat command dereference
symlinks by default?
Did you even look at the linked posix documentation? ls is specifically
called out as an exception on various grounds, and explains that this is
for compatibility with historical systems. (And since it does deviate so
much for normal symlink handling, the man page explains its behavior.)
Why are there bugs in various commands (the chmod
command from the coreutils,
I'm not aware of a bug in chmod.
chgrp from zsh)?
People make mistakes, may not be aware of the standards language, or may
feel that they've got a better way to do things.
(Unless otherwise specified, the target of the symlink is operated
upon, rather than the symlink itself.)
Where is this documented?
http://www.opengroup.org/onlinepubs/009695399/xrat/xbd_chap03.html#tag_01_03_00_57
The POSIX standard is not the man pages. The man pages should be
self-contained. Or for the same reason, you could remove all what
is defined by POSIX (such as the description of the -a option for
'touch').
Why on earth would coreutils include a man page for "fundamental
concepts of unix systems"? It's simply out of scope for this package.
You can argue for putting such documentation in another package
installed by default, but I'm not aware of any such that's free (POSIX
isn't).
Note that the POSIX man pages also don't explain the fundamental
concepts, they're in a seperate rationale document (so your absurdam
argument about the -a option is spurious).
The man pages can't explain everything. There's nothing in the ls man
page that tells you what a file is, what a directory is, what a symlink
is, etc., even though it uses those terms. *And that is a good thing.*
You're expected to have a basic knowledge of the concepts before you
read the man page, and that's not something that's likely to change.
Mike Stone
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
