[9front] grep: always show path with '-n'

[9front] grep: always show path with '-n'

[ori]

With the new 'g', I noticed that sometimes
we'd fail to show the filename; this happens
because 'g' now uses xargs, and if there's
exactly one file picked up by xargs, the
Hflag does not get set.

This change makes grep now print the filename
if Hflag *or* Nflag is set, which is what I'd
expect.

Before:

	% grep -n -- Nflag main.c
	106: 		flag |= Nflag;		/* count only */

After:

	% grep -n -- Nflag main.c
	main.c:106: 		flag |= Nflag;		/* count only */

And it still does something sensible for stdin:

	% grep -n asdf
	asdf
	stdin:1: asdf

Does this make sense to people?


diff 251c3cfd610abd169676852d301a2aa1267c0e57 uncommitted
--- a/sys/src/cmd/grep/main.c
+++ b/sys/src/cmd/grep/main.c
@@ -180,7 +180,7 @@
 			count++;
 			if(flag & (Cflag|Sflag|Llflag|LLflag))
 				goto cont;
-			if(flag & Hflag)
+			if(flag & (Hflag|Nflag))
 				Bprint(&bout, "%s:", file);
 			if(flag & Nflag)
 				Bprint(&bout, "%ld: ", lineno);
@@ -219,7 +219,7 @@
 			count++;
 			if(flag & (Cflag|Sflag|Llflag|LLflag))
 				goto conti;
-			if(flag & Hflag)
+			if(flag & (Hflag|Nflag))
 				Bprint(&bout, "%s:", file);
 			if(flag & Nflag)
 				Bprint(&bout, "%ld: ", lineno);

Re: [9front] grep: always show path with '-n'

[unobe]

Makes sense to me.

Quoth ori@eigenstate.org:
> With the new 'g', I noticed that sometimes
> we'd fail to show the filename; this happens
> because 'g' now uses xargs, and if there's
> exactly one file picked up by xargs, the
> Hflag does not get set.
> 
> This change makes grep now print the filename
> if Hflag *or* Nflag is set, which is what I'd
> expect.
> 
> Before:
> 
> 	% grep -n -- Nflag main.c
> 	106: 		flag |= Nflag;		/* count only */
> 
> After:
> 
> 	% grep -n -- Nflag main.c
> 	main.c:106: 		flag |= Nflag;		/* count only */
> 
> And it still does something sensible for stdin:
> 
> 	% grep -n asdf
> 	asdf
> 	stdin:1: asdf
> 
> Does this make sense to people?
> 
> 
> diff 251c3cfd610abd169676852d301a2aa1267c0e57 uncommitted
> --- a/sys/src/cmd/grep/main.c
> +++ b/sys/src/cmd/grep/main.c
> @@ -180,7 +180,7 @@
>  			count++;
>  			if(flag & (Cflag|Sflag|Llflag|LLflag))
>  				goto cont;
> -			if(flag & Hflag)
> +			if(flag & (Hflag|Nflag))
>  				Bprint(&bout, "%s:", file);
>  			if(flag & Nflag)
>  				Bprint(&bout, "%ld: ", lineno);
> @@ -219,7 +219,7 @@
>  			count++;
>  			if(flag & (Cflag|Sflag|Llflag|LLflag))
>  				goto conti;
> -			if(flag & Hflag)
> +			if(flag & (Hflag|Nflag))
>  				Bprint(&bout, "%s:", file);
>  			if(flag & Nflag)
>  				Bprint(&bout, "%ld: ", lineno);
> 

Re: [9front] grep: always show path with '-n'

[Steve Simon]

the “traditional” way to achieve this is for g(1) to always pass /dev/null to grep to ensure there are always multiple files.

-Steve


On 3 Feb 2022, at 5:34 am, ori@eigenstate.org wrote:

With the new 'g', I noticed that sometimes
we'd fail to show the filename; this happens
because 'g' now uses xargs, and if there's
exactly one file picked up by xargs, the
Hflag does not get set.

