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:

-d, --directories=ACTION how to handle directories;
-r, --recursive like --directories=recurse
-R, --dereference-recursive likewise, but follow all symlinks
--include=GLOB search only files that match GLOB (a file
pattern)
--exclude=GLOB skip files that match GLOB
--exclude-from=FILE skip files that match any file pattern from
FILE
--exclude-dir=GLOB skip directories that match GLOB

when traditionally "grep" exists to "g/re/p" (the "ed" commands to
Globally match a Regular Expression within files and Print the result),
the tool "find" exists to "find" files, no other text processing
commands have options to find files, and #1 in the Unix philosophy
(https://en.wikipedia.org/wiki/Unix_philosophy) is to "Make each program
do one thing well. To do a new job, build afresh rather than complicate
old programs by adding new "features"."

If grep should have options to find files then maybe they should also:

a) Give "grep" additional options to "sort" it's output, "tr"anslate
characters, "paste" results from multiple files, etc.
b) Give "sed", "awk", "tr", "cut", "paste" etc. the same options as GNU
grep now has so they can also "find" files.

I see grep commands these days that are a relatively long, complicated
mixture of options, some to find files and others to search within
files, e.g.:

grep -r --include='*.html' --include='*.php' --include='*.htm' -Fxl
'regexp' /some/path/
grep -R --include='*.{html,php,htm}' -Fxl 'regexp' /some/path

when "find ... -exec grep ... {} +":

find /some/path \( -name '*.html' -o -name '*.php' -o -name '*.htm'
\) -exec grep -Fxl 'regexp' {} +
find /some/path -regextype egrep -regex '.*\.(html|php|htm)$' -exec
grep -Fxl 'regexp' {} +

or similar would do the job about as briefly and efficiently as well as
making it easier to replace just the grep command with sed or awk
if/when the "search within files" part in future became more complex
than made sense for "grep".

So:

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?

2) Can we expect GUN grep to get additional options in future to do
other things that other Unix commands currently do?

3) Can we expect GNU sed, awk, etc. to also get options to find files
for consistency with GNU grep?

Ed.

Ed Morton <mortonspam@gmail.com> 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...

--
https://www.greenend.org.uk/rjk/

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.

--
Chris Elvidge, England
THE PRINCIPAL'S TOUPEE IS NOT A FRISBEE

On Sun, 01 Oct 2023 14:37:37 +0100, 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".

Oh???

>
> SYNOPSIS
> grep [OPTION...] PATTERNS [FILE...]
> grep [OPTION...] -e PATTERNS ... [FILE...] grep [OPTION...] -f
> PATTERN_FILE ... [FILE...]
>
> DESCRIPTION
> grep searches for PATTERNS in each FILE.

GREP(1) General Commands Manual GREP(1)

NAME
grep, egrep, fgrep - print lines matching a pattern

SYNOPSIS
grep [OPTIONS] PATTERN [FILE...]
grep [OPTIONS] [-e PATTERN | -f FILE] [FILE...]

...

File and Directory Selection

...

-r, --recursive
Read all files under each directory, recursively, following
symbolic links only if they are on the command line. Note
that if no file operand is given, grep searches the working
directory. This is equivalent to the -d recurse option.
....

BUGS
Reporting Bugs
Email bug reports to the bug-reporting address
<bug-grep@gnu.org>. An email archive
<http://lists.gnu.org/mailman/listinfo/bug-grep>
and a bug tracker
<http://debbugs.gnu.org/cgi/pkgreport.cgi?package=grep>
are available.

--
Lew Pitcher
"In Skills We Trust"

On 10/1/2023 7:19 AM, Richard Kettlewell wrote:
> Ed Morton <mortonspam@gmail.com> 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.

Something being useful is a long way from being the only criteria for
adding it to a command. Finding files would be useful for awk, sed,
sort, paste, and every other command that operates on files so by that
criteria all commands should have options to find files in addition to
their existing options. Sorting output would be useful for all commands
that operate on text files too so that "it's useful" criteria all
commands should have options to sort content in addition to their
existing options. Down that path lies the conclusion we should just have
1 command with all options to do everything that all existing commands
do since everything is useful.

>
> You don’t have to use them if you don’t like them...
>

But I do have to deal with existing software that uses them, I don't
have the luxury of pretending they don't exist.

Ed.

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.

Ed Morton <mortonspam@gmail.com> writes:
> On 10/1/2023 7:19 AM, Richard Kettlewell wrote:
>> Ed Morton <mortonspam@gmail.com> 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.
>
> Something being useful is a long way from being the only criteria for
> adding it to a command.

