find VS GNU find
Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
Consider some common *nix systems (say Debian, Ubuntu, Fedora, CentOS, Arch and Kali).
I use Linux since 2014 but always used find
. I don't recall personally using GNU find, but from one example I've seen I assumed the syntax of GNU find might be simpler (though might as well allow less operations).
Exceptionally, I have two questions:
Is only
find
the default "find or-and operate" utility in common systems or these usually come with bothfind
andGNU find
?Was
GNU find
intended to be simpler thanfind
?
find utilities gnu
add a comment |Â
up vote
2
down vote
favorite
Consider some common *nix systems (say Debian, Ubuntu, Fedora, CentOS, Arch and Kali).
I use Linux since 2014 but always used find
. I don't recall personally using GNU find, but from one example I've seen I assumed the syntax of GNU find might be simpler (though might as well allow less operations).
Exceptionally, I have two questions:
Is only
find
the default "find or-and operate" utility in common systems or these usually come with bothfind
andGNU find
?Was
GNU find
intended to be simpler thanfind
?
find utilities gnu
you have always used GNU find on linux, unless you're a big user offind
on busybox or android ;-) On non-linux systems, GNU find is usually namedgfind
.
– mosvy
24 mins ago
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
Consider some common *nix systems (say Debian, Ubuntu, Fedora, CentOS, Arch and Kali).
I use Linux since 2014 but always used find
. I don't recall personally using GNU find, but from one example I've seen I assumed the syntax of GNU find might be simpler (though might as well allow less operations).
Exceptionally, I have two questions:
Is only
find
the default "find or-and operate" utility in common systems or these usually come with bothfind
andGNU find
?Was
GNU find
intended to be simpler thanfind
?
find utilities gnu
Consider some common *nix systems (say Debian, Ubuntu, Fedora, CentOS, Arch and Kali).
I use Linux since 2014 but always used find
. I don't recall personally using GNU find, but from one example I've seen I assumed the syntax of GNU find might be simpler (though might as well allow less operations).
Exceptionally, I have two questions:
Is only
find
the default "find or-and operate" utility in common systems or these usually come with bothfind
andGNU find
?Was
GNU find
intended to be simpler thanfind
?
find utilities gnu
find utilities gnu
edited 51 mins ago
asked 57 mins ago
JohnDoea
130728
130728
you have always used GNU find on linux, unless you're a big user offind
on busybox or android ;-) On non-linux systems, GNU find is usually namedgfind
.
– mosvy
24 mins ago
add a comment |Â
you have always used GNU find on linux, unless you're a big user offind
on busybox or android ;-) On non-linux systems, GNU find is usually namedgfind
.
– mosvy
24 mins ago
you have always used GNU find on linux, unless you're a big user of
find
on busybox or android ;-) On non-linux systems, GNU find is usually named gfind
.– mosvy
24 mins ago
you have always used GNU find on linux, unless you're a big user of
find
on busybox or android ;-) On non-linux systems, GNU find is usually named gfind
.– mosvy
24 mins ago
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
5
down vote
GNU utilities often implement the POSIX standard, and then also extend it with extra functionality for added convenience (and, as the flip side of that, decreased portability across Unices).
If you are on a Linux system, you would very likely be using the GNU implementation of find
, and you would probably not have another find
installed. On non-Linux systems, you would have a native find
and the possibility to also install GNU find
(which would most often install under the name gfind
or, less often, gnufind
).
As with most GNU utilities, GNU find
implements and extends the standard find
specification. It is therefore not "simpler" but "more convenient", and it would be somewhat easier to do certain complex tasks with it than with a strictly standard compliant find
.
Extended implementations of find
often, for example, implement the -maxdepth
and -mindepth
predicates which the standard does not mention, and GNU find
in particular also has -printf
to print out the found pathnames using a variety of formatting possibilities (the standard find
does not have -printf
), and predicates for doing regular expression matching of various kinds on pathnames, as well as a number of other non-standard predicates, some of which are also found in other implementations of find
(possibly with ever so slightly different semantics, like -execdir
which works slightly different depending on what find
is being used1).
The -delete
predicate, used in the answer that you link to, is non-standard, but implemented by GNU find
as well as in the find
on some other non-Linux systems.
Most Linux systems, regardless of distribution, use the same coreutils and findutils toolset (variants like busybox exists, obviously). To use a completely different set of tool implementations, you would have to move to one of the open source BSD systems or to macOS, Solaris, AIX or some other commercial Unix.
1GNU find
prepends ./
to pathnames when using -execdir
while some other implementations don't.
And-print0
, and-direxec
, and-delete
, and ... ;-). The null separator options available in GNU tools are particularly convenient.
– Stephen Kitt
49 mins ago
@StephenKitt But seldom needed :-)
– Kusalananda
44 mins ago
right, except when writing non-POSIX answers here ;-). (Or scripts which need to work anywhere.)
– Stephen Kitt
42 mins ago
The main problem with the GNU documentation is that it tries to let people use non-standard aliases to POSIX methods and thus cause the related scripts to create a vendor lock in.
– schily
36 mins ago
add a comment |Â
up vote
2
down vote
Avoid GNU find on platforms that com with an own find
implementation.
GNU find e.g. does not support to check for ACLs and Extended attribute files.
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
5
down vote
GNU utilities often implement the POSIX standard, and then also extend it with extra functionality for added convenience (and, as the flip side of that, decreased portability across Unices).
If you are on a Linux system, you would very likely be using the GNU implementation of find
, and you would probably not have another find
installed. On non-Linux systems, you would have a native find
and the possibility to also install GNU find
(which would most often install under the name gfind
or, less often, gnufind
).
As with most GNU utilities, GNU find
implements and extends the standard find
specification. It is therefore not "simpler" but "more convenient", and it would be somewhat easier to do certain complex tasks with it than with a strictly standard compliant find
.
Extended implementations of find
often, for example, implement the -maxdepth
and -mindepth
predicates which the standard does not mention, and GNU find
in particular also has -printf
to print out the found pathnames using a variety of formatting possibilities (the standard find
does not have -printf
), and predicates for doing regular expression matching of various kinds on pathnames, as well as a number of other non-standard predicates, some of which are also found in other implementations of find
(possibly with ever so slightly different semantics, like -execdir
which works slightly different depending on what find
is being used1).
The -delete
predicate, used in the answer that you link to, is non-standard, but implemented by GNU find
as well as in the find
on some other non-Linux systems.
Most Linux systems, regardless of distribution, use the same coreutils and findutils toolset (variants like busybox exists, obviously). To use a completely different set of tool implementations, you would have to move to one of the open source BSD systems or to macOS, Solaris, AIX or some other commercial Unix.
1GNU find
prepends ./
to pathnames when using -execdir
while some other implementations don't.
And-print0
, and-direxec
, and-delete
, and ... ;-). The null separator options available in GNU tools are particularly convenient.
– Stephen Kitt
49 mins ago
@StephenKitt But seldom needed :-)
– Kusalananda
44 mins ago
right, except when writing non-POSIX answers here ;-). (Or scripts which need to work anywhere.)
– Stephen Kitt
42 mins ago
The main problem with the GNU documentation is that it tries to let people use non-standard aliases to POSIX methods and thus cause the related scripts to create a vendor lock in.
– schily
36 mins ago
add a comment |Â
up vote
5
down vote
GNU utilities often implement the POSIX standard, and then also extend it with extra functionality for added convenience (and, as the flip side of that, decreased portability across Unices).
If you are on a Linux system, you would very likely be using the GNU implementation of find
, and you would probably not have another find
installed. On non-Linux systems, you would have a native find
and the possibility to also install GNU find
(which would most often install under the name gfind
or, less often, gnufind
).
As with most GNU utilities, GNU find
implements and extends the standard find
specification. It is therefore not "simpler" but "more convenient", and it would be somewhat easier to do certain complex tasks with it than with a strictly standard compliant find
.
Extended implementations of find
often, for example, implement the -maxdepth
and -mindepth
predicates which the standard does not mention, and GNU find
in particular also has -printf
to print out the found pathnames using a variety of formatting possibilities (the standard find
does not have -printf
), and predicates for doing regular expression matching of various kinds on pathnames, as well as a number of other non-standard predicates, some of which are also found in other implementations of find
(possibly with ever so slightly different semantics, like -execdir
which works slightly different depending on what find
is being used1).
The -delete
predicate, used in the answer that you link to, is non-standard, but implemented by GNU find
as well as in the find
on some other non-Linux systems.
Most Linux systems, regardless of distribution, use the same coreutils and findutils toolset (variants like busybox exists, obviously). To use a completely different set of tool implementations, you would have to move to one of the open source BSD systems or to macOS, Solaris, AIX or some other commercial Unix.
1GNU find
prepends ./
to pathnames when using -execdir
while some other implementations don't.
And-print0
, and-direxec
, and-delete
, and ... ;-). The null separator options available in GNU tools are particularly convenient.
– Stephen Kitt
49 mins ago
@StephenKitt But seldom needed :-)
– Kusalananda
44 mins ago
right, except when writing non-POSIX answers here ;-). (Or scripts which need to work anywhere.)
– Stephen Kitt
42 mins ago
The main problem with the GNU documentation is that it tries to let people use non-standard aliases to POSIX methods and thus cause the related scripts to create a vendor lock in.
– schily
36 mins ago
add a comment |Â
up vote
5
down vote
up vote
5
down vote
GNU utilities often implement the POSIX standard, and then also extend it with extra functionality for added convenience (and, as the flip side of that, decreased portability across Unices).
If you are on a Linux system, you would very likely be using the GNU implementation of find
, and you would probably not have another find
installed. On non-Linux systems, you would have a native find
and the possibility to also install GNU find
(which would most often install under the name gfind
or, less often, gnufind
).
As with most GNU utilities, GNU find
implements and extends the standard find
specification. It is therefore not "simpler" but "more convenient", and it would be somewhat easier to do certain complex tasks with it than with a strictly standard compliant find
.
Extended implementations of find
often, for example, implement the -maxdepth
and -mindepth
predicates which the standard does not mention, and GNU find
in particular also has -printf
to print out the found pathnames using a variety of formatting possibilities (the standard find
does not have -printf
), and predicates for doing regular expression matching of various kinds on pathnames, as well as a number of other non-standard predicates, some of which are also found in other implementations of find
(possibly with ever so slightly different semantics, like -execdir
which works slightly different depending on what find
is being used1).
The -delete
predicate, used in the answer that you link to, is non-standard, but implemented by GNU find
as well as in the find
on some other non-Linux systems.
Most Linux systems, regardless of distribution, use the same coreutils and findutils toolset (variants like busybox exists, obviously). To use a completely different set of tool implementations, you would have to move to one of the open source BSD systems or to macOS, Solaris, AIX or some other commercial Unix.
1GNU find
prepends ./
to pathnames when using -execdir
while some other implementations don't.
GNU utilities often implement the POSIX standard, and then also extend it with extra functionality for added convenience (and, as the flip side of that, decreased portability across Unices).
If you are on a Linux system, you would very likely be using the GNU implementation of find
, and you would probably not have another find
installed. On non-Linux systems, you would have a native find
and the possibility to also install GNU find
(which would most often install under the name gfind
or, less often, gnufind
).
As with most GNU utilities, GNU find
implements and extends the standard find
specification. It is therefore not "simpler" but "more convenient", and it would be somewhat easier to do certain complex tasks with it than with a strictly standard compliant find
.
Extended implementations of find
often, for example, implement the -maxdepth
and -mindepth
predicates which the standard does not mention, and GNU find
in particular also has -printf
to print out the found pathnames using a variety of formatting possibilities (the standard find
does not have -printf
), and predicates for doing regular expression matching of various kinds on pathnames, as well as a number of other non-standard predicates, some of which are also found in other implementations of find
(possibly with ever so slightly different semantics, like -execdir
which works slightly different depending on what find
is being used1).
The -delete
predicate, used in the answer that you link to, is non-standard, but implemented by GNU find
as well as in the find
on some other non-Linux systems.
Most Linux systems, regardless of distribution, use the same coreutils and findutils toolset (variants like busybox exists, obviously). To use a completely different set of tool implementations, you would have to move to one of the open source BSD systems or to macOS, Solaris, AIX or some other commercial Unix.
1GNU find
prepends ./
to pathnames when using -execdir
while some other implementations don't.
edited 8 mins ago
answered 50 mins ago


