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
