ls(1) new command line options '-/' and '-%': CIFS system attributes support [PSARC/2007/394 FastTrack timeout 07/11/2007]

[Don Cragun]

>Date: Tue, 03 Jul 2007 18:09:49 +0100
>From: Darren J Moffat <Darren.Moffat at sun.com>
>
>Don Cragun wrote:
>>> Date: Mon, 02 Jul 2007 13:17:06 +0100
>>> From: Darren J Moffat <Darren.Moffat at sun.com>
>>>
>>> Was consideration given to just extending the meaning of -V so that it 
>>> also displayed system attribute info as well as the verbose ACL ?
>> 
>> Yes.  The project team chose not to do that because it could break
>> scripts that are using ls to process ACLs.
>
>Is the syntax of the -v an -V ACL display defined in PSARC/2006/043 
>actually intended to be and given a taxonomy that allows for parsing ? 
>That arc case doesn't actually say what stability the output has.
>

The project team for this case noted that all of the output produced by
ls before PSARC/2006/043 was approved was standard, stable, or
committed.  Since 2006/043 didn't say otherwise, the it was assumed the
output added by that case was also committed.  If the ARC would like to
amend 2006/043 to make the -v and -V output be clearly intended only
for human readable uses, I believe the project team would be willing to
add -/c output to -v and -V and drop the -/ option.  But, there is
still the question of how to specify compact versus verbose extended
system attribute output format.  Would you also want to add an option
argument to -v and -V at this point?

>Also given that it is really still quite new and currently only applies 
>to ZFS and NFSv4 anyway (for -V) I think the risk of extending it is 
>minimal and would be my preferred outcome.
>
>One has to know what the underlying filesystem actually is to know what 
>output style you will get from -v and -V (UFS,TMPFS,NFSv3 will give very 
>different output than NFSv4 and ZFS) means that parsing the output of 
>ls(1) is very complex and IMO unlikely to be reliable anyway.
>
>-- 
>Darren J Moffat