This change makes grep now print the filename
if Hflag *or* Nflag is set, which is what I'd
expect.

Before:

   % grep -n -- Nflag main.c
   106:        flag |= Nflag;        /* count only */

After:

   % grep -n -- Nflag main.c
   main.c:106:        flag |= Nflag;        /* count only */

And it still does something sensible for stdin:

   % grep -n asdf
   asdf
   stdin:1: asdf

Does this make sense to people?


diff 251c3cfd610abd169676852d301a2aa1267c0e57 uncommitted
--- a/sys/src/cmd/grep/main.c
+++ b/sys/src/cmd/grep/main.c
@@ -180,7 +180,7 @@
           count++;
           if(flag & (Cflag|Sflag|Llflag|LLflag))
               goto cont;
-            if(flag & Hflag)
+            if(flag & (Hflag|Nflag))
               Bprint(&bout, "%s:", file);
           if(flag & Nflag)
               Bprint(&bout, "%ld: ", lineno);
@@ -219,7 +219,7 @@
           count++;
           if(flag & (Cflag|Sflag|Llflag|LLflag))
               goto conti;
-            if(flag & Hflag)
+            if(flag & (Hflag|Nflag))
               Bprint(&bout, "%s:", file);
           if(flag & Nflag)
               Bprint(&bout, "%ld: ", lineno);

Re: [9front] grep: always show path with '-n'

[ori]

Quoth Steve Simon <steve@quintile.net>:
> the “traditional” way to achieve this is for g(1) to always pass
> /dev/null to grep to ensure there are always multiple files.
> 

That's certainly *an* option, but it
seems surprising that 1 vs n args are
treated differently for '-n', and I
think it makes sense to make it
consistent.

Re: [9front] grep: always show path with '-n'

[Nicola Girardi]

Quoth ori@eigenstate.org:
> Quoth Steve Simon <steve@quintile.net>:
> > the “traditional” way to achieve this is for g(1) to always pass
> > /dev/null to grep to ensure there are always multiple files.
> > 
> 
> That's certainly *an* option, but it
> seems surprising that 1 vs n args are
> treated differently for '-n', and I
> think it makes sense to make it
> consistent.

I've always wondered about that behavior for '-n'.  Does anyone know
the historical reason for omitting the file name when there's only one
file to search?

Re: [9front] grep: always show path with '-n'

[ori]

Quoth Nicola Girardi <ng@0x80.stream>:
> Quoth ori@eigenstate.org:
> > Quoth Steve Simon <steve@quintile.net>:
> > > the “traditional” way to achieve this is for g(1) to always pass
> > > /dev/null to grep to ensure there are always multiple files.
> > > 
> > 
> > That's certainly *an* option, but it
> > seems surprising that 1 vs n args are
> > treated differently for '-n', and I
> > think it makes sense to make it
> > consistent.
> 
> I've always wondered about that behavior for '-n'.  Does anyone know
> the historical reason for omitting the file name when there's only one
> file to search?
> 

It removes a processing step to remove a prefix,
I guess.

Re: [9front] grep: always show path with '-n'

[ori]

Quoth Nicola Girardi <ng@0x80.stream>:
> Quoth ori@eigenstate.org:
> > Quoth Steve Simon <steve@quintile.net>:
> > > the “traditional” way to achieve this is for g(1) to always pass
> > > /dev/null to grep to ensure there are always multiple files.
> > > 
> > 
> > That's certainly *an* option, but it
> > seems surprising that 1 vs n args are
> > treated differently for '-n', and I
> > think it makes sense to make it
> > consistent.
> 
> I've always wondered about that behavior for '-n'.  Does anyone know
> the historical reason for omitting the file name when there's only one
> file to search?
> 

It removes a processing step to remove a prefix,
I guess.

This doesn't change that behavior -- it just makes
'-n' always prefix 'file:line' instead of just 'line'.

