Actually it's really simple. Stack in 9vx begins at 48 MB. A bit small
for compiling gs I suppose :-)
I'll see how to grow it.
ron
diff -r 6ab31397d4b9 src/9vx/a/mem.h
--- a/src/9vx/a/mem.h Sat Sep 11 23:09:14 2010 +0200
+++ b/src/9vx/a/mem.h Sat Sep 11 19:31:19 2010 -0700
@@ -41,7 +41,7 @@
#defineVMAPSIZE(0x1000-VPTSIZE-KMAPSIZE)
#defineUZERO 0 /* base of user
OK, the bigger user stack is committed to my vx32 at bitbucket.
ron
I want to build a kw kernel, which caused me to want to update my 9vx
installation.
Have my file system on a case-sensitive remote mounted drive.
I'm getting essentially every file tagged as locally modified; will not
update.
When a file is good, I get a warning that I can't set the uid; I can
FWIW, Ron's got a regularly updated snapshot of the source tree in
mercurial -- he and I have been using that to keep our 9vx plan 9
directories up to date -- works faster, better, and is more reliable
than replica. Using floren's python installation you can even use it
under Plan 9.
On Fri, Sep 10, 2010 at 6:24 PM, Paul Lalonde paul.a.lalo...@gmail.com wrote:
What am I doing wrong?
I would argue that, while it is quite cool in principle, replica is
the wrong way to solve the source distribution problem. I gave up on
replica a year ago because I got tired of the kinds of
What am I doing wrong?
I would argue that, while it is quite cool in principle, replica is
the wrong way to solve the source distribution problem. I gave up on
replica a year ago because I got tired of the kinds of problems you're
having.
while some much-needed patches have been slow in
it's interesting that neither of philippe's changes,
however justified, make any visible difference
to 9vx on my ubuntu 10.04LTS system: 9vx still
fails almost immediately. that's consistent with
9vx behaving itself as well as on any other platform
until i changed the linux and/or ubuntu version.
Charles,
Can you please give us stack information with gdb ?
Phil;
On Mon, 2010-06-14 at 20:15 +0100, Charles Forsyth wrote:
it's interesting that neither of philippe's changes,
however justified, make any visible difference
to 9vx on my ubuntu 10.04LTS system: 9vx still
fails almost
If anyone can help me with some valgrind patches we can see if
valgrind can be useful.
Charles, I am really puzzled about your ubuntu experience.
Oh, wait, can you set
LANG=C
and try again? Or is it?
BTW when you get the immediate explosion does a window even ever come
up or does it die
On Sun, Jun 13, 2010 at 11:03 AM, Philippe Anel x...@bouyapop.org wrote:
I tried with adding :
while (p-mach)
sched_yield();
at the end of sched.c:^runproc(), before the return.
It seems to work well.
What do you think ?
Not sure I understand all the implications but I'll try
- splhi -- it's not a true splhi in some sense; is it possible that
some code is sneaking in and running even when you splhi()? Could this
explain it?
The error Philippe has found is only indirectly related to splhi().
It's a race between a process in sleep() returning to the scheduler on
cpu
that's only because the clock interrupt handler directly or indirectly (eg,
via sched) calls spllo, and other trap or interrupt handlers could do that.
wouldn't that be fatal with shared 8259 interrupts?
- erik
In fact you're right, and this shows us this would only happens to 9vx.
Indeed, the proc is a kproc and thus is not scheduled by the
9vx/a/proc.c scheduler,
but by the one in 9vx/sched.c ... where dequeueproc() is not called and
where p-mach
is not checked.
Thank you !
Phil;
Richard Miller
Should be, at least I think so. But I don't even know yet how we can do
this. :)
I think we can use the go trick and postpone the call to ready() while
p-mach != 0.
But I don't know where yet.
Phil;
ron minnich wrote:
On Sun, Jun 13, 2010 at 7:26 AM, Philippe Anel x...@bouyapop.org wrote:
Hi,
The solution is not that simple. I mean when kprocs go to sleep
through the call to psleep(), a pwakeup() is required. We cannot
simply change the following sched.c:^runproc() part :
while((p = kprocq.head) == nil){
by:
while(((p = kprocq.head) == nil) || p-mach){
The a/proc.c
Hi,
I really think the spin model is good. And in fact, I really think
current sleep/wakeup/postnote code is good. However, this model makes
the assumption that plan9 processes are really Machs and not coroutines.
I think we need a larger model, which includes the scheduler.
I mean a model
9fans,
FYI, I've wondered if they had the same problem in go runtime because
I suspected the code to be quite similar. And I think go team fixed the
problem in ready() equivalent in go runtime, by adding a flag in Proc
equivalent so the proc (G in go) is put back to the run queue ...
Phil;
- does richard miller's alternate implementation of wakeup
solve this problem.
No, it doesn't.
There's kind of an interesting similarity here to what I had to deal
with on the Xen port.
So, a few random thoughts, probably useless, from early problems of
this sort I've had.
- in Linux parlance, Plan 9 is a preemptible kernel. Interrupt
handlers can be interrupted, so to speak. Except for
in Linux parlance, Plan 9 is a preemptible kernel. Interrupt handlers can be
interrupted, so to speak.
interrupt handlers are not normally interruptible during the interrupt
processing, but rather at the end (eg, when anyhigher, anyready or preempted
is called).
processes running at
FYI, I've wondered if they had the same problem in go runtime because
I suspected the code to be quite similar. And I think go team fixed the
problem in ready() equivalent in go runtime, by adding a flag in Proc
equivalent so the proc (G in go) is put back to the run queue ...
are you sure?
Dear 9fans,
I think I maybe have found the reason why some of us have a *double
sleep* error while running 9vx. I think this would even explain some
segmentation faults seen in kprocs.
Please forgive me for the length of this post. I'm trying to be as
explicit as possible.
I have no certainty
I'll look but one thing doesn't make sense to me:
On Fri, Jun 11, 2010 at 2:06 PM, Philippe Anel x...@bouyapop.org wrote:
// xigh: move unlocking to schedinit()
schedinit only runs once and sleep runs all the time. That's the part
I don't get.
But you might have found something, I
Schedinit() initialize the scheduler label ... on which sleep() goes
when calling gotolabel(m-sched).
Phil;
ron minnich wrote:
I'll look but one thing doesn't make sense to me:
On Fri, Jun 11, 2010 at 2:06 PM, Philippe Anel x...@bouyapop.org wrote:
// xigh: move unlocking to
schedinit only runs once and sleep runs all the time. That's the part
I don't get.
gotolabel in sleep sends you back to the
setlabel at the top of schedinit.
But you might have found something, I sure wish I understood it all better :-)
i'm not entirely convinced that the problem isn't the
I don't think either splhi fixes the problem ... it only hides it for
the 99.9% cases.
Phil;
erik quanstrom wrote:
schedinit only runs once and sleep runs all the time. That's the part
I don't get.
gotolabel in sleep sends you back to the
setlabel at the top of schedinit.
Ooops I forgot to answer this :
- does changing spl* to manipulation of a per-cpu lock solve the problem?
sometimes preventing anything else from running on your mach is
exactly what you want.
No ... I don't think so. I think the problem comes from the fact the
process is no longer
On Fri, Jun 11, 2010 at 2:49 PM, Philippe Anel x...@bouyapop.org wrote:
Schedinit() initialize the scheduler label ... on which sleep() goes when
calling gotolabel(m-sched).
Phil;
yep. Toldja I was not awake yet.
ron
I'm going to put this change into my hg repo for 9vx and do some
testing; others are welcome to as well.
That's a pretty interesting catch.
ron
On Fri Jun 11 11:03:32 EDT 2010, rminn...@gmail.com wrote:
I'm going to put this change into my hg repo for 9vx and do some
testing; others are welcome to as well.
That's a pretty interesting catch.
please wait. we still don't understand this problem
very well. (why does this work on real
On Fri Jun 11 10:54:40 EDT 2010, x...@bouyapop.org wrote:
I don't think either splhi fixes the problem ... it only hides it for
the 99.9% cases.
on a casual reading, i agree. unfortunately,
the current simplified promela model disagrees,
and coraid has run millions of cpu-hrs on quad
I never seen it on real hardware but I think it does not mean it
cannot happen. The problem in 9vx comes from the fact 9vx Mach are
simulated by pthreads which can be scheduled just before calling
gotolabel in sleep(). This gives the time to another Mach (or pthread)
to 'readies' the proc A.
Oooops ... sorry for double copy :) The post was supposed to be :
I never seen it on real hardware but I think it does not mean it
cannot happen. The problem in 9vx comes from the fact 9vx Mach are
simulated by pthreads which can be scheduled just before calling
gotolabel in sleep(). This gives
On Fri, Jun 11, 2010 at 8:04 AM, erik quanstrom quans...@quanstro.net wrote:
please wait. we still don't understand this problem
very well. (why does this work on real hardware?)
all the 9vx failures I have seen are with the kexec threads. This is a
major 0vx change from 9. I do think that
On Fri, 11 Jun 2010 16:59:42 +0200 Philippe Anel x...@bouyapop.org wrote:
Ooops I forgot to answer this :
- does changing spl* to manipulation of a per-cpu lock solve the problem?
sometimes preventing anything else from running on your mach is
exactly what you want.
No ... I don't
I only did my tests on 9vx. I have a version that I instrumented with
a circular log buffer, and I have some gdb macros which dumps the
buffer.
I can put the whole source somewhere and even a log with my comments
of the bug if you want to see it. But please note that I made several
changes
On Fri, 11 Jun 2010 19:31:58 +0200 Philippe Anel x...@bouyapop.org wrote:
I only did my tests on 9vx. I have a version that I instrumented with
a circular log buffer, and I have some gdb macros which dumps the
buffer.
I can put the whole source somewhere and even a log with my comments
You can download my own (ugly) 9vx source code here :
http://www.bouyapop.org/9vxigh.tar.bz2
In 9vx you'll find .gdbinit and crash.c.
Just copy it to vx32 and replace 9vx folder, compile it and execute it
under gdb with you own 9vx env.
(gdb) r -F -r your folder
then compile and
On Sun, Jun 6, 2010 at 3:16 AM, EBo e...@sandien.com wrote:
I'm still having 9vx crash even after removing -O3 from the build flags.
An odd error that pops up randomly in rio (not in the terminal window) is
double sleep called from Thought this tidbit might be useful to the
discussion of
On Sun, Jun 6, 2010 at 3:16 AM, EBo e...@sandien.com wrote:
I'm still having 9vx crash even after removing -O3 from the build flags.
An odd error that pops up randomly in rio (not in the terminal window) is
double sleep called from Thought this tidbit might be useful to the
The update to 10.04 has overloaded my email with messages from ubuntu's dosemu
forum. Basically the same issue as with 9vx. A fix [sic] is suggested. So,
question is:
On Sat, 1 May 2010 23:36:08 +0200
Mathieu Lonjaret mathieu.lonja...@gmail.com wrote:
Fwiw, 9vx does build and run fine on
Not that I know of. it's a lucid lynx install I did when it was still
in beta and I haven't kept it up to date since then, so maybe that's
where the difference lies.
How do I check if that fix you're speaking of is installed or not?
Cheers,
Mathieu
---BeginMessage---
The update to 10.04 has
On Tue, 4 May 2010 11:06:29 +0200
Mathieu Lonjaret mathieu.lonja...@gmail.com wrote:
Not that I know of. it's a lucid lynx install I did when it was still
in beta and I haven't kept it up to date since then, so maybe that's
where the difference lies.
How do I check if that fix you're
having upgraded a machine to ubunut 10.04LTS yesterday,
9vx now crashes with a segmentation violation shortly after
saying it is starting /bin/rc. has anyone else a similar
problem on that or another linux system? 9vx itself was unchanged,
but i also tried recompiling it (in case a linux include
2.6.32-21-generic according to uname -a
what kernel version is it nowadays?
ron
2.6.32-21-generic according to uname -a
or is that a combination?
On Sat, May 1, 2010 at 1:53 PM, Charles Forsyth fors...@terzarima.net wrote:
2.6.32-21-generic according to uname -a
hmm. I'm running 9vx just fine on 2.6.33 -- a non-ubongo version. I
wonder if some ubuntu patch to the kernel has broken something?
Blast. if you do an ldd on it what libc etc.
% ldd 9vx.Linux # old
linux-gate.so.1 = (0xb772)
libX11.so.6 = /usr/lib/libX11.so.6 (0xb7617000)
...
% ldd 9vx # new
linux-gate.so.1 = (0x00704000)
libX11.so.6 = /usr/lib/libX11.so.6 (0x00c35000)
...
where an obvious difference is that
On Sat, May 1, 2010 at 2:05 PM, Charles Forsyth fors...@terzarima.net wrote:
having upgraded a machine to ubunut 10.04LTS yesterday,
9vx now crashes with a segmentation violation shortly after
saying it is starting /bin/rc. has anyone else a similar
problem on that or another linux system? 9vx
% ldd 9vx.Linux # old
...
% ldd 9vx # new
note that `old' is run on an existing 9.04 (2.6.28-18-generic), which works,
and `new' is the 10.04 (2.6.32-21-generic), which doesn't.
Fwiw, 9vx does build and run fine on 10.04 here.
Lemme know if I can give you some relevant info which might help.
Cheers,
Mathieu
---BeginMessage---
% ldd 9vx.Linux # old
...
% ldd 9vx # new
note that `old' is run on an existing 9.04 (2.6.28-18-generic), which works,
and `new' is
On Sat, May 1, 2010 at 6:33 PM, Charles Forsyth fors...@terzarima.net wrote:
% ldd 9vx.Linux # old
...
% ldd 9vx # new
note that `old' is run on an existing 9.04 (2.6.28-18-generic), which works,
and `new' is the 10.04 (2.6.32-21-generic), which doesn't.
can you run the
On Sat, May 1, 2010 at 6:39 PM, Charles Forsyth fors...@terzarima.net wrote:
can you run the current 9vx in 9.04?
yes
this version madness confuses me. i could not get it to run on 9.10.
9.04 was fine.
this version madness confuses me. i could not get it to run on 9.10.
i had 9vx running fine in 9.10 on the same machine.
it was the upgrade to 10.04 LTS that messed it up today.
i wonder why the library allocation addresses are different.
The address shown by ldd can even vary from run to run, for the same file -
http://linux.derkeiler.com/Mailing-Lists/Kernel/2005-03/4363.html
On Sun, May 2, 2010 at 3:27 AM, Charles Forsyth fors...@terzarima.netwrote:
this version madness confuses me. i could not get it to run on 9.10.
i had
On Sat, May 1, 2010 at 10:48 PM, Vinu Rajashekhar vinuthe...@gmail.com wrote:
The address shown by ldd can even vary from run to run, for the same file -
yeah it's a feechur.
But still all my libs are living in high half of 32-bit space on a
running instance.
The two LOAD segments on my 9vx
I forget what all else I did when trying nano. I ended up focusing back on
9atom, and Erik had just patched the source so that a mk all would compile
everything. See ftp://ftp.quanstro.net/other/9atom.iso.bz2 if interested.
That is one of the source trees I'm playing with for setting
On 04/26/2010 09:52 AM, lu...@proxima.alt.za wrote:
Try http://werc.homelinux.net/hacks/nano9/
Hope that helps,
How does one install the stuff in that directory? Specifically, what
handles *.xz files?
See http://tukaani.org/xz/
--
Balwinder S bdheeman DheemanRegistered Linux
sure. what specifically would you like to see?
Well, of course, the bit about xz would not go amiss. I note that
Ubuntu doesn't offer xz utilities, so as soon as I have copies for my
installation (plan 9, ubuntu, netbsd 3.1) I'll let you know so you can
put that on the wiki as well.
I'll
Try http://werc.homelinux.net/hacks/nano9/
Hope that helps,
How does one install the stuff in that directory? Specifically, what
handles *.xz files?
++L
lu...@proxima.alt.za said:
Try http://werc.homelinux.net/hacks/nano9/
Hope that helps,
How does one install the stuff in that directory? Specifically, what
handles *.xz files?
I tripped over that one too... This might help with the *.xz files:
http://en.wikipedia.org/wiki/Xz
I
I forget what all else I did when trying nano. I ended up focusing back on
9atom, and Erik had just patched the source so that a mk all would compile
everything. See ftp://ftp.quanstro.net/other/9atom.iso.bz2 if interested.
That is one of the source trees I'm playing with for setting up 9vx
On 04/20/2010 11:46 PM, EBo wrote:
that pc is in the floating point code. clearly bogus.
as find doesn't do any floating point.
I have no idea why this is happening, only that it is and it is failing
consistently.
While I could spend time trying to tracing through the code to figure
On Wed, Apr 21, 2010 at 1:39 AM, Balwinder S Dheeman
bsd.sans...@cto.homelinux.net wrote:
Try http://werc.homelinux.net/hacks/nano9/
That's neat, I'm going to have to try it now :-)
ron
On 04/21/2010 05:05 PM, erik quanstrom wrote:
While I could spend time trying to tracing through the code to figure out
what
is going on, I have opted for the moment to update the base root I am using
as
the old one is just shy of two years old, and the newer one seem to run
correctly so
Sorry, forget to mention that I also spend a lot of time on figuring out
why newly build 9vx from hg was crashing both on FreeBSD and Linux, but
all in a vain (currently don't have access to an OS/X machine).
I'm not sure, if it was a correct fix, but removing -melf_i386 option
did the
randomly changing build options is one approach to debugging but not
always effective :-)
ron
ron minnich rminn...@gmail.com said:
randomly changing build options is one approach to debugging but not
always effective :-)
true, true ;-) I'm still waking up! and in my best NASCAR announcers
voice-over: Gentlemen, Start your tea-pot/coffee-makers! and the crowd goes
wild
randomly changing build options is one approach to debugging but not
always effective :-)
I also forgot to mention that the reason I tried that is that I noticed both
of those switches were missing from one of the Makefrag files I was reading
recently, so it was not completely random ;-)
Just an FYI. I've been working on getting 9vx running on a TinyCoreLinux USB
stick, and I have been having 9vx crash in odd ways and wanted to post a note
about it.
For starters, I am building 9vx from hg source and using the root from 9vx's
2008/7/1 release 9vx-0.12. There are three points of
2) I installed Erik's find utility and running it gave the error:
find 2062: suicide: sys: trap: invalid opcode pc=0x5001
from inside 9vx, and:
invalid opcode ff ff ba at eip 5001
in the linux terminal that spawned it.
that pc is in the floating point code.
that pc is in the floating point code. clearly bogus.
as find doesn't do any floating point.
I have no idea why this is happening, only that it is and it is failing
consistently.
While I could spend time trying to tracing through the code to figure out what
is going on, I have opted for
On 15 Apr 2010, at 16:38, hiro wrote:
Plan 9 is not trying to be compatible to linux.
What does this have to do with the present discussion? We are
discussing something which has to run on linux, and on *BSD and other
things: 9vx.
--
Simplicity does not precede complexity, but follows
On 15 Apr 2010, at 15:29, Balwinder S Dheeman wrote:
Please don't compare apples with oranges.
I'm sure you have not read, Program design in the UNIX® environment
(http://werc.homelinux.net/links/reference_material/unix_prog_design.pdf
);
these notes are still valid today and are
Your point is valid. Back to work...
On 4/16/10, Ethan Grammatikidis eeke...@fastmail.fm wrote:
On 15 Apr 2010, at 15:29, Balwinder S Dheeman wrote:
Please don't compare apples with oranges.
I'm sure you have not read, Program design in the UNIX® environment
Plan 9 is not trying to be compatible to linux.
What does this have to do with the present discussion? We are
discussing something which has to run on linux, and on *BSD and other
things: 9vx.
sorry for adding to this thread.
i think the original point is valid. while 9vx does live
On 15 Apr 2010, at 07:48, EBo wrote:
what I had meant is simply that when a user tries to run a program
which has
been installed system wide it should simply work.
A good goal, but I'm not sure an environment variable is a good way to
achieve it. At the very least it means, in a typical
On 04/14/2010 09:55 PM, Ethan Grammatikidis wrote:
On 13 Apr 2010, at 06:20, EBo wrote:
Skip Tavakkolian 9...@9netics.com said:
but both
of the hard-coded paths in 9vx main.c are obviously in RSC's home
directories
it's not hardcoded;
What? The findroot code reads:
static char*
On 15 Apr 2010, at 08:39, EBo wrote:
Define reasonable. For me, that’s just 1 single spot. But it seems
the Linux people are very insistent on Freedom meaning do what you
want, even if it's against the build suggestions.
I say stick to one hardcoded path, and make everyone else stop doing
it
On 15 Apr 2010, at 09:44, Balwinder S Dheeman wrote:
On 04/14/2010 09:55 PM, Ethan Grammatikidis wrote:
On 13 Apr 2010, at 06:20, EBo wrote:
Skip Tavakkolian 9...@9netics.com said:
but both
of the hard-coded paths in 9vx main.c are obviously in RSC's home
directories
it's not
Just to add more complications ;)
Did you choose the word complications because in watchmaking it
denotes extra (and often near-pointless) features? :D
Those watches are amazing!
Speaking for simplicity, the first time I saw the Salisbury cathedral clock
But the world isn't Linux.
http://www.freebsd.org/cgi/man.cgi?query=hiersektion=7
I never said it was, but if you look at FeeBSD's /usr/local you will also see
they are in agreement.
EBo --
2010/4/15 EBo e...@sandien.com:
Define reasonable. For me, that’s just 1 single spot. But it seems
the Linux people are very insistent on Freedom meaning do what you
want, even if it's against the build suggestions.
I say stick to one hardcoded path, and make everyone else stop doing
it
On 04/15/2010 03:46 PM, Ethan Grammatikidis wrote:
On 15 Apr 2010, at 09:44, Balwinder S Dheeman wrote:
On 04/14/2010 09:55 PM, Ethan Grammatikidis wrote:
I don't usually like to say why bother, but given 9vx could be
launched with the appropriate parameter from a 2 line shell script
Plan 9 is not trying to be compatible to linux.
While some people make life on earth as exciting as possible, others
are trying to fly to Mars.
On 4/15/10, Balwinder S Dheeman bsd.sans...@cto.homelinux.net wrote:
On 04/15/2010 03:46 PM, Ethan Grammatikidis wrote:
On 15 Apr 2010, at 09:44,
Clearly, this calls for an XML-based configuration file, setting the
environment of each program at startup by patching gnulibc.
I didn't have the energy to make a forced acronym for `bloat', so let's just
assume I did and that I suggested the configuration files live in /etc/bloat,
ok?
*Chad
On Thu Apr 15 12:53:57 EDT 2010, yand...@mit.edu wrote:
Clearly, this calls for an XML-based configuration file, setting the
environment of each program at startup by patching gnulibc.
I didn't have the energy to make a forced acronym for `bloat', so let's just
assume I did and that I
On 13 Apr 2010, at 06:20, EBo wrote:
Skip Tavakkolian 9...@9netics.com said:
but both
of the hard-coded paths in 9vx main.c are obviously in RSC's home
directories
it's not hardcoded;
What? The findroot code reads:
static char*
findroot(void)
{
static char cwd[1024];
I don't usually like to say why bother, but given 9vx could be
launched with the appropriate parameter from a 2 line shell script
(including the #!), why are you even debating this?
wow... I can understand people not liking checking the environmental
variables as it does increase the
the point is that any default is bound to be wrong. my guess is that
'/home/rsc/...' default was introduced early in the development and
before '-r' was added. it might be more useful to lobby for a default
location like '/usr/lib/9vx'.
secondly writing
$ NINEROOT=/usr/ebo/9vxroot 9vx
What? The findroot code reads:
read the code again; findroot doesn't come into play.
it most certainly does!
the whole point was that given -r, findroot doesn't come into play.
if NINEROOT is not set, what does your version of 9vx do (without -r)?
What? The findroot code reads:
read the code again; findroot doesn't come into play.
it most certainly does!
the whole point was that given -r, findroot doesn't come into play.
if NINEROOT is not set, what does your version of 9vx do (without -r)?
In short it fails with the
you could also use a script to call 9vx as you please.
On Mon, Apr 12, 2010 at 5:22 AM, EBo e...@sandien.com wrote:
Why isn't 9vx -r yourdir good enough?
it is if you want to force all users to specify the root directory every
single time they run 9vx, or if you want to use an alternative
Francisco J Ballesteros n...@lsub.org said:
you could also use a script to call 9vx as you please.
That is what I did for the first prototype. I thought this would be a beeter
solution.
Out of curiosity, have I hit a nerve or something. Have I somehow offended?
I'm just a bit confused by
Skip Tavakkolian 9...@9netics.com said:
but both
of the hard-coded paths in 9vx main.c are obviously in RSC's home
directories
it's not hardcoded;
What? The findroot code reads:
static char*
findroot(void)
{
static char cwd[1024];
int i;
char buf[1024];
What? The findroot code reads:
read the code again; findroot doesn't come into play.
The following is a little patch to 9vx which uses getenv to read the
environmental variable PLAN9 to set plan 9 root on startup if it has not
been overloaded on the command line or in the CWD. I would enjoy any feedback.
Best regards,
EBo --
recommend using a different environment variable
other than PLAN9, since that is taken by p9p to mean
something else.
- erik
201 - 300 of 556 matches
Mail list logo
