#392 Backwards-incompatible joerc syntax
The EPEL repository for RHEL7 recently updated its joe package from 3.7 to 4.6. Users with custom .joerc files in their home directories now receive syntax errors on startup, "Bad key sequence '^@ TO X'", which refers to several occurances of "type ^@ TO <ff>" lines in the v3.7 joerc file. The v4.6 joerc file replaces these lines with the Unicode compatible "type U+0 TO U+10FFFF". The problem is, in an environment with NFS home directories and a mixture of both RHEL6 (which still has joe-3.7) and RHEL7 (now on joe-4.6), there now appears to be no mutually-compatible syntax a user can have in their custom .joerc file that will work with both versions of joe. If you replace the "type" lines with the v4.6 syntax, then joe 3.7 throws the same "Bad key sequence" error when a user logs into a RHEL6 system.</ff>
Therefore I'm wondering; is there any "type" line syntax that will work with both joe v3.7 and v4.6?
Thanks.
Surely shared NFS home causes problems like this for many other programs (like user's personal bin/ directory?), so I'm wondering if there is an OS solution... I see one solution here:
https://superuser.com/questions/211792/how-to-deal-with-shared-home-directory-on-linux
Possibly we could modify JOE to look for ".joerc-4.6" instead of ".joerc". I'd rather have something like this than requiring the syntax to be backward compatible forever. At some point the rc syntax needs revamping anyway.
I've been a Linux sysadmin in such environments for over 20 years, and in my experience such problems are actually pretty rare in practice. Most applications that don't maintain backwards-compatibility with their older config files do something like you suggest, and either have versioned config files, or some ability to fall back to an earlier compatibility mode.
Another approach to config file handling that would both solve this problem and make some other things simpler for users would be to allow user config files to contain only those settings that the user wants to override from system default. So, on startup, the application would first consult /etc/joe/joerc, then check for a custom ~/.joerc, and override the defaults for any settings found there. If a user only cares about enabling "nobackups" and "noxon", then their .joerc could contain only those two lines. Maybe something to consider for a future enhancement.