plot $DATA w lines
expands to
plot 10
12
15 w lines
i.e. whatever $DATA contains gets put there literally, newlines and all. That likely breaks the command. (I'm not sure if gnuplot has a way to give the data directly on the plot command line, but it'd probably need to be in some other format.)
The shell has process substitution that makes the output of a command available as a "file", and expands to the filename, but you might be better off passing the data through stdin, and giving the plot command to gnuplot as an option.
Based on the example command used here, something like this might work:
echo "$DATA" | gnuplot -e 'plot "-" w lines"'lines'
or rather by piping the data directly from where you're getting it, without collecting it in the shell in the first place:
echo ":TRAC:DATA? TRACE1" | netcat -q1 "$SERVER" "$PORT" |
cut -c 13- | tr ',' '\n' | tr -d "[:blank:]" |
gnuplot -e 'plot "-" w lines"'lines'
Then again, I don't think using a temporary file is that bad. A lot of shell scripts use them, and so do non-shell programs, too. A lot of the programs commonly called from shell scripts can read files directly, while passing data from a shell variable requires more complications. (E.g. the pipeline echo "$var" | somecmd requires launching an extra copy of the shell to write the data, and here-docs and here-strings like somecmd <<< "$var" just might create a temporary file in background anyway...)
Of course you usually want to remove any temporary files when you're done, and you should make sure they're created with a unique name so there are no collisions. But that's not hard to do:
#!/bin/bash
server=192.168.0.12
port=5555
tempfile=$(mktemp)
echo ":TRAC:DATA? TRACE1" | netcat -q1 "$server" "$port" |
cut -c 13- | tr ',' '\n' | tr -d "[:blank:]" > "$tempfile"
gnuplot -persist <<-EOFMarker
plot "$tempfile" w lines
EOFMarker
rm -f -- "$tempfile"