FPMENU

[Bruce Easton]

On 8/27/13 1:55 PM, Jean-Pierre A. Radley wrote:
> Scott Walker propounded (on Tue, Aug 27, 2013 at 12:39:18PM -0400):
> | if you got PFMENU set to some value and fp does NOT find the menu there, it
> | then goes and looks for it in whatever is set in /etc/default/fppath .
> |
> | So if you have PFMENU set, and for some reason you rename a menu in that
> | directory  to make sure no one can run it, if  fp does not find the menu in
> | there it gets it from /u/appl/fp/menus (for example) if the path set in
> | fppath is /u/appl.
> |
> |
> | Is this a bug or expected  behavior fp 5.0.14
>
> Well, that's the surprise for today!
>
> Aside from your case of renaming, it means in general that a desired
> menu is searched for first in PFMENU if set, then in the default
> directory for menus,
>
> I never noticed that, and I don't see any mention of that behavior in
> online help or online manual.
>
I do not remember where that behavior may have been documented, although 
I do remember that being the norm since the advent of PFMENU.  I can 
only guess that it was described in the gray 4.1 add-on pages for the 
3.0 manual and/or revision notes for 4.1 (I'm noticing that online 
revision history only goes back to 4.05.02.) I also remember, for 
alternate filepro "neighborhoods", having to create menus with the same 
names, but leading to a "not available under this login" type menu as 
one way to override the bleed-through from menus referenced via fppath.

Bruce