Re: [9front] grep: always show path with '-n'

[Alex Musolino]

> I've always wondered about that behavior for '-n'.  Does anyone know
> the historical reason for omitting the file name when there's only one
> file to search?

Perhaps the original grep only searched one file.

Re: [9front] grep: always show path with '-n'

[Nicola Girardi]

Quoth ori@eigenstate.org:
> Quoth Nicola Girardi <ng@0x80.stream>:
> > Quoth ori@eigenstate.org:
> > > Quoth Steve Simon <steve@quintile.net>:
> > > > the “traditional” way to achieve this is for g(1) to always pass
> > > > /dev/null to grep to ensure there are always multiple files.
> > > > 
> > > 
> > > That's certainly *an* option, but it
> > > seems surprising that 1 vs n args are
> > > treated differently for '-n', and I
> > > think it makes sense to make it
> > > consistent.
> > 
> > I've always wondered about that behavior for '-n'.  Does anyone know
> > the historical reason for omitting the file name when there's only one
> > file to search?
> > 
> 
> It removes a processing step to remove a prefix,
> I guess.
> 
> This doesn't change that behavior -- it just makes
> '-n' always prefix 'file:line' instead of just 'line'.

Sure, by the way, I don't oppose the change, it makes sense to me.
I was just curious because it seems like it should've been done long ago.
Perhaps people have so far worried about breaking scripts.

Re: [9front] grep: always show path with '-n'

[有澤 健治]

Hello,

On 2022/02/03 8:01, ori@eigenstate.org wrote:
> And it still does something sensible for stdin:
>
> 	% grep -n asdf
> 	asdf
> 	stdin:1: asdf
>
> Does this make sense to people?
Isn't it logically better:

% grep -n asdf
asdf
:1: asdf

Re: [9front] grep: always show path with '-n'

[hiro]

it should be a no-brainer.

i have my own g, obviously it doesn't suffer from the shortcoming
discussed here. i'm shocked it took people so long to notice.

also remember that 'g' originally was meant more as an example of
personalization.
everybody could have their own 'g', it wasn't really meant as a system utility.

system utilities otoh aren't short single-letter scripts, leaving
those names free for dumping conveniently into them your most common
repetitive tasks...

Re: [9front] grep: always show path with '-n'

[Stanley Lieber]

On February 5, 2022 4:57:09 PM UTC, hiro <23hiro@gmail.com> wrote:
>it should be a no-brainer.
>
>i have my own g, obviously it doesn't suffer from the shortcoming
>discussed here. i'm shocked it took people so long to notice.
>
>also remember that 'g' originally was meant more as an example of
>personalization.
>everybody could have their own 'g', it wasn't really meant as a system utility.
>
>system utilities otoh aren't short single-letter scripts, leaving
>those names free for dumping conveniently into them your most common
>repetitive tasks...
>

i imported g from p9p. i believe it was one of rsc's scripts. we've updated it several times. i don't think i've used it since it was imported, though...

sl

Re: [9front] grep: always show path with '-n'

[hiro]

i never ever even ran it but i liked the idea. iirc he must have
presented this lesson on 9fans at some point

On 2/5/22, Stanley Lieber <sl@stanleylieber.com> wrote:
> On February 5, 2022 4:57:09 PM UTC, hiro <23hiro@gmail.com> wrote:
>>it should be a no-brainer.
>>
>>i have my own g, obviously it doesn't suffer from the shortcoming
>>discussed here. i'm shocked it took people so long to notice.
>>
>>also remember that 'g' originally was meant more as an example of
>>personalization.
>>everybody could have their own 'g', it wasn't really meant as a system
>> utility.
>>
>>system utilities otoh aren't short single-letter scripts, leaving
>>those names free for dumping conveniently into them your most common
>>repetitive tasks...
>>
>
> i imported g from p9p. i believe it was one of rsc's scripts. we've updated
> it several times. i don't think i've used it since it was imported,
> though...
>
> sl
>