Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Strange Tree




christoph remarked:
| > On Mon, 2 Aug 1999 Chris DiTrani <cditrani at ne.mediaone.net> wrote:
| > 
| > /usr/bin/mh is a symlink to ".", which makes /usr/bin/mh a reference to
| > /usr/bin. The behavior you're seeing is a natural side effect of this.
| > 
| > /usr/bin/mh is the original installation directory for the Rand MH, and
| > some third-party tools depended on it; hence the symlink to maintain
| > backwards compatibility.

| In my opinion, this is a silly hack.  If RedHat builds the packages from
| source, they should be able to control things better than this.

| A few years back, this type of recusive linking provided endless headaches
| when used with tar, find & cpio, and even worse was the unix-unaware vender
| that ported crummy code.

Also, putting all the components of a package like mh  into  /usr/bin
isn't all that wise an idea.  This is an invitation to having package
X stomp on package Y by "accidentally" installing an executable  with
the same name as one of Y's executables.  For a package with only one
executable, this isn't much of a problem, but for a package  like  mh
with  a  whole  flock of executables, it is a recipe for disaster and
finger pointing and user bafflement.

A much better approach would be to install such complex packages into
their  own  directories,  as is conventionally done with X11 (and was
done with the original mh). Users who need to directly exec pieces of
the  package  will  need  to  be  told what to add to their $PATH, of
course, or a startup script could do it for them. But this isn't much
of  a  constraint,  and  is  much  easier to deal with than trying to
diagnose problems with one package overwriting another's executables.

I'm reminded of the many months it took me to get ghostview  to  work
properly. For the longest time, it just gave me bizarre error windows
with incomprehensible error messages.  I finally discovered that  the
problem  was  another  package  I'd  installed that had an executable
called "gs", which had wiped out  ghostview's  program  by  the  same
name.  I re-installed both of them into different directories (from a
non-su account so that they couldn't install their pieces  into  /bin
or  /usr/bin),  and  wrapped  their main commands in scripts that put
their own directories at the head of $PATH, and they both work now.


--
Modern GUIs are very well designed, for people with three hands. The
real problem has been how slow customers have been to make necessary
hardware upgrades to meet the requirements of the software.
-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org