On 3 February 2010 19:28, erik quanstrom wrote:
> On Wed Feb 3 13:16:28 EST 2010, rudolf.syk...@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 quan
ok!
contrib/install quanstro/find
is the right way...
I now got it.
thanks
R
On 3 February 2010 18:58, Rudolf Sykora 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 wr
On Wed Feb 3 13:16:28 EST 2010, rudolf.syk...@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
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 wrote:
>> And if you like find, write and put it in contrib.
>
> contrib/pull quanstro/find
>
> - erik
>
>
On Sun, Jan 24, 2010 at 10:05 AM, Tim Newsham 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
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 ta
> 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 56
On 23 January 2010 16:24, Steve Simon 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
> 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, t
> 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 li
On 23 January 2010 11:16, John Stalker 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
> 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 wan
>> > 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
> > 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
> And if you like find, write and put it in contrib.
contrib/pull quanstro/find
- erik
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 ou
> 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 l
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
> 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
On Fri, Jan 22, 2010 at 12:23 PM, John Stalker 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 o
On Fri, Jan 22, 2010 at 12:16 PM, Jason Catena 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
On Fri Jan 22 15:24:49 EST 2010, stal...@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
> 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
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
> > 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;re
> 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 Coll
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 unders
> 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
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*)
On Fri, Jan 22, 2010 at 10:40 AM, Rudolf Sykora 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
now I understand your question.
I just tested this and it worked fine.
du -a / | awk '{print "grep something " $2}' |/bin/rc
ron
2010/1/22 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
>
The relation to the find command: the linux/unix find command can be
producing and using the list at the same time (actually i
2010/1/22 Joseph Xu
>
> 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
On Fri, Jan 22, 2010 at 10:19 AM, Joseph Xu 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
> 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
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
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
Building a large list in advance can exhaust main memory on smaller terminals.
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.
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
(
2010/1/22 maht
> 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
2010/1/22 Robert Raschke
> 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
nee
2010/1/22 ron minnich
> 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
On Fri, Jan 22, 2010 at 5:29 PM, 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,
>
> grep foo `{du -a . | awk '{print $2}'}
>
> Now I want to find all files containing foo.
> Is it so tha
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,
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
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
47 matches
Mail list logo