That’s very situational. For a volunteer “useful and fun to do” might be
sufficent, for example.

--
https://www.greenend.org.uk/rjk/

On 01/10/2023 15:48, Ed Morton wrote:
> 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.

OK. Perhaps wrong terminology.

[FILE...] is a list of files - could be * (all files) - shell expands it
to the list of files.

PATTERNS may be a straight character string or a regular expression (see
what I said above) or several, or read from a file.

-R/-r = follow the list of files into subdirectories (doesn't do this by
default)

Of course this has the effect of finding files in the list containing
the pattern. If the list is *, all files are searched.

--
Chris Elvidge, England
I AM SO VERY TIRED

On 2023-10-01, Ed Morton <mortonspam@gmail.com> 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.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On Sun, 01 Oct 2023 17:02:44 +0000, Kaz Kylheku wrote:

> On 2023-10-01, Ed Morton <mortonspam@gmail.com> 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.

Unless you give grep(1) the -l argument[1]:
find . -type f -exec grep -l foo {} \;

[1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/grep.html

[snip]

HTH
--
Lew Pitcher
"In Skills We Trust"

On 2023-10-01, Ed Morton <mortonspam@gmail.com> wrote:

> I'm trying to understand why it's OK for GNU grep to have options to
> find files:

It all started when people added the -C flag for columnized output
to ls(1) and enabled it by default if stdout was a tty--instead of
manually invoking "ls | column" as God intended...

--
Christian "naddy" Weisgerber naddy@mips.inka.de

On 01.10.2023 13:40, Ed Morton 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: [...]

When I read that other post's statement
"Forget find, use grep -rl (or -Rl) (recursive, list)"
I had some (partly similar) thoughts. That's why (in my post) I
emphasized my wording to distinguish the cases by the necessity
to "find" files or not. (Has that wording triggered your post?)

My random thoughts (in no particular order or any valuation) were...
a) Do Unix tools start implementing each function (like DOS does e.g.
with expansion of * and other "wildcards" in each tool vs. shell)
duplicated in every program now, just for (sort of) "convenience"?
Why is there a deviation from the "Separation of Duties" principle?
b) Pipe expressions may grow, it may be simpler to use one process.
Modern xargs or find syntaxes support efficient processing.
Implementing it in 'grep' may simplify logic in certain cases.
There are already deviations from the "Separation of Duties" in
other tools; see 'ls' with its sort extensions and GNU 'ls' yet
with more sort options and a lot other options.
c) Which program shall at what stage do the directory tree walk?
We have a specialized 'find' (or a more powerful/modern 'tw').
We have it supported as ** in newer shell (ksh, zsh, bash)
(but exec buffer limit might pop in here, so safe options are
desirable, or using it in safe ways with built-ins only; ksh).
Now we see it in 'grep'. Will we see it in other programs as well.
(See point a)
d) It is non-standard.
Many folks don't care about standards, they want functionality
(provided by tools that are sometimes designed by "featurities").
It will probably result in a wild proliferation of software versions
(as seen in the public domain sector).
e) Is it an ideological issue? Should I really care?
If it's no burden (in space or time complexity) but helps in some
cases, why not use it?

Janis

On 10/1/2023 10:55 AM, David W. Hodgins wrote:
> On Sun, 01 Oct 2023 08:19:29 -0400, Richard Kettlewell
> <invalid@invalid.invalid> wrote:
>
>> Ed Morton <mortonspam@gmail.com> 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.

find ... -exec grep 'regexp' {} +

doesn't call grep once per file, it calls grep on groups of files so as
to not exceed ARG_MAX for each group.

So, yes it's probably a bit more efficient to call grep once on all
files but not enough so as to justify given grep it's own set of
file-finding arguments and if it did make sense for grep then it'd also
make sense for awk, sed, and every other tool that runs on text files
(or even giving find options to grep in files instead of the other way
around!).

Ed.

>
> Regards, Dave Hodgins

On 10/1/2023 12:02 PM, Kaz Kylheku wrote:
> On 2023-10-01, Ed Morton <mortonspam@gmail.com> 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.

I find myself writing find+grep commands much less frequently than
find+sed or find+awk but YMMV I suppose.

> 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.

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:

find . -type f -exec grep -H foo {} +

I changed the `\;` to `+` so grep gets called on multiple files at a
time instead of one at a time.

