>If I understand you correctly, "-xattr regex" is true if the file has
>an extended attribute whose name is matched by "regex".
>- Is the matching case sensitive? (Is there any reason for it to be
> case-insensitive?)
I initially made it case-insensitive as capabilities are defined
all uppercase in man pages (CAP_XXX) but the output from
cap_to_text() is lower, it seemed reasonable that users may
not know or care what case it was stored in, just whether or
not it was present. What are your feelings on this?
>- Is the nature of the regex controlled by -regextype (as is -regex)?
It's currently hardcoded but I plan to support -regextype, maybe
default to case-insensitive if -regextype is not defined.
>- If the current file name is a symbolic link, does -xattr test the
> symbolic link itself, or the file it points to? (It's possible that
> symbolic links can never have extended attributes, in which case
> looking at the file that is pointed to would always make sense.) Is
> this behavior affected by the -L option? Or do we need a "-lxattr"
> test?
Extended attributes are supported on symlinks via a different call
(llistxattr), I guess it should be supported even though there may
not be much demand - is your preference to detect '-L' or offer
'-lxattr' instead?
>- Is there any way to test whether a particular attribute has a
> particular value, or matches a regex? Is there any need for this?
> If there is: It appears to me that the values can be binary
> strings; what do we have to do to allow comparison values to be
> specified (especially given that 0 bytes cannot appear in command
> arguments). If the values can be binary strings, is there a need to
> provide a mask-and-test operation?
This is what '-cap' does, but in the case of capabilities the binary value
needs to be interpreted correctly.
Tools that handle regular expressions as command line arguments
will always support escaping of non-printing characters, so to match
a binary '0' you would use '\0' in your regex.
Considering that a given extended attribute's value could contain
any type of data that may or may not require interpretation I don't
know that there's value in offering that functionality. Wouldn't this
also require 2 arguments - <xattr_name> and <regex> ?
>If I understand you correctly, "-cap" is true if there is an attribute
>with the name "security.capability". The third and fourth questions
>in the above list apply to that.
No, cap specifically retrieves the value of security.capability, decodes
it then matches the text value against the regex.
>Dale
Thanks for taking an interest, the feedback is great
Morgan