Re: grep -R without directory argument
On April 30, 2015 2:02:23 PM GMT+02:00, "Todd C. Miller"
wrote:
>On Thu, 30 Apr 2015 05:58:57 -0600, "Todd C. Miller" wrote:
>
>> GNU grep warns in this case before reading from stdin which seems
>reasonable.
>> % grep -R foo
>> grep: warning: recursive search of stdin
>> ...
>>
>> I'd rather add a warning than change the behavior.
>
>Trivial diff to add the warning.
I think the warning is wrong. -R is only said to affect directories passed as
arguments, right? I'm inclined to say this is excessive hand holding.
/Alexander
>
> - todd
>
>Index: usr.bin/grep/grep.c
>===
>RCS file: /cvs/src/usr.bin/grep/grep.c,v
>retrieving revision 1.50
>diff -u -p -u -r1.50 grep.c
>--- usr.bin/grep/grep.c16 Mar 2015 13:27:59 - 1.50
>+++ usr.bin/grep/grep.c30 Apr 2015 12:01:32 -
>@@ -444,6 +444,8 @@ main(int argc, char *argv[])
> ++argv;
> }
>
>+ if (Rflag && argc == 0)
>+ warnx("warning: recursive search of stdin");
> if (Eflag)
> cflags |= REG_EXTENDED;
> if (Fflag)
Re: grep -R without directory argument
On Thu, 30 Apr 2015 05:58:57 -0600, "Todd C. Miller" wrote:
> GNU grep warns in this case before reading from stdin which seems reasonable.
> % grep -R foo
> grep: warning: recursive search of stdin
> ...
>
> I'd rather add a warning than change the behavior.
Trivial diff to add the warning.
- todd
Index: usr.bin/grep/grep.c
===
RCS file: /cvs/src/usr.bin/grep/grep.c,v
retrieving revision 1.50
diff -u -p -u -r1.50 grep.c
--- usr.bin/grep/grep.c 16 Mar 2015 13:27:59 - 1.50
+++ usr.bin/grep/grep.c 30 Apr 2015 12:01:32 -
@@ -444,6 +444,8 @@ main(int argc, char *argv[])
++argv;
}
+ if (Rflag && argc == 0)
+ warnx("warning: recursive search of stdin");
if (Eflag)
cflags |= REG_EXTENDED;
if (Fflag)
Re: grep -R without directory argument
On Thu, 30 Apr 2015 07:51:55 +0200, Martin Natano wrote: > grep reads from standard input when no files are specified. It also does > so when -R is used, which doesn't really make sense. I think using the > current working directory as a fallback when no directories are > specified would make sense. POSIX says "If no file operands are > specified, the standard input shall be used.", but -R is an extension > to POSIX, so I guess it is not bound by that. GNU grep warns in this case before reading from stdin which seems reasonable. % grep -R foo grep: warning: recursive search of stdin ... I'd rather add a warning than change the behavior. - todd
Re: grep -R without directory argument
On 2015-04-30 04:16, Mark Kettenis wrote: Date: Thu, 30 Apr 2015 07:51:55 +0200 From: Martin Natano grep reads from standard input when no files are specified. It also does so when -R is used, which doesn't really make sense. I think using the current working directory as a fallback when no directories are specified would make sense. POSIX says "If no file operands are specified, the standard input shall be used.", but -R is an extension to POSIX, so I guess it is not bound by that. Far too often I've started a grep -R and waiting for the output, only to recognize minutes later, that I forgot to add the '.' at the end of the command and it is reading from stdin. I do that without the -R option too ;). Any thoughts? OK? Not convinced this is an improvement. Some other *Nixes print a warning in that event, which I find more useful than grepping a directory I didn't mean. On OS X f'rinstance: $ grep -r foo grep: warning: recursive search of stdin $
Re: grep -R without directory argument
On Thu, 30 Apr 2015, Stuart Henderson wrote: On 2015/04/30 07:51, Martin Natano wrote: grep reads from standard input when no files are specified. It also does so when -R is used, which doesn't really make sense. I think using the current working directory as a fallback when no directories are specified would make sense. POSIX says "If no file operands are specified, the standard input shall be used.", but -R is an extension to POSIX, so I guess it is not bound by that. Far too often I've started a grep -R and waiting for the output, only to recognize minutes later, that I forgot to add the '.' at the end of the command and it is reading from stdin. It's an extension, and it might not make sense to you (though I can imagine counter-arguments), but the current behaviour matches other common greps in use - deviating from this seems like a bad idea. It also matches behaviour of gzip(1) (gzip -r) and other tools, like find(1) or tar(1). Regards, David
Re: grep -R without directory argument
> Date: Thu, 30 Apr 2015 07:51:55 +0200 > From: Martin Natano > > grep reads from standard input when no files are specified. It also does > so when -R is used, which doesn't really make sense. I think using the > current working directory as a fallback when no directories are > specified would make sense. POSIX says "If no file operands are > specified, the standard input shall be used.", but -R is an extension > to POSIX, so I guess it is not bound by that. > > Far too often I've started a grep -R and waiting for the output, only to > recognize minutes later, that I forgot to add the '.' at the end of the > command and it is reading from stdin. I do that without the -R option too ;). > Any thoughts? OK? Not convinced this is an improvement.
Re: grep -R without directory argument
On April 30, 2015 9:19:18 AM GMT+02:00, Alexander Hall wrote: >While the situation you describe is admittedly horribly annoying >(BTDT), we do allow 'grep -I "123"', which would also seem >"pointless". Bah. That's lowercase -i, obviously. Stupid phone. /Alexander
Re: grep -R without directory argument
On 2015/04/30 07:51, Martin Natano wrote: > grep reads from standard input when no files are specified. It also does > so when -R is used, which doesn't really make sense. I think using the > current working directory as a fallback when no directories are > specified would make sense. POSIX says "If no file operands are > specified, the standard input shall be used.", but -R is an extension > to POSIX, so I guess it is not bound by that. > > Far too often I've started a grep -R and waiting for the output, only to > recognize minutes later, that I forgot to add the '.' at the end of the > command and it is reading from stdin. It's an extension, and it might not make sense to you (though I can imagine counter-arguments), but the current behaviour matches other common greps in use - deviating from this seems like a bad idea. Apart from potential damage in ports, I'd also be concerned about user scripts misbehaving if this were to change.
Re: grep -R without directory argument
2015-04-30 8:51 GMT+03:00 Martin Natano :
> grep reads from standard input when no files are specified. It also does
> so when -R is used, which doesn't really make sense. I think using the
> current working directory as a fallback when no directories are
> specified would make sense. POSIX says "If no file operands are
> specified, the standard input shall be used.", but -R is an extension
> to POSIX, so I guess it is not bound by that.
>
> Far too often I've started a grep -R and waiting for the output, only to
> recognize minutes later, that I forgot to add the '.' at the end of the
> command and it is reading from stdin.
>
> Any thoughts? OK?
>
> cheers,
> natano
>
> Index: grep.1
> ===
> RCS file: /cvs/src/usr.bin/grep/grep.1,v
> retrieving revision 1.43
> diff -u -p -r1.43 grep.1
> --- grep.1 13 Jan 2015 04:45:34 - 1.43
> +++ grep.1 29 Apr 2015 20:09:15 -
> @@ -238,6 +238,7 @@ will only search a file until a match ha
> making searches potentially less expensive.
> .It Fl R
> Recursively search subdirectories listed.
> +If no directories are specified, the current working directory is used.
> .It Fl s
> Silent mode.
> Nonexistent and unreadable files are ignored
> Index: grep.c
> ===
> RCS file: /cvs/src/usr.bin/grep/grep.c,v
> retrieving revision 1.50
> diff -u -p -r1.50 grep.c
> --- grep.c 16 Mar 2015 13:27:59 - 1.50
> +++ grep.c 29 Apr 2015 20:09:15 -
> @@ -481,14 +481,17 @@ main(int argc, char *argv[])
> if ((argc == 0 || argc == 1) && !Rflag && !Hflag)
> hflag = 1;
>
> - if (argc == 0)
> - exit(!procfile(NULL));
>
> - if (Rflag)
> - c = grep_tree(argv);
> - else
> + if (Rflag) {
> + char *cwd[] = {".", NULL};
> + c = grep_tree(argc ? argv : cwd);
> + } else {
> + if (argc == 0)
> + exit(!procfile(NULL));
> +
> for (c = 0; argc--; ++argv)
> c += procfile(*argv);
> + }
>
> exit(c ? (file_err ? (qflag ? 0 : 2) : 0) : (file_err ? 2 : 1));
> }
The -R is not "go through directories listed" option; it's a "go
through directories instead of ignoring them, if they are listed on
the command line". It's perfectly acceptable to list only files on
command line and still use -R option; it'll be just a no-op in this
case. Same applies to "no files listed on command line": -R is just a
no-op here.
Maybe some sentences in manual page could be reworded to make this
more clear, though.
--
WBR,
Vadim Zhukov
Re: grep -R without directory argument
On April 30, 2015 7:51:55 AM GMT+02:00, Martin Natano wrote: >grep reads from standard input when no files are specified. It also >does >so when -R is used, which doesn't really make sense. I think using the >current working directory as a fallback when no directories are >specified would make sense. POSIX says "If no file operands are >specified, the standard input shall be used.", but -R is an extension >to POSIX, so I guess it is not bound by that. > >Far too often I've started a grep -R and waiting for the output, only >to >recognize minutes later, that I forgot to add the '.' at the end of the >command and it is reading from stdin. > .It Fl R > Recursively search subdirectories listed. I don't like this implied "." entry. If anything, it could fail or whine, but I think it does exactly what is said to do. If there are any directory entries listed, recursively search them. While the situation you describe is admittedly horribly annoying (BTDT), we do allow 'grep -I "123"', which would also seem "pointless". /Alexander
grep -R without directory argument
grep reads from standard input when no files are specified. It also does
so when -R is used, which doesn't really make sense. I think using the
current working directory as a fallback when no directories are
specified would make sense. POSIX says "If no file operands are
specified, the standard input shall be used.", but -R is an extension
to POSIX, so I guess it is not bound by that.
Far too often I've started a grep -R and waiting for the output, only to
recognize minutes later, that I forgot to add the '.' at the end of the
command and it is reading from stdin.
Any thoughts? OK?
cheers,
natano
Index: grep.1
===
RCS file: /cvs/src/usr.bin/grep/grep.1,v
retrieving revision 1.43
diff -u -p -r1.43 grep.1
--- grep.1 13 Jan 2015 04:45:34 - 1.43
+++ grep.1 29 Apr 2015 20:09:15 -
@@ -238,6 +238,7 @@ will only search a file until a match ha
making searches potentially less expensive.
.It Fl R
Recursively search subdirectories listed.
+If no directories are specified, the current working directory is used.
.It Fl s
Silent mode.
Nonexistent and unreadable files are ignored
Index: grep.c
===
RCS file: /cvs/src/usr.bin/grep/grep.c,v
retrieving revision 1.50
diff -u -p -r1.50 grep.c
--- grep.c 16 Mar 2015 13:27:59 - 1.50
+++ grep.c 29 Apr 2015 20:09:15 -
@@ -481,14 +481,17 @@ main(int argc, char *argv[])
if ((argc == 0 || argc == 1) && !Rflag && !Hflag)
hflag = 1;
- if (argc == 0)
- exit(!procfile(NULL));
- if (Rflag)
- c = grep_tree(argv);
- else
+ if (Rflag) {
+ char *cwd[] = {".", NULL};
+ c = grep_tree(argc ? argv : cwd);
+ } else {
+ if (argc == 0)
+ exit(!procfile(NULL));
+
for (c = 0; argc--; ++argv)
c += procfile(*argv);
+ }
exit(c ? (file_err ? (qflag ? 0 : 2) : 0) : (file_err ? 2 : 1));
}
