filepro menus and Ctrl-S - maybe Anzio setting?

[Brian K. White]

On 12/9/2010 8:11 PM, Bruce Easton wrote:
> I wanted to see this first-hand, so I loaded demo of latest Anzio Lite onto
> this vista partition, accepting, I think all the defaults, and saying
> yes to
> older SCO mode question.  Very easy install.  And filepro's dpromenu came
> up in color beautifully.   Found one of the 19-option menus that had
> been adjusted to less than 19 lines and put it back to 19 lines.
>
> Sure enough, works OK from prompt or from option G on dpromenu,
> but from a calling menu - as George said, 'LOCK' appears at lower
> right and you have to key Alt-U to be able to navigate/select anything.
>
> (fp 5.0.14 by the way)
>
> Then things got really interesting.  I took a look around and found that
> some of the filepro executables (including dmakemenu, runmenu) did
> not get the SUID bit set correctly from the setperms prog.  So I
> referenced another Linux box, did an "ls -l|grep rws" standing in fp and
> lib
> to help refresh my memory and proceeded to fix these perms.
> Well that did not help.
>
> I then found another system with that same problem menu
> (Linux); ported it over and did a sum on the two menus (which visually
> when run looked exactly the same - incl title, ver).  One returned 27672
> and the other returned 32887. So I thought maybe the problem one
> was just corrupt.  If I pointed the source menu to the newly ported
> version,
> it did not have Anzio turn lock on.
>
> Then I looked at the perms on the problem menu file itself. It was 777.
> I thought that it didn't need and probably should have that - it was
> already owned by filepro, so I changed it to 600.  Boom.  It no
> longer had a problem!  So for kicks, I changed the perms on the
> newly ported menu to 777 and walla - Anzio started turning the lock
> on on that menu.  (And by the way - this all as far as I can tell happens
> on menus with 19 items, but i'm suspicious that maybe this is the only
> obvious side-effect and that these ctrl chars in all menus are not
> being treated properly - I mean we know these files are all supposed
> to have one of those chars at the top right?)
>
> If that's not enough (and it really oughtta be), I then noticed that
> if I edited any menu on the system and used F5 to go into the
> script and then Del to cancel, I did not come back to the edit session
> of the menu, but was blown all the way out to dpromenu.  So at this point,
> just to make sure, I ported from another working Linux-fp5.014 box
> runmenu, dmakemenu and menupass and put them into place
> temporarily to see if that would get rid of that problem - no go.
> (But I realize I may have compounded the situation by not porting
> a complete set, so I restored what was there.)
>
> I also re-saved the problem menu once it had 'correct' perms, but
> it did not change its size which is still different than the other
> one that looks and behaves the same way under the same
> circumstances, but has a different size.
>
> During all of this, without injuring me or my cat, I was also
> trying out different emulations.  To try out linux for instance,
> I had to set it in Anzio, then set TERM and also the config
> file on this system where they have a PFTERM=cansi.  None of
> that made a difference with this problem, and didn't change
> much with the terminal behavior.  It all just looked the same
> (and nice) through Anzio.   Finally, just for kicks - I did an
> 'stty sane<ret>' and that didn't change anything except I
> then had to start using Ctrl-C instead of the Del key to
> cancel.  (And if I then tried to use the Del key, I'd get a
> little character that looks like the outline of a monopoly
> house from the front.)
>
> Anyway, that's what I tried - maybe this will ring a bell with
> someone.  So, as it stands, if the perms of menu files (not the
> scripts) are 600, then they are OK.  But, with that unexpected
> behavior in define menus  - blowing all the way out from the
> script, I'm suspicious of the health of the filepro executables
> for this particular install  - maybe something got corrupted.
> Probably best at this point to re-install filepro.
>
>
> Bruce
>
> Bruce Easton
> STN, Inc.
>
>
> On 12/9/10 12:46 PM, flowersoft at compuserve.com wrote:
>> P menuname
>>
>> -----Original Message-----
>> From: Kenneth Brody [mailto:kenbrody at spamcop.net]
>> Sent: Thursday, December 09, 2010 9:17 AM
>> To: flowersoft at compuserve.com
>> Cc: filepro-list at lists.celestial.com
>> Subject: Re: filepro menus and Ctrl-S - maybe Anzio setting?
>>
>> On 12/9/2010 12:03 AM, flowersoft at compuserve.com wrote:
>> [...]
>>> Second, the menu behaves normally if called from the command line or
>>> dpromenu.  In other words, if you type p menuname from the command line,
>> no
>>> problems.  If you run it from the G option of the filePro menu, no
>> problems.
>>> It is only when the menus with 19 lines are called from another filePro
>> user
>>> menu,
>> How, exactly, are you calling the menu from another?
>>
>> [...]

I have seen some of those things myself since years ago. I always 
figured it was just me and dealt with it.

Several years ago when we first switched to linux I tracked down several 
mystery "menu doesn't work" problems to the fact that we had almost all 
"p menuname" in our menus, and some of these acted as though fp were 
trying to execute the menuname rather than just hand it to runmenu as an 
argument.

I fixed all those problems by changing all "p menuname" to "!menuname" 
what a chore but it worked.

I still get blasted out of the F5 batch editor all the way out of the 
menu editor to the main menu when I break out (doesn't matter, ctrl-c in 
linux or Del in scoansi), but no problem when I save with escesc.
I never fixed that since it doesn't seem to hurt anything, doesn't 
corrupt the script or the menu, and I rarely use the F5 editor anyways.

Both of these are only on linux. Same app same code, same version of fp, 
no problems on sco.

I never saw the menu lockup problem though. But I use my own setperms 
routinely which sets the menu files to 644 and only the scripts to 755 
so perhaps I never saw the lock problem just by luck of running setperms 
at the drop of a hat.

There's a couple other little minor annoyances. In linux emulation mode, 
backspace doesn't behave right when editing the F9 search string in 
cabe. You press backspace, and the cursor moves to the right.

-- 
bkw