Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!sun-barr!newstop!sun!turnpike!argv
From: argv%turnpike@Sun.COM (Dan Heller)
Newsgroups: comp.mail.mush
Subject: Re: mushtool bugs and patches
Message-ID: <128303@sun.Eng.Sun.COM>
Date: 22 Nov 89 20:39:19 GMT
References: <1989Nov21.055514.6990@semi.harris-atd.com> <5756@ogccse.ogc.edu> <128221@sun.Eng.Sun.COM> <1989Nov22.064230.13339@semi.harris-atd.com>
Sender: news@sun.Eng.Sun.COM
Reply-To: argv@sun.UUCP (Dan Heller)
Lines: 49

In article <1989Nov22.064230.13339@semi.harris-atd.com> del@thrush.semi.harris-atd.com (Don Lewis) writes:
> But in the mean time, the function keys are the only way to do useful
> operations that are not possible given the buttons and menus.  I use
> one of the function keys to do "mail -f".  So see below for a throwaway
> patch for this until we get the real thing.

well, function keys haven't -really- gone away yet (depending on your
version).  the fkey command still exists in most versions so you can 
still specify function key bindings in your .mushrc.  And you can use
these function keys in the headers window.  In the meantime, your fix
is a fine temporary workaround.

Incidentally, you included the same patch twice, so anyone attempting
to apply the patch might find interesting errors :-)

> The following is a patch to what appears to be an real tool mode bug.  I
A fine fix for your current version, but this code has changed
somewhat in the latest version.

> I found the above when I was looking to see how hard it would be to modify
> mushtool so that it would go iconic before actually saving the mail folder.
You could do it by using a notify_interpose_proc(), but then you get into
hairy details.

> Odds and Ends:
> I noticed that if you hit the update button and your folder is already
> up to date, mushtool doesn't ask if you want to update the folder, but
> it does go off and think for quit a while.  It's not obvious what it is
> doing.
What -- don't you like to just go off and think for a while? :-)
As noted above, this portion of the code has changed a lot so this
problem may have gone away.  At least, I haven't noticed it.

> I noticed in msgs.c that the permission checking on the folders is done
> by checking the owner permission bits returned by stat().  This is not
> correct if the folder is owned by another user.  Shouldn't the access()
> system call be used instead?
Mush uses its own call: Access() --this is because the access() system
call has an undocumented feature which prohibits use when suid to someone
else.  However, in the case you're talking about, you may be right that
the stat() call should check the file's uid and check the appropriate
permission bits as well..

> I'm really impressed by the different mouse buttons getting highlighted
> on the cursor in the header window ;-).
The first one who ever appreciated it :-|  Everyone else asks:
"why the hell do all the mouse buttons blink when I move the cursor
in the headers window?"
dan