> From: KillBoy PowerHed <killboy_power...@yahoo.com.au>
>
> >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?
Mostly I want to make sure that you have carefully thought through all
the issues. But in this case, your response seems to be about
capability values, whereas I was asking about attribute names.
> >- 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.
My understanding is that all regexes in find are controlled by
-regextype, so the regex handling in any new predicates should work
the same way. The particular syntax for the regex is set by
-regextype, but whether the regex is case-sensitive is determined by
whether the predicate starts with "i". (E.g., -iname vs. -name,
-ilname vs. -lname)
The one exception I can see is if the datum you are testing is
inherently case-insensitive. (E.g., if it is enforced that capability
bit names have only one case) In that case, there's no reason to
provide case-sensitive tests.
> >- 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?
I would expect it to work like -name vs. -lname. And the meaning of
both of these is modified by the -P, -L, -H, and deprecated --follow
options.
> >- 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.
That's true, but if it's common to have attributes whose octets are
interpreted as integers or bit-vectors, it is far easier on the user
to provide tests that treat them as such. The important question is,
What will users want to do?
> 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> ?
There are a number of ways that you could organize it. For instance:
-xattr name value-format test-value -- -xattr foo.bigness i4 '>12'
But you could combine the format and test-value argument:
-xattr name value-format:test-value -- -xattr foo.bigness 'i4:>12'
At this point, it's more important to develop a complete list of what
users will want to do in practice than to worry about detailed syntax.
Dale
_______________________________________________
Findutils-patches mailing list
Findutils-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/findutils-patches
