On Sat, Apr 01, 2023 at 08:18:56AM +0200, Solène Rapenne wrote:
> Le Fri, 31 Mar 2023 19:40:45 -0700,
> Jared Harper <ja...@hrpr.us> a écrit :
> 
> > I have put together a patch that adds -executable, -readable, and
> > -writable to /usr/bin/find.
> > 
> > When I first started working on this patch, I implemented the access
> > check by checking the stat of the file like so:
> > 
> 
> this doesn't add much value IMO, we already have -perm that can be used
> to return paths matching the permission, or only a bit.
> 
> find . -executable can be written find . -type f -perm -100
> find . -writable can   be written find . -type f -perm -200
> find . -readable can   be written find . -type f -perm -400
> 
> on linux, those flags make sense to have because they also take care of
> ACLs, while their -perm doesn't. OpenBSD doesn't have ACLs.


Note that e.g. -executable tests whether the current item is readable
by the current user, a test that is quite difficult to implement using
-perm (you would have to involve -user and possibly -group too, as well
as $LOGNAME).

With -executable as an example, you could avoid entering directories
that you don't have access to in a convenient way

        find . -type d ! -executable -prune -o ...

GNU extensions to standard utilities are almost exclusively about
providing convenient shortcuts and convinient functionality to the lazy
user.  Usually, this extra functionality is found in other standard
tools, or it can trivially be implemented by a short script written
in the shell or using awk etc., so their extensions often seems to be
running counter to the Unix philsophy of "do one thing and do it well".
But then again, "GNU is not Unix".

However, in this particular case, the extension is *useful* and not
at all trivial to implement with existing predicates in find(1) or by
calling other utilities.  The above example could be implemented with
"find . -type d ! -exec cd {} \; -prune -o ..." on systems where cd(1)
is an external utility, which it is not on OpenBSD, so we would use
something silly like "! -exec sh -c 'cd "$1"' sh {} \;" instead, unless
we got either really creative or just ignored the fact that we can't
enter that directory and redirect all diagnostic messages to /dev/null.


Cheers,

-- 
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden

.

Reply via email to