We are starting to get more inquiries about migrating to -EL8 (e.g. RHEL8 or CentOS 8) so I started this thread as a convenient place to record general notes and comments relating to it.

A-Shell executable compatibility: Plainly put, no version of of A-Shell compiled for -EL7 or below will run on -EL8. So you definitely need to start with an A-Shell -el8 package. As if this writing, the best choice is: ash-6.5.1684.5-el8.bin. Most or all of the executables and libraries in the bin directory require updating, so best to use the full (.bin) package rather than just trying to overlay an updated ashell executable on an earlier release.

A-Shell 6.4: We haven't decided yet whether to support 6.4 on the -EL8 platform. Given the size of the leap to -EL7 from prior releases, any arguments for sticking with the "stable" 6.4 seems pretty weak, so at the moment our thinking is that if you're going to -EL8, you might as well go to A-Shell 6.5 at the same time.

PolyShell: Needs to be updated, to version 1.5.171+. Note however, that in this chapter of the continuing evolution of Korn Shell implementations for Linux, it appears that we are back to an official ksh package (in contrast to the preceding several Linux versions that relied on the pdksh package.) As of this writing, the latest version appears to be ksh-20120801-254.el8.x86_64. Even more interesting and important to note: it is no longer necessary to use the mysterious set +o monitor to keep ksh from meddling with the job control signals used by PolyShell. In fact, you MUST NOT USE the set +o monitor option. (Apparently the sense has been reversed?)

AXL: 3.8.8+ works

ASQL: not yet supported.

FTPDLX: The original version is no longer supported, but the /2 version (aka FTP2) is. Note that FTP2.SBR, along with HTTP.SBR and CRYPTO.SBR and the PDFX email method 4 all rely on libashnet.dll, which must be at least 1.0.172.el8 for the -EL8 platform.

Then why not start out fresh with a 6.6 stable?

PS: we have been deploying 6.5 for some time now.

I installed a Centos 8 VM

These are still needed on a base system (no Dev stuff installed):

yum install libstdc++.i686
yum install ncurses-libs.i686
yum install pcre.i686

any update on if/when asql will be supported? thanks

It's close to the top of the list. I've gotten bogged down in a once-every-4-year upgrade/refresh of my complete development environment which has led to many detours, but things are starting to fall into place.

Can someone please explain why we are even discussing the viability of Polyshell? Am i missing some value to this option?

There are a few dealers and a lot of users who use PolyShell. Arguably much of the original motivation (allowing multiple sessions without having to pay OS licenses on them) has disappeared now that none of the UNIX platforms charge by the connection. But there is still a convenience factor of being able to launch a new session nearly instantly, and/or to start out with 2 or 3 pre-launched sessions. On the other hand, PolyShell in only compatible with plain text environments, so wouldn't apply to you or to most of the people posting on this forum.

Ok thanks Cap.

just checking to see if asql is still on your list to get working on centos 8 ?

thanks

Thanks for the reminder - yes it's still on the list. Things have been a bit chaotic here these last several months, making it too easy to ignore the wheel that isn't squeaking. I'll bring the can of oil around and see I can get working in the not-too-distant future.

thanks

has the not-too-distant future arrived yet?

Um..., think of it like the vaccine -- it may have arrived, but it's still very hard to get your hands on it. I'll try to focus on improving the roll-out soon...

Here's a brief status update on ASQL compatibility with EL8 (or CS8)... I spent a few hours playing with it over the weekend, but I'm coming to the conclusion that it may be time to switch over from i686 (32 bit) to the x86_64 (64 bit) environment. It's getting harder and harder to find 32 bit versions of all the packages that go into a running A-Shell environment, and in the case of ASQL, I've been unable to find a 32 bit binary for the MySQL or MariaDB C connector. I tried building one from source, but kept getting stuck in the Linux version of DLL hell, where the package you need is incompatible with another one that you also need, leading to endless rounds of uninstalling/re-installing packages. None of that would be necessary for the 64 bit version, which is readily available as a binary package.

Most of the A-Shell code is already 64 bit compatible, but it's not easy to ferret out all the potential latent traps lurking inside XCALLs and other low-level code. Unfortunately it's an all-or-nothing deal - there's no practical way to intermix 32 and 64 bit components, at least on the Linux platform. And for better or worse, A-Shell has accumulated a number of third-party dependencies over years, depending on which features are being used, all of which need to be switched over (and in some cases re-licensed) at the same time. So it's an undertaking. But the new plan is to focus on converting to 64 bit for the EL8/CS8 platform and beyond. If/when that's accomplished, I'll think about whether/when it makes sense to tackle it for Windows. At this point I don't see any particular need to consider it for older linux platforms.

Stay tuned...