yes, i'm sure i'm about to embarrass myself here but i just checked some directory perms created while root and they display as
drwxr-xr-x. ^ ????
what's that period? i've never seen that before. or have i just not been paying attention?
rday --
======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA ========================================================================
On Tue, 2009-03-03 at 09:34 -0500, Robert P. J. Day wrote:
yes, i'm sure i'm about to embarrass myself here but i just checked some directory perms created while root and they display as
drwxr-xr-x. ^ ????
what's that period? i've never seen that before. or have i just not been paying attention?
I think it is an extended attribute.
try running getfattr on the file.
-sv
seth vidal wrote:
On Tue, 2009-03-03 at 09:34 -0500, Robert P. J. Day wrote:
yes, i'm sure i'm about to embarrass myself here but i just checked some directory perms created while root and they display as
drwxr-xr-x. ^ ????
I think it is an extended attribute.
try running getfattr on the file.
I thought that was a plus (+) when file ACLs were present.
-Doug
On Tue, 2009-03-03 at 11:29 -0500, Douglas E. Warner wrote:
seth vidal wrote:
On Tue, 2009-03-03 at 09:34 -0500, Robert P. J. Day wrote:
yes, i'm sure i'm about to embarrass myself here but i just checked some directory perms created while root and they display as
drwxr-xr-x. ^ ????
I think it is an extended attribute.
try running getfattr on the file.
I thought that was a plus (+) when file ACLs were present.
That's what "info ls" says (though "man ls" doesn't). I can't see any reference to a '.' as part of the mode.
poc
On Tue, Mar 3, 2009 at 11:37 AM, Patrick O'Callaghan pocallaghan@gmail.com wrote:
I thought that was a plus (+) when file ACLs were present.
That's what "info ls" says (though "man ls" doesn't). I can't see any reference to a '.' as part of the mode.
File a bug? info and man really ought to return the same information.
Regards,
On Tue, 2009-03-03 at 16:54 -0500, Michel Salim wrote:
On Tue, Mar 3, 2009 at 11:37 AM, Patrick O'Callaghan pocallaghan@gmail.com wrote:
I thought that was a plus (+) when file ACLs were present.
That's what "info ls" says (though "man ls" doesn't). I can't see any reference to a '.' as part of the mode.
File a bug? info and man really ought to return the same information.
I decided to report this, but I can't figure out which component to file it against. There a BZ page for documentation bugs, but nothing specifically mentions man pages (or info). Or is one expected to file it against the actual command ('ls')?
poc
Patrick O'Callaghan wrote, On 03/05/2009 10:19 AM:
On Tue, 2009-03-03 at 16:54 -0500, Michel Salim wrote:
On Tue, Mar 3, 2009 at 11:37 AM, Patrick O'Callaghan pocallaghan@gmail.com wrote:
I thought that was a plus (+) when file ACLs were present.
That's what "info ls" says (though "man ls" doesn't). I can't see any reference to a '.' as part of the mode.
File a bug? info and man really ought to return the same information.
I decided to report this, but I can't figure out which component to file it against. There a BZ page for documentation bugs, but nothing specifically mentions man pages (or info). Or is one expected to file it against the actual command ('ls')?
poc
According to some posts by Adam Williamson and Jerry Amundson, a few days ago: locate ls > /tmp/lslocated #revel where the ls info page is at: grep /ls /tmp/lslocated |grep info #revel where the ls man page is at: grep /ls.[0-9].gz /tmp/lslocated
rpm -qf --qf '%{SOURCERPM}\n' info_location rpm -qf --qf '%{SOURCERPM}\n' man_location
and file against the appropriate package(s) by source rpm.
Once upon a time, Patrick O'Callaghan pocallaghan@gmail.com said:
I decided to report this, but I can't figure out which component to file it against. There a BZ page for documentation bugs, but nothing specifically mentions man pages (or info). Or is one expected to file it against the actual command ('ls')?
BZ entries are filed against the source package that provides the program in question. You can find that with (in bash):
$ rpm --qf '%{sourcerpm}\n' -qf $(type -P ls) coreutils-6.10-33.fc9.src.rpm
Note that the first "qf" has two dashes before it while the second has one dash.
So, you'd file a bug with "ls" against "coreutils".
"MS" == Michel Salim michel.sylvan@gmail.com writes:
MS> File a bug? info and man really ought to return the same MS> information.
This would be abnormal for most, perhaps all, of the GNU utilities. The manpages all contain only short summaries of options and refer to the info pages for complete documentation. The ls manpage doesn't even begin to discuss the output format. It's not merely missing mention of this additional dot.
If you want to open a discussion of whether these abbreviated manpages are problematic, feel free, but this isn't an isolated property of the ls manpage. I imagine this discussion has been had repeatedly in various other fora in any case.
- J<
On Thu, 2009-03-05 at 10:07 -0600, Jason L Tibbitts III wrote:
"MS" == Michel Salim michel.sylvan@gmail.com writes:
MS> File a bug? info and man really ought to return the same MS> information.
This would be abnormal for most, perhaps all, of the GNU utilities. The manpages all contain only short summaries of options and refer to the info pages for complete documentation. The ls manpage doesn't even begin to discuss the output format. It's not merely missing mention of this additional dot.
I actually though that might be the case. I don't think I'll bother after all.
If you want to open a discussion of whether these abbreviated manpages are problematic, feel free, but this isn't an isolated property of the ls manpage. I imagine this discussion has been had repeatedly in various other fora in any case.
As an old-school Unix hand I'm a firm believer on 'man' as the reference point for documentation, but I think I'm swimming against the tide. For example KDE has virtually no man docs (and precious few other docs). This is bad and it's going to get worse.
poc
On Thursday 05 March 2009 17:03:46 Patrick O'Callaghan wrote: ...
As an old-school Unix hand I'm a firm believer on 'man' as the reference point for documentation, but I think I'm swimming against the tide. For example KDE has virtually no man docs (and precious few other docs). This is bad and it's going to get worse.
In fairness, KDE is a GUI, and their help tool allows you to view man pages (and generally formats them quite well). The man/info thing annoys me a lot, because info pages gets formatted for 80 column text and left that; man pages on the other hand can be rendered to fit your terminal (as long as the size can be determined correctly :o)).
Patrick O'Callaghan wrote:
As an old-school Unix hand I'm a firm believer on 'man' as the reference point for documentation, but I think I'm swimming against the tide. For example KDE has virtually no man docs (and precious few other docs). This is bad and it's going to get worse.
Actually KDE has recently added several manpages, probably contributed by the Debian folks. (In Debian, manpages are mandatory even for GUI apps.)
Kevin Kofler
"RPJD" == Robert P J Day rpjday@crashcourse.ca writes:
RPJD> drwxr-xr-x. ^ ???? RPJD> what's that period? i've never seen that before. or have i RPJD> just not been paying attention?
From "info ls":
Following the file mode bits is a single character that specifies whether an alternate access method such as an access control list applies to the file. When the character following the file mode bits is a space, there is no alternate access method. When it is a printing character, then there is such a method.
GNU `ls' uses a `.' character to indicate a file with an SELinux security context, but no other alternate access method.
A file with any other combination of alternate access methods is marked with a `+' character.
- J<
On Tue, 2009-03-03 at 10:33 -0600, Jason L Tibbitts III wrote:
"RPJD" == Robert P J Day rpjday@crashcourse.ca writes:
RPJD> drwxr-xr-x. ^ ???? RPJD> what's that period? i've never seen that before. or have i RPJD> just not been paying attention?
From "info ls":
Following the file mode bits is a single character that specifies whether an alternate access method such as an access control list applies to the file. When the character following the file mode bits is a space, there is no alternate access method. When it is a printing character, then there is such a method. GNU `ls' uses a `.' character to indicate a file with an SELinux security context, but no other alternate access method. A file with any other combination of alternate access methods is marked with a `+' character.
I missed that because it's different in the F10 version of ls:
Following the file mode bits is a single character that specifies whether an alternate access method such as an access control list applies to the file. When the character following the file mode bits is a space, there is no alternate access method. When it is a printing character, then there is such a method.
For a file with an extended access control list, a `+' character is listed. Basic access control lists are equivalent to the permissions listed, and are not considered an alternate access method.
poc