Re: [9fans] 9vx patch to read environment var PLAN9

Re: [9fans] 9vx patch to read environment var PLAN9

[Chad Brown]

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

Re: [9fans] 9vx patch to read environment var PLAN9

[erik quanstrom]

On Thu Apr 15 12:53:57 EDT 2010, yandros@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 suggested the configuration files live in /etc/bloat, ok?

while this thread is a bit chatty, i think the issues
here have been reasonablly and thoroughly discussed.
there's nothing to add outside of trolling.

- erik

Re: [9fans] 9vx patch to read environment var PLAN9

[erik quanstrom]

> > 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 in
a unix world, it has not been the tradition for such tools
to get overly compunctious about toeing the "standard"
line.  there isn't much agreement what the standards are,
and they change too often.

- erik

Re: [9fans] 9vx patch to read environment var PLAN9

[hiro]

Your point is valid. Back to work...

On 4/16/10, Ethan Grammatikidis <eekee57@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"
>> (http://werc.homelinux.net/links/reference_material/unix_prog_design.pdf
>> );
>> these notes are still valid today and are applicable to Plan9
>> environment also :)
>
> I don't understand why you're bringing this up. Does my reply to hiro
> answer this too?
>
> --
> Simplicity does not precede complexity, but follows it. -- Alan Perlis
>
>
>

Re: [9fans] 9vx patch to read environment var PLAN9

[Ethan Grammatikidis]

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 applicable to Plan9
> environment also :)

I don't understand why you're bringing this up. Does my reply to hiro  
answer this too?

-- 
Simplicity does not precede complexity, but follows it. -- Alan Perlis

Re: [9fans] 9vx patch to read environment var PLAN9

[Ethan Grammatikidis]

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 it. -- Alan Perlis

Re: [9fans] 9vx patch to read environment var PLAN9

[hiro]

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.SANSPAM@cto.homelinux.net> wrote:
> 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
>>>> (including the #!), why are you even debating this?
>>>
>>> Just to add more complications ;)
>>
>> Did you choose the word "complications" because in watchmaking it
>> denotes extra (and often near-pointless) features? :D
>>
>> In the minute space within a wristwatch complications are wonderful
>> things, particularly when the whole watch is mechanical, but in a
>> computer... A computer is a working machine, a mechanical wristwatch
>> today is first and foremost art.
>>
>> Speaking of watches, I can't resist sharing these for those who have
>> time to waste:
>> http://watchismo.blogspot.com/2010/03/hodinkee-shares-baselworld-videos-of.html
>>
>> http://watchismo.blogspot.com/2010/03/rebellion-t-1000-vertical-roller.html
>> http://watchismo.blogspot.com/2010/03/4n-mvt01-four-numbers-disc-watch-by.html
>>
>>
>> I wonder if anything is signified by the seeming inability of the
>> watchmaking fraternity to make a simple website? MB&F are about the most
>> seminal group in the field, but they use flash for a very simple menu:
>> http://www.mbandf.com/
>
> 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 applicable to Plan9
> environment also :)
>
> --
> Balwinder S "bdheeman" Dheeman        Registered Linux User: #229709
> Anu'z Linux@HOME (Unix Shoppe)        Machines: #168573, 170593, 259192
> Chandigarh, UT, 160062, India         Plan9, T2, Arch/Debian/FreeBSD/XP
> Home: http://werc.homelinux.net/      Visit: http://counter.li.org/
>
>

Re: [9fans] 9vx patch to read environment var PLAN9

[Balwinder S Dheeman]

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
>>> (including the #!), why are you even debating this?
>>
>> Just to add more complications ;)
>
> Did you choose the word "complications" because in watchmaking it
> denotes extra (and often near-pointless) features? :D
>
> In the minute space within a wristwatch complications are wonderful
> things, particularly when the whole watch is mechanical, but in a
> computer... A computer is a working machine, a mechanical wristwatch
> today is first and foremost art.
>
> Speaking of watches, I can't resist sharing these for those who have
> time to waste:
> http://watchismo.blogspot.com/2010/03/hodinkee-shares-baselworld-videos-of.html
>
> http://watchismo.blogspot.com/2010/03/rebellion-t-1000-vertical-roller.html
> http://watchismo.blogspot.com/2010/03/4n-mvt01-four-numbers-disc-watch-by.html
>
>
> I wonder if anything is signified by the seeming inability of the
> watchmaking fraternity to make a simple website? MB&F are about the most
> seminal group in the field, but they use flash for a very simple menu:
> http://www.mbandf.com/

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 applicable to Plan9
environment also :)