>
> 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.

sed, awk, and every other Unix tool have the same behavior, writing
`find . -type f -exec grep -l foo {} +` is just not a big deal, avoids
the problems you mentioned with "**/*.c" and "xargs", and it's good for
people to know how to find files with "find" for when they need to use
any other Unix tool instead of grep on the resultant files.

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.

In article <ufct99$2hrnj$1@dont-email.me>,
Ed Morton <mortonspam@gmail.com> 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>

YMMV
John
groenveld@acm.org

On 2023-10-01, John D Groenveld <groenveld@acm.org> wrote:
> In article <ufct99$2hrnj$1@dont-email.me>,
> Ed Morton <mortonspam@gmail.com> 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>

Looking at just the OpenBSD one at the bottom, I see also that it
includes a -R recursive option.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Ed Morton <mortonspam@gmail.com> 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.

--
https://www.greenend.org.uk/rjk/

In article <wwvr0mda4am.fsf@LkoBDZeT.terraraq.uk>,
Richard Kettlewell <invalid@invalid.invalid> wrote:
>Ed Morton <mortonspam@gmail.com> 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.

2) There will always be a tension between wanting programs to be as useful
as possible and being in conformance with the idea that there should be
limits on functionality (i.e., the concept of "feature creep"). The
standard cliche on this topic is "All programs expand to eventually include
email". We will know we've lost the battle when grep expands to the point
where it can email you the results of the search.

Anyway, this tension always exists and almost always functionality wins
out over conservatism. In the specific case under discussion (recursive
searching in grep), it is pretty common that when you are introducing grep
to a newuser, one of their first comments/requests will be "And, of course
I want to search all the files (meaning, all the subdirectories and files)
So, of course, your tool will do that, right?"

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.

--
To my knowledge, Jacob Navia is not a Christian.

- Rick C Hodgin -

On 02.10.2023 11:30, Kenny McCormack wrote:
> 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.

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 only found a man page lying around on my disk and put it here
http://volatile.gridbug.de/tw.out" rel="nofollow" target="_blank">http://volatile.gridbug.de/tw.out
With usage examples at the bottom of that file.
I found also an old Linux binary from 2006 that I put there
http://volatile.gridbug.de/tw
(Haven't used it regularly, though; was used to archaic 'find'.)

Janis

On 10/2/2023 2:09 AM, Richard Kettlewell wrote:
> Ed Morton <mortonspam@gmail.com> 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.

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.

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" but takes the same arguments
they added to grep for finding files if they feel those are better than
the equivalent "find" arge, and calls whatever command is also provided
in the args with the resulting files, and then we could do:

ftf grep 'regexp'

which is about the same number of chars as using "-r", is consistent
with the Unix philosophy, and has the huge benefit that we could use it
for every other text processing tool too:

ftf sed '...'
ftf awk '...'
etc.

I assume they didn't spend their time and effort
designing/coding/testing/documenting/supporting the grep functionality
for finding files on a whim and I think it's reasonable to ask what the
rationale was for doing that, especially when they could have either
done nothing (20 simple chars - who cares?) or introduced a far more
generally useful separate tool for the purpose. Of the possibilities
they had, the one they chose to implement is concerning for other
potential changes that they might introduce in future.

Ed.

* Janis Papanagnou <janis_papanagnou+ng@hotmail.com> 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.

--
DW

On 02.10.2023 14:26, Damien Wyart wrote:
> * Janis Papanagnou <janis_papanagnou+ng@hotmail.com> 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

(I cannot even get or clone it from here.)

> but it seems some work would be needed to compile it on a recent Linux.

The AST software tools had their own build process, so probably you
have to get the whole AST tree with its build-system to create it.

Janis

> > I found this https://github.com/att/ast/tree/master/src/cmd/tw

* Janis Papanagnou <janis_papanagnou+ng@hotmail.com> 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

--
DW

On 02.10.2023 15:39, Damien Wyart wrote:
>>> I found this https://github.com/att/ast/tree/master/src/cmd/tw" rel="nofollow" target="_blank">https://github.com/att/ast/tree/master/src/cmd/tw
>
> * Janis Papanagnou <janis_papanagnou+ng@hotmail.com> 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

Ah, thanks!

Janis

Ed Morton <mortonspam@gmail.com> writes:
> On 10/2/2023 2:09 AM, Richard Kettlewell wrote:
>> Ed Morton <mortonspam@gmail.com> 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.

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.

--
https://www.greenend.org.uk/rjk/