Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 714 - nmh /usr/bin/mh link can be wrong
Summary: nmh /usr/bin/mh link can be wrong
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: nmh
Version: 5.2
Hardware: i386
OS: Linux
low
medium
Target Milestone: ---
Assignee: David Lawrence
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-01-06 18:09 UTC by Steve Wills
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 1999-01-06 18:43:56 UTC


Attachments (Terms of Use)

Description Steve Wills 1999-01-06 18:09:05 UTC
in /usr/bin/  the file "mh" is an symlink to .

so doing a `ls m*` shows the entire directory.

This is in the install scripts for nmh...

[alikins@grimlock alikins]$ rpm -q --scripts nmh
postinstall script (through /bin/sh):
if [ ! -d /usr/bin/mh -a ! -L /usr/bin/mh ] ; then
    ln -s . /usr/bin/mh
fi
if [ ! -d /usr/lib/mh -a ! -L /usr/lib/mh ] ; then
    ln -s nmh /usr/lib/mh
fi
preuninstall script (through /bin/sh):
[ ! -L /usr/bin/mh ] || rm -f /usr/bin/mh
[ ! -L /usr/lib/mh ] || rm -f /usr/lib/mh


I havent a clue what the first chunk of that is trying to
do, suppose its trying to link /usr/bin/mh to something in
/usr/lib/nmh.

Comment 1 Jeff Johnson 1999-01-06 18:43:59 UTC
nmh and exmh go to great lengths (using triggers) to insure
that the symlink /usr/bin/mh is correct. If there is a problem,
please reopen the bug with more specific details. You probably should
look at what happens to /usr/bin/mh and /usr/lib/mh when exmh and/or
nmh are installed/updated separately and/or together in order to
identify the circumstances where the symlink is incorrect.

Comment 2 Steve Wills 1999-01-18 20:25:59 UTC
Here are some more comments on this from Adrian:

        The symlinks is bad when nmh and exmh are isntalled (on my
system here ( a everythign install), my home system (a custom with
both), crashes system (custom with nmh and exmh).

        Further more: after removing exmh and nmh, the link is gone.

        With just nmh:

[root@grimlock RPMS]# ls -al /usr/bin/mh
lrwxrwxrwx   1 root     root            1 Jan  6 16:39 /usr/bin/mh ->
.

[root@grimlock RPMS]# rpm -Uvh exmh*
exmh
##################################################
[root@grimlock RPMS]# ls -al /usr/bin/mh
lrwxrwxrwx   1 root     root            1 Jan  6 16:39 /usr/bin/mh ->
.


        The link is made by the nmh install scripts, I dont see how
having exmh installed makes a difference. Exmh does nt run any
scripts.

I havent a clue why having mh -> . would ever be useful for any
reason. And even if it were, it still seems broken.

The script seem to test if the dir or symlink "/usr/bin/mh" doesnt
exist, then make the silly symlink. Then does the same thign again
before creating the useful link (to nmh...) but of course, its always
going to be a symlink then it seems.

I dunno, but it seems broken on fresh full installs...

Of course, --triggers doesnt seem to show the triggers for the rpms
as the man page and --helps suggests it would, but i suppose thats
another issue.


Note You need to log in before you can comment on or make changes to this bug.