1) Is there some reason why the GNU folks having added options to find
files onto grep was a reasonable thing to do rather than flying in the
face of the Unix philosophy and unnecessarily complicating the
interface of grep?
1) Is there some reason why the GNU folks having added options to find
files onto grep was a reasonable thing to do rather than flying in the
face of the Unix philosophy and unnecessarily complicating the interface
of grep?
On 01/10/2023 12:40, Ed Morton wrote:
1) Is there some reason why the GNU folks having added options to find
files onto grep was a reasonable thing to do rather than flying in the
face of the Unix philosophy and unnecessarily complicating the
interface of grep?
Grep doesn't find files; the shell does that. Grep only searches the
files given for the "regular expression".
SYNOPSIS
grep [OPTION...] PATTERNS [FILE...]
grep [OPTION...] -e PATTERNS ... [FILE...] grep [OPTION...] -f
PATTERN_FILE ... [FILE...]
DESCRIPTION
grep searches for PATTERNS in each FILE.
Ed Morton <[email protected]> writes:
1) Is there some reason why the GNU folks having added options to find
files onto grep was a reasonable thing to do rather than flying in the
face of the Unix philosophy and unnecessarily complicating the
interface of grep?
I expect they thought they would be useful; if so they were right.
You don’t have to use them if you don’t like them...
On 01/10/2023 12:40, Ed Morton wrote:
1) Is there some reason why the GNU folks having added options to find
files onto grep was a reasonable thing to do rather than flying in the
face of the Unix philosophy and unnecessarily complicating the
interface of grep?
Grep doesn't find files; the shell does that. Grep only searches the
files given for the "regular expression".
SYNOPSIS
grep [OPTION...] PATTERNS [FILE...]
grep [OPTION...] -e PATTERNS ... [FILE...]
grep [OPTION...] -f PATTERN_FILE ... [FILE...]
DESCRIPTION
grep searches for PATTERNS in each FILE.
Forget find, use grep -rl (or -Rl) (recursive, list)
Ed Morton <[email protected]> writes:
1) Is there some reason why the GNU folks having added options to find
files onto grep was a reasonable thing to do rather than flying in the
face of the Unix philosophy and unnecessarily complicating the
interface of grep?
I expect they thought they would be useful; if so they were right.
You don’t have to use them if you don’t like them...
On 10/1/2023 7:19 AM, Richard Kettlewell wrote:
Ed Morton <[email protected]> writes:
1) Is there some reason why the GNU folks having added options to findI expect they thought they would be useful; if so they were right.
files onto grep was a reasonable thing to do rather than flying in the
face of the Unix philosophy and unnecessarily complicating the
interface of grep?
Something being useful is a long way from being the only criteria for
adding it to a command.
A recent thread titled "Get a list of files that contain a string"
produced an answer suggesting the OP use "grep -rl regexp" with "-l
string" being the GNU grep option to only output the file name when
"regexp" matches a string in a file, and "-r" being the GNU grep option
to recursively find files.
I'm trying to understand why it's OK for GNU grep to have options to
find files:
On 10/1/2023 8:37 AM, Chris Elvidge wrote:
On 01/10/2023 12:40, Ed Morton wrote:
1) Is there some reason why the GNU folks having added options to
find files onto grep was a reasonable thing to do rather than flying
in the face of the Unix philosophy and unnecessarily complicating the
interface of grep?
Grep doesn't find files; the shell does that. Grep only searches the
files given for the "regular expression".
SYNOPSIS
grep [OPTION...] PATTERNS [FILE...]
grep [OPTION...] -e PATTERNS ... [FILE...]
grep [OPTION...] -f PATTERN_FILE ... [FILE...]
DESCRIPTION
grep searches for PATTERNS in each FILE.
I'm surprised to see you say that since it was your recent answer at https://groups.google.com/g/comp.unix.shell/c/9mFNQ27MI0A/m/zwGln8V6AAAJ:
Forget find, use grep -rl (or -Rl) (recursive, list)
where `-r` is the option to recursively find files, that inspired me to
start this thread.
Ed.
On 2023-10-01, Ed Morton <[email protected]> wrote:
A recent thread titled "Get a list of files that contain a string"
produced an answer suggesting the OP use "grep -rl regexp" with "-l
string" being the GNU grep option to only output the file name when
"regexp" matches a string in a file, and "-r" being the GNU grep option
to recursively find files.
I'm trying to understand why it's OK for GNU grep to have options to
find files:
People often need to recursively grep a tree of files. They do it interactively.
Using find together with a flat grep is annoyingly verbose for the task, like:
find . -type f -exec grep foo {} /dev/null \;
Remember your /dev/null because grep behaves differently with one file argument: won't print the file name.
I'm trying to understand why it's OK for GNU grep to have options to
find files:
A recent thread titled "Get a list of files that contain a string"
produced an answer suggesting the OP use "grep -rl regexp" with "-l
string" being the GNU grep option to only output the file name when
"regexp" matches a string in a file, and "-r" being the GNU grep option
to recursively find files.
I'm trying to understand why it's OK for GNU grep to have options to
find files: [...]
On 2023-10-01, Ed Morton <[email protected]> wrote:
A recent thread titled "Get a list of files that contain a string"
produced an answer suggesting the OP use "grep -rl regexp" with "-l
string" being the GNU grep option to only output the file name when
"regexp" matches a string in a file, and "-r" being the GNU grep option
to recursively find files.
I'm trying to understand why it's OK for GNU grep to have options to
find files:
People often need to recursively grep a tree of files. They do it interactively.
Using find together with a flat grep is annoyingly verbose for the task, like:
find . -type f -exec grep foo {} /dev/null \;
Remember your /dev/null because grep behaves differently with one
file argument: won't print the file name.
Each user would end up writing a function or alias for this.
GNU Bash has a ** glob pattern (double star) which can replace uses
of find, and can potentially run into environmental passing limits
if used like this:
grep -l foo **/*.c
If the expansion is large you need either xargs, which has problems
with spaces in file names withtout GNU extensions, or write a loop:
for x in **/*.c; do grep -l foo "$x" /dev/null; done
Also an annoying mouthful for something you need often.
On Sun, 01 Oct 2023 08:19:29 -0400, Richard Kettlewell <[email protected]d> wrote:
Ed Morton <[email protected]> writes:
1) Is there some reason why the GNU folks having added options to find
files onto grep was a reasonable thing to do rather than flying in the
face of the Unix philosophy and unnecessarily complicating the
interface of grep?
I expect they thought they would be useful; if so they were right.
You don’t have to use them if you don’t like them...
The find command is used to find files within a directory tree based on
the file name.
While find can be used to invoke grep on each file it returns, when
searching
for text in all files in a directory tree, or in a list of files (as
returned
by shell expansion), it's more efficient to only invoke grep once and let
it do all parts of the searching.
Regards, Dave Hodgins
If you're using GNU grep (which you'd need for the file-finding options)
give it the `-H` argument and it'll print file names as well as the
matching string without having to add /dev/null:
In article <ufct99$2hrnj$[email protected]>,
Ed Morton <[email protected]> wrote:
If you're using GNU grep (which you'd need for the file-finding options) >>give it the `-H` argument and it'll print file names as well as the >>matching string without having to add /dev/null:
illumos, FreeBSD and OpenBSD grep(1) also include -H:
<URL:https://illumos.org/man/1/grep> ><URL:https://man.freebsd.org/cgi/man.cgi?grep(1)> ><URL:https://man.openbsd.org/grep>
So I don't see any of that as justifying adding a bunch of options to
grep to do something other than it's primary purpose of g/re/p and
making it different from all other text processing tools in that
regard.
Ed Morton <[email protected]> writes:
So I don't see any of that as justifying adding a bunch of options to
grep to do something other than it's primary purpose of g/re/p and
making it different from all other text processing tools in that
regard.
Why do you think it needs justifying? Its their code, they can add
whatever they like to it.
And, finally, let me add:
3) I personally find the "find" command archaic and hard to use (meaning:
If it were being designed today, it wouldn't be like it is). From a usability standpoint, it is much better to be able to just include "-r" on the grep command line, than to have to write out a long, ugly "find" invocation.
Ed Morton <[email protected]> writes:
So I don't see any of that as justifying adding a bunch of options to
grep to do something other than it's primary purpose of g/re/p and
making it different from all other text processing tools in that
regard.
Why do you think it needs justifying? It’s their code, they can add whatever they like to it.
What about the 'tw' (tree walk) command from AT&T; unfortunately I cannot find
it online at the moment. Basic usage is simple (less "archaic" syntax) but it can get as complicated as a programming language with complex actions possible.
* Janis Papanagnou <[email protected]> in comp.unix.shell:
What about the 'tw' (tree walk) command from AT&T; unfortunately I cannot find
it online at the moment. Basic usage is simple (less "archaic" syntax) but it
can get as complicated as a programming language with complex actions possible.
I found this https://github.com/att/ast/tree/master/src/cmd/tw
but it seems some work would be needed to compile it on a recent Linux.
I found this https://github.com/att/ast/tree/master/src/cmd/tw
* Janis Papanagnou <[email protected]> in comp.unix.shell:
(I cannot even get or clone it from here.)
Sorry, just wanted to point out "tw" in a precise way.
The root of the repository is here: https://github.com/att/ast
I found this https://github.com/att/ast/tree/master/src/cmd/tw
(I cannot even get or clone it from here.)
On 10/2/2023 2:09 AM, Richard Kettlewell wrote:
Ed Morton <[email protected]> writes:
So I don't see any of that as justifying adding a bunch of options toWhy do you think it needs justifying? It’s their code, they can add
grep to do something other than it's primary purpose of g/re/p and
making it different from all other text processing tools in that
regard.
whatever they like to it.
The GNU people added functionality to grep in a way that is
contradictory to the Unix philosophy and makes it inconsistent with
all other text processing tools.
So far the only suggestion I've heard for why they did that is so
people could do:
grep -r 'regexp'
instead of:
find . -type f -exec grep -H 'regexp' {} +
which saves us about 20 simple, common characters over find+grep but
does nothing for find+awk, find+sed, etc.
On 10/2/2023 2:09 AM, Richard Kettlewell wrote:
Ed Morton <[email protected]> writes:
So I don't see any of that as justifying adding a bunch of options to
grep to do something other than it's primary purpose of g/re/p and
making it different from all other text processing tools in that
regard.
Why do you think it needs justifying? It’s their code, they can add
whatever they like to it.
The GNU people added functionality to grep in a way that is
contradictory to the Unix philosophy and makes it inconsistent with all
other text processing tools.
- Unix programs have recursion built in: from memory I can think of
ls, rm, cp, mv, chgrp, chmod and chown.
[...]
If reducing how much typing we need to do for that was their only goal,
they could have introduced a separate tool named something like "ftf"
that does the equivalent of "Find -Type F" [...]
On 2023-10-03, Janis Papanagnou <[email protected]> wrote:
On 03.10.2023 09:26, Kaz Kylheku wrote:
- Unix programs have recursion built in: from memory I can think of
ls, rm, cp, mv, chgrp, chmod and chown.
When I saw in the 'tw' examples command calls like 'tw chmod go-w' I
wondered whether it would have been a good design idea to use such a
paradigm generally; tw ls; tw rm, etc., instead of implementing some
-r (or -R or other) tree walks in each program separately. This ship
may have sailed already but the idea seems sensible. (And 'tw' seems
more powerful than 'find', yet with a less "archaic" syntax.)
In the case of chmod, you have to be careful about order. E.g. if you're *removing* read/execute permissions from everything, you have to go
bottom up. If adding, then top down.
to 'tw' would control the tree walk and the commands would have their
own options; a good separation of control, no multiple duplications.
Of course we have such a beast already as standard with find -exec +,
but the 'tw' interface seems smarter. I wonder why 'tw' didn't get in
wider use.
Performance? Launch a new chmod process for every visited object.
That could be addressed by allowing executables to be loadable as shared libraries that expose the main function.
Then tw could find chmod in PATH, try to dlopen it, and if that works
and a "main" symbol is found, repeatedly call that function rather
than fork + exec.
On 03.10.2023 09:26, Kaz Kylheku wrote:
- Unix programs have recursion built in: from memory I can think of
ls, rm, cp, mv, chgrp, chmod and chown.
When I saw in the 'tw' examples command calls like 'tw chmod go-w' I
wondered whether it would have been a good design idea to use such a
paradigm generally; tw ls; tw rm, etc., instead of implementing some
-r (or -R or other) tree walks in each program separately. This ship
may have sailed already but the idea seems sensible. (And 'tw' seems
more powerful than 'find', yet with a less "archaic" syntax.)
to 'tw' would control the tree walk and the commands would have their
own options; a good separation of control, no multiple duplications.
Of course we have such a beast already as standard with find -exec +,
but the 'tw' interface seems smarter. I wonder why 'tw' didn't get in
wider use.
- Unix programs have recursion built in: from memory I can think of
ls, rm, cp, mv, chgrp, chmod and chown.
On 02.10.2023 13:59, Ed Morton wrote:
[...]
If reducing how much typing we need to do for that was their only goal,
they could have introduced a separate tool named something like "ftf"
that does the equivalent of "Find -Type F" [...]
Have a look at 'tw' (man page: http://volatile.gridbug.de/tw.out) which
is not restricted to '-type f' but can be parameterized with all options necessary to control the search.
tw -tw-options... cmd -cmd-options... cmd-args...
All file subsets are determined by the 'tw' options and the commands use
just their own options. (The commands need not implement the tree walk
and the options to control it.) And each command used with 'tw' just
cares about its own command specific functional options.
Janis
Ed Morton <[email protected]> writes:
On 10/2/2023 2:09 AM, Richard Kettlewell wrote:
Ed Morton <[email protected]> writes:
So I don't see any of that as justifying adding a bunch of options toWhy do you think it needs justifying? It’s their code, they can add
grep to do something other than it's primary purpose of g/re/p and
making it different from all other text processing tools in that
regard.
whatever they like to it.
The GNU people added functionality to grep in a way that is
contradictory to the Unix philosophy and makes it inconsistent with
all other text processing tools.
Why does that matter?
So far the only suggestion I've heard for why they did that is so
people could do:
grep -r 'regexp'
instead of:
find . -type f -exec grep -H 'regexp' {} +
which saves us about 20 simple, common characters over find+grep but
does nothing for find+awk, find+sed, etc.
Sounds good to me. Less typing = better. Given the uptake of the GNU
tools I suspect my opinion is widely shared.
Kaz Kylheku <[email protected]> wrote:
- Unix programs have recursion built in: from memory I can think of
ls, rm, cp, mv, chgrp, chmod and chown.
It's also interesting to compare tar and cpio. Tar also has
recursion built in, and filtering functionality duplicated with
find. Cpio instead takes a list of files to archive from stdin,
which also avoids the maximum argument number and maximum command
length limits that complicate using command-line arguments.
GNU cpio actually supports creating tar archives, but it's notable
that people (including me) don't seem to use it for that, even
though its behaviour is more UNIXy than tar. POSIX apparantly
recommends pax, which supports doing things both ways, but everyone
ignores that too.
find . | tar --create --files-from=- --file=- > archive.tar
That is at least the case of GNU/tar. I just checked the OpenBSD/tar
manpage and the feature to get files from stdin does not appear.
On 10/3/2023 2:00 AM, Richard Kettlewell wrote:
Ed Morton <[email protected]> writes:
The GNU people added functionality to grep in a way that isWhy does that matter?
contradictory to the Unix philosophy and makes it inconsistent with
all other text processing tools.
For the same reasons that cohesion and consistency matter in any
system. Google "software" with those 2 terms to find more information
on how those concepts apply to software.
If Unix were being invented today and the design decision being
presented in an attempt to answer the question "how do we call a text processing tool on every file found under a directory?" was:
IF (tool == grep) && (provider == GNU) THEN
tool -r '...'
ELSE
find . -type f tool '...' {} +
ENDIF
instead of just:
find . -type f tool '...' {} +
the person suggesting it would be ridiculed and sent back to the
drawing board.
The GNU providers have made many worthwhile contributions to many
tools, people are not adopting GNU tools because they added "-r" to
grep.
Richard Kettlewell <[email protected]d> wrote:
Ed Morton <[email protected]> writes:
So I don't see any of that as justifying adding a bunch of options to
grep to do something other than it's primary purpose of g/re/p and
making it different from all other text processing tools in that
regard.
Why do you think it needs justifying? Its their code, they can add
whatever they like to it.
1) "Justifying" was, perhaps, too strong of a word. Obviously, there's no need to do so, in a strict, legalistic sense. Though (total aside coming up), it reminds me of when lawyers get uppity when they see computer
messages like "illegal instruction" - when they know that, in their terms
and frame of reference, there's nothing illegal about it.
3) I personally find the "find" command archaic and hard to use (meaning:
If it were being designed today, it wouldn't be like it is). From a usability standpoint, it is much better to be able to just include "-r" on the grep command line, than to have to write out a long, ugly "find" invocation.
IF (tool == grep) && (provider == GNU) THEN
tool -r '...'
ELSE
find . -type f tool '...' {} +
ENDIF
instead of just:
find . -type f tool '...' {} +
the person suggesting it would be ridiculed and sent back to the
drawing board.
Are you somehow under the impression that the existence of grep -r
prevents the second answer from working? If not then why on earth would
you imagine anyone would give the first answer?
Why do you think it needs justifying? Its their code, they can add >>>whatever they like to it.
1) "Justifying" was, perhaps, too strong of a word. Obviously, there's no >> need to do so, in a strict, legalistic sense. Though (total aside coming
up), it reminds me of when lawyers get uppity when they see computer
messages like "illegal instruction" - when they know that, in their terms
and frame of reference, there's nothing illegal about it.
It's the OPs choice of word...
3) I personally find the "find" command archaic and hard to use (meaning:
If it were being designed today, it wouldn't be like it is). From a
usability standpoint, it is much better to be able to just include "-r" on >> the grep command line, than to have to write out a long, ugly "find"
invocation.
Quite.
Note also that the real bad thing about the "find ... -exec grep ..." type solution (that OP seems to favor) is that it inefficiently spawns a new process for each file.
This has, of course been noted many times in this
thread, but it cannot be over-stressed. Note that you can use "xargs" to mitigate this problem (as I routinely do) or use the (non-standard) "+" option in (GNU) find. [...]
On 10/3/2023 2:00 AM, Richard Kettlewell wrote:
Ed Morton <[email protected]> writes:
On 10/2/2023 2:09 AM, Richard Kettlewell wrote:Why does that matter?
Ed Morton <[email protected]> writes:
So I don't see any of that as justifying adding a bunch of options to >>>>> grep to do something other than it's primary purpose of g/re/p andWhy do you think it needs justifying? It’s their code, they can add
making it different from all other text processing tools in that
regard.
whatever they like to it.
The GNU people added functionality to grep in a way that is
contradictory to the Unix philosophy and makes it inconsistent with
all other text processing tools.
For the same reasons that cohesion and consistency matter in any
system. Google "software" with those 2 terms to find more information on
how those concepts apply to software.
If Unix were being invented today and the design decision being presented
in an attempt to answer the question "how do we call a text processing tool on every file found under a directory?" was:
IF (tool == grep) && (provider == GNU) THEN
tool -r '...'
ELSE
find . -type f tool '...' {} +
ENDIF
instead of just:
find . -type f tool '...' {} +
the person suggesting it would be ridiculed and sent back to the drawing board.
Ed Morton <[email protected]> writes:
On 10/3/2023 2:00 AM, Richard Kettlewell wrote:
Ed Morton <[email protected]> writes:
On 10/2/2023 2:09 AM, Richard Kettlewell wrote:Why does that matter?
Ed Morton <[email protected]> writes:
So I don't see any of that as justifying adding a bunch of options to >>>>>> grep to do something other than it's primary purpose of g/re/p and >>>>>> making it different from all other text processing tools in thatWhy do you think it needs justifying? It’s their code, they can add >>>>> whatever they like to it.
regard.
The GNU people added functionality to grep in a way that is
contradictory to the Unix philosophy and makes it inconsistent with
all other text processing tools.
For the same reasons that cohesion and consistency matter in any
system. Google "software" with those 2 terms to find more information on
how those concepts apply to software.
Those are not the only concepts that matter.
If Unix were being invented today and the design decision being presented
in an attempt to answer the question "how do we call a text processing tool >> on every file found under a directory?" was:
IF (tool == grep) && (provider == GNU) THEN
tool -r '...'
ELSE
find . -type f tool '...' {} +
ENDIF
instead of just:
find . -type f tool '...' {} +
find . -type f -exec tool '...' '{}' +
the person suggesting it would be ridiculed and sent back to the drawing
board.
It's not "just" find ... find is a mess. If the file system, the shell
and all the rest were such that adding some command or prefix like
rec grep pattern .
made grep behave pretty much like grep -r then no one would bother to
add options like -r to grep.
But find is the best we have, and it's a mess. It uses mandatory syntax
that needs to be quoted (the {}) and does not always preserve the desred behaviour. For example
grep -rq needle haystack
can succeed (exit 0) where
find haystack -type f -exec grep -q needle '{}' +
can fail (exit non-zero). This is because find can run multiple
commands and does not always combine the exit statuses correctly. I
would be happy to be wrong about this, but I'm sure I tested it some
time ago.
Of course what's really needed is proper functional composition of
tools. What I mean is that where a list of arguments is needed a lazy
list resulting from a program (something like a generator if you prefer
the term) could be given. We can't use bash's **/* nor $(find . -type
f) for various reasons, not least because the argument list must be
fully evaluated before being passed to exec'd program. A lot would have
to change before (to invent syntax on the fly)
grep needle $[files-in haystack]
started to produce output immediately and could not run out of
resources.
Unix tries with pipes and macro expansion, but the input stream is not
always available (or logical to use) and the shell's expansion and
quoting rules are so intricate that I doubt there is anyone here who has
not been caught out by them even after years of Unix use.
Ed Morton <[email protected]> writes:
On 10/3/2023 2:00 AM, Richard Kettlewell wrote:
Ed Morton <[email protected]> writes:
The GNU people added functionality to grep in a way that isWhy does that matter?
contradictory to the Unix philosophy and makes it inconsistent with
all other text processing tools.
For the same reasons that cohesion and consistency matter in any
system. Google "software" with those 2 terms to find more information
on how those concepts apply to software.
Prioritizing consistency over usability, then.
If Unix were being invented today and the design decision being
presented in an attempt to answer the question "how do we call a text
processing tool on every file found under a directory?" was:
IF (tool == grep) && (provider == GNU) THEN
tool -r '...'
ELSE
find . -type f tool '...' {} +
ENDIF
instead of just:
find . -type f tool '...' {} +
the person suggesting it would be ridiculed and sent back to the
drawing board.
Are you somehow under the impression that the existence of “grep -r” prevents the second answer from working? If not then why on earth would
you imagine anyone would give the first answer?
The GNU providers have made many worthwhile contributions to many
tools, people are not adopting GNU tools because they added "-r" to
grep.
Well it’s demonstrably not an obstacle to many people.
On 10/5/2023 2:37 PM, Ben Bacarisse wrote:
Ed Morton <[email protected]> writes:
On 10/3/2023 2:00 AM, Richard Kettlewell wrote:Those are not the only concepts that matter.
Ed Morton <[email protected]> writes:
On 10/2/2023 2:09 AM, Richard Kettlewell wrote:Why does that matter?
Ed Morton <[email protected]> writes:
So I don't see any of that as justifying adding a bunch of options to >>>>>>> grep to do something other than it's primary purpose of g/re/p and >>>>>>> making it different from all other text processing tools in that >>>>>>> regard.Why do you think it needs justifying? It’s their code, they can add >>>>>> whatever they like to it.
The GNU people added functionality to grep in a way that is
contradictory to the Unix philosophy and makes it inconsistent with
all other text processing tools.
For the same reasons that cohesion and consistency matter in any
system. Google "software" with those 2 terms to find more information on >>> how those concepts apply to software.
Of course, they're just the answer to the question Richard asked.
If Unix were being invented today and the design decision being presented >>> in an attempt to answer the question "how do we call a text processing tool >>> on every file found under a directory?" was:find . -type f -exec tool '...' '{}' +
IF (tool == grep) && (provider == GNU) THEN
tool -r '...'
ELSE
find . -type f tool '...' {} +
ENDIF
instead of just:
find . -type f tool '...' {} +
Right, thanks. I typed my response once and my newsreader discarded it so I had to type it again and rushed it.
the person suggesting it would be ridiculed and sent back to the drawing >>> board.It's not "just" find ... find is a mess. If the file system, the shell
and all the rest were such that adding some command or prefix like
rec grep pattern .
made grep behave pretty much like grep -r then no one would bother to
add options like -r to grep.
Agreed, that is the right solution if people are unhappy with `find` and apparently there is an existing tool to do just that, see Janis's posts in this thread.
But find is the best we have, and it's a mess. It uses mandatory syntax
that needs to be quoted (the {}) and does not always preserve the desred
behaviour. For example
grep -rq needle haystack
can succeed (exit 0) where
find haystack -type f -exec grep -q needle '{}' +
can fail (exit non-zero). This is because find can run multiple
commands and does not always combine the exit statuses correctly. I
would be happy to be wrong about this, but I'm sure I tested it some
time ago.
Interesting - that's not something I've ever come across but thanks for bringing it up as a possible concern.
On 10/5/2023 12:40 PM, Richard Kettlewell wrote:
Prioritizing consistency over usability, then.
No. Having one doesn't mean you can't have the other. Assuming that
some people find it unusable to type "find . -type f exec grep" for
calling grep when they already do "find . -type f" for finding files
and "find . -type f -exec sed" for calling sed, then had the GNU
people solved that usability problem by providing a tool to let us do:
tool finding-args grep greping-args
tool finding-args sed seding-args
tool finding-args awk seding-args
instead of:
grep finding-args greping-args
find finding-args -exec sed seding-args
find finding-args -exec awk awking-args
we would have usability and consistency.
If Unix were being invented today and the design decision beingAre you somehow under the impression that the existence of “grep -r”
presented in an attempt to answer the question "how do we call a text
processing tool on every file found under a directory?" was:
IF (tool == grep) && (provider == GNU) THEN
tool -r '...'
ELSE
find . -type f tool '...' {} +
ENDIF
instead of just:
find . -type f tool '...' {} +
the person suggesting it would be ridiculed and sent back to the
drawing board.
prevents the second answer from working? If not then why on earth would
you imagine anyone would give the first answer?
The imaginary proposed existence of "GNU grep -r" when first designing
Unix is what I described in that first answer and no, you cannot give
the second answer when there are exceptions to the rule. I don't know
how to restate what I'm saying in a way you might better understand,
sorry.
But your remark raises an interesting question. Are you happy with
find? I use it quite a lot, but I am unhappy with it pretty much every
time!
I think OP is somewhat cryptically arguing that:
a) People can't use the new fancy GNU stuff in portable scripts. except
if they...
b) In order to use them in a portable script, they'd have to code as
shown above - that is, only use the new fancy GNU stuff if they are
running in an environment known to have that stuff. But ...
c) Nobody is going to do that, because it is just silly, so you end up
just coding it the old-fashioned way, and thus ...
d) The new stuff never gets used, so why should anyone bother designing
and implementing it?
But find is the best we have, and it's a mess. It uses mandatory syntax
that needs to be quoted (the {})
and does not always preserve the desred
behaviour. For example
grep -rq needle haystack
can succeed (exit 0) where
find haystack -type f -exec grep -q needle '{}' +
can fail (exit non-zero). This is because find can run multiple
commands and does not always combine the exit statuses correctly.
Ben Bacarisse wrote:
But find is the best we have, and it's a mess. It uses mandatory syntax
that needs to be quoted (the {})
The {} does not need to be quoted. That's because { is a reserved
word in the shell, not an operator like (.
and does not always preserve the desred
behaviour. For example
grep -rq needle haystack
can succeed (exit 0) where
find haystack -type f -exec grep -q needle '{}' +
can fail (exit non-zero). This is because find can run multiple
commands and does not always combine the exit statuses correctly.
It combines them in the way specified in POSIX, which says "If any
invocation returns a non-zero value as exit status, the find utility
shall return a non-zero exit status." If I recall correctly, the
POSIX spec for this was based on SVR4. Presumably the SVR4 developers
did it that way because that's what you want for the usual case where non-zero means an error occurred. I.e. if find exits non-zero you
know that either find itself or at least one of the utility
invocations encountered an error.
However, it does mean find's exit status is misleading if the invoked
utility can exit with non-zero in some non-error situations (such as
grep's exit of 1 indicating no match). It shouldn't be too hard to
come up with a tweak that gives the right info. Maybe something like (untested):
test -n "$(find haystack -type f -exec \
sh -c 'grep -q needle "$@" && echo found' sh {} +)"
Obviously it's only worth going to that much trouble in a script.
For casual interactive use, I'd be inclined to use:
find haystack -type f -exec grep -l needle '{}' + | head -n 1
and just observe whether it writes a pathname or not. (Or even just
omit the "head -n 1" and hit Ctrl-C if it starts writing pathnames.)
Ed Morton <[email protected]> writes:
On 10/2/2023 2:09 AM, Richard Kettlewell wrote:
Ed Morton <[email protected]> writes:
So I don't see any of that as justifying adding a bunch of options toWhy do you think it needs justifying? It’s their code, they can add
grep to do something other than it's primary purpose of g/re/p and
making it different from all other text processing tools in that
regard.
whatever they like to it.
The GNU people added functionality to grep in a way that is
contradictory to the Unix philosophy and makes it inconsistent with
all other text processing tools.
Why does that matter?
So far the only suggestion I've heard for why they did that is so
people could do:
grep -r 'regexp'
instead of:
find . -type f -exec grep -H 'regexp' {} +
which saves us about 20 simple, common characters over find+grep but
does nothing for find+awk, find+sed, etc.
Sounds good to me. Less typing = better. Given the uptake of the GNU
tools I suspect my opinion is widely shared.
To me, banning ‘grep -r’ would not introduce enough additional consistency to justify the reduction in convenience. Not even close.
Well, that's the trouble with feeping creaturism. Once the
creature has fept, it's impossible to reconsider it; there are always
some people using it who mustn't be upset. The time to decide is
/before/ adding it. [...]
[ disproportionally growing sizes of man-pages (since V7) ]
Geoff Clare <[email protected]d> writes:
Ben Bacarisse wrote:
But find is the best we have, and it's a mess. It uses mandatory syntax >>> that needs to be quoted (the {})
The {} does not need to be quoted. That's because { is a reserved
word in the shell, not an operator like (.
Is this true of all shells? I was going by the find man page. Maybe
it needs an update?
`echo {}` prints "{}" in every shell I've tried (bash, csh, tcsh, ksh,
zsh, fish, dash, busybox sh).
Ben Bacarisse <[email protected]> writes:
Geoff Clare <[email protected]d> writes:
Ben Bacarisse wrote:
But find is the best we have, and it's a mess. It uses mandatory syntax >>>> that needs to be quoted (the {})
The {} does not need to be quoted. That's because { is a reserved
word in the shell, not an operator like (.
Is this true of all shells? I was going by the find man page. Maybe
it needs an update?
`echo {}` prints "{}" in every shell I've tried (bash, csh, tcsh, ksh,
zsh, fish, dash, busybox sh).
Keith Thompson <[email protected]> writes:
Ben Bacarisse <[email protected]> writes:
Geoff Clare <[email protected]d> writes:
Ben Bacarisse wrote:
But find is the best we have, and it's a mess. It uses mandatory syntax >>>>> that needs to be quoted (the {})
The {} does not need to be quoted. That's because { is a reserved
word in the shell, not an operator like (.
Is this true of all shells? I was going by the find man page. Maybe
it needs an update?
`echo {}` prints "{}" in every shell I've tried (bash, csh, tcsh, ksh,
zsh, fish, dash, busybox sh).
The find man page repeats that {} "might" have to be escaped or quoted several times. The EXAMPLES sections quotes it, and then some text goes
on to explain why!
I accept that it's wrong to say that.
So I'll change my remark back to the one I had intended: find uses
syntax that needs to be quoted (the ;). Annoyingly, I'd flipped from ;
to {} because I didn't think that ; was used in the quoted text!
On Fri, 06 Oct 2023 13:28:43 -0400, Keith Thompson <[email protected]> wrote:
`echo {}` prints "{}" in every shell I've tried (bash, csh, tcsh, ksh,
zsh, fish, dash, busybox sh).
From "man bash" ...
{ and } are reserved words and must occur where a reserved word is permitted to be recognized.
So if they occur somewhere where a reserved word is not permitted, then they are
just normal characters.
Ed Morton <[email protected]> writes:
On 10/5/2023 2:37 PM, Ben Bacarisse wrote:
Ed Morton <[email protected]> writes:
On 10/3/2023 2:00 AM, Richard Kettlewell wrote:Those are not the only concepts that matter.
Ed Morton <[email protected]> writes:
On 10/2/2023 2:09 AM, Richard Kettlewell wrote:Why does that matter?
Ed Morton <[email protected]> writes:
So I don't see any of that as justifying adding a bunch of options to >>>>>>>> grep to do something other than it's primary purpose of g/re/p and >>>>>>>> making it different from all other text processing tools in that >>>>>>>> regard.Why do you think it needs justifying? It’s their code, they can add >>>>>>> whatever they like to it.
The GNU people added functionality to grep in a way that is
contradictory to the Unix philosophy and makes it inconsistent with >>>>>> all other text processing tools.
For the same reasons that cohesion and consistency matter in any
system. Google "software" with those 2 terms to find more information on >>>> how those concepts apply to software.
Of course, they're just the answer to the question Richard asked.
They are /your/ answer to his question -- these are the concepts that
make it matter to you. Other concepts (like ease of use) don't
necessarily give the same answer which is why I mention them.
answer would be "It doesn't matter much -- ease of use is too important
in this case".
(I hope you are not being hyper literal here. My "answer" is not an
answer in the literal sense. If I took "Why does that matter?"
absolutely literally, I'd have to give your answer as well with maybe
just "but only a teeny, tiny bit" added. But ripostes like "Why does
that matter?" are almost always rhetorical, and not literal requests for
the reasons, no matter how insignificant the respondent might consider
them to be.)
If Unix were being invented today and the design decision being presented >>>> in an attempt to answer the question "how do we call a text processing toolfind . -type f -exec tool '...' '{}' +
on every file found under a directory?" was:
IF (tool == grep) && (provider == GNU) THEN
tool -r '...'
ELSE
find . -type f tool '...' {} +
ENDIF
instead of just:
find . -type f tool '...' {} +
Right, thanks. I typed my response once and my newsreader discarded it so I >> had to type it again and rushed it.
the person suggesting it would be ridiculed and sent back to the drawing >>>> board.It's not "just" find ... find is a mess. If the file system, the shell >>> and all the rest were such that adding some command or prefix like
rec grep pattern .
made grep behave pretty much like grep -r then no one would bother to
add options like -r to grep.
Agreed, that is the right solution if people are unhappy with `find` and
apparently there is an existing tool to do just that, see Janis's posts in >> this thread.
tw may be better than find, but that's a low bar. My "rec" was intended
to be hypothetical. I should maybe have said that if it were possible
to have a rec prefix that magically just "did the right thing" then -r
would not be needed.
But your remark raises an interesting question. Are you happy with
find? I use it quite a lot, but I am unhappy with it pretty much every
time!
But find is the best we have, and it's a mess. It uses mandatory syntax >>> that needs to be quoted (the {}) and does not always preserve the desred >>> behaviour. For example
grep -rq needle haystack
can succeed (exit 0) where
find haystack -type f -exec grep -q needle '{}' +
can fail (exit non-zero). This is because find can run multiple
commands and does not always combine the exit statuses correctly. I
would be happy to be wrong about this, but I'm sure I tested it some
time ago.
Interesting - that's not something I've ever come across but thanks for
bringing it up as a possible concern.
It's not a possible concern, it's an actual concern!
know if "pattern" occurs in any file from . down, you /can't/ use
find . -type f -exec grep -q pattern '{}' +
because you will get the wrong answer in some cases.
But consider the general case... Imagine a collection of tools to test
if a file has this or that property. The tools can all have multiple arguments but what do they do with conflicting answers? For some
properties it might be useful for the tool to report success (0) if
/all/ the arguments have that property and for other properties it might
be desirable to report success if /any/ of the arguments have it. If
find splits an argument list into two and the tool reports 0 on one half
and 1 on the second, what should find report? If the tool is an "all"
tool it should report 1, and if the tool is an "any" tool it should
report 0.
On 2023-10-02, Ed Morton <[email protected]> wrote:
On 10/2/2023 2:09 AM, Richard Kettlewell wrote:
Ed Morton <[email protected]> writes:
So I don't see any of that as justifying adding a bunch of options to
grep to do something other than it's primary purpose of g/re/p and
making it different from all other text processing tools in that
regard.
Why do you think it needs justifying? It’s their code, they can add
whatever they like to it.
The GNU people added functionality to grep in a way that is
contradictory to the Unix philosophy and makes it inconsistent with all
other text processing tools.
- GNU stands for GNU is Not Unix.
- The GNU coding standards document says:
The GNU Project regards standards published by other organizations
as suggestions, not orders. We consider those standards, but we do
not “obey” them. In developing a GNU program, you should implement
an outside standard’s specifications when that makes the GNU system
better overall in an objective sense. When it doesn’t, you shouldn’t.
- Unix programs have recursion built in: from memory I can think of
ls, rm, cp, mv, chgrp, chmod and chown.
- BSD Unixes have a -R option on grep; some, like FreeBSD, have an -r
option as well as a rgrep utility.
But your remark raises an interesting question. Are you happy with
find? I use it quite a lot, but I am unhappy with it pretty much every
time!
To be clear, I'm not talking about "grep -r" violating any standards,
I'm talking about it violating the Unix philosophy and software
engineering fundamentals of cohesion and consistency.
On 10/5/2023 9:25 PM, Ben Bacarisse wrote:
Ed Morton <[email protected]> writes:
On 10/5/2023 2:37 PM, Ben Bacarisse wrote:They are /your/ answer to his question -- these are the concepts that
Ed Morton <[email protected]> writes:
On 10/3/2023 2:00 AM, Richard Kettlewell wrote:Those are not the only concepts that matter.
Ed Morton <[email protected]> writes:
On 10/2/2023 2:09 AM, Richard Kettlewell wrote:Why does that matter?
Ed Morton <[email protected]> writes:
So I don't see any of that as justifying adding a bunch of options to >>>>>>>>> grep to do something other than it's primary purpose of g/re/p and >>>>>>>>> making it different from all other text processing tools in that >>>>>>>>> regard.Why do you think it needs justifying? It’s their code, they can add >>>>>>>> whatever they like to it.
The GNU people added functionality to grep in a way that is
contradictory to the Unix philosophy and makes it inconsistent with >>>>>>> all other text processing tools.
For the same reasons that cohesion and consistency matter in any
system. Google "software" with those 2 terms to find more information on >>>>> how those concepts apply to software.
Of course, they're just the answer to the question Richard asked.
make it matter to you. Other concepts (like ease of use) don't
necessarily give the same answer which is why I mention them.
I said "The GNU people added functionality to grep in a way that is contradictory to the Unix philosophy and makes it inconsistent with all
other text processing tools." and in response Richard asked "Why does that matter?"
I don't see how "ease of use" is an answer to Richard's question.
/My/
answer would be "It doesn't matter much -- ease of use is too important
in this case".
I'm claiming that X matters and being asked why, so responding that it doesn't matter wouldn't make sense or be useful.
(I hope you are not being hyper literal here. My "answer" is not an
answer in the literal sense. If I took "Why does that matter?"
absolutely literally, I'd have to give your answer as well with maybe
just "but only a teeny, tiny bit" added. But ripostes like "Why does
that matter?" are almost always rhetorical, and not literal requests for
the reasons, no matter how insignificant the respondent might consider
them to be.)
It's not a possible concern, it's an actual concern!But find is the best we have, and it's a mess. It uses mandatory syntax >>>> that needs to be quoted (the {}) and does not always preserve the desred >>>> behaviour. For example
grep -rq needle haystack
can succeed (exit 0) where
find haystack -type f -exec grep -q needle '{}' +
can fail (exit non-zero). This is because find can run multiple
commands and does not always combine the exit statuses correctly. I
would be happy to be wrong about this, but I'm sure I tested it some
time ago.
Interesting - that's not something I've ever come across but thanks for
bringing it up as a possible concern.
It's only an actual concern if it actually happens and you're saying above that you're not sure if it happens or not, it's just something you think
you saw some time in the past ("I would be happy to be wrong about this,
but I'm sure I tested it some time ago."), hence my saying it's a possible concern.
If you want to
know if "pattern" occurs in any file from . down, you /can't/ use
find . -type f -exec grep -q pattern '{}' +
because you will get the wrong answer in some cases.
OK, then don't do that, do it one of the various other simple ways it can
be done, e.g.:
find . -type f -exec grep -m1 pattern '{}' +
and test for any output, but I'm not arguing that `find` is the best
possible answer to the issues, I'm saying that adding `-r` to grep is the wrong answer for the reasons I've already stated.
But consider the general case... Imagine a collection of tools to test
if a file has this or that property. The tools can all have multiple
arguments but what do they do with conflicting answers? For some
properties it might be useful for the tool to report success (0) if
/all/ the arguments have that property and for other properties it might
be desirable to report success if /any/ of the arguments have it. If
find splits an argument list into two and the tool reports 0 on one half
and 1 on the second, what should find report? If the tool is an "all"
tool it should report 1, and if the tool is an "any" tool it should
report 0.
How does adding "-r" to grep solve that problem for awk and sed?
Ed Morton <[email protected]> writes:<snip>
On 10/5/2023 9:25 PM, Ben Bacarisse wrote:
But consider the general case... Imagine a collection of tools to test
if a file has this or that property. The tools can all have multiple
arguments but what do they do with conflicting answers? For some
properties it might be useful for the tool to report success (0) if
/all/ the arguments have that property and for other properties it might >>> be desirable to report success if /any/ of the arguments have it. If
find splits an argument list into two and the tool reports 0 on one half >>> and 1 on the second, what should find report? If the tool is an "all"
tool it should report 1, and if the tool is an "any" tool it should
report 0.
How does adding "-r" to grep solve that problem for awk and sed?
Eh?
On 10/7/2023 5:17 PM, Ben Bacarisse wrote:
Ed Morton <[email protected]> writes:<snip>
On 10/5/2023 9:25 PM, Ben Bacarisse wrote:
Eh?But consider the general case... Imagine a collection of tools to test >>>> if a file has this or that property. The tools can all have multiple
arguments but what do they do with conflicting answers? For some
properties it might be useful for the tool to report success (0) if
/all/ the arguments have that property and for other properties it might >>>> be desirable to report success if /any/ of the arguments have it. If
find splits an argument list into two and the tool reports 0 on one half >>>> and 1 on the second, what should find report? If the tool is an "all" >>>> tool it should report 1, and if the tool is an "any" tool it should
report 0.
How does adding "-r" to grep solve that problem for awk and sed?
The problem you describe above isn't unique to grep, it also exists for
sed, awk and other tools.
Giving GNU grep a "-r" option to solve the
problem for grep does nothing to solve the problem for any other tool, but there are alternative solutions that could be implemented to solve it for
all similar tools as discussed elsethread.
Ed Morton <[email protected]> writes:
On 10/7/2023 5:17 PM, Ben Bacarisse wrote:
Ed Morton <[email protected]> writes:<snip>
On 10/5/2023 9:25 PM, Ben Bacarisse wrote:
Eh?But consider the general case... Imagine a collection of tools to test >>>>> if a file has this or that property. The tools can all have multiple >>>>> arguments but what do they do with conflicting answers? For some
properties it might be useful for the tool to report success (0) if
/all/ the arguments have that property and for other properties it might >>>>> be desirable to report success if /any/ of the arguments have it. If >>>>> find splits an argument list into two and the tool reports 0 on one half >>>>> and 1 on the second, what should find report? If the tool is an "all" >>>>> tool it should report 1, and if the tool is an "any" tool it should
report 0.
How does adding "-r" to grep solve that problem for awk and sed?
The problem you describe above isn't unique to grep, it also exists for
sed, awk and other tools.
Yes. The problem is even described in a tool-agnostic way -- no mention
of grep at all!
Giving GNU grep a "-r" option to solve the
problem for grep does nothing to solve the problem for any other tool, but >> there are alternative solutions that could be implemented to solve it for
all similar tools as discussed elsethread.
Two points. I don't thing there are alternative solutions, but if so,
can you point me to them as I've lost track? I want to find one (since
I've been bitten by this problem) so I would like to check them out.
Secondly, I am pretty sure that any near solution to this problem will
come with complications. Your original complaint was based on adding -r
to grep (a very common use case) when find is the consistent option.
But find's behaviour is /not/ consistent with what grep does as I have detailed above. I would go so far as to argue that a solution that is apparently coherent and consistent, right up until it breaks because of something arbitrary like when find breaks it's argument list is
borderline dangerous. At the very least, it requires more careful
thought than remembering which tools have -r.
A good, consistent, solution would be allow an argument list to be
supplied by a generator. The program could get to work as soon as it
had a file to process, but there would be no limit on the number of
files. But this is not possible with the Unix model of what constitutes
a command's arguments.
On 10/8/2023 8:43 AM, Ben Bacarisse wrote:
Secondly, I am pretty sure that any near solution to this problem will
come with complications. Your original complaint was based on adding -r
to grep (a very common use case) when find is the consistent option.
My complaint is that adding -r to grep makes it inconsistent with and
doesn't solve the issues for any of the other similar tools.
On 09.10.2023 15:18, Ed Morton wrote:
On 10/8/2023 8:43 AM, Ben Bacarisse wrote:
Secondly, I am pretty sure that any near solution to this problem will
come with complications. Your original complaint was based on adding -r >>> to grep (a very common use case) when find is the consistent option.
My complaint is that adding -r to grep makes it inconsistent with and
doesn't solve the issues for any of the other similar tools.
I think there's even a bigger issue. It's usually not sufficient to add
only a -r option,
more sooner than later you want to control subsets of
the directory tree, thus have to add yet more options - to *every* tool
that is to be enhanced by a [built-in] recursive tree-walk function.
And every tool will choose its own option subset (and usually also its
own syntax) to implement that.
This observation (incl. inconsistencies between tools' implementations)
make it (design-wise) straightforward for a separation (as already
posted) like tw -tw-options... cmd -cmd-options... cmd-args...
Looking into the original post's GNU grep's options example is quite enlightening, I'd say.
Janis
On 10/8/2023 8:43 AM, Ben Bacarisse wrote:
Ed Morton <[email protected]> writes:
On 10/7/2023 5:17 PM, Ben Bacarisse wrote:Yes. The problem is even described in a tool-agnostic way -- no mention
Ed Morton <[email protected]> writes:<snip>
On 10/5/2023 9:25 PM, Ben Bacarisse wrote:
Eh?But consider the general case... Imagine a collection of tools to test >>>>>> if a file has this or that property. The tools can all have multiple >>>>>> arguments but what do they do with conflicting answers? For some
properties it might be useful for the tool to report success (0) if >>>>>> /all/ the arguments have that property and for other properties it might >>>>>> be desirable to report success if /any/ of the arguments have it. If >>>>>> find splits an argument list into two and the tool reports 0 on one half >>>>>> and 1 on the second, what should find report? If the tool is an "all" >>>>>> tool it should report 1, and if the tool is an "any" tool it should >>>>>> report 0.
How does adding "-r" to grep solve that problem for awk and sed?
The problem you describe above isn't unique to grep, it also exists for
sed, awk and other tools.
of grep at all!
Giving GNU grep a "-r" option to solve theTwo points. I don't thing there are alternative solutions, but if so,
problem for grep does nothing to solve the problem for any other tool, but >>> there are alternative solutions that could be implemented to solve it for >>> all similar tools as discussed elsethread.
can you point me to them as I've lost track? I want to find one (since
I've been bitten by this problem) so I would like to check them out.
A tool such as the tree-walk "tw" (https://github.com/att/ast/tree/master/src/cmd/tw) tool that apparently
can find files and call a tool on those found files as suggested by me and others in this thread. I'm not saying that THAT tool is the solution,
though, (I'd never heard of it till it was mentioned in this thread and I don't know any more about it) I'm saying a solution for all tools could
have been created instead of modifying grep as was done.
Secondly, I am pretty sure that any near solution to this problem will
come with complications. Your original complaint was based on adding -r
to grep (a very common use case) when find is the consistent option.
My complaint is that adding -r to grep makes it inconsistent with and
doesn't solve the issues for any of the other similar tools.
But find's behaviour is /not/ consistent with what grep does as I have
detailed above. I would go so far as to argue that a solution that is
apparently coherent and consistent, right up until it breaks because of
something arbitrary like when find breaks it's argument list is
borderline dangerous. At the very least, it requires more careful
thought than remembering which tools have -r.
I'm not saying that "find" solves all of the issues, I'm saying that adding "-r" to grep was the wrong thing to do as it doesn't solve all the issues
and introduces other issues.
Do you think that ls -R, rm -r and chmod -r were the wrong thing to
do? What about cp -r?
On 10/9/2023 2:22 PM, Ben Bacarisse wrote:
<snip>
Do you think that ls -R, rm -r and chmod -r were the wrong thing to
do? What about cp -r?
As I mentioned elsethread, those are tools that operate on file
attributes, not file contents, so it seems as reasonable to me for them
to be able to find files to operate on as it does for tools that operate
on file contents, such as grep and awk, to be able to find that text
within files to operate on.
If someone decided to add arguments to `rm` or `cp` to change the
contents of files then we could have this same discussion about breaking
with Unix philosophy, loose cohesion, etc. about those tools.
Ben Bacarisse <[email protected]> writes:
Keith Thompson <[email protected]> writes:
Ben Bacarisse <[email protected]> writes:
Geoff Clare <[email protected]d> writes:
Ben Bacarisse wrote:
But find is the best we have, and it's a mess. It uses mandatory syntax >>>>>> that needs to be quoted (the {})
The {} does not need to be quoted. That's because { is a reserved
word in the shell, not an operator like (.
Is this true of all shells? I was going by the find man page. Maybe
it needs an update?
`echo {}` prints "{}" in every shell I've tried (bash, csh, tcsh, ksh,
zsh, fish, dash, busybox sh).
The find man page repeats that {} "might" have to be escaped or quoted
several times. The EXAMPLES sections quotes it, and then some text goes
on to explain why!
I accept that it's wrong to say that.
So I'll change my remark back to the one I had intended: find uses
syntax that needs to be quoted (the ;). Annoyingly, I'd flipped from ;
to {} because I didn't think that ; was used in the quoted text!
The find(1) man page (for GNU findutils 4.8.0 and in the latest version
in the git repo) says in one place (under "-exec command ;") that {} and ; *might* need to be escaped, and in another (under "-exec command {}+")
that {} *needs* to be escaped.
On 10/9/2023 2:22 PM, Ben Bacarisse wrote:
<snip>
Do you think that ls -R, rm -r and chmod -r were the wrong thing to
do? What about cp -r?
As I mentioned elsethread, those are tools that operate on file attributes, not file contents, so it seems as reasonable to me for them to be able to find files to operate on as it does for tools that operate on file
contents, such as grep and awk, to be able to find that text within files
to operate on.
Ed Morton <[email protected]> writes:
On 10/9/2023 2:22 PM, Ben Bacarisse wrote:
<snip>
Do you think that ls -R, rm -r and chmod -r were the wrong thing to
do? What about cp -r?
As I mentioned elsethread, those are tools that operate on file attributes, >> not file contents, so it seems as reasonable to me for them to be able to
find files to operate on as it does for tools that operate on file
contents, such as grep and awk, to be able to find that text within files
to operate on.
I was going to suggest that, as we have both made our points well enough
by now, we could call it a day,
but you've introduced a whole new
mystery (to me at least) about what kinds of tool can get away with
having -r and which can't.
To my mind, if I were re-designing the way programs get their arguments,
I would want to come up with one solution that worked for as many of the above as possible.
On 10/3/2023 2:26 AM, Kaz Kylheku wrote:
On 2023-10-02, Ed Morton <[email protected]> wrote:
On 10/2/2023 2:09 AM, Richard Kettlewell wrote:
Ed Morton <[email protected]> writes:
So I don't see any of that as justifying adding a bunch of options to >>>>> grep to do something other than it's primary purpose of g/re/p and
making it different from all other text processing tools in that
regard.
Why do you think it needs justifying? It’s their code, they can add
whatever they like to it.
The GNU people added functionality to grep in a way that is
contradictory to the Unix philosophy and makes it inconsistent with all
other text processing tools.
- GNU stands for GNU is Not Unix.
- The GNU coding standards document says:
The GNU Project regards standards published by other organizations
as suggestions, not orders. We consider those standards, but we do
not “obey” them. In developing a GNU program, you should implement >> an outside standard’s specifications when that makes the GNU system >> better overall in an objective sense. When it doesn’t, you shouldn’t.
To be clear, I'm not talking about "grep -r" violating any standards,
I'm talking about it violating the Unix philosophy and software
engineering fundamentals of cohesion and consistency.
- Unix programs have recursion built in: from memory I can think of
ls, rm, cp, mv, chgrp, chmod and chown.
Those all operate on file attributes, not on the contents of files as
text processing tools like grep do. Tools like `rm` or `chmod` being
able to find and perform actions on files is equivalent to text
processing tools like `grep` or `awk` being able to find and perform
actions on text inside files.
- BSD Unixes have a -R option on grep; some, like FreeBSD, have an -r
option as well as a rgrep utility.
Yes, GNUisms are apparently creeping into BSD tools, usually for the
better though.
Ed.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 10:30:33 |
| Calls: | 12,100 |
| Files: | 15,003 |
| Messages: | 6,517,978 |