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
findthe default "find or-and operate" utility in common systems or these usually come with bothfindandGNU find?Was
GNU findintended 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
findthe default "find or-and operate" utility in common systems or these usually come with bothfindandGNU find?Was
GNU findintended to be simpler thanfind?
find utilities gnu
you have always used GNU find on linux, unless you're a big user offindon 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
findthe default "find or-and operate" utility in common systems or these usually come with bothfindandGNU find?Was
GNU findintended 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
findthe default "find or-and operate" utility in common systems or these usually come with bothfindandGNU find?Was
GNU findintended 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 offindon 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 offindon 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
findon busybox or android ;-) On non-linux systems, GNU find is usually namedgfind.â mosvy
24 mins ago