[9fans] find command reloaded

[9fans] find command reloaded

[Rudolf Sykora]

[-- Attachment #1: Type: text/plain, Size: 520 bytes --]

Hello,

I've been wondering.
The plan9 'replacement' for the (linux/unix-like) find command, according to
the faq, is, in a way,

grep foo `{du -a . | awk '{print $2}'}

Now I want to find all files containing foo.
Is it so that `{ ... } produces the full list first and only afterwards this
is used?
If so (and as I understand it really is so), the number of arguments may be
enormous, e.g. millions of names...
I don't feel this is the way to go...

How do you carry out such a search?

Thanks
Ruda

[-- Attachment #2: Type: text/html, Size: 731 bytes --]

Re: [9fans] find command reloaded

[ron minnich]

I just do
du -a . | grep foo

I don't much care about the noise, but if you do
du -a . | grep foo | awk '{print $2}'

Not sure why you're putting all those names into an arg list.

ron

Re: [9fans] find command reloaded

[Rudolf Sykora]

[-- Attachment #1: Type: text/plain, Size: 234 bytes --]

2010/1/22 ron minnich <rminnich@gmail.com>

> I just do
> du -a . | grep foo
>

Isn't it that this finds files whose filenames contain foo (like
foofoo2.txt)?!
I want files inside which there is foo somewhere...

Thanks
R

[-- Attachment #2: Type: text/html, Size: 489 bytes --]

Re: [9fans] find command reloaded

[ron minnich]

I found your post a bit confusing then. The little bit of script you
posted won't do the job, and the problem is not related to find at
all,

Anyway, while working with some hugely messy non-plan 9-software, I
found I really needed grep -r.

See /n/sources/contrib/rminnich/grep

ron

Re: [9fans] find command reloaded

[erik quanstrom]

> I found your post a bit confusing then. The little bit of script you
> posted won't do the job, and the problem is not related to find at
> all,
>
> Anyway, while working with some hugely messy non-plan 9-software, I
> found I really needed grep -r.
>
> See /n/sources/contrib/rminnich/grep

why not just use a russ' g from p9p?

- erik

here's a variant:
#!/bin/rc

rfork e
filepat='\.h$'
exec g $*

of my version:
#!/bin/rc

rfork e
flags=-n
re=()
files=/dev/null
f=1
if(~ $#filepat 0)
	filepat = '\.[Cbchlmsy]$'

fn collect{
	find $* | grep $filepat
}

fn collect1{
	ls | grep $filepat
}

for(i){
	if(~ $f 1 && ~ $i -*)
		flags = ($flags $i)
	if not if (~ $#re 0){
		f = 0
		re = $i
	}
	if not{
		if(test -d $i)
			files = ($files `{collect $i})
		if not
			files = ($files $i)
	}
}
if(~ $#re 0){
	echo usage: g '[flags]' pattern ... >[1=2]
	exit usage
}
modre>[2=]
switch($#files){
case 1
	grep $flags $re `{collect1} $files
case *
	grep $flags $re $files
}

Re: [9fans] find command reloaded

[Rudolf Sykora]

[-- Attachment #1: Type: text/plain, Size: 725 bytes --]

> why not just use a russ' g from p9p?
>

Ok. Maybe. So now I have several propositions:

- g by R Cox
- sth similar to g by E Quanstrom
- grep -r by R Minnich (actually, this really exists in linux, I didn't
know...)
- search the archives for mails subjected as : breadth first walking, du and
find, from December 2009, by maht
- get sth like xargs somewhere, e.g. by J Catena

Can anybody comment on these and their differences?
I don't know 'g' yet. I'll look at it shortly. Anyway, it seems to me that
something like xargs could be of quite general use, so probably also be a
better solution than anything like 'grep -r' (adding switches to individual
commands to do some job recursively).

Thanks
R

[-- Attachment #2: Type: text/html, Size: 992 bytes --]

Re: [9fans] find command reloaded

[Rudolf Sykora]

[-- Attachment #1: Type: text/plain, Size: 524 bytes --]

2010/1/22 ron minnich <rminnich@gmail.com>

> I found your post a bit confusing then. The little bit of script you
> posted won't do the job, and the problem is not related to find at
> all
>

The relation to the find command: the linux/unix find command can be
producing and using the list at the same time (actually it perhaps doesn't
even create any list).

Why do you think
grep foo `{du -a . | awk '{print $2}'}
doesn't do the job? Apart from potentially reporting one file several
times...

Thanks
R

[-- Attachment #2: Type: text/html, Size: 859 bytes --]

Re: [9fans] find command reloaded

[ron minnich]

On Fri, Jan 22, 2010 at 10:40 AM, Rudolf Sykora <rudolf.sykora@gmail.com> wrote:

> Why do you think
> grep foo `{du -a . | awk '{print $2}'}
> doesn't do the job? Apart from potentially reporting one file several
> times...

Because my brain is only partially on today!

ron

Re: [9fans] find command reloaded

[maht]

search the archives for mails subjected as :

breadth first walking

and

du and find

from December 2009

On 22/01/2010 17:29, Rudolf Sykora wrote:
> Hello,
>
> I've been wondering.
> The plan9 'replacement' for the (linux/unix-like) find command,
> according to the faq, is, in a way,
>

Re: [9fans] find command reloaded

[Rudolf Sykora]

[-- Attachment #1: Type: text/plain, Size: 243 bytes --]

2010/1/22 maht <maht-9fans@maht0x0r.net>

> search the archives for mails subjected as :
>
> breadth first walking
>
> and
>
> du and find
>
> from December 2009
>
>
Ok, I will. I just thought there is a well-established way.
R

[-- Attachment #2: Type: text/html, Size: 523 bytes --]

Re: [9fans] find command reloaded

[Robert Raschke]

[-- Attachment #1: Type: text/plain, Size: 742 bytes --]

On Fri, Jan 22, 2010 at 5:29 PM, Rudolf Sykora <rudolf.sykora@gmail.com>wrote:

> Hello,
>
> I've been wondering.
> The plan9 'replacement' for the (linux/unix-like) find command, according
> to the faq, is, in a way,
>
> grep foo `{du -a . | awk '{print $2}'}
>
> Now I want to find all files containing foo.
> Is it so that `{ ... } produces the full list first and only afterwards
> this is used?
> If so (and as I understand it really is so), the number of arguments may be
> enormous, e.g. millions of names...
> I don't feel this is the way to go...
>
> How do you carry out such a search?
>
> Thanks
> Ruda
>
>

Have you come across a situation where it doesn't work or it's too slow for
your needs?

Robby

[-- Attachment #2: Type: text/html, Size: 1195 bytes --]

Re: [9fans] find command reloaded

[Rudolf Sykora]

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

2010/1/22 Robert Raschke <rtrlists@googlemail.com>

> Have you come across a situation where it doesn't work or it's too slow for
> your needs?
>
> Robby
>

Well. I honestly don't know where the limits are. So generally, how long can
the line be?
My filesystem has now about 1e6 files, i.e. is of a modest size. Thus you
need about 10 MB just for the list.

Regardless of me having or not having encountered a problem, building the
whole list in advance is not really smart and will lead to problems at some
point for sure.

Thanks
R

[-- Attachment #2: Type: text/html, Size: 882 bytes --]

Re: [9fans] find command reloaded

[Corey Thomasson]

On 1/22/2010 12:59 PM, Rudolf Sykora wrote:
> Regardless of me having or not having encountered a problem, building
> the whole list in advance is not really smart and will lead to
> problems at some point for sure.
>
> Thanks
> R
>
Assuming that's true, couldn't you do some kind of trick to break it up
(mind you my syntax may be wrong, I don't use plan9 often)

for(i in a b c [and so on]) grep foo `{du -a . | awk '{print $2}' | grep
^$i}

If you're worried about the argument list being too long that would
break it up into 26 separate greps with smaller arg lists I believe

Re: [9fans] find command reloaded

[andrey mirtchovski]

Building a large list in advance can exhaust main memory on smaller terminals.

Re: [9fans] find command reloaded

[Joseph Xu]

On Fri, Jan 22, 2010 at 01:08:02PM -0500, Corey Thomasson wrote:
> On 1/22/2010 12:59 PM, Rudolf Sykora wrote:
> >Regardless of me having or not having encountered a problem,
> >building the whole list in advance is not really smart and will
> >lead to problems at some point for sure.
> >
> >Thanks
> >R
> >
> Assuming that's true, couldn't you do some kind of trick to break it
> up (mind you my syntax may be wrong, I don't use plan9 often)
>
> for(i in a b c [and so on]) grep foo `{du -a . | awk '{print $2}' |
> grep ^$i}
>
> If you're worried about the argument list being too long that would
> break it up into 26 separate greps with smaller arg lists I believe
>

In linux there is the xargs command, which will read lines from stdin
and distribute them in chunks to the arguments of another command, as in

du -a . | awk '{print $2}' | xargs -n 10 grep foo

This will take every 10 lines of stdin and append them to "grep foo".
It's quite a useful command and seems to provide a unique function.  Is
there some equivalent of this in Plan 9?

Also, the title of this thread is a bit misleading. As far as I know,
find doesn't have the option to test for the contents of files, so even
with find you'd have to use xargs and grep.

Re: [9fans] find command reloaded

[ron minnich]

On Fri, Jan 22, 2010 at 10:19 AM, Joseph Xu <josephzxu@gmail.com> wrote:

> Also, the title of this thread is a bit misleading. As far as I know,
> find doesn't have the option to test for the contents of files, so even
> with find you'd have to use xargs and grep.

if you have find you don't need the xargs; -exec will do.

ron

Re: [9fans] find command reloaded

[Rudolf Sykora]

[-- Attachment #1: Type: text/plain, Size: 474 bytes --]

2010/1/22 Joseph Xu <josephzxu@gmail.com>
>
>  Also, the title of this thread is a bit misleading. As far as I know,
> find doesn't have the option to test for the contents of files, so even
> with find you'd have to use xargs and grep.
>

Let me explain then.
In Linux I'd use something like

find . -type f  -exec grep -l foo {} \;

So, you are right about the need to use grep. On the other hand, the linux
find command takes care of the repetition...

R

[-- Attachment #2: Type: text/html, Size: 750 bytes --]

Re: [9fans] find command reloaded

[ron minnich]

now I understand your question.

I just tested this and it worked fine.

du -a / | awk '{print "grep something " $2}' |/bin/rc

ron

Re: [9fans] find command reloaded

[geoff]

These two scripts should be enough to do what's needed:

; cat /bin/xargs
#!/bin/rc
# xargs cmd [arg ...] - emulate Unix xargs
#	only needed for arg lists longer than TSTKSIZ*BY2PG
#	(100*4096 = 400K on typical PC kernels).
rfork ne
ramfs
split -n 500 -f /tmp/x
for (f in /tmp/x*)
	$* `{cat $f}

; cat /bin/files
#!/bin/rc
# files [dir...] - enumerate files below dir(s)
du -a $* | sed 's/^[^	 ]+[	 ]+//' | sort -u

Can we stop now?

Re: [9fans] find command reloaded

[John Stalker]

> I just tested this and it worked fine.
> du -a / | awk '{print "grep something " $2}' |/bin/rc
> ron

Try

touch 'x;reboot'

and then see if it still works fine.  I don't think I like your
version on a system with users I don't trust completely.
--
John Stalker
School of Mathematics
Trinity College Dublin
tel +353 1 896 1983
fax +353 1 896 2282

Re: [9fans] find command reloaded

[erik quanstrom]

> > du -a / | awk '{print "grep something " $2}' |/bin/rc
> > ron
>
> Try
>
> touch 'x;reboot'
>
> and then see if it still works fine.  I don't think I like your
> version on a system with users I don't trust completely.

sneaky.  but it won't work.

; touch 'x;reboot'
; du -a .
0	'./x;reboot'
0	.

- erik

Re: [9fans] find command reloaded

[Jason Catena]

Recursively list only files; grep them with g to get full path,
filename, and line number; protect against John's semicolon trick by
quoting each file.

walk -f | sed 's,^,g '^$1^' '',;s,$,'',' | rc

walk apparently completely omits from its output files with a
single-quote in their names, and does not quote files with embedded
semicolons.  ls lists them both quoted, with the embedded single-quote
doubled.

All this tested in p9p.

Re: [9fans] find command reloaded

[ron minnich]

On Fri, Jan 22, 2010 at 12:16 PM, Jason Catena <jason.catena@gmail.com> wrote:
> Recursively list only files; grep them with g to get full path,
> filename, and line number; protect against John's semicolon trick by
> quoting each file.


john's semicolon trick is fun but as pointed out doesn't work.

ron

Re: [9fans] find command reloaded

[John Stalker]

> sneaky.  but it won't work.
>
> ; touch 'x;reboot'
> ; du -a .
> 0	'./x;reboot'
> 0	.
>
> - erik

It worked under 9vx on my Mac.  I didn't test on real hardware.
--
John Stalker
School of Mathematics
Trinity College Dublin
tel +353 1 896 1983
fax +353 1 896 2282

Re: [9fans] find command reloaded

[erik quanstrom]

On Fri Jan 22 15:24:49 EST 2010, stalker@maths.tcd.ie wrote:
> > sneaky.  but it won't work.
> >
> > ; touch 'x;reboot'
> > ; du -a .
> > 0	'./x;reboot'
> > 0	.
> >
> > - erik
>
> It worked under 9vx on my Mac.  I didn't test on real hardware.

this rebooted your 9vx?  sounds wrong to me.
i thought the orginal script was

du -a . | awk '{print "grep -l pattern " $2}' | rc

if i run that on my machine, i get

	; du -a . | awk '{print "grep -l something " $2}'
	grep -l something './x;reboot'
	grep -l something .

if executed, that won't reboot your machine.
it will just print "x;reboot".  if you were to reexecute
that, it would.  but you wouldn't want to execute a list
of file names, would you?

- erik

Re: [9fans] find command reloaded

[John Stalker]

> this rebooted your 9vx?  sounds wrong to me.

It did, or rather it tried to.  Of course, /bin/reboot doesn't
work in 9vx.  I tested it before I posted.
--
John Stalker
School of Mathematics
Trinity College Dublin
tel +353 1 896 1983
fax +353 1 896 2282

Re: [9fans] find command reloaded

[ron minnich]

On Fri, Jan 22, 2010 at 12:23 PM, John Stalker <stalker@maths.tcd.ie> wrote:
>> sneaky.  but it won't work.
>>
>> ; touch 'x;reboot'
>> ; du -a .
>> 0     './x;reboot'
>> 0     .
>>
>> - erik
>
> It worked under 9vx on my Mac.  I didn't test on real hardware.


interesting. OK, my idea sucks due to a lack of foresight on my part :-)

So far, given the complexity of all the alternatives, I'm sticking
with my grep -r. Yeah, it's gross to special-case something, but
sometimes a special case has more use than a general case.

But, hey, if you don't like my idea don't use it. No feelings will be
harmed; after all, I've only got one real user for smacme and it's not
me :-)

And if you like find, write and put it in contrib.

I don't understand all the concern about whether this or that tool
ends up in the "official" tree, or who is resistant to it. Plan 9 is a
distributed OS. Roll your own tree. put it on bitbucket. Add all the
stuff you think should be there. Maybe others will like it too. In the
70s just about every university had a Unix distro ... harvard, jhu, on
and on ... it was only in the 80s that BSD became the choice item.
With the tools we have today it's pretty easy to fork something. Who
knows, you might pull a BSD :-)

ron

Re: [9fans] find command reloaded

[Steve Simon]

the only time I ever wanted this kind of feature
is for grepping through sourcecode.

ron's modified grep is now installed on my boxes;
there is a precident (diff -r).

-Steve

Re: [9fans] find command reloaded

[Tim Newsham]

> the only time I ever wanted this kind of feature
> is for grepping through sourcecode.
>
> ron's modified grep is now installed on my boxes;
> there is a precident (diff -r).

If you're like me, you often have a bunch of object files
in your source tree and you usually want to enumerate
files, filter out some of the names and then grep the resulting
list... ie. recursive grep will grep a bunch of files you
dont want to grep...  something like:

     grep -n foo `{f|grep '\.c'}

will go much faster (assuming /bin/f enumerates filenames).

> -Steve

Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com

Re: [9fans] find command reloaded

[John Stalker]

> interesting. OK, my idea sucks due to a lack of foresight on my part :-)

Your idea is fine.  I do similar things all the time, but using
awk or sed or things like that to produce shell scripts is hard
to get right.  Harder than getting a find command right, which
was my point.  I'll grant that life is easier if the shell you're
piping to is /bin/rc than /bin/sh.

> So far, given the complexity of all the alternatives, I'm sticking
> with my grep -r. Yeah, it's gross to special-case something, but
> sometimes a special case has more use than a general case.

That's fine for Rudolf's situation, but most of my find commands
end in -delete.

> But, hey, if you don't like my idea don't use it. No feelings will be
> harmed; after all, I've only got one real user for smacme and it's not
> me :-)

I actually like your idea better than any of the others that were
suggested except for the idea of a native version of find.

> And if you like find, write and put it in contrib.

I'll put it on my to do list.  But things often stay on that list
for a long time. :-(

> I don't understand all the concern about whether this or that tool
> ends up in the "official" tree, or who is resistant to it. Plan 9 is a
> distributed OS. Roll your own tree. put it on bitbucket. Add all the
> stuff you think should be there. Maybe others will like it too. In the
> 70s just about every university had a Unix distro ... harvard, jhu, on
> and on ... it was only in the 80s that BSD became the choice item.
> With the tools we have today it's pretty easy to fork something. Who
> knows, you might pull a BSD :-)

We had one here at TCD, though that was well before my time.  These
days all the servers run FreeBSD.  Although I like plan9, I don't
think it's likely to get installed on those servers any time soon.

> ron
--
John Stalker
School of Mathematics
Trinity College Dublin
tel +353 1 896 1983
fax +353 1 896 2282

Re: [9fans] find command reloaded

[erik quanstrom]

> And if you like find, write and put it in contrib.

contrib/pull quanstro/find

- erik

Re: [9fans] find command reloaded

[John Stalker]

> > And if you like find, write and put it in contrib.
>
> contrib/pull quanstro/find
>
> - erik

Thanks
--
John Stalker
School of Mathematics
Trinity College Dublin
tel +353 1 896 1983
fax +353 1 896 2282

Re: [9fans] find command reloaded

[lucio]

>> > And if you like find, write and put it in contrib.
>>
>> contrib/pull quanstro/find
>>
>> - erik
>
> Thanks
> --
> John Stalker

Does this answer Ron's question as to why one wants things added to
the distribution, not just tacked onto any old branched version?

++L

Re: [9fans] find command reloaded

[John Stalker]

> Does this answer Ron's question as to why one wants things added to
> the distribution, not just tacked onto any old branched version?
> ++L

No.  It doesn't.  Here's an attempt to answer that question:

As I see it, there are three types of program:
1) Stuff only one person is ever likely to want.  No worth
contributing.
2) Stuff of interest only to a small group of people.  This belongs
in contrib.
3) Stuff of more general utility.  This should probably go in the
main tree unless there is a good reason not to put it there.

It was Rudolf who asked for a find command, and I've said I would
like one, so we can exclude (1) in this case.  (2) or (3) is
obviously a judgment call.  I remember the issue of find coming
up before, though, so I am guessing that it's more than just two
people who will use it.  It's worth noting that find is part of
posix, so it's often used in scripts that are meant to be portable
across unix variants.  Plan9 was never meant to be a unix variant,
but having a find makes porting scripts a bit easier.  I don't
see the downside.  It's not like find is evolving and will need
to be maintained by someone at the labs.

In the end, of course, it's not my call what goes in the base
system.  I can just express an opinion.
--
John Stalker
School of Mathematics
Trinity College Dublin
tel +353 1 896 1983
fax +353 1 896 2282

Re: [9fans] find command reloaded

[Rudolf Sykora]

On 23 January 2010 11:16, John Stalker <stalker@maths.tcd.ie> wrote:
> As I see it, there are three types of program:
> 1) Stuff only one person is ever likely to want.  No worth
> contributing.
> 2) Stuff of interest only to a small group of people.  This belongs
> in contrib.
> 3) Stuff of more general utility.  This should probably go in the
> main tree unless there is a good reason not to put it there.

I believe that some version of 'find' and 'xargs' would easily find
its users and not just few.
Another problem with stuff in contrib is, that their software is not
well documented (i.e. no man pages), so that one probably has to read
the source in order to be able to use it. This often forms an obstacle
for usage... Being accepted to the main tree brings along good
documentation, too, which is of importance to me.

R

Re: [9fans] find command reloaded

[Steve Simon]

> Another problem with stuff in contrib is, that their software is not
> well documented (i.e. no man pages), so that one probably has to read
> the source in order to be able to use it.

s/with stuff/with some stuff/

> Btw., I know the " and "" scripts by R Cox, I use them. Without
> something like them, it would be hell.

I have never felt the need for tools like these, I use the mouse to edit
the text on the screen (changing history), I then double click to the right
of the line and click send which resubmits the text.

The idea that any text on the screen may be used to form a new command is
very powerful, but takes some getting used to.

Perhaps you need to give it a bit more time.

-Steve

Re: [9fans] find command reloaded

[Rudolf Sykora]

On 23 January 2010 16:24, Steve Simon <steve@quintile.net> wrote:
>> Another problem with stuff in contrib is, that their software is not
>> well documented (i.e. no man pages), so that one probably has to read
>> the source in order to be able to use it.
>
> s/with stuff/with some stuff/

Ok, so far I haven't seen an exception, but sure there must be. :)

>> Btw., I know the " and "" scripts by R Cox, I use them. Without
>> something like them, it would be hell.
>
> I have never felt the need for tools like these, I use the mouse to edit
> the text on the screen (changing history), I then double click to the right
> of the line and click send which resubmits the text.
>
> The idea that any text on the screen may be used to form a new command is
> very powerful, but takes some getting used to.
>
> Perhaps you need to give it a bit more time.
>
> -Steve

Well, probably this is more about what kind of work you do.

If the commands have a rich output to the screen, you, fist, have to
visually find the command you want to reuse. This may be well off the
screen now, even thought it may be just say a last-but-one command
issued. Not speaking of commands issued somewhat earlier. Finding
these sometimes is cumbersome. This was probably the reason why " and
"" exist (and why the videos someone here recently pointed to suggest
using these scripts in situations like I describe).

I also often do reediting as you describe. It is powerful, no
question. But sometimes, since such editing also disturbs 'the
history', I find copying the command to the input line first a more
secure choice. If you edit the commands of the 'history', you limit
the possibility of checking later what actually was issued. And the
knowledge of what really was there may be of help when you realize you
made a mistake somewhere.

R

Re: [9fans] find command reloaded

[Tim Newsham]

> I have never felt the need for tools like these, I use the mouse to edit
> the text on the screen (changing history), I then double click to the right
> of the line and click send which resubmits the text.
>
> The idea that any text on the screen may be used to form a new command is
> very powerful, but takes some getting used to.

the " command works with the grain here.  It brings text
on the screen that may be further away closer.

> -Steve

Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com

Re: [9fans] find command reloaded

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 1052 bytes --]

On Sun, Jan 24, 2010 at 10:05 AM, Tim Newsham <newsham@lava.net> wrote:

> I have never felt the need for tools like these, I use the mouse to edit
>> the text on the screen (changing history), I then double click to the
>> right
>> of the line and click send which resubmits the text.
>>
>> The idea that any text on the screen may be used to form a new command is
>> very powerful, but takes some getting used to.
>>
>
> the " command works with the grain here.  It brings text
> on the screen that may be further away closer.
>

Actually, I've never used those scripts... mainly because I'm not really
sure I "get it".  I've just always typed what I wanted in, and a lot of
times, my work patterns involve invoking the same pretty recent steps over
and over.  Snarf buffer often works just fine for me.

I guess I should learn to try out the " command sometime.  I mean like
pretty much everything else Russ has done :-)

Dave


>
>  -Steve
>>
>
> Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com
>
>

[-- Attachment #2: Type: text/html, Size: 1917 bytes --]

Re: [9fans] find command reloaded

[erik quanstrom]

> Another problem with stuff in contrib is, that their software is not
> well documented (i.e. no man pages), so that one probably has to read
> the source in order to be able to use it. This often forms an obstacle
> for usage... Being accepted to the main tree brings along good
> documentation, too, which is of importance to me.

i think you'll get further talking to the author of various packages
than inaccurately tarring everyone with the same brush.

i've been writing man pages, and i'm clearly not the only one:

minooka; 9fs sources ; cd /n/sources/contrib
minooka; find -f */root/sys/man | wc
    564     564   20926

- erik

Re: [9fans] find command reloaded

[Rudolf Sykora]

> i think you'll get further talking to the author of various packages
> than inaccurately tarring everyone with the same brush.
>
> i've been writing man pages, and i'm clearly not the only one:
>
> minooka; 9fs sources ; cd /n/sources/contrib
> minooka; find -f */root/sys/man | wc
>    564     564   20926
>
> - erik

Fine.
Just I forgot to write 'often' there. Sorry. But my argument was of an
additional nature, and also I guess there is no doubt that the main
tree plainly is better documented.

R

PS.: Can that 'find' of yours be found somewhere? Thanks.

Re: [9fans] find command reloaded

[Rudolf Sykora]

Hello!

when I do
contrib/pull quanstro/find
I get
no such replica: find
What am I doing wrong?!

Thanks
R

On 22 January 2010 22:54, erik quanstrom <quanstro@coraid.com> wrote:
>> And if you like find, write and put it in contrib.
>
> contrib/pull quanstro/find
>
> - erik
>
>

Re: [9fans] find command reloaded

[Rudolf Sykora]

ok!
contrib/install quanstro/find
is the right way...
I now got it.
thanks
R

On 3 February 2010 18:58, Rudolf Sykora <rudolf.sykora@gmail.com> wrote:
> Hello!
>
> when I do
> contrib/pull quanstro/find
> I get
> no such replica: find
> What am I doing wrong?!
>
> Thanks
> R
>
> On 22 January 2010 22:54, erik quanstrom <quanstro@coraid.com> wrote:
>>> And if you like find, write and put it in contrib.
>>
>> contrib/pull quanstro/find
>>
>> - erik
>>
>>
>

Re: [9fans] find command reloaded

[erik quanstrom]

On Wed Feb  3 13:16:28 EST 2010, rudolf.sykora@gmail.com wrote:
> Hello!
>
> when I do
> contrib/pull quanstro/find
> I get
> no such replica: find
> What am I doing wrong?!

perhaps you haven't installed it?
	contrib/install quanstro/find

- erik

Re: [9fans] find command reloaded

[Rudolf Sykora]

On 3 February 2010 19:28, erik quanstrom <quanstro@labs.coraid.com> wrote:
> On Wed Feb  3 13:16:28 EST 2010, rudolf.sykora@gmail.com wrote:
>> Hello!
>>
>> when I do
>> contrib/pull quanstro/find
>> I get
>> no such replica: find
>> What am I doing wrong?!
>
> perhaps you haven't installed it?
>        contrib/install quanstro/find
>
> - erik

yes. that was it.
Thanks
R

Re: [9fans] find command reloaded

[Jason Catena]

If looking through code:
du -a . | xargs g pattern >[2]/dev/null

If looking through all files:
du -a . | xargs grep -n foo >[2]/dev/null

The -n is to be friendly with acme.

This presumes you have (at least a cheap knockoff of) xargs.

Re: [9fans] find command reloaded

[John Stalker]

On unix systems I tend to use find a lot, and in ways that aren't
easy to replicate with du.  Anything even slightly complicated,
say combining -prune, -type, -newer, and -exec, is nearly impossible
to do in a correct and efficient way without find, even if you have
an xargs.  I'm not sure I understand the resistance to having a
find command in plan9.
--
John Stalker
School of Mathematics
Trinity College Dublin
tel +353 1 896 1983
fax +353 1 896 2282