Is gnuplot better for the use cases demonstrated on the page here?
I've always avoided gnuplot because it has looked pretty hard to get anything useful out of. But uplot looks much more approachable. Just piping some data to "uplot hist --nbins 20" is something I'll remember.
Within the gnuplot shell you use `<` at the start of a "filename" like
gnuplot> plot '<pipeline'
It just uses system(3) for "pipeline". So, technically you could have a whole script in there with maybe tricky gnuplot-quoting/escaping of shell stuff.
You do have 2 different history logs this way - the shell one and the plot one while the uplot way is integrated.
If you really want integrated, you could drive gnuplot with temp files, though each shell command-line would probably have to pass a lot of controls. E.g.,
#!/bin/sh
cat > /tmp/dat # should use mktemp -d
cat > /tmp/p.gpi <<-EOF
plot '/tmp/dat' $*
EOF
gnuplot /tmp/p.gpi
and then
$ seq 1 10 | gpl with lines
It is an exercise for the reader (well, it has probably been done N times...) to harden the temp paths, clean up afterward, generalize to source user/maybe per-directory `foo.gpi` setup and so on.
In the unlikely event temp space is actually any sort of issue then you might be able to use mkfifo (I've never tried) or else generate a .gpi script that uses the plot '<string' syntax escaping `string`.
Oh, that goes to show you how little I use it. I read the documentation and merely assumed that it would work for stdin, but gnuplot exits with an error in that case. This will work, but it’s pretty funky:
I've always avoided gnuplot because it has looked pretty hard to get anything useful out of. But uplot looks much more approachable. Just piping some data to "uplot hist --nbins 20" is something I'll remember.