>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 definedall uppercase in man pages (CAP_XXX) but the output from cap_to_text() is lower, it seemed reasonable that users maynot know or care what case it was stored in, just whether ornot 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, maybedefault 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 maynot 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 valueneeds 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, decodesit then matches the text value against the regex. >Dale Thanks for taking an interest, the feedback is great Morgan
_______________________________________________ Findutils-patches mailing list Findutils-patches@gnu.org https://lists.gnu.org/mailman/listinfo/findutils-patches
