I will cross-post on the PDL bug tracker, but here is a bit more information. My last thought in my post was to edit the list of external plot mechanisms in Simple.pm, but neither shuffling the order or even removing all but Gnuplot fail to resolve the issue. So, I tried cpanm PDL::Graphics::Gnuplot, because gnuplot is alive and well on my system. I can plot to XQuartz from stand-alone gnuplot with either terminal set default to 'aqua' (macOS default) or with GNUTERM='x11' set in my zsh environment. However, therein is another issue that may be either related or a second bug with PDL itself. The build log for PDL::Graphics::Gnuplot contains:

#   Failed test at t/plot.t line 16.
#          got: 'PDL::Graphics::Gnuplot: Your gnuplot has terminal 'un
+known' but it is not supported.
#         unknown: Unknown term (gnuplot final default)   [NS: not a t
+erminal]
# 
# You can use the 'terminfo' method for a list of available terminals.
# 
#  at /Users/wills/.cpanm/work/1691895761.64888/PDL-Graphics-Gnuplot-2
+.024/blib/lib/PDL/Graphics/Gnuplot.pm line 2333.
#       PDL::Graphics::Gnuplot::output(undef) called at /Users/wills/.
+cpanm/work/1691895761.64888/PDL-Graphics-Gnuplot-2.024/blib/lib/PDL/G
+raphics/Gnuplot.pm line 2174
#       PDL::Graphics::Gnuplot::new("PDL::Graphics::Gnuplot") called a
+t /Users/wills/.cpanm/work/1691895761.64888/PDL-Graphics-Gnuplot-2.02
+4/blib/lib/PDL/Graphics/Gnuplot.pm line 2091
#       PDL::Graphics::Gnuplot::gpwin() called at t/plot.t line 14
#       eval {...} called at t/plot.t line 14
# '
#     expected: ''

#   Failed test ''Constructor created a plotting object' isa 'PDL::Gra
+phics::Gnuplot''
#   at t/plot.t line 17.
#     'Constructor created a plotting object' isn't defined
[download]

I can find no way to configure the build environment in PDL::Graphics::Gnuplot to set the terminal type, and the build environment does not recognize the environment variable GNUTERM set to 'x11', even though gnuplot does. There is code in the POD for Gnuplot.pm such as

that shows how to set gnuplot terminal from inside a PDL script but no explanation of how to configure the interface to gnuplot to get the module to build and pass its tests. Also, quoting from the POD, to wit:

  gpwin is the PDL::Graphics::Gnuplot exported constructor.  It is
  exported by default and is a synonym for "new
  PDL::Graphics::Gnuplot(...)".  If given no arguments, it creates a
  plot object with the default terminal settings for your gnuplot.  You
  can also give it the name of a Gnuplot terminal type (e.g. 'x11') and
  some terminal and output options (see "output").

If I can set GNUTERM='x11' in zsh, and gnuplot recognizes it as its default, why doesn't the Makefile recognize it? Another intreresting observation in the POD is that PDL uses Alien::Gnuplot to discover whether gnuplot is installed and working correctly. If it isn't Alien::Gnuplot will barf and terminate. Mine doesn't but PD::Graphics::Gnuplot will still not build. I know interfacing PDL with an external plotting engine such as gnuplot is not trivial, but neither is getting it to build. As I said, I will cross-post, but getting an answer from the PDL dev group can take a very long time. Any advice from Monks would be very welcome.

You might know more about this than me, but I find it odd that you're setting the GNUTERM variable instead of the TERM variable. The latter is the one that all software I know of is looking at.

Hello NERDVANA (cool handle :-)): if you have gnuplot installed do 'man gnuplot' and scroll down to:

ENVIRONMENT
       A number of shell environment variables are understood by gnuplot.  None
       of these are required.

       GNUTERM
              The name of the terminal type to be used by default.  This can be
              overridden by the gnuplotrc, .gnuplot, or
              $XDG_CONFIG_HOME/gnuplot/gnuplotrc start-up files and, of course,
              by later explicit "set terminal" commands.

TERM is not mentioned. I can find no ref to this variable in any of the PDL/Perl POD, which means it can't be preset outside of a gnuplot environment (that's why the module build failed.) It is a gnuplot paramater, syntactic sugar to preset the engine for use by clients (a neat client/server model facilitated by Alien). In PDL literature there is only the notion of passing an actual terminal alias string in the graphics interface constructor (or using the engine's default) using the pipe mechanism established in Alien. It is no easy task getting PDL up and running. Do you think I'm right to criticise the PDL devs for NOT discussing this in installation instructions? Cheers,

Will

Insights, insights, insights :-) I don't know if there is an easy fix for this but I discovered that in my perlbrewed perl 5.36.1 there is a gnuplot binary, Version 5.4 patchlevel 6 last modified 2023-02-09, whereas mine built and installed in /opt/local with macPorts is Version 5.4 patchlevel 8 last modified 2023-06-01. The versions themselves are not important, but what is, is that 'unknown' terminal type is coming from the perlbrew version, as in:

  Terminal type is now 'unknown'

  set term x11
         ^
  unknown or ambiguous terminal type; type just 'set terminal' for a list

  WARNING: Error during initialization

The PDL::Graphics::Gnuplot build Make is not using my macPorts gnuplot but this one in perlbrew that may be crippled. Also, this perlbrewed version is not honoring GNUTERM='x11' in zsh. Simply relying on $PATH won't work as 'which gnuplot' already returns the one in /opt/local while the Make in PDL::Graphics::Gnuplot is not. It looks like fetching and building Alien::Gnuplot with cpanm is the source of that gnuplot binary in perlbrew. I'm not sure what the best fix is, to delete all traces of gnuplot in perlbrew or to explore its config. It strikes me as the better solution is to use the macPorts version which probably contains a full implementation of gnuplot. Comments please?

My bad :-( I did an rtfm on the docs in Alien::Gnuplot and discovered two environment variables that can and should be set in zsh, to wit:

  GNUPLOT_BINARY=/opt/local/bin/gnuplot
  GNUPLOT_INTERACTIVE=1   # to enable interactive tests
  GNUTERM=x11

I then ran 'make test' in the Alien::Gnuplot build directory and got these results:

Click in the X11 window for mouse test.
t/plot.t ............. 135/? lot to continue...
#   Failed test 'Mouse test read a click'
#   at t/plot.t line 638.
#          got: 'read_mouse: string Key: 1 at xy: 1.440036900369 , 8.8
+0252100840336 shift: 0 alt: 0 ctrl: 0 doesn't look right - doesn't ma
+tch parse regexp.
#  at /Users/wills/.cpanm/work/1691895761.64888/PDL-Graphics-Gnuplot-2
+.024/blib/lib/PDL/Graphics/Gnuplot.pm line 4481, <STDIN> line 15.
#     PDL::Graphics::Gnuplot::read_mouse(PDL::Graphics::Gnuplot=HASH(0
+x7fe90334bc58)) called at t/plot.t line 637
#     eval {...} called at t/plot.t line 637
# '
#     expected: ''
t/plot.t ............. 137/? Gnuplot warning: empty y range [0:0], adj
+usting to [-1:1]
 at t/plot.t line 819.
INFO: Plotting to 'Plot-1.txt'
 at t/plot.t line 911.
INFO: Plotting to 'Plot-2.txt'
 at t/plot.t line 914.
# Looks like you failed 1 test of 192.
t/plot.t ............. Failed 1/192 subtests 
    (less 4 skipped subtests: 187 okay)

Test Summary Report
-------------------
t/plot.t           (Wstat: 0 Tests: 192 Failed: 1)
  Failed test:  135
Files=3, Tests=197, 123 wallclock secs ( 0.05 usr  0.01 sys +  8.36 cu
+sr  2.67 csys = 11.09 CPU)
Result: FAIL
Failed 1/3 test programs. 1/197 subtests failed.
make: *** [test_dynamic] Error 22
[download]

Not sure what the issue is with my mouse, a Logitech 2-button USB wireless with a scroll wheel. I think it is probably safe to install this module. And finally, running that sin.pl script I referenced in my original post does execute an XQuartz plot with only this harmless warning:

Trying gnuplot (PDL::Graphics::Gnuplot)...ok
Use of uninitialized value in string eq at /Users/wills/perl5/perlbrew
+/perls/perl-5.36.1/lib/site_perl/5.36.1/PDL/Graphics/Gnuplot.pm line 
+7494.
[download]

This looks at first glance like a genuine bug in the PDL distribution

Gnuplot is fiendishly hard to interact with programmatically, because it requires talking to an executable over a pipe. This makes it prone to all sorts of cross-platform problems.