Thanks for the details. I can see the usefulness of displaying all meta data together. I presume one can specify -e and -@ together also? More notes below...
On 04/21/2014 07:49 PM, April Arcus wrote: > Feature request per @pixelbeat_ ( > https://twitter.com/pixelbeat_/status/458221138964127745 ) > > Apple's fork of FreeBSD's ls supports the options -@ and -e to show extended > attributes and access control lists, respectively: > > Zephyr:~ ril$ /bin/ls -lFh -e ~ > total 2944 > drwxr-xr-x 4 ril staff 136B Feb 17 16:06 Applications/ > drwxr-xr-x@ 5 ril staff 170B Mar 31 20:39 Applications (Parallels)/ > drwxr-xr-x 156 ril staff 5.2K Nov 9 2011 CS3 Fonts/ > drwxr-xr-x@ 16 ril staff 544B Dec 11 23:35 Classic/ > drwx------@ 63 ril staff 2.1K Apr 19 14:35 Desktop/ > 0: group:everyone deny delete > drwx------+ 30 ril staff 1.0K Feb 17 15:47 Documents/ > 0: group:everyone deny delete > drwx------+ 179 ril staff 5.9K Apr 21 10:52 Downloads/ > 0: group:everyone deny delete So the extended attributes indicator '@' will override the ACLs indicator '+'. That's a general awkwardness about trying to indicate many things with a single character. In this case the ambiguity is resolved by also listing the ACLs. For reference GNU considers access meta data for this character, with . implying just a security context, and + indicating anything else (i.e. and/or ACLs). > Zephyr:~ ril$ /bin/ls -lFh -@ ~ > total 2944 > drwxr-xr-x 4 ril staff 136B Feb 17 16:06 Applications/ > drwxr-xr-x@ 5 ril staff 170B Mar 31 20:39 Applications (Parallels)/ > com.apple.FinderInfo 32B > drwxr-xr-x 156 ril staff 5.2K Nov 9 2011 CS3 Fonts/ > drwxr-xr-x@ 16 ril staff 544B Dec 11 23:35 Classic/ > com.apple.FinderInfo 32B > org.BasiliskII.ExtendedFinderInfo 16B > org.BasiliskII.FinderInfo 16B > drwx------@ 63 ril staff 2.1K Apr 19 14:35 Desktop/ > CDQJEIS1UO5TGNv0Q2Y_dvi9Ui8Oe2bc= 235B Interesting. In this case you wouldn't know that Desktop/ had ACLs, so personally I would have changed the '@' to '+' in this case as displaying the xattrs would resolve that ambiguity. > drwx------+ 30 ril staff 1.0K Feb 17 15:47 Documents/ > drwx------+ 179 ril staff 5.9K Apr 21 10:52 Downloads/ > coreutils ls can detect the presence of an ACL, but cannot display it, and is > oblivious to xattrs: > > Zephyr:~ ril$ /usr/local/Cellar/coreutils/8.22/bin/gls -lFh ~ > total 1.5M > drwxr-xr-x 4 ril staff 136 Feb 17 16:06 Applications/ > drwxr-xr-x 5 ril staff 170 Mar 31 20:39 Applications (Parallels)/ > drwxr-xr-x 156 ril staff 5.2K Nov 9 2011 CS3 Fonts/ > drwxr-xr-x 16 ril staff 544 Dec 11 23:35 Classic/ > drwx------+ 63 ril staff 2.1K Apr 19 14:35 Desktop/ > drwx------+ 30 ril staff 1020 Feb 17 15:47 Documents/ > drwx------+ 179 ril staff 6.0K Apr 21 10:52 Downloads/ > > I am currently using a kludgy shim to dynamically switch between BSD and GNU > ls depending on the passed in flags ( > https://gist.github.com/AprilArcus/11124713 ) - it would be great if > coreutils supported these features, so that I could stop doing this ^^ So something that might be useful as a first step to both ls(1) and stat(1) would be to at least indicate the presence of extended attributes. Note often security contexts and ACLs are implemented using extended attributes, to that would further complicate things. I don't know the implementation details of ACLs on HFS+ for example, and whether they're separate. thanks, Pádraig.
