Thanks for the Strawberry info. I used to run Strawberry in XP before I got my first Mac, still have it, in fact, on my XP in VirtualBox. I also used Active State and gave it a dose of Unix with the MKS-Toolkit. I got that Mac because I wanted Unix on a laptop and it was so challenging to get Linux running on the laptops of that day (2005, or thereabouts: chasing drivers was the pits). Today, if I had to start over from scratch I would just buy a modular laptop from Framework and put Ubuntu up on it, less difficult than getting Ubuntu running in VirtualBox). Those were the days...

I still have not nailed down in the Alien tree which module fetched a truly broken pre-built (I think) gnuplot binary and stuffed it into my perlbrew. That binary is brain-dead in a macOS environment because ...drum roll, in macOS I know of only three terminal types that can render graphics, to wit: aqua, wxt and x11, and none of these are in the terminal list returned by set terminal in the broken binary. All are in the binary I built with macPorts. No macOS head would ever fetch such a binary and expect it to work. That's why it returned terminal 'unknown'.

I, like probably many perl-heads who use cpanm, take installing modules for granted. It is so easy and reliable that when it isn't, as with this mix of stuff needed to get PDL up and running, it is, or can be non-trivial to debug the failures. I have now resolved before I install any Perl module to first read the docs on cpan or github or wherever that discuss installation issues. Had I done that and found those environment variables I could have saved myself a load of grief. Still, need I say, there is work to be done in the PDL distribution docs and builds to make installing PDL easier. Oops, I just wrote something that's going to get me bashed by one of the devs, who shall remain nameless, but he knows me :-(

UPDATE, 8/15/2023

Perusing (snooping) in the build directory for Alien::Gnuplot I discovered that Alien::Gnuplot actually downloaded the source for gnuplot and built it on my machine using clang. However, it failed to build it for macOS because it omitted the terminal definitions for aqua, wxt and x11, the only graphics drivers that are installed by default or can be downloaded (XQuartz) to macOS. Here's why, found in term.h, to wit:

/*
 * term.h: terminal support definitions
 *   Edit this file depending on the set of terminals you wish to support.
 * Comment out the terminal types that you don't want or don't have, and
 * uncomment those that you want included. Be aware that some terminal
 * types will require changes in the makefile LIBS definition.
 */

Need I say, in total exasperation, the three .h files for these three are commented out. I built my instance of gnuplot with macPorts and it knew to include these terminal defs without any prompting from me. Now granted, it took me at least two hours of valuable time to find these useful fragments of information, even knowing where to look took some hacking, but get real folks, this is a build that base Alien executed on a very recent macOS, and did not even provision to test for darwin (a simple uname in an #ifdef would suffice) and include those headers, since building and testing the gnuplot binary was successful and silent. I installed my own gnuplot and expected it to be used, as I was unaware that another binary would be built and installed without my knowledge in my private Perl tree. The Alien concept is brilliant in conception (the notion of using pipes to connect Perl clients with non-Perl executables, but hiding the details leaves the user up the proverbial creek without a paddle if it doesn't work. Apparently, we all have to be hackers to survive in a modern Perl environment. Could that be why so many new programming heads are embracing Python? I know that's what's being taught in CS, and I use NumPy and SciPy in my own teaching, because my students expect me to be able to answer their questions, but Perl is still hands down more programmer productive than Python (especially non-OOP functional Perl). For example, I write all non-trivial regex in Perl (to use Regexp::Debugger), and put equivalent Python3 code below __END__, because debugging regex in Python sucks. At the moment I can't find this boffo quote from some Perl wag, to wit: "Python is TIMTOWTDI in Perl", but I digress.