Kusalananda
109k14212334
109k14212334
And-print0
, and-direxec
, and-delete
, and ... ;-). The null separator options available in GNU tools are particularly convenient.
– Stephen Kitt
49 mins ago
@StephenKitt But seldom needed :-)
– Kusalananda
44 mins ago
right, except when writing non-POSIX answers here ;-). (Or scripts which need to work anywhere.)
– Stephen Kitt
42 mins ago
The main problem with the GNU documentation is that it tries to let people use non-standard aliases to POSIX methods and thus cause the related scripts to create a vendor lock in.
– schily
36 mins ago
add a comment |Â
And-print0
, and-direxec
, and-delete
, and ... ;-). The null separator options available in GNU tools are particularly convenient.
– Stephen Kitt
49 mins ago
@StephenKitt But seldom needed :-)
– Kusalananda
44 mins ago
right, except when writing non-POSIX answers here ;-). (Or scripts which need to work anywhere.)
– Stephen Kitt
42 mins ago
The main problem with the GNU documentation is that it tries to let people use non-standard aliases to POSIX methods and thus cause the related scripts to create a vendor lock in.
– schily
36 mins ago
And
-print0
, and -direxec
, and -delete
, and ... ;-). The null separator options available in GNU tools are particularly convenient.– Stephen Kitt
49 mins ago
And
-print0
, and -direxec
, and -delete
, and ... ;-). The null separator options available in GNU tools are particularly convenient.– Stephen Kitt
49 mins ago
@StephenKitt But seldom needed :-)
– Kusalananda
44 mins ago
@StephenKitt But seldom needed :-)
– Kusalananda
44 mins ago
right, except when writing non-POSIX answers here ;-). (Or scripts which need to work anywhere.)
– Stephen Kitt
42 mins ago
right, except when writing non-POSIX answers here ;-). (Or scripts which need to work anywhere.)
– Stephen Kitt
42 mins ago
The main problem with the GNU documentation is that it tries to let people use non-standard aliases to POSIX methods and thus cause the related scripts to create a vendor lock in.
– schily
36 mins ago
The main problem with the GNU documentation is that it tries to let people use non-standard aliases to POSIX methods and thus cause the related scripts to create a vendor lock in.
– schily
36 mins ago
add a comment |Â
up vote
2
down vote
Avoid GNU find on platforms that com with an own find
implementation.
GNU find e.g. does not support to check for ACLs and Extended attribute files.
add a comment |Â
up vote
2
down vote
Avoid GNU find on platforms that com with an own find
implementation.
GNU find e.g. does not support to check for ACLs and Extended attribute files.
add a comment |Â
up vote
2
down vote
up vote
2
down vote
Avoid GNU find on platforms that com with an own find
implementation.
GNU find e.g. does not support to check for ACLs and Extended attribute files.
Avoid GNU find on platforms that com with an own find
implementation.
GNU find e.g. does not support to check for ACLs and Extended attribute files.
answered 31 mins ago


schily
9,67731537
9,67731537
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f475020%2ffind-vs-gnu-find%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
you have always used GNU find on linux, unless you're a big user of
find
on busybox or android ;-) On non-linux systems, GNU find is usually namedgfind
.– mosvy
24 mins ago