--
Balwinder S "bdheeman" Dheeman        Registered Linux User: #229709
Anu'z Linux@HOME (Unix Shoppe)        Machines: #168573, 170593, 259192
Chandigarh, UT, 160062, India         Plan9, T2, Arch/Debian/FreeBSD/XP
Home: http://werc.homelinux.net/      Visit: http://counter.li.org/

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

> But the world isn't Linux.
> http://www.freebsd.org/cgi/man.cgi?query=hier&sektion=7

I never said it was, but if you look at FeeBSD's /usr/local you will also see
they are in agreement.

  EBo --

Re: [9fans] 9vx patch to read environment var PLAN9

[Devon H. O'Dell]

2010/4/15 EBo <ebo@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 their own way, and stick to one simple, consistent solution.
>
> Two possible guides are:
>
> Linux Standard Base <http://www.linuxfoundation.org/collaborate/workgroups/lsb>
>
> and
>
> Filesystem Hierarchy Standard <http://proton.pathname.com/fhs/>

But the world isn't Linux.
http://www.freebsd.org/cgi/man.cgi?query=hier&sektion=7

--dho

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

> > 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
<http://en.wikipedia.org/wiki/Salisbury_cathedral_clock> I wanted to go out
and build one.  So, if you know anyone with dimensional drawings I should soon
have my forge up and running again ;-)

  EBo --

Re: [9fans] 9vx patch to read environment var PLAN9

[Ethan Grammatikidis]

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 <9nut@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];
>>>    char *dir[] = {
>>>        cwd,
>>
>> 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?
>
>
> Just to add more complications ;)

Did you choose the word "complications" because in watchmaking it
denotes extra (and often near-pointless) features? :D

In the minute space within a wristwatch complications are wonderful
things, particularly when the whole watch is mechanical, but in a
computer... A computer is a working machine, a mechanical wristwatch
today is first and foremost art.

Speaking of watches, I can't resist sharing these for those who have
time to waste:
http://watchismo.blogspot.com/2010/03/hodinkee-shares-baselworld-videos-of.html
http://watchismo.blogspot.com/2010/03/rebellion-t-1000-vertical-roller.html
http://watchismo.blogspot.com/2010/03/4n-mvt01-four-numbers-disc-watch-by.html

I wonder if anything is signified by the seeming inability of the
watchmaking fraternity to make a simple website? MB&F are about the
most seminal group in the field, but they use flash for a very simple
menu: http://www.mbandf.com/

>
> --
> Balwinder S "bdheeman" Dheeman        Registered Linux User: #229709
> Anu'z Linux@HOME (Unix Shoppe)        Machines: #168573, 170593,
> 259192
> Chandigarh, UT, 160062, India         Plan9, T2, Arch/Debian/FreeBSD/
> XP
> Home: http://werc.homelinux.net/      Visit: http://counter.li.org/
>

--
Simplicity does not precede complexity, but follows it. -- Alan Perlis

Re: [9fans] 9vx patch to read environment var PLAN9

[Ethan Grammatikidis]

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 their own way, and stick to one simple, consistent solution.
>
> Two possible guides are:
>
> Linux Standard Base <http://www.linuxfoundation.org/collaborate/workgroups/lsb 
> >
>
> and
>
> Filesystem Hierarchy Standard <http://proton.pathname.com/fhs/>

I deliberately avoided referring to these two... _interesting_  
documents. I studied the FHS at some length some years ago, not the  
latest version but the one before. As I understood it, it provides no  
possible place for a 9vx tree, for a plan9port tree, for a GNUStep  
tree, in short, for anything which does not conform precisely to the  
same layout of directories it specifies for /usr. The requirements  
for /opt at least have been softened in the latest version, so that a  
distro could 'legitimately' install 9vx or p9p under /opt, but I doubt  
it could be put anywhere else.

I won't comment on the LSB except to say that between the way Linux  
has been going lately and the almost perversely obsolete document the  
LSB was the last time I looked at it, I don't really want to know  
anything about it, least of all if it's been brought up to date.

I deliberately used the phrase "commonly used" in my earlier email  
because at the end of the day that's the only useful guide. In any  
case these standards are only made by taking common use and  
constraining it within (sometimes perverse) reasoning.

-- 
Simplicity does not precede complexity, but follows it. -- Alan Perlis

Re: [9fans] 9vx patch to read environment var PLAN9

[Balwinder S Dheeman]

On 04/14/2010 09:55 PM, Ethan Grammatikidis wrote:
>
> On 13 Apr 2010, at 06:20, EBo wrote:
>
>> Skip Tavakkolian <9nut@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];
>>     char *dir[] = {
>>         cwd,
>
> 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?


Just to add more complications ;)

--
Balwinder S "bdheeman" Dheeman        Registered Linux User: #229709
Anu'z Linux@HOME (Unix Shoppe)        Machines: #168573, 170593, 259192
Chandigarh, UT, 160062, India         Plan9, T2, Arch/Debian/FreeBSD/XP
Home: http://werc.homelinux.net/      Visit: http://counter.li.org/

Re: [9fans] 9vx patch to read environment var PLAN9

[Ethan Grammatikidis]

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 Linux
distribution, an additional file in each of /etc/profile.d, /etc/
zprofile.d, /etc/cshlogin.d (or whatever they call it) and etc. for
each shell the user might possibly want.

Then there's the matter of users who commit the heinous crime of
preferring a display manager over startx, which raises questions over
when where or even _if_ system-wide environment variables will be set
at all. Display managers are still the truculent beasts they were 10
years ago.

Then too there's the possibility that some poor [l]user will get the
notion that the environment variable is the right way to set the
parameter, and get in a muddle when half his open xterms (that he's
had open for the past month) still have the old setting. Better to let
him write a script, at least he can stick it in ~/bin. (Yes, it
happened to me, more than once, and rather converted me to wrapper
scripts.)

If some distro wants to stick a default 9vx tree in some _really_
weird place, let them patch the source!

--
Simplicity does not precede complexity, but follows it. -- Alan Perlis

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 527 bytes --]


> 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 their own way, and stick to one simple, consistent solution.

Two possible guides are:

Linux Standard Base <http://www.linuxfoundation.org/collaborate/workgroups/lsb>

and

Filesystem Hierarchy Standard <http://proton.pathname.com/fhs/>

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

> I don't mind adding more directories to the list in findroot,
> and something like /usr/local/9vx is certainly a better entry
> in that list than /home/rsc/plan9/4e (sorry).

no apologies necessary.  I actually liked Ethan Grammatikidis' last comments
regarding adding standard the standard locations.

> What I didn't understand was the rationale behind putting
> in a new environment variable when there is already a
> command-line option.  The argument about being right
> for the users is bogus: the amount of work required to
> make all users have the right environment variable setting
> is about the same as the amount of work required to
> make all users pass the right -r flag.

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.  If writing a shell script
around the exe is considered a better way to go about it then I'm good with it.

  EBo --

Re: [9fans] 9vx patch to read environment var PLAN9

[Russ Cox]

I don't mind adding more directories to the list in findroot,
and something like /usr/local/9vx is certainly a better entry
in that list than /home/rsc/plan9/4e (sorry).

What I didn't understand was the rationale behind putting
in a new environment variable when there is already a
command-line option.  The argument about being right
for the users is bogus: the amount of work required to
make all users have the right environment variable setting
is about the same as the amount of work required to
make all users pass the right -r flag.

Russ

Re: [9fans] 9vx patch to read environment var PLAN9

[Patrick Kelly]

> I'm not so sure about /usr/lib or /usr/share. I'd tolerate both (I've stopped caring about the unix filesystem hierarchy), but speaking as
> a long-time Linux user they don't feel right, especially not /usr/share.
> If you do put them in they probably won't draw any trouble as just hard-coded paths hidden in the source.
> 
> Is there any harm in putting in as many hard-coded paths in as might be reasonable?

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 their own way, and stick to one simple, consistent solution.

Re: [9fans] 9vx patch to read environment var PLAN9

[Ethan Grammatikidis]

On 14 Apr 2010, at 19:38, EBo wrote:

>
>> hardcode your own path and let the next sucker repeat the story
>
> fair enough, and now for the heart of the question that I have been
> dancing
> around all along (actually I thought it was obvious) -- what is the
> best way
> to fix this section of code so that we can be done with it once and
> for all?
> Remove all hard coded paths and require -r and startup from root
> dir?  ok.
> add the env variable?  ok.  do whatever I am going to do and never
> post my
> patches to start another flame drizzle (as compared to an all out
> flame war)?
> So, what's to be done?

Watching yet another 'flame drizzle' (good term, btw) is precisely
what made me grumpy, sorry about that. I get really tired of watching
them but don't do any good when I get involved, so I don't know what
to do really. Perhaps if I only comment if I can think of something
positive.

If I do have a constructive comment on this subject, I can't see any
harm in adding both /usr/local/9vx and /opt/9vx to the hard-coded
paths as these are paths on the host system, not plan 9, and thus
*shouldn't* start up that old debate again. I think /usr/local and /
opt are both commonly used for odd binary trees, P9p being a prime
example with build instructions suggesting /usr/local/plan9 and more
than one Linux distro choosing /opt/plan9.

I'm not so sure about /usr/lib or /usr/share. I'd tolerate both (I've
stopped caring about the unix filesystem hierarchy), but speaking as a
long-time Linux user they don't feel right, especially not /usr/share.
If you do put them in they probably won't draw any trouble as just
hard-coded paths hidden in the source.

Is there any harm in putting in as many hard-coded paths in as might
be reasonable?

--
Simplicity does not precede complexity, but follows it. -- Alan Perlis

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

> 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
>
> is less pleasant than:
>
> $ 9vx -r /usr/ebo/9vxroot
>
> it's true that NINEROOT can be set and forgotten about, but the same
> argument could be made for writing a shell function that aliases 9vx
> to '9vx -r ...' etc -- and probably in the same place, e.g. .profile.

excellent, some constructive feedback, and thank all of you who have done so.

We already have -r so that we can either alias 9vx, or write a two line
wrapper as also previously suggested.

Now lets debate if there should be any hard coded paths in the program.  Where
are the most appropraite locations?  We could of course open up the /opt
/usr/local debate again, but there is also putting it into /usr/share/9vx and
/usr/lib/9vx as suggested. We could hash out what is suggested with the Linux
Standard Base, or throw the whole thing out the window.

What I have decided to do for my current work is to put it in /usr/local.
Why?  I am working on Tvx, and their standard install is in /usr/local/${package}

I'll take consensus on the NINEROOT and ${home}/ if people do not mind that
complexity.

  EBo --

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

> relax.  it is unfortunte that there's too much resistance
> to improving on the initial cut.

Don't worry I'm relaxed, just seriously amazed and trying to figure this out.

The issue that will eventually stress me out however is the fact that these
discussions have hamstrung my productivity to probably less than 10% my
normal.  Learning the plan9 way is so far more than worth it, and I hope it
will continue to be.

  EBo --

Re: [9fans] 9vx patch to read environment var PLAN9

[Skip Tavakkolian]

>> 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 complexity, but I would have thought that
> changing the default lookup from /home/rcs... would not have been a problem.
> I guess I was wrong about that.

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

is less pleasant than:

$ 9vx -r /usr/ebo/9vxroot

it's true that NINEROOT can be set and forgotten about, but the same
argument could be made for writing a shell function that aliases 9vx
to '9vx -r ...' etc -- and probably in the same place, e.g. .profile.

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

> hardcode your own path and let the next sucker repeat the story

fair enough, and now for the heart of the question that I have been dancing
around all along (actually I thought it was obvious) -- what is the best way
to fix this section of code so that we can be done with it once and for all?
Remove all hard coded paths and require -r and startup from root dir?  ok.
add the env variable?  ok.  do whatever I am going to do and never post my
patches to start another flame drizzle (as compared to an all out flame war)?
 So, what's to be done?

Re: [9fans] 9vx patch to read environment var PLAN9

[erik quanstrom]

> > 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 complexity, but I would have thought that
> changing the default lookup from /home/rcs... would not have been a problem.
> I guess I was wrong about that.

relax.  it is unfortunte that there's too much resistance
to improving on the initial cut.

- erik

Re: [9fans] 9vx patch to read environment var PLAN9

[lucio]

> hardcode your own path and let the next sucker repeat the story

I dunno, it would seem to me that the sequence:

	-r option? yes: use argument
		no: $NINEROOT set? yes: use value
			no: use $HOME/9vx (or somesuch)

would be pretty much acceptable.  I guess if there is no $HOME (or
$home, I don't see much point arguing over that, try both if you feel
that way inclined) one can use /usr/rsc or /home/rcs, but that seems a
bit outlandish.

++L

Re: [9fans] 9vx patch to read environment var PLAN9

[Federico G. Benavento]

hardcode your own path and let the next sucker repeat the story

On Wed, Apr 14, 2010 at 3:10 PM, EBo <ebo@sandien.com> 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
>> (including the #!), why are you even debating this?
>
> wow...  I can understand people not liking checking the environmental
> variables as it does increase the complexity, but I would have thought that
> changing the default lookup from /home/rcs... would not have been a problem.
> I guess I was wrong about that.
>
>



-- 
Federico G. Benavento

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

> 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 complexity, but I would have thought that
changing the default lookup from /home/rcs... would not have been a problem.
I guess I was wrong about that.

Re: [9fans] 9vx patch to read environment var PLAN9

[Ethan Grammatikidis]

On 13 Apr 2010, at 06:20, EBo wrote:

> Skip Tavakkolian <9nut@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];
> 	char *dir[] = {
> 		cwd,

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?

--
Simplicity does not precede complexity, but follows it. -- Alan Perlis

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

> >> > 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 error "cannot find plan 9 root; use -r"

Here is the specific sequence:

  If the 9vx invocation is in the root directory use `cwd`

    -> here is where I checked for NINEROOT

  try "/Users/rsc/9vx"

  try "/home/rsc/plan9/4e"

  fail with error "cannot find plan 9 root; use -r"


  EBo --

Re: [9fans] 9vx patch to read environment var PLAN9

[Skip Tavakkolian]

>> > 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)?

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

Skip Tavakkolian <9nut@9netics.com> said:

> > What?  The findroot code reads:
>
> read the code again; findroot doesn't come into play.

it most certainly does!

in main...

	if(!bootboot){
		if(localroot == nil && (localroot = findroot()) == nil)
			panic("cannot find plan 9 root; use -r");

So, if you do not specify localroot (via -r) then it uses findroot.  Findroot
first checks the cwd, and then two hardcoded paths.  This means that unless
the program is run from the 9vx's associated Plan 9 root, or the programs were
installed in "/Users/rsc/9vx" or "/home/rsc/plan9/4e", then you are requiring
all users on a system to run 9vx with -r and know where that root is always.

Is it unreasonable to expect that an invocation of "9vx" to actually run?

  EBo --

Re: [9fans] 9vx patch to read environment var PLAN9

[Skip Tavakkolian]

> What?  The findroot code reads:

read the code again; findroot doesn't come into play.

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

Skip Tavakkolian <9nut@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];
	char *dir[] = {
		cwd,
		"/Users/rsc/9vx",
		"/home/rsc/plan9/4e"
	};

	if(getcwd(cwd, sizeof cwd) == nil){
		oserrstr();
		panic("getcwd: %r");
	}

	for(i=0; i<nelem(dir); i++){
		snprint(buf, sizeof buf, "%s/386/bin/rc", dir[i]);
		if(access(buf, 0) >= 0)
			return dir[i];
	}
	return nil;
}

"/Users/rsc/9vx","/home/rsc/plan9/4e" are most certainly hard coded locations,
and will likely only be default on rsc's machines.

> you can use -r as Russ said.  the difference is:
> "use default unless -r is given" vs.  "use default unless
> getenv(NINEROOT) is given".  -r makes it very obvious what the root is
> and probably will work better for un-unix-like environments.

Put another way, what are the default locations?

Also, it would probably be "use default unless getenv(NINEROOT) or -r is
given".  Also, getenv works on Windoz.  What un-unix-like environments are you
referring to?

> but at any rate, you have the sources and are free to change things
> locally to suit your taste.

true, but will these patches be accepted upstream?  If I was looking to just
build this for myself I would not be bothering any of you, I'm trying to
figure out what would be useful to include upstream.  I guess I should not
have posted this to the list, but simply taken it up with Russ off-list since
it is his code.

  EBo --

Re: [9fans] 9vx patch to read environment var PLAN9

[Skip Tavakkolian]

> but both
> of the hard-coded paths in 9vx main.c are obviously in RSC's home directories

it's not hardcoded; you can use -r as Russ said.  the difference is:
"use default unless -r is given" vs.  "use default unless
getenv(NINEROOT) is given".  -r makes it very obvious what the root is
and probably will work better for un-unix-like environments.

but at any rate, you have the sources and are free to change things
locally to suit your taste.

Re: [9fans] 9vx patch to read environment var PLAN9

[erik quanstrom]

> 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 some of the responses.

no.  i don't think anyone's offended.  and i personally
think the env variable is fine.

but i can see the objection to complication.

if i were you, the question i'd why have a list of
hardcoded roots at all?  none are even in the
user's home directory.

- erik

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1303 bytes --]

Francisco J Ballesteros <nemo@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 some of the responses.

I could easily understand the reluctance if there are some standardization
issues with getenv on the targeted platforms I do not know about.  I could
also understand if I was proposing to put it in some weird location, but both
of the hard-coded paths in 9vx main.c are obviously in RSC's home directories
and not more generic locations like /home/9vx, $home/9vx, /usr/local/9vx, /opt...

  EBo --


> On Mon, Apr 12, 2010 at 5:22 AM, EBo <ebo@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 root.  If
I use
> > a standard install locations then we can either change "/Users/rsc/9vx" and
> > "/home/rsc/plan9/4e" or I can simply run a sed script during the build phase.
> >  Setting up a $root9vx (what I have changed it to) seemed the cleanest
approach.
> >
> >  EBo --

Re: [9fans] 9vx patch to read environment var PLAN9

[Francisco J Ballesteros]

you could also use a script to call 9vx as you please.



On Mon, Apr 12, 2010 at 5:22 AM, EBo <ebo@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 root.  If I use
> a standard install locations then we can either change "/Users/rsc/9vx" and
> "/home/rsc/plan9/4e" or I can simply run a sed script during the build phase.
>  Setting up a $root9vx (what I have changed it to) seemed the cleanest approach.
>
>  EBo --
>
>
>
>

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

> 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 root.  If I use
a standard install locations then we can either change "/Users/rsc/9vx" and
"/home/rsc/plan9/4e" or I can simply run a sed script during the build phase.
 Setting up a $root9vx (what I have changed it to) seemed the cleanest approach.

  EBo --

Re: [9fans] 9vx patch to read environment var PLAN9

[Russ Cox]

Why isn't 9vx -r yourdir good enough?

Russ

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 211 bytes --]


> I was going to suggest that, but you can't start env. var. names with
> numbers in many shells.

That's why I named it vx9root (not to screem).  ;-)

> > and there's no reason to shout. �:-)

Re: [9fans] 9vx patch to read environment var PLAN9

[erik quanstrom]

> I was going to suggest that, but you can't start env. var. names with
> numbers in many shells.

i'd forgotten about that.  unix really has gotten
crunchy.

- erik

Re: [9fans] 9vx patch to read environment var PLAN9

[Devon H. O'Dell]

2010/4/11 erik quanstrom <quanstro@quanstro.net>:
>> Agreed. PLAN9ROOT seems good.
>
> suggest 9vxroot instead.  there are enough plan9y
> things floating around that it makes sense to me
> to specify which plan9y root you're talking about.

I was going to suggest that, but you can't start env. var. names with
numbers in many shells.

--dho

> and there's no reason to shout.  :-)
>
> - erik
>
>

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]

Got it!  Changed.  I'll also change it along the lines of Erik's suggestion.

As a note, I thought that 9vx ran on top of the p9p stuff.

  Thanks again,

  EBo --


"Devon H. O'Dell" <devon.odell@gmail.com> said:

> 2010/4/11 EBo <ebo@sandien.com>:
> > I thought p9p uses it for the root of the Plan 9 tree? �At least that is what
> > the ebuilds imply. �Maybe I am using the wrong term for what PLAN9 points to.
>
> That's true, but in the case of 9vx, the tree it points to contains
> actual plan 9 binaries, whereas p9p binaries are compiled for the host
> system. Since it is very feasible that someone may run p9p and 9vx on
> the same machine (I do, for instance), it would be a good idea to not
> overload the env var.
>
> --dho
>
> > �EBo --
> >
> >
> > erik quanstrom <quanstro@quanstro.net> said:
> >
> >> recommend using a different environment variable
> >> other than PLAN9, since that is taken by p9p to mean
> >> something else.
> >>
> >> - erik
> >>
> >
> >
> >
> > --
> >
> >
> >
> >
> >
>



--

Re: [9fans] 9vx patch to read environment var PLAN9

[Devon H. O'Dell]

2010/4/11 EBo <ebo@sandien.com>:
> I thought p9p uses it for the root of the Plan 9 tree?  At least that is what
> the ebuilds imply.  Maybe I am using the wrong term for what PLAN9 points to.

That's true, but in the case of 9vx, the tree it points to contains
actual plan 9 binaries, whereas p9p binaries are compiled for the host
system. Since it is very feasible that someone may run p9p and 9vx on
the same machine (I do, for instance), it would be a good idea to not
overload the env var.

--dho

>  EBo --
>
>
> erik quanstrom <quanstro@quanstro.net> said:
>
>> recommend using a different environment variable
>> other than PLAN9, since that is taken by p9p to mean
>> something else.
>>
>> - erik
>>
>
>
>
> --
>
>
>
>
>

Re: [9fans] 9vx patch to read environment var PLAN9

[EBo]

I thought p9p uses it for the root of the Plan 9 tree?  At least that is what
the ebuilds imply.  Maybe I am using the wrong term for what PLAN9 points to.

  EBo --


erik quanstrom <quanstro@quanstro.net> said:

> recommend using a different environment variable
> other than PLAN9, since that is taken by p9p to mean
> something else.
>
> - erik
>



--

Re: [9fans] 9vx patch to read environment var PLAN9

[erik quanstrom]

> Agreed. PLAN9ROOT seems good.

suggest 9vxroot instead.  there are enough plan9y
things floating around that it makes sense to me
to specify which plan9y root you're talking about.

and there's no reason to shout.  :-)

- erik

Re: [9fans] 9vx patch to read environment var PLAN9

[Devon H. O'Dell]

2010/4/11 erik quanstrom <quanstro@quanstro.net>:
> recommend using a different environment variable
> other than PLAN9, since that is taken by p9p to mean
> something else.

Agreed. PLAN9ROOT seems good.

--dho

> - erik
>
>

Re: [9fans] 9vx patch to read environment var PLAN9

[erik quanstrom]

recommend using a different environment variable
other than PLAN9, since that is taken by p9p to mean
something else.

- erik

[9fans] 9vx patch to read environment var PLAN9

[EBo]

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 --

=====================================================================

diff -r 8184025094f4 src/9vx/main.c
--- a/src/9vx/main.c    Mon Oct 05 02:53:41 2009 -0400
+++ b/src/9vx/main.c    Sun Apr 11 11:59:03 2010 -0500
@@ -10,6 +10,8 @@

 #include       "u.h"
 #include       "libvx32/vx32.h"
+#include       <stdlib.h>
+#include       <string.h>
 #include       <sys/mman.h>
 #include       <signal.h>
 #include       <pwd.h>
@@ -224,12 +226,13 @@
 findroot(void)
 {
        static char cwd[1024];
+       static char plan9[1024];
        int i;
        char buf[1024];
        char *dir[] = {
                cwd,
-               "/Users/rsc/9vx",
-               "/home/rsc/plan9/4e"
+               plan9,
+               "/usr/local/plan9"
        };

        if(getcwd(cwd, sizeof cwd) == nil){
@@ -237,6 +240,9 @@
                panic("getcwd: %r");
        }

+       if(getenv("PLAN9") != nil)
+               strncpy(plan9, getenv("PLAN9"), sizeof plan9);
+
        for(i=0; i<nelem(dir); i++){
                snprint(buf, sizeof buf, "%s/386/bin/rc", dir[i]);
                if(access(buf, 0) >= 0)