[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Findutils-patches] [6 PATCHES] New feature added to find: -type xyz

From: Bernhard Voelker
Subject: Re: [Findutils-patches] [6 PATCHES] New feature added to find: -type xyz
Date: Fri, 4 Mar 2016 18:01:24 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 02/28/2016 11:06 PM, Young Mo Kang wrote:
> I just thought it would be useful to enable multiple type search at once
> feature in find, i.e., find’s option "-type xyz” can be a shorthand form
> for “( -type x -o -type -y -o -type z )”. It should work with -xtype exactly
> the same way.
> To me, this new syntax seems very intuitive, and it should greatly reduce 
> typing.

I also like this feature, and it does not seem to contradict to any
existing implementation I know, plus it doesn't violate POSIX [1] - it
would just be a nice GNU extension.

The only potential drawback I see is that it would not be possible anymore
to use multi-character types when adding more types in future, e.g. -type shm.
Currently, -type only allows a few out of many more already-existing
possibilities (e.g. see gnulib's file_type function [2]).


> I have modified from the most recent git commit 4.7.0-git
> 19f6f691de4f41b4af76c33782a96f191378830a to enable this feature,
> but have not done much testing; I just added one simple test case.
> Below is the git patch result. I am new to contributing to GNU projects
> and am NOT an experienced hacker, so I would very much like to learn.
> By the way, I am not sure if this is the proper way to sending out the
> patch results: should I send out each patch result one by one? I have
> followed the instructions on the READM-hacking file as much as possible.

The important thing regarding the form of the patches is that they can be
applied without problems using "git am ...". Some email clients mangle patches
in their default settings, so sometimes it's safer to add it as an attachment.
However, "git send-email ..." should be always safe, too.

Furthermore, the enhancement exceeds the border of triviality, therefore
we need some Copyright paperwork with the FSF, as documented in README-hacking
in section "Copyright assignment".
Just for the record: I did not look at the patches yet to not taint myself
regarding your idea.  This means that if you are unable (or - unlikely, but
for completeness - unwilling) to undergo the above copyright paperwork,
then we can still re-implement the feature without Copyright issues.
I think James will kindly support you if you are willing to do the Copyright

Thanks & have a nice day,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]