It would be easy to say that list should be divided, in practice
though, I'm not sure the folks who I would like to have a privilege
of addressing would voluntarily subscribe to the #3 type of list.
Being a curious sometime user I guess I fall in category 3. Which
seems natural since the list
> bootfile=ether0!/386/9pccpu.gz
> bootargs=tcp!192.168.1.40!564 -D
> fs=192.168.1.40
> auth=192.168.1.50
> sysname=cpu-003
> *nomp=1
> *debugload=1
> *nodumpstack=1
i think that should be should be (indent for clarity)
bootfile=ether0!$mydhcpserver!/386/9pccpu.gz
Hi,
I am (net)booting a Qemu instance from a Plan 9 fileserver named
colossus(192.168.1.40) running cwfs, an authserver, named
cerberus(192.168.1.50) is also present in the same domain.
The client is named cpu-003(192.168.1.33), it retrieves, via dhcp its
plan9.ini, which is as such:
bootfile=
On Thu, 2009-09-17 at 17:02 -0400, erik quanstrom wrote:
> > ... In case anyone is wondering what they could be doing instead of feeding
> > this massive thread more fatty foods.
>
> there's lots of complaining on the list about the
> content of the list.
>
> it's not like there aren't good meaty
> what happened with either of the recently-reported
> fossil lockup problems, for instance?
As I now have two servers at home (old and new) I have been trying
to provoke the old one into locking up so I can take a snap of its fossil.
sadly the old server has been irriatingly reliable and the onl
Has anyone taken a crack at running a current Plan 9 under
Microsoft's standalone Hyper-V distribution? It's been a year
and a month since this last came up on the list, and a lot has
happened since then ...
--lyndon
forget about my previous post regarding the leading space,
I am tired, it was wrong...
Anyway the question about () is still hot...
R
2009/9/17 Rudolf Sykora :
> 2009/9/17 erik quanstrom :
>> i don't think you need an extra () for the leading
>> white space. just tack it on in with the leading e
> Anyway, what do you think about that problem with the empty group? Why
> linux is ok with it while plan 9 is not? Is there any reason? Is that
> a bug in plan9 sed?
it is not a bug. see regexp(6). there is no production in the
grammar that allows ().
- erik
2009/9/17 erik quanstrom :
> i don't think you need an extra () for the leading
> white space. just tack it on in with the leading expression.
see below
> the hoc is unnecessary. just start with 2.
true :)
> fn buildre {
> re = 's:^([ ]*'
> for(i in `{seq 2 $1})
>
http://ninetimes.cat-v.org/news/2009/09/07/0-mplayer9/
On Thu, Sep 17, 2009 at 10:31 PM, Anant Narayanan wrote:
> On Sep 17, 2009, at 10:26 PM, erik quanstrom wrote:
>>>
>>> Good luck trying to get Plan 9 to play video!
>>>
>>
>> minooka; lc /sys/src/9/pc/*tv*.c
>> devtv.c vgatvp3020.c
> ... In case anyone is wondering what they could be doing instead of feeding
> this massive thread more fatty foods.
there's lots of complaining on the list about the
content of the list.
it's not like there aren't good meaty issues to discuss.
what happened with either of the recently-reported
> What I was referring to was Plan 9's ability
> (or lack thereof) to decode and play digital video codecs. Just one of those
> things that prevent someone from running only Plan 9 on their computers --
> you need one of the big 3 for web browser + video.
With Cinap Lenrek's work on linuxemu, one
i don't think you need an extra () for the leading
white space. just tack it on in with the leading expression.
the hoc is unnecessary. just start with 2.
fn buildre {
re = 's:^([ ]*'
for(i in `{seq 2 $1})
re = $re ^ '[^ ]+[ ]+'
re = $re ^ ')([^
2009/9/17 roger peppe :
> just change the regexp as required.
Ok. I decided (although just for game now) to play a little with the
idea of building the regexp.
Starting from Eric's post I slowly progressed to sth. quite similar to
your post :) :
fn buildre {
re = 's:^([ ]*)('
f
On Sep 17, 2009, at 10:26 PM, erik quanstrom wrote:
Good luck trying to get Plan 9 to play video!
minooka; lc /sys/src/9/pc/*tv*.c
devtv.c vgatvp3020.cvgatvp3026.c
Sure, if you have a TV tuner. What I was referring to was Plan 9's
ability (or lack thereof) to decode and play di
> Good luck trying to get Plan 9 to play video!
>
minooka; lc /sys/src/9/pc/*tv*.c
devtv.c vgatvp3020.cvgatvp3026.c
- erik
Not meaning to add fuel to the fire, but;
On Sep 17, 2009, at 7:38 PM, Jack Norton wrote:
I hate iTunes with a passion. It is a huge monolithic godlike
creature that tries to do everything for me (usually when I don't
want it to). It brings my 12" powerbook to a screeching halt (I get
beac
2009/9/17 Rudolf Sykora :
> Yes, I now see yours and Roger Peppe's idea to build a regexps and then use
> it.
> That's true.
> Only as I look at your code, not sure if it can stand possible spaces
> at the beginning of a line, like
> 1 2 3
just change the regexp as required.
David Leimbach wrote:
On Thu, Sep 17, 2009 at 1:43 AM, Charles Forsyth
mailto:fors...@terzarima.net>> wrote:
we'd have been much better off if Apple had instead spent the
time and effort writing a decent iTunes, or opening their platform
interfaces enough that someone else could
On Sep 17, 2009, at 3:19 AM, Andrew Simmons wrote:
And no doubt we'd have been much better off if Apple had instead
spent the
time and effort making a decent iPod.
Um... what is it you dislike about the iPod?
—
Daniel Lyons
2009/9/17 erik quanstrom :
> fn buildre {
> re = 's:^'
> for(i in `{seq 1 $1})
> re = $re ^ '([^ ][ ]*)'
> re = $re ^ '([^ ]):\' ^ $1 ^ $2 ^ :
> }
>
> - erik
>
Yes, I now see yours and Roger Peppe's idea to build a regexps and then use it.
T
> # usage: buildre n replacement
> fn buildre {
> re = '^'
> for(i in `{seq 1 $1})
> re = $re ^ '([^ ][ ]*)'
> re = $re ^ ([^ ]):\' ^ $2 ^ ':'
> }
sorry. quote snafu.
fn buildre {
re = 's:^'
for(i in `{seq 1 $1})
re =
2009/9/17 Noah Evans :
> Since you're doing character processing rather than record processing,
> isn't C your best tool for the job here?
>
> This is what I whipped out YMMV:
>
> #include
> #include
> #include
>
> char *str;
> int ntok;
>
> #define WHITESPACE(c) ((c) == ' ' || (c) ==
> As I said in my second post, neither the field (the problem with sed)
> nor the string to be used as a replacement (no problem) is not known
> in advance...
> Apparently nobody reads but the 1st post... :)
why would it be hard to build up the regular expression
with a script?
something like thi
2009/9/17 erik quanstrom :
> i don't know why this can't be done with sed. if the
> task is to just change the second field without messing
> with whitespace, why doesn't this work
As I said in my second post, neither the field (the problem with sed)
nor the string to be used as a replacement (no
On Thu Sep 17 12:28:18 EDT 2009, maht-9f...@maht0x0r.net wrote:
> look who's trolling now :)
if that's your opinion, then maybe you have
misunderstood my point. perhaps i made it
poorly.
the plan 9 kernel often looks basic but is actually
quite sophisticated. (this is even more true of
the file
look who's trolling now :)
i don't know how ingo managed to put his
finger on so many reasons i enjoy plan 9
by counterexample.
Linux is a 18+ years old kernel, there's not that
many easy projects left in it anymore :-/ Core kernel
features that look basic and which are not in Linux
yet often t
2009/9/17 erik quanstrom :
> i don't know why this can't be done with sed. if the
> task is to just change the second field without messing
> with whitespace, why doesn't this work
indeed. i did the same thing (see previous post, except i've
just noticed that i forgot the ^ at the start of the re
i don't know why this can't be done with sed. if the
task is to just change the second field without messing
with whitespace, why doesn't this work
; cat x
1 3 4 8
1 2 3 4
; sed 's:^([^ ][ ]*)([^ ]):\1hell:g' < x
1 hell 48
1 hell 3 4
- erik
On Thu, Sep 17, 2009 at 8:30 AM, Jack Norton wrote:
> erik quanstrom wrote:
>
>> Now, Plan 9's kernel is pretty old too, isn't it?
>>>
>>>
>>
>> that's the point. age is a red herring.
>>
>>
>>
>>> What has saved other 'popular' kernels from this? For instance, no body
>>> ever complains about
On Thu, Sep 17, 2009 at 5:52 AM, erik quanstrom wrote:
> > Now, Plan 9's kernel is pretty old too, isn't it?
>
> that's the point. age is a red herring.
>
> > What has saved other 'popular' kernels from this? For instance, no body
> > ever complains about FreeBSD being a complex cluster, but it
==8<==
> No, no, it is, what I mean is that I haven't heard similar sentiments
> towards the open source released by Apple. Apple's 'open source' is
> software that is developed in a closed source fashion, then released as
> open source when the time is right, as opposed to Linux and related
>
On Thu, Sep 17, 2009 at 1:43 AM, Charles Forsyth wrote:
> we'd have been much better off if Apple had instead spent the
> time and effort writing a decent iTunes, or opening their platform
> interfaces enough that someone else could do it (and on Linux, not just Mac
> or Windows).
>
>
What's your
> The trouble with this is that the same string can appear more than
> once (before, after the field, ...), so the simple substitution isn't
> enough.
It's sounding like awk is the wrong tool. It should be trivial to code
up a short piece of C to do the job.
erik quanstrom wrote:
Now, Plan 9's kernel is pretty old too, isn't it?
that's the point. age is a red herring.
What has saved other 'popular' kernels from this? For instance, no body
ever complains about FreeBSD being a complex cluster, but it has
pretty wide adoption (even as a '
another approach, build up a regexp and use that:
fn changefield {
n = $1
repl = $2
s=')([^ ]+)(.*)'
for(i in `{seq 1 `{echo $n 1 -p | dc}}){
s='[^ ]+[ ]+'^$s
}
s='('^$s
sed 's/'^$s^'/\1'^$repl^'\3/'
}
(N.B. if
Like shuffle db (i.e. no iTunes).
On Thu, Sep 17, 2009 at 5:19 AM, Andrew Simmons wrote:
> >> we'd have been much better off if Apple had instead spent the
> >> time and effort writing a decent iTunes
>
> And no doubt we'd have been much better off if Apple had instead spent the
> time and effor
Since you're doing character processing rather than record processing,
isn't C your best tool for the job here?
This is what I whipped out YMMV:
#include
#include
#include
char *str;
int ntok;
#define WHITESPACE(c) ((c) == ' ' || (c) == '\t' || (c) == '\n')
void
chgtok(Biobuf *bin
I setup pingdom to track plan9.bell-labs.com -- it routinely checks
from several "probe" server scattered across the world so its a good
resource to check when you are trying to see if its your problem or if
something is wrong at the Labs. I've got an email notification relay
setup too, but haven'
2009/9/17 yy :
> if you want to preserve white-space, you better forget about fields
> and work with indexes on the string, match is your friend:
>
> % echo '1 3 4 8' | awk '{match($0, /[ \t]*[^ \t]+[
> \t]+/);a=RLENGTH+1;match(substr($0, a), /[ \t]/);print
> substr($0,0,a-1) "hell"
> Now, Plan 9's kernel is pretty old too, isn't it?
that's the point. age is a red herring.
> What has saved other 'popular' kernels from this? For instance, no body
> ever complains about FreeBSD being a complex cluster, but it has
> pretty wide adoption (even as a 'desktop'). What about OS
Hello,
is the <> operator a feature only of native plan 9?
It doesn't seem to work for me in p9p...
Is the right solution then, instead of
program <> file
write
program < file > file_tmp
mv file_tmp file
?
Thanks
Ruda
if you want to preserve white-space, you better forget about fields
and work with indexes on the string, match is your friend:
% echo '1 3 4 8' | awk '{match($0, /[ \t]*[^ \t]+[
\t]+/);a=RLENGTH+1;match(substr($0, a), /[ \t]/);print
substr($0,0,a-1) "hell" substr($0,RSTART+a)}'
1
erik quanstrom wrote:
i don't know how ingo managed to put his
finger on so many reasons i enjoy plan 9
by counterexample.
Linux is a 18+ years old kernel, there's not that
many easy projects left in it anymore :-/ Core kernel
features that look basic and which are not in Linux
yet often turn ou
i don't know how ingo managed to put his
finger on so many reasons i enjoy plan 9
by counterexample.
Linux is a 18+ years old kernel, there's not that
many easy projects left in it anymore :-/ Core kernel
features that look basic and which are not in Linux
yet often turn out to be not that simple.
Ok. Thanks again. I think I've found what I need.
(on lines of 'inpch' that contain 'TH' I change the field at position
$pos to be $new, preserving spacing made of 'space's and/or tabs).
If anyone comes up with sth. simpler...
Ruda
(The script is for 'rc', btw., so that the concatanation on the 3
>> we'd have been much better off if Apple had instead spent the
>> time and effort writing a decent iTunes
And no doubt we'd have been much better off if Apple had instead spent the
time and effort making a decent iPod.
The iTunes on my computer strikes me as at worst perfectly decent, in
genera
2009/9/17 matt :
> awk '{a=$2; sub(a, "hell"); print}' file
The trouble with this is that the same string can appear more than
once (before, after the field, ...), so the simple substitution isn't
enough.
Ruda
On Sep 17, 2009, at 2:43 AM, Charles Forsyth wrote:
opening their platform interfaces
Any in particular?
—
Daniel Lyons
awk '{a=$2; sub(a, "hell"); print}' file
also works if it contains no regex special chars
this seems to do the trick otherwise
awk ' { p=substr($0, index($0, " ")); split(p, a, "[^ ]"); sub(/ +[^ ]+/, "", p); print
$1 a[1] "hell" p} '
Rudolf Sykora wrote:
Hello,
simple task.
I want to
2009/9/17 matt :
> sed 's/^([^ ]+ +)([^ ]+)/\1HELL/'
Well, actually, my problem is a part of a more complicated script; I
don't know in advance neither the column nor what to put there.
I currently have this
awk '
/TH/ {$'$pos'='$new'}
{print}
' inpch
where 'TH' plays a role of a g
we'd have been much better off if Apple had instead spent the
time and effort writing a decent iTunes, or opening their platform
interfaces enough that someone else could do it (and on Linux, not just Mac or
Windows).
sed 's/^([^ ]+ +)([^ ]+)/\1HELL/'
Hello,
simple task.
I want to change the 2nd field on each line of a file, but preserve
the spacing of the lines.
If I do
awk '{$2="hell"; print}' file
the field gets changed, but all the spacing of the lines is gone; i.e.
any space is now just ' ' like this:
Hello,
simple task.
I want to change the 2nd field on each line of a file, but preserve
the spacing of the lines.
If I do
awk '{$2="hell"; print}' file
the field gets changed, but all the spacing of the lines is gone; i.e.
any space is now just ' ' like this:
1 3 4 8
changes to
1
54 matches
Mail list logo
