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);
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);
>
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);
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.
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?
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.
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'.
> 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.
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.
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
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...
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
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
>