FPtermcap entry for OS/X Terminal (was 'Difference in how declared variables handled in report breaks?')

Bruce Easton bruce at stn.com
Mon Nov 24 18:34:28 PST 2014


I have corrected the end of my third paragraph below, but let me also 
take this opportunity to mention iTerm.  I don't use it much (but maybe 
should).  I do seem to remember it working better than the mac Terminal 
in some instances, and I'm really not sure why I stopped using it.  I do 
see they just came out with an update a couple of weeks ago for 
Yosemite, so maybe it's worth a look.

On 11/24/14, 9:15 PM, Bruce Easton wrote:
> On 11/24/14, 7:19 PM, Jay Ashworth wrote:
>> PS: Anyone got a good, tight FPtermcap entry for OS/X Terminal? :-) 
>
> Tight?   No.  For me, Jay, it's been a tale of mystery and intrigue, 
> but mostly mystery.  I think some of the mystery lies with the files 
> the target OS holds that control the terminal experience, and in other 
> cases the version of filepro seems to make a difference.  (So far, I'm 
> speaking of differences when filepro's termcap file remains unchanged.)
>
> One of our clients has an old Fedora RH box with 5.0.14, where the 
> original termcap entries for Linux and xterm came from the install. 
> When I started using a mac to support them, the only changes necessary 
> to the mac Terminal was to declare terminal as xterm, use Latin-US 
> (DOS) text encoding and check 'Delete sends Control-H'. That's it - 
> the function keys worked mostly fine, but I did have to change some of 
> mac's pre-mission-control 'exposé' program key mappings so that they 
> wouldn't supersede filepro for the higher-numbered function keys.  
> Those are the keys that would zoom your desktop in and out in various 
> ways.
>
> Since then, on target machines where 5.0.14 was installed, but on 
> newer Linux, for instance, things would look OK, but the function keys 
> would not work.  Swapping termcaps with one that would work for me on 
> an older machine seemed to show that the problem was not the termcap.  
> Prior to using vmware, when I had this problem and was getting tired 
> of rebooting just to bring up putty in windows on the mac, I started  
> rummaging around in the client's newer Linux OS terminal files and 
> came across this file called "mn" which I think had a comment about it 
> as "mac New" inside it.  So I tried setting TERM to xterm as usual, 
> then I added "mn" to fp's termcap entry for xterm in its header 
> (..|mn|..), then I set PFTERM to mn and exporting that, and then the 
> function keys worked.  Most of the newer Linux boxes (where 5.0.14 or 
> earlier is running) *STILL REQUIRE* these additional steps on the 
> target box. <--- CORRECTION
>
> Lastly, since I think about 5.6 or 5.7, something changed in filepro 
> itself I believe.  Maybe something was restored to it's original 
> state. I'm only guessing, but the reason I say this is because, under 
> a brand new install of filepro, I now see that things work fine 
> without PFTERM=mn, even if I substitute one of my original termcaps in 
> place of the one from the new install.
>
> So maybe an easy way to look at what I would still do is to go with 
> the steps from my second paragraph, and then if necessary, on the 
> particular target machine, also try what I have in the third paragraph 
> regarding "mn".
>
> I think in a couple of cases, where I didn't want to change the 
> client's termcap, I've copied it, modified it with "mn" and then for 
> my session set the TERMCAP env var.
>
> Hopefully someone has an easier solution.
>
> Bruce
>
>
>




More information about the Filepro-list mailing list