Re: [patch] -H flag for grep.
On Mon, Feb 21, 2011 at 2:29 PM, Ted Unangst ted.unan...@gmail.com wrote: On Mon, Feb 21, 2011 at 7:34 AM, Pascal Stumpf pascal.stu...@cubes.de wrote: Implement a -H flag for grep, useful for combining e.g. find and grep. Can anyone commit it? I think I can do so tonight, unless someone has a serious problem with it. There was a serious problem (namely, src lock :) ), but it's now been committed. Thanks.
Re: [patch] -H flag for grep.
On Mon, Feb 21, 2011 at 10:00:21PM -0430, Andres Perera wrote:
On Mon, Feb 21, 2011 at 7:01 PM, Philip Guenther guent...@gmail.com wrote:
On Mon, Feb 21, 2011 at 2:30 PM, Fred Crowson open...@crowsons.net wrote:
On 02/21/11 15:54, Alexander Schrijver wrote:
...
grep(1) only prints the filename when it receives more then 1 filename as
arguments. Thus, when you do this:
$ find . -name '*.c' -exec grep bla {} \;
It doesn't print the filename.
But when you use xargs(1), like Bret suggests it does.
$ find . -name *.php -exec grep blah {} \; -print
Will print the file name after the line that grep matches.
The other classical solution is to always pass multiple filenames by
including a /dev/null argument:
B find . -name '*.c' -exec grep bla {} /dev/null \;
That works with the xargs case too:
B find . -name '*.c' -print0 | xargs -0 grep bla /dev/null
these two ugly hacks and the the redundant flag have been sought while
what's natural has been overlooked
find . -name '*.c' -exec awk '/bla/ {print FILENAME $0}'
my that's awkward.
why complicate grep?
--patrick
Anybody has a right to evade taxes if he can get away with it. No citizen
has a moral obligation to assist in maintaining his government.
-- J.P. Morgan
Re: [patch] -H flag for grep.
On Mon, Feb 21, 2011 at 11:30 PM, Andres Perera andre...@zoho.com wrote:
On Mon, Feb 21, 2011 at 7:01 PM, Philip Guenther guent...@gmail.com
wrote:
On Mon, Feb 21, 2011 at 2:30 PM, Fred Crowson open...@crowsons.net
wrote:
On 02/21/11 15:54, Alexander Schrijver wrote:
...
grep(1) only prints the filename when it receives more then 1 filename
as
arguments. Thus, when you do this:
$ find . -name '*.c' -exec grep bla {} \;
It doesn't print the filename.
But when you use xargs(1), like Bret suggests it does.
$ find . -name *.php -exec grep blah {} \; -print
Will print the file name after the line that grep matches.
The other classical solution is to always pass multiple filenames by
including a /dev/null argument:
B B find . -name '*.c' -exec grep bla {} /dev/null \;
That works with the xargs case too:
B find . -name '*.c' -print0 | xargs -0 grep bla /dev/null
these two ugly hacks and the the redundant flag have been sought while
what's natural has been overlooked
find . -name '*.c' -exec awk '/bla/ {print FILENAME $0}'
why complicate grep?
because they forgot to read 'Program Design in the UNIX Environment'?
iru
Re: [patch] -H flag for grep.
On Tue, Feb 22, 2011 at 6:08 AM, patrick keshishian sids...@boxsoft.com wrote: my that's awkward. if you can't combine unix tools, you should be looking at perl. iru
Re: [patch] -H flag for grep.
On Tue, Feb 22, 2011 at 12:52:24PM -0300, Iruatc Souza wrote: On Tue, Feb 22, 2011 at 6:08 AM, patrick keshishian sids...@boxsoft.com wrote: my that's awkward. if you can't combine unix tools, you should be looking at perl. iru I bet everyone here knows one can achieve the same results with awk, perl, C, python, ruby, tcl, Haskell, java and goat sacrifices at fullmoon. That doesn't mean any of those is the easiest or most convenient tool for the job. Using a fully-blown programming language just to output a filename and a line matching a regex is plain overkill.
Re: [patch] -H flag for grep.
On Tue, Feb 22, 2011 at 04:13:34PM -0300, Iruatc Souza wrote: On Tue, Feb 22, 2011 at 2:21 PM, Pascal Stumpf pascal.stu...@cubes.de wrote: On Tue, Feb 22, 2011 at 12:52:24PM -0300, Iruatc Souza wrote: On Tue, Feb 22, 2011 at 6:08 AM, patrick keshishian sids...@boxsoft.com wrote: my that's awkward. if you can't combine unix tools, you should be looking at perl. iru I bet everyone here knows one can achieve the same results with awk, perl, C, python, ruby, tcl, Haskell, java and goat sacrifices at fullmoon. That doesn't mean any of those is the easiest or most convenient tool for the job. Using a fully-blown programming language just to output a filename and a line matching a regex is plain overkill. are you sure adding a flag is the right tool? maybe you should take a look at the reference i mentioned earlier. iru grep(1) is the right tool. Adding a flag just makes it more usable for specific tasks.
Re: [patch] -H flag for grep.
On Tue, Feb 22, 2011 at 02:29:59PM -0430, Andres Perera wrote: On Tue, Feb 22, 2011 at 12:51 PM, Pascal Stumpf pascal.stu...@cubes.de wrote: On Tue, Feb 22, 2011 at 12:52:24PM -0300, Iruatc Souza wrote: On Tue, Feb 22, 2011 at 6:08 AM, patrick keshishian sids...@boxsoft.com wrote: my that's awkward. if you can't combine unix tools, you should be looking at perl. iru I bet everyone here knows one can achieve the same results with awk, perl, C, python, ruby, tcl, Haskell, java and goat sacrifices at fullmoon. That doesn't mean any of those is the easiest or most convenient tool for the job. Using a fully-blown programming language just to output a filename and a line matching a regex is plain overkill. then make the awk line a function or a script ... which would still invoke awk. The problem is not that I'm too lazy to type that awk line. don't add more flags to grep that are hard to guess what they do man(1). -H for header? what does it mean? The name is arbitrarily chosen for GNU compatibility. But as todd@ remarked, there already is a -h flag, so the semantics of -H are quite easy to guess. have you looked at how many flags ls(1) can have? it's a nightmare Yes. I'm not suggesting to add tons of useless long options no one ever uses. It's _one_ flag that's commonly needed in everyday use. All those proposed workarounds and hacks rather prove than disprove that.
Re: [patch] -H flag for grep.
On Tue, Feb 22, 2011 at 12:51 PM, Pascal Stumpf pascal.stu...@cubes.de wrote: On Tue, Feb 22, 2011 at 12:52:24PM -0300, Iruatc Souza wrote: On Tue, Feb 22, 2011 at 6:08 AM, patrick keshishian sids...@boxsoft.com wrote: my that's awkward. if you can't combine unix tools, you should be looking at perl. iru I bet everyone here knows one can achieve the same results with awk, perl, C, python, ruby, tcl, Haskell, java and goat sacrifices at fullmoon. That doesn't mean any of those is the easiest or most convenient tool for the job. Using a fully-blown programming language just to output a filename and a line matching a regex is plain overkill. then make the awk line a function or a script don't add more flags to grep that are hard to guess what they do -H for header? what does it mean? have you looked at how many flags ls(1) can have? it's a nightmare
Re: [patch] -H flag for grep.
You made your point; no need repeating it. On Tue, Feb 22, 2011 at 08:26:31PM +0100, Pascal Stumpf wrote: On Tue, Feb 22, 2011 at 04:13:34PM -0300, Iruatc Souza wrote: On Tue, Feb 22, 2011 at 2:21 PM, Pascal Stumpf pascal.stu...@cubes.de wrote: On Tue, Feb 22, 2011 at 12:52:24PM -0300, Iruatc Souza wrote: On Tue, Feb 22, 2011 at 6:08 AM, patrick keshishian sids...@boxsoft.com wrote: my that's awkward. if you can't combine unix tools, you should be looking at perl. iru I bet everyone here knows one can achieve the same results with awk, perl, C, python, ruby, tcl, Haskell, java and goat sacrifices at fullmoon. That doesn't mean any of those is the easiest or most convenient tool for the job. Using a fully-blown programming language just to output a filename and a line matching a regex is plain overkill. are you sure adding a flag is the right tool? maybe you should take a look at the reference i mentioned earlier. iru grep(1) is the right tool. Adding a flag just makes it more usable for specific tasks.
Re: [patch] -H flag for grep.
On Tue, Feb 22, 2011 at 2:21 PM, Pascal Stumpf pascal.stu...@cubes.de wrote: On Tue, Feb 22, 2011 at 12:52:24PM -0300, Iruatc Souza wrote: On Tue, Feb 22, 2011 at 6:08 AM, patrick keshishian sids...@boxsoft.com wrote: my that's awkward. if you can't combine unix tools, you should be looking at perl. iru I bet everyone here knows one can achieve the same results with awk, perl, C, python, ruby, tcl, Haskell, java and goat sacrifices at fullmoon. That doesn't mean any of those is the easiest or most convenient tool for the job. Using a fully-blown programming language just to output a filename and a line matching a regex is plain overkill. are you sure adding a flag is the right tool? maybe you should take a look at the reference i mentioned earlier. iru
Re: [patch] -H flag for grep.
On Tue, Feb 22, 2011 at 2:21 PM, Pascal Stumpf pascal.stu...@cubes.de wrote: On Tue, Feb 22, 2011 at 12:52:24PM -0300, Iruatc Souza wrote: On Tue, Feb 22, 2011 at 6:08 AM, patrick keshishian sids...@boxsoft.com wrote: my that's awkward. if you can't combine unix tools, you should be looking at perl. iru I bet everyone here knows one can achieve the same results with awk, perl, C, python, ruby, tcl, Haskell, java and goat sacrifices at fullmoon. That doesn't mean any of those is the easiest or most convenient tool for the job. Using a fully-blown programming language just to output a filename and a line matching a regex is plain overkill. not everyone knows sarcasm. iru
Re: [patch] -H flag for grep.
On Tue, Feb 22, 2011 at 4:26 PM, Pascal Stumpf pascal.stu...@cubes.de wrote: On Tue, Feb 22, 2011 at 04:13:34PM -0300, Iruatc Souza wrote: On Tue, Feb 22, 2011 at 2:21 PM, Pascal Stumpf pascal.stu...@cubes.de wrote: On Tue, Feb 22, 2011 at 12:52:24PM -0300, Iruatc Souza wrote: On Tue, Feb 22, 2011 at 6:08 AM, patrick keshishian sids...@boxsoft.com wrote: my that's awkward. if you can't combine unix tools, you should be looking at perl. iru I bet everyone here knows one can achieve the same results with awk, perl, C, python, ruby, tcl, Haskell, java and goat sacrifices at fullmoon. That doesn't mean any of those is the easiest or most convenient tool for the job. Using a fully-blown programming language just to output a filename and a line matching a regex is plain overkill. are you sure adding a flag is the right tool? maybe you should take a look at the reference i mentioned earlier. iru grep(1) is the right tool. Adding a flag just makes it more usable for specific tasks. as it did for cat -v, right?
Re: [patch] -H flag for grep.
On 2011/02/22 01:08, patrick keshishian wrote:
find . -name '*.c' -exec awk '/bla/ {print FILENAME $0}'
my that's awkward.
^^^
*groan*
Re: [patch] -H flag for grep.
On Tue, Feb 22, 2011 at 11:10 AM, Iruatc Souza iru.mu...@gmail.com wrote: On Tue, Feb 22, 2011 at 2:21 PM, Pascal Stumpf pascal.stu...@cubes.de wrote: On Tue, Feb 22, 2011 at 12:52:24PM -0300, Iruatc Souza wrote: On Tue, Feb 22, 2011 at 6:08 AM, patrick keshishian sids...@boxsoft.com wrote: my that's awkward. if you can't combine unix tools, you should be looking at perl. iru I bet everyone here knows one can achieve the same results with awk, perl, C, python, ruby, tcl, Haskell, java and goat sacrifices at fullmoon. That doesn't mean any of those is the easiest or most convenient tool for the job. Using a fully-blown programming language just to output a filename and a line matching a regex is plain overkill. not everyone knows sarcasm. or gets humor for that matter. --patrick
Re: [patch] -H flag for grep.
On 02/22/11 16:47, Stuart Henderson wrote:
On 2011/02/22 01:08, patrick keshishian wrote:
find . -name '*.c' -exec awk '/bla/ {print FILENAME $0}'
my that's awkward.
^^^
*groan*
d'oh. I missed that. And I thought I was good at the bad pun.
Nick.
Re: [patch] -H flag for grep.
On Tue, Feb 22, 2011 at 08:41:07PM -0500, Nick Holland wrote:
On 02/22/11 16:47, Stuart Henderson wrote:
On 2011/02/22 01:08, patrick keshishian wrote:
find . -name '*.c' -exec awk '/bla/ {print FILENAME $0}'
my that's awkward.
^^^
*groan*
d'oh. I missed that. And I thought I was good at the bad pun.
Nick.
http://www.thebestpageintheuniverse.net/c.cgi?u=puns
[patch] -H flag for grep.
Implement a -H flag for grep, useful for combining e.g. find and grep.
Can anyone commit it?
Index: grep.1
===
RCS file: /cvs/src/usr.bin/grep/grep.1,v
retrieving revision 1.39
diff -u -r1.39 grep.1
--- grep.1 3 Sep 2010 11:09:28 - 1.39
+++ grep.1 21 Feb 2011 12:29:41 -
@@ -38,7 +38,7 @@
.Sh SYNOPSIS
.Nm grep
.Bk -words
-.Op Fl abcEFGhIiLlnqRsUVvwxZ
+.Op Fl abcEFGHhIiLlnqRsUVvwxZ
.Op Fl A Ar num
.Op Fl B Ar num
.Op Fl C Ns Op Ar num
@@ -184,6 +184,10 @@
.Nm grep
to behave as traditional
.Nm grep ) .
+.It Fl H
+Always print filename headers
+.Pq i.e. filenames
+with output lines.
.It Fl h
Never print filename headers
.Pq i.e. filenames
@@ -349,7 +353,7 @@
specification.
.Pp
The flags
-.Op Fl AaBbCGhILRUVwZ
+.Op Fl AaBbCGHhILRUVwZ
are extensions to that specification, and the behaviour of the
.Fl f
flag when used with an empty pattern file is left undefined.
Index: grep.c
===
RCS file: /cvs/src/usr.bin/grep/grep.c,v
retrieving revision 1.42
diff -u -r1.42 grep.c
--- grep.c 2 Jul 2010 22:18:03 - 1.42
+++ grep.c 21 Feb 2011 12:29:41 -
@@ -62,6 +62,7 @@
int Eflag; /* -E: interpret pattern as extended regexp */
int Fflag; /* -F: interpret pattern as list of fixed strings */
int Gflag; /* -G: interpret pattern as basic regexp */
+int Hflag; /* -H: always print filename header */
int Lflag; /* -L: only show names of files with no matches */
int Rflag; /* -R: recursively search directory trees */
#ifndef NOZ
@@ -106,9 +107,9 @@
{
fprintf(stderr,
#ifdef NOZ
- usage: %s [-abcEFGhIiLlnqRsUVvwx] [-A num] [-B num] [-C[num]]\n
+ usage: %s [-abcEFGHhIiLlnqRsUVvwx] [-A num] [-B num] [-C[num]]\n
#else
- usage: %s [-abcEFGhIiLlnqRsUVvwxZ] [-A num] [-B num] [-C[num]]\n
+ usage: %s [-abcEFGHhIiLlnqRsUVvwxZ] [-A num] [-B num] [-C[num]]\n
#endif
\t[-e pattern] [-f file] [--binary-files=value]
[--context[=num]]\n
\t[--line-buffered] [pattern] [file ...]\n, __progname);
@@ -116,9 +117,9 @@
}
#ifdef NOZ
-static char *optstr = 0123456789A:B:CEFGILRUVabce:f:hilnqrsuvwxy;
+static char *optstr = 0123456789A:B:CEFGHILRUVabce:f:hilnqrsuvwxy;
#else
-static char *optstr = 0123456789A:B:CEFGILRUVZabce:f:hilnqrsuvwxy;
+static char *optstr = 0123456789A:B:CEFGHILRUVZabce:f:hilnqrsuvwxy;
#endif
struct option long_options[] =
@@ -134,6 +135,7 @@
{extended-regexp, no_argument,NULL, 'E'},
{fixed-strings, no_argument,NULL, 'F'},
{basic-regexp,no_argument,NULL, 'G'},
+ {with-filename, no_argument,NULL, 'H'},
{binary, no_argument,NULL, 'U'},
{version, no_argument,NULL, 'V'},
{text,no_argument,NULL, 'a'},
@@ -315,6 +317,9 @@
Eflag = Fflag = 0;
Gflag++;
break;
+ case 'H':
+ Hflag++;
+ break;
case 'I':
binbehave = BIN_FILE_SKIP;
break;
@@ -476,7 +481,7 @@
if (lbflag)
setlinebuf(stdout);
- if ((argc == 0 || argc == 1) !Rflag)
+ if ((argc == 0 || argc == 1) !Rflag !Hflag)
hflag = 1;
if (argc == 0)
Index: grep.h
===
RCS file: /cvs/src/usr.bin/grep/grep.h,v
retrieving revision 1.15
diff -u -r1.15 grep.h
--- grep.h 5 Apr 2010 03:03:55 - 1.15
+++ grep.h 21 Feb 2011 12:29:41 -
@@ -63,7 +63,7 @@
extern int cflags, eflags;
/* Command line flags */
-extern int Aflag, Bflag, Eflag, Fflag, Gflag, Lflag,
+extern int Aflag, Bflag, Eflag, Fflag, Gflag, Hflag, Lflag,
Rflag, Zflag,
bflag, cflag, hflag, iflag, lflag, nflag, qflag, sflag,
vflag, wflag, xflag;
Re: [patch] -H flag for grep.
On Mon, Feb 21, 2011 at 01:38:41PM +0100, Bret Lambert wrote: find / -name my\*balls | xargs grep -e batman -e robocop Lol. I donbt have CVS access. ;)
Re: [patch] -H flag for grep.
find / -name my\*balls | xargs grep -e batman -e robocop
On Mon, Feb 21, 2011 at 1:34 PM, Pascal Stumpf pascal.stu...@cubes.de
wrote:
Implement a -H flag for grep, useful for combining e.g. find and grep.
Can anyone commit it?
Index: grep.1
===
RCS file: /cvs/src/usr.bin/grep/grep.1,v
retrieving revision 1.39
diff -u -r1.39 grep.1
--- grep.1 3 Sep 2010 11:09:28 - 1.39
+++ grep.1 21 Feb 2011 12:29:41 -
@@ -38,7 +38,7 @@
.Sh SYNOPSIS
.Nm grep
.Bk -words
-.Op Fl abcEFGhIiLlnqRsUVvwxZ
+.Op Fl abcEFGHhIiLlnqRsUVvwxZ
.Op Fl A Ar num
.Op Fl B Ar num
.Op Fl C Ns Op Ar num
@@ -184,6 +184,10 @@
.Nm grep
to behave as traditional
.Nm grep ) .
+.It Fl H
+Always print filename headers
+.Pq i.e. filenames
+with output lines.
.It Fl h
Never print filename headers
.Pq i.e. filenames
@@ -349,7 +353,7 @@
specification.
.Pp
The flags
-.Op Fl AaBbCGhILRUVwZ
+.Op Fl AaBbCGHhILRUVwZ
are extensions to that specification, and the behaviour of the
.Fl f
flag when used with an empty pattern file is left undefined.
Index: grep.c
===
RCS file: /cvs/src/usr.bin/grep/grep.c,v
retrieving revision 1.42
diff -u -r1.42 grep.c
--- grep.c 2 Jul 2010 22:18:03 - 1.42
+++ grep.c 21 Feb 2011 12:29:41 -
@@ -62,6 +62,7 @@
int Eflag; /* -E: interpret pattern as extended regexp */
int Fflag; /* -F: interpret pattern as list of fixed strings
*/
int Gflag; /* -G: interpret pattern as basic regexp */
+int Hflag; /* -H: always print filename header */
int Lflag; /* -L: only show names of files with no matches */
int Rflag; /* -R: recursively search directory trees */
#ifndef NOZ
@@ -106,9 +107,9 @@
{
fprintf(stderr,
#ifdef NOZ
- usage: %s [-abcEFGhIiLlnqRsUVvwx] [-A num] [-B num]
[-C[num]]\n
+ usage: %s [-abcEFGHhIiLlnqRsUVvwx] [-A num] [-B num]
[-C[num]]\n
#else
- usage: %s [-abcEFGhIiLlnqRsUVvwxZ] [-A num] [-B num]
[-C[num]]\n
+ usage: %s [-abcEFGHhIiLlnqRsUVvwxZ] [-A num] [-B num]
[-C[num]]\n
#endif
\t[-e pattern] [-f file] [--binary-files=value]
[--context[=num]]\n
\t[--line-buffered] [pattern] [file ...]\n, __progname);
@@ -116,9 +117,9 @@
}
#ifdef NOZ
-static char *optstr = 0123456789A:B:CEFGILRUVabce:f:hilnqrsuvwxy;
+static char *optstr = 0123456789A:B:CEFGHILRUVabce:f:hilnqrsuvwxy;
#else
-static char *optstr = 0123456789A:B:CEFGILRUVZabce:f:hilnqrsuvwxy;
+static char *optstr = 0123456789A:B:CEFGHILRUVZabce:f:hilnqrsuvwxy;
#endif
struct option long_options[] =
@@ -134,6 +135,7 @@
{extended-regexp, no_argument,NULL, 'E'},
{fixed-strings, no_argument,NULL, 'F'},
{basic-regexp,no_argument,NULL, 'G'},
+ {with-filename, no_argument,NULL, 'H'},
{binary, no_argument,NULL, 'U'},
{version, no_argument,NULL, 'V'},
{text,no_argument,NULL, 'a'},
@@ -315,6 +317,9 @@
Eflag = Fflag = 0;
Gflag++;
break;
+ case 'H':
+ Hflag++;
+ break;
case 'I':
binbehave = BIN_FILE_SKIP;
break;
@@ -476,7 +481,7 @@
if (lbflag)
setlinebuf(stdout);
- if ((argc == 0 || argc == 1) !Rflag)
+ if ((argc == 0 || argc == 1) !Rflag !Hflag)
hflag = 1;
if (argc == 0)
Index: grep.h
===
RCS file: /cvs/src/usr.bin/grep/grep.h,v
retrieving revision 1.15
diff -u -r1.15 grep.h
--- grep.h 5 Apr 2010 03:03:55 - 1.15
+++ grep.h 21 Feb 2011 12:29:41 -
@@ -63,7 +63,7 @@
extern int cflags, eflags;
/* Command line flags */
-extern int Aflag, Bflag, Eflag, Fflag, Gflag, Lflag,
+extern int Aflag, Bflag, Eflag, Fflag, Gflag, Hflag, Lflag,
Rflag, Zflag,
bflag, cflag, hflag, iflag, lflag, nflag, qflag, sflag,
vflag, wflag, xflag;
Re: [patch] -H flag for grep.
On Mon, Feb 21, 2011 at 01:34:51PM +0100, Pascal Stumpf wrote:
Implement a -H flag for grep, useful for combining e.g. find and grep.
-o used to do this but has been removed. (See the commit logs for the reason, i
forgot it)
grep(1) only prints the filename when it receives more then 1 filename as
arguments. Thus, when you do this:
$ find . -name '*.c' -exec grep bla {} \;
It doesn't print the filename.
But when you use xargs(1), like Bret suggests it does.
Re: [patch] -H flag for grep.
On Mon, Feb 21, 2011 at 04:54:40PM +0100, Alexander Schrijver wrote:
| On Mon, Feb 21, 2011 at 01:34:51PM +0100, Pascal Stumpf wrote:
| Implement a -H flag for grep, useful for combining e.g. find and grep.
|
| -o used to do this but has been removed. (See the commit logs for the reason,
i
| forgot it)
|
| grep(1) only prints the filename when it receives more then 1 filename as
| arguments. Thus, when you do this:
|
| $ find . -name '*.c' -exec grep bla {} \;
|
| It doesn't print the filename.
|
| But when you use xargs(1), like Bret suggests it does.
It does not when there's only one file matching the find-experssion
(which is unclear when using find | xargs grep).
[weerd@despair] $ find . -name pi.c
./pi.c
[weerd@despair] $ find . -name pi.c | xargs grep main
main(int argc, char *argv[]) {
Paul 'WEiRD' de Weerd
--
[++-]+++.+++[---].+++[+
+++-].++[-]+.--.[-]
http://www.weirdnet.nl/
Re: [patch] -H flag for grep.
On Mon, Feb 21, 2011 at 04:54:40PM +0100, Alexander Schrijver wrote:
On Mon, Feb 21, 2011 at 01:34:51PM +0100, Pascal Stumpf wrote:
Implement a -H flag for grep, useful for combining e.g. find and grep.
-o used to do this but has been removed. (See the commit logs for the reason,
i
forgot it)
Because it's neither POSIX nor GNU behaviour. -H is the same flag GNU
grep uses.
grep(1) only prints the filename when it receives more then 1 filename as
arguments. Thus, when you do this:
$ find . -name '*.c' -exec grep bla {} \;
It doesn't print the filename.
But when you use xargs(1), like Bret suggests it does.
I know, but given this is such an easy change, I don't really see a
reason why one shouldn't be able to use grep in an -exec statement.
Plus, it provides compatibility with scripts that use it (although one
shouldn't).
Re: [patch] -H flag for grep.
On Mon, Feb 21, 2011 at 04:54:40PM +0100, Alexander Schrijver wrote:
On Mon, Feb 21, 2011 at 01:34:51PM +0100, Pascal Stumpf wrote:
grep(1) only prints the filename when it receives more then 1 filename as
arguments. Thus, when you do this:
$ find . -name '*.c' -exec grep bla {} \;
It doesn't print the filename.
grep will always print the filename if you specify the -R flag. It's
more of a side effect, though. Also, you'd probably want to specify
'-type f' to avoid recursing through a directory.
$ find . -type f -name '*.c' -exec grep -R blah {} \;
Re: [patch] -H flag for grep.
Date: Mon, 21 Feb 2011 14:29:37 -0500 From: Ted Unangst ted.unan...@gmail.com On Mon, Feb 21, 2011 at 7:34 AM, Pascal Stumpf pascal.stu...@cubes.de wrote: Implement a -H flag for grep, useful for combining e.g. find and grep. Can anyone commit it? I think I can do so tonight, unless someone has a serious problem with it. Yes, I have an issue with this. The tree is in soft-lock. Changing the command line options of a common tool like grep(1) may affect ports. That is not acceptable at this point. Also, -H is non-standard AFIK, and we try to avoid adding non-standard options to our tools. Theo has objected to changes like this before. So I don't think this should go in without giving him a chance to comment.
Re: [patch] -H flag for grep.
On Mon, Feb 21, 2011 at 04:20:24PM -0500, Ted Unangst wrote: On Mon, Feb 21, 2011 at 3:46 PM, Mark Kettenis mark.kette...@xs4all.nl wrote: Also, -H is non-standard AFIK, and we try to avoid adding non-standard options to our tools. Theo has objected to changes like this before. So I don't think this should go in without giving him a chance to comment. Yes, but let's be honest. In the case of grep, there is only one standard that counts, what GNU grep does. Well, I kind of disagree. First priority should be to obey POSIX (which GNU grep violates e.g. by making EREs the default even when given the -G flag). But concerning everything that goes beyond POSIX, GNU is a defacto standard. In this case, there are already a lot of flags not required by POSIX, so 'we don't like non-standard options' can hardly be a valid objection. The only problem I could come up with is that it changes the previous meaning of the -H flag on OpenBSD (which was removed exactly because it was an OpenBSD-only flag). Concerning ports, I don't see how this could cause problems. Rather, any script that might use the -H flag should be fixed by this change as they will rely on GNU behaviour. However, I don't think there are any. But let Theo decide ... :)
Re: [patch] -H flag for grep.
On 02/21/11 15:54, Alexander Schrijver wrote:
On Mon, Feb 21, 2011 at 01:34:51PM +0100, Pascal Stumpf wrote:
Implement a -H flag for grep, useful for combining e.g. find and grep.
-o used to do this but has been removed. (See the commit logs for the reason, i
forgot it)
grep(1) only prints the filename when it receives more then 1 filename as
arguments. Thus, when you do this:
$ find . -name '*.c' -exec grep bla {} \;
It doesn't print the filename.
But when you use xargs(1), like Bret suggests it does.
$ find . -name *.php -exec grep blah {} \; -print
Will print the file name after the line that grep matches.
hth
Fred
Re: [patch] -H flag for grep.
On Mon, Feb 21, 2011 at 3:46 PM, Mark Kettenis mark.kette...@xs4all.nl wrote: Also, -H is non-standard AFIK, and we try to avoid adding non-standard options to our tools. Theo has objected to changes like this before. So I don't think this should go in without giving him a chance to comment. Yes, but let's be honest. In the case of grep, there is only one standard that counts, what GNU grep does.
Re: [patch] -H flag for grep.
On Mon, Feb 21, 2011 at 2:30 PM, Fred Crowson open...@crowsons.net wrote:
On 02/21/11 15:54, Alexander Schrijver wrote:
...
grep(1) only prints the filename when it receives more then 1 filename as
arguments. Thus, when you do this:
$ find . -name '*.c' -exec grep bla {} \;
It doesn't print the filename.
But when you use xargs(1), like Bret suggests it does.
$ find . -name *.php -exec grep blah {} \; -print
Will print the file name after the line that grep matches.
The other classical solution is to always pass multiple filenames by
including a /dev/null argument:
find . -name '*.c' -exec grep bla {} /dev/null \;
That works with the xargs case too:
find . -name '*.c' -print0 | xargs -0 grep bla /dev/null
Philip Guenther
Re: [patch] -H flag for grep.
On Mon, Feb 21, 2011 at 7:01 PM, Philip Guenther guent...@gmail.com wrote:
On Mon, Feb 21, 2011 at 2:30 PM, Fred Crowson open...@crowsons.net wrote:
On 02/21/11 15:54, Alexander Schrijver wrote:
...
grep(1) only prints the filename when it receives more then 1 filename as
arguments. Thus, when you do this:
$ find . -name '*.c' -exec grep bla {} \;
It doesn't print the filename.
But when you use xargs(1), like Bret suggests it does.
$ find . -name *.php -exec grep blah {} \; -print
Will print the file name after the line that grep matches.
The other classical solution is to always pass multiple filenames by
including a /dev/null argument:
B find . -name '*.c' -exec grep bla {} /dev/null \;
That works with the xargs case too:
B find . -name '*.c' -print0 | xargs -0 grep bla /dev/null
these two ugly hacks and the the redundant flag have been sought while
what's natural has been overlooked
find . -name '*.c' -exec awk '/bla/ {print FILENAME $0}'
why complicate grep?
Philip Guenther
