Thanks for your answers!
But I consider it ugly, to ask for the disk usage if you just want to
recursively list all files.
And then, the man page for du(1) is missing from the distribution
http://github.com/9fans/plan9port
If found one in the book "Plan9 the Manuals", snd edition. But
> But I consider it ugly, to ask for the disk usage if you just want to
> recursively list all files.
Find queries a lot more information than du, including what du
queries, so that's purely aesthetic.
You'll find "walk" as well as my own "stat" on "sources", if you can
get to it. I'm not sure
On Wed, Sep 30, 2015 at 9:26 AM, Wolfgang Helbig wrote:
> Hello 9fans,
> in Unix I use find() like
> $ ed `find . -name blabla.java`
>
> to edit a file in a deeply nested directory.
>
> How would you accomplish this with commands from plan9 for user space?
>
> Greetings,
>
>
leave away the 9 if you're not running ubuntu with a plan9 theme *sigh*
On 30 September 2015 at 09:01, Wolfgang Helbig wrote:
> But I consider it ugly, to ask for the disk usage if you just want to
> recursively list all files.
>
It probably is not ideal, even when the circumlocution is hidden in a
script.
Perhaps find's syntax and conventions
> i'd suggest creating an index of all files you have,
> sorted into a text file.
NetBSD irritates me every Saturday, when it announces that it has
refreshed the "locate" database. It is the default in the
distribution.
I bet "locate" can be ported to Plan 9, I've found most of NetBSD's
base
I'm surprised you can even remember find's command line options.
If you need to optimize this cause you have a jillion files and think
du takes too long i'd suggest creating an index of all files you have,
sorted into a text file.
Then you only have to use grep filename index.
In Plan 9 a command is needed, that lists recursively all files. Not more and
not less. The du(1) command offers too much. I do not want to list the disk
usage!
The command du(1) from the second edition of plan9 only has two command line
options (-a and -b size),
whereas du(1) from
It is indeed a matter of taste and aesthetics. One reason I prefer Plan 9 is
the Bell Labs aesthetics, as opposed to the so called "complete" solution
aesthetic of other design philosophies which are slaves to some orthogonality
or other, is the small is beautiful aesthetic. I've been using
Both of them exactly fill the gap!
Thank you for all your insidefull discussions.
Wolfgang
> Am 30.09.2015 um 11:58 schrieb Aram Hăvărneanu :
>
> https://swtch.com/lsr.c
> https://github.com/4ad/mgk.ro/blob/master/cmd/lsr/lsr.go
>
> --
> Aram Hăvărneanu
>
On Plan9 it should also be possible to write a virtual overlay file
server where creation of a new file triggers the creation of an index
entry.
On linux you would use inotify for something similar.
Perhaps you could optimize even more by adding a special file-listing
instruction to your CPU design.
On Wed, Sep 30, 2015 at 12:07 PM, Steve Simon wrote:
> NB: don't use sed or awk, they don't understand the shells
> quoting convention for filenames containing frogs.
That's a good point.
Mark.
https://swtch.com/lsr.c
https://github.com/4ad/mgk.ro/blob/master/cmd/lsr/lsr.go
--
Aram Hăvărneanu
On Wed Sep 30 01:12:36 PDT 2015, charles.fors...@gmail.com wrote:
> On 30 September 2015 at 09:01, Wolfgang Helbig wrote:
>
> > But I consider it ugly, to ask for the disk usage if you just want to
> > recursively list all files.
> >
>
> It probably is not ideal, even when
http://doc.cat-v.org/unix/find-history
sl
Somewhat late to the party, but I use the following in my profile:
fn find {du -a $* |awk '{print $2}'}
http://plan9.bell-labs.com/sources/contrib/stallion/profile
On Wed, Sep 30, 2015 at 8:20 AM, erik quanstrom wrote:
> On Wed Sep 30 01:12:36 PDT 2015,
Is there a C level equivalent of the BSD fts(3) suite of routines?
Or even the System V ftw / GLIBC nftw suite?
I suspect that having this would save some wheel-reinvention in
these kinds of programs.
Thanks,
Arnold
erik quanstrom wrote:
> On Wed Sep 30 01:12:36 PDT
18 matches
Mail list logo