Well, not all the time.
If I have netscape already running and then run up2date as
myself (entering the root password), the netscape step will
open up the proper page, but it appears to do it by telling
my already existing copy of netscape (running as "eric"
instead of "root") to open a window. Therefore when I click
either submit button, I get a save dialog. This seems to
happen whether I run up2date as "eric" or when I run up2date
as "root" inside of an "eric" X session.
If I exit netscape first, it works fine, since a new copy
running as root is fired up. If I start up an X session as
root and run it then, up2date works fine.
I tried a workaround of placing this in my own .mailcap:
application/redhat-package-list;/usr/sbin/up2date -p %s
But I just get an error that up2date must be run as root.
(Clearly, simply not having netscape already running is an
easy workaround. But it seems to me that the mailcap entry
should be more global and that up2date should do something
like ask for the root password when run with the -p option,
instead of simply informing me that it must be run as root.)
Remove /root/.netscape/lock before running up2date should fix
the problem. It sees the stale lock file from a previous
run of netscape by root, and so tries to send a command to
the currently running netscape.
That does temporarily fix the problem.
However, if I run netscape as root and exit normally, there is no lock
file. Consistently, if I run up2date, when it runs netscape, there is
a lock file left behind.
I'd like to suggest 2 things:
1) figure out why the lock file gets erroneously left behind and fix
2) Instead of just checking for a lockfile, check for a lockfile, and
if it's found look at the information and determine if it's stale.
netscape has been modified for 6.2 to check the lockfile's validity before
trusting it, fixing this problem.