Re: [Gnuplot-info] Fwd: How to realize a single plot in a double loop?

[Ethan A M. <EAM...@gm...>]

On Sunday, 13 August 2017 11:48:03 ivana richterova wrote:

> 1, gnuplot is a "unix" program. As such, it can do something quite
> well: to plot. It doesn't care about files. It supposes that you know
> what you want to plot and provide requested files.
> 
> Under Unix/Linux, It'd be the default solution to generate a plot
> script for each directory outside gnuplot. So, the primary task is how
> simple can be this shell/pearl/... script.
>
> Secondly, it's nice that you can even do inside script as well now in
> V5+, although you need to run syscalls. (Personally, I'd appreciate if
> I can disable all syscalls on startup at all. Otherwise I need to
> check if there are commands such 'rm -rf /', 'chmod -R a+r ~/.ssh',
> etc. in other-hands scripts.)

This idea has been raised before.
The major problem I see with it is that gnuplot gains a lot of power from
being able to filter input and output through pipes.  It is common to filter
input data through standard system tools like awk or grep, or convert
output on-the-fly using image conversion or display utilities.  
Or both at once:

gnuplot> set term png
gnuplot> set output "| display png:-"
gnuplot> plot "< grep May annual.dat"

The concern is that every time you create a pipe you open a window
of vulnerability.  If you are operating in an untrusted environment then
the use of pipes is exactly as dangerous as direct use of system
or shell commands.   It would make no sense to disable one but not
the other, and a non-piping gnuplot would be substantially less useful.

Current gnuplot does its initial setup in a restricted mode that
disables both system commands and pipes.  Neither is permitted in
a system or private initialization file ~/.gnuplot or $SOMEWHERE/gnuplot.rc
That provides a minimal level of protection against issuing the "gnuplot"
command in a potentially booby-trapped environment, but once the 
program is initialized and accepting user commands pipes are reenabled.
 
> 2, gnuplot is currently highly developed. Iteration and arrays will
> probably continue development. Currently, on my wish-list there is (1)
> a possibility to index arrays by letters OR get ascii code of chars,
> and (2) to manipulate the iterating variable. Both would helpful also
> in your case.

Characters as numerical array indices does not seem feasible.
gnuplot accepts (indeed defaults to) multibyte encoding, usually UTF-8.
You can manipulate a multibyte character easily  enough, e.g.
gnuplot> s = "mør"
gnuplot> print s[2:2]
                ø
but the only character->numerical mapping that might be feasible is
mapping to a unicode code point. 

I suppose one could have associative arrays, or LEAP/SAIL style
associative triplets.   I'd want to see a solid use case for such an
extension before considering it further.  Do you have an example
application for which using a character as an array index is a  big win?

	Ethan