Menu
▾
▴
Re: [Gnuplot-info] Managing long/complicated plot commands?
|
From: Bjorn B. <bjo...@gm...> - 2026-03-30 07:22:16
|
Thanks Ethan for digging to the bottom of this and for the workaround! (I
guess that the other workaround is simply to not use `\` and have very long
lines, at the expense of readability, of course.)
Note that I still see the second problem that I mentioned at the end of an
earlier email. I repeat it here. This is the message I get if I include
your "junk" code prior to my script. As expected the data files are not
found, but the strange thing is the last message:
```
reference a string of length 6144
garbage
"$plot_polar" line 13: warning: Cannot find or open file "world_110m.txt"
"$plot_polar" line 13: warning: Cannot find or open file "data/ReportA.txt"
"$plot_polar" line 13: warning: Cannot find or open file "data/ReportA.txt"
"$plot_polar" line 13: undefined variable: orbit
```
I have had trouble where this last message/error pops up sometimes and I
haven't been able to nail down the exact circumstances. I believe in this
case that it refers to `title orbit`. If I change that to `notitle` it
disappears. And changing from `notitle` to `title orbit` in the preceding
line does not trigger the message. This seems also somehow related to the
length of the command.
Many thanks,
Bjorn
On Mon, Mar 30, 2026 at 1:34 AM Ethan Merritt <eam...@gm...> wrote:
> On Sunday, 29 March 2026 10:25:16 PDT Bjorn Buckwalter wrote:
> > Hi Philipp and all,
> >
> > So, trying to minimize a bit more, I realized that a key piece of
> > information that was omitted seems to be that the plot command is inside
> a
> > function block. Below is a case that reproduces the error for me that you
> > could test. I realised that if I take the command out of the function it
> > works properly.
> >
> > By the way I am on macos and `gnuplot --version` says `gnuplot 6.0
> > patchlevel 4`.
> >
> > Here is the case that fails with the error in question. Since it fails
> > early (at least for me) you will not actually need the data files:
> >
> > ```
> > local lon(x) = x
> > local lat(x) = x
> > local filter_lat(x) = x
> > local next_color(x) = "#00FF00"
> > local next_color_t(x, y) = "#00FF00"
> >
> > local lat1 = 0
> >
> > function $plot_polar(orbits) <<EOF
> > plot \
> > 'world_110m.txt' using (lon($1)):(filter_lat($2)) linecolor "gray"
> > notitle , \
> > lat(0) black dt 2 title "Equator" , \
> > lat(66.6) black dt 5 title "Arctic/Antarctic circle", \
> > lat(-66.6) black dt 5 notitle , \
> > for [orbit in orbits] \
> > 'data/Report'.orbit.'.txt' using (lon($7)):(filter_lat($6)) \
> > lc rgb next_color_t(1, 'cc') notitle, \
> > for [orbit in orbits] \
> > 'data/Report'.orbit.'.txt' using (lon($7)):($3 == 2030 ?
> > filter_lat($6) : NaN) \
> > lc rgb next_color(n) title orbit, \
> > 0, \
> > 1
> > EOF
> >
> > _ = $plot_polar("A")
> > ```
> >
> > The error message:
> >
> > ```
> > plot 'world_110m.txt' using (lon($1)):(filter_lat($2)) linecolor
> > "gray" notitle , lat(0) black dt 2 title "Equator" , lat(66.6)
> > black dt 5 title "Arctic/Antarctic circle", lat(-66.6) black dt 5
> > notitle , for [orbit in orbits] 'data/Report'.orbit.'.txt'
> using
> > (lon($7)):(filter_lat($6)) lc rgb next_color_t(1, 'cc') notitle,
> > for [orbit in orbits] 'data/Report'.orbit.'.txt' using
> > (lon($7)):($3 == 2030 ? filter_lat($6) : NaN) lc rgb
> next_color(n)
> > title orbit, 0, \ 1
> >
> > ^
> > "$plot_polar" line 13: invalid character \
> > ```
> >
> > If I change the `linecolor` in the first line of `plot` to `lc`, The
> error
> > does not occur.
>
> This is a strange one.
>
> I believe I have tracked it down to a program bug that has has nothing in
> particular to do with the details of your script, although as you noted it
> is
> more likely to be triggered by a function block than by input from a file.
> You just got unlucky.
>
> The program has no fixed limit on input line length or command length.
> The size of the command buffer is expanded if necessary to hold the
> next bit of input. The new input is appended to the current content of
> the buffer, except that if the current buffer ends in a backslash it is
> appended on top of the backslash rather than after it.
>
> The bug is that the check for a trailing backslash gets skipped if the next
> chunk of input is the one that causes the command buffer to be expanded,
> so the command buffer is left with a spurious backslash character.
>
> I don't have an immediately work-around for existing binaries other than
> to note that once the command buffer has been expanded, the bug will
> not trigger again. So even though the first invocation of the function
> block fails, a subsequent invocation will succeed because this time the
> buffer does not need to be expanded and the check for a backslash is
> made correctly.
>
> Or I suppose you could prefix the script with a useless bit of code that
> constructs and executes a very long command so that the command
> buffer gets expanded:
>
> junk = "garbage garbage garbage "
> do for [i=1:8] { junk = junk . junk }
> command = 'print "' . junk . '" [1:8]'
> print "reference a string of length ", strlen(junk)
> eval(command)
> ...
> start your real script here
>
> - Ethan
>
>
>
> > If you test, you may instead get:
> >
> > ```
> > "$plot_polar" line 13: warning: Cannot find or open file "world_110m.txt"
> > "$plot_polar" line 13: warning: Cannot find or open file
> "data/ReportA.txt"
> > "$plot_polar" line 13: warning: Cannot find or open file
> "data/ReportA.txt"
> > "$plot_polar" line 13: undefined variable: orbit
> > ```
> >
> > By the way, the last message is rather curious. I have had trouble where
> > this pops up sometimes and I haven't been able to nail down the exact
> > circumstances. I believe in this case that it refers to `title orbit`.
> If I
> > change that to `notitle` it disappears. And changing from `notitle` to
> > `title orbit` in the preceding line does not trigger the message. This
> > seems also somehow related to the length of the command.
> >
> > I guess Hernán's suggestion to generate a “flat” gnuplot script with a
> > non-gnuplot script could allow me to avoid using function blocks. (At
> least
> > that is how I interpreted the suggestion).
> >
> > Thanks,
> > Bjorn
> >
> >
> > On Sun, Mar 29, 2026 at 2:24 PM Philipp K. Janert <ph...@ja...>
> wrote:
> >
> > > On Sun, 29 Mar 2026 11:49:01 +0200
> > > Bjorn Buckwalter <bjo...@gm...> wrote:
> > >
> > > > Thanks Jesper and Philpp. Jespers suggestion with variables can
> > > > likely help – I will try it!
> > >
> > > It's not so easy for me to reproduce your
> > > problem, because I don't have access to the
> > > data files, etc.
> > >
> > > The cmd does not seem overly long. I still
> > > suspect that there is a problem with one of
> > > the CRs not being properly escaped - such
> > > as having a blank after a backslash, but
> > > before the actual CR. The error msg in your
> > > original email points to that, too.
> > >
> > > I did not dig into the code to see whether
> > > there is an actual limit to the length of
> > > the cmd line. Ethan would know.
> > >
> > > Do you enter the cmd interactively, or do
> > > you have it in a file, which you load?
> > >
> > > >
> > > > FYI here is an example plot command that fails:
> > > >
> > > > ```
> > > > plot \
> > > > 'world_110m.txt' using (lon($1)):(filter_lat($2)) with lines
> > > > linecolor "gray" notitle , \
> > > > lat(0) with lines black dashtype 2 title "Equator" , \
> > > > lat(66.6) with lines black dashtype 5 title "Arctic/Antarctic
> > > > circle", \ lat(-66.6) with lines black dashtype 5 notitle , \
> > > > for [orbit in orbits] \
> > > > 'data/Report'.orbit.'.txt' using (lon($7)):(filter_lat($6)) \
> > > > with lines linecolor rgb next_color_t(n, 'cc') notitle, \
> > > > for [orbit in orbits] \
> > > > 'data/Report'.orbit.'.txt' using (lon($7)):($3 == 2030 ?
> > > > filter_lat($6) : NaN) \
> > > > with lines linecolor rgb next_color(n) title orbit, \
> > > > lat(lat1) black notitle # edge of plot
> > > > ```
> > > >
> > > > There is A LOT going on there with various custom functions, etc. I
> > > > tried to make a minimal and “dependency-free” example but failed to
> > > > reproduce the behavior. I could maybe try harder.
> > > >
> > > > Here is in any case the error from gnuplot. The command has been
> > > > concatenated at all baskslashes except the last:
> > > >
> > > > ```
> > > > plot 'world_110m.txt' using (lon($1)):(filter_lat($2)) with
> > > > lines linecolor "gray" notitle , lat(0) with lines black dashtype
> > > > 2 title "Equator" , lat(66.6) with lines black dashtype 5 title
> > > > "Arctic/Antarctic circle", lat(-66.6) with lines black dashtype 5
> > > > notitle , for [orbit in orbits] 'data/Report'.orbit.'.txt'
> > > > using (lon($7)):(filter_lat($6)) with lines linecolor rgb
> > > > next_color_t(n, 'cc') notitle, for [orbit in orbits]
> > > > 'data/Report'.orbit.'.txt' using (lon($7)):($3 == 2030 ?
> > > > filter_lat($6) : NaN) with lines linecolor rgb next_color(n)
> > > > title orbit, \ lat(lat1) black notitle # edge of plot
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ^
> > > > "$plot_polar" line 15: invalid character \
> > > > ```
> > > >
> > > > There is nothing wrong with the backslash (no trailing spaces, etc.).
> > > >
> > > > If I change it as so (just shortening style definitions) it works:
> > > >
> > > > ```
> > > > set style data lines
> > > > plot \
> > > > 'world_110m.txt' using (lon($1)):(filter_lat($2)) lc "gray"
> > > > notitle , \ lat(0) black dt 2 title "Equator" , \
> > > > lat(66.6) black dt 5 title "Arctic/Antarctic circle", \
> > > > lat(-66.6) black dt 5 notitle , \
> > > > for [orbit in orbits] \
> > > > 'data/Report'.orbit.'.txt' using (lon($7)):(filter_lat($6)) \
> > > > lc rgb next_color_t(n, 'cc') notitle, \
> > > > for [orbit in orbits] \
> > > > 'data/Report'.orbit.'.txt' using (lon($7)):($3 == 2030 ?
> > > > filter_lat($6) : NaN) \
> > > > lc rgb next_color(n) title orbit, \
> > > > lat(lat1) black notitle # edge of plot
> > > > ```
> > > >
> > > > All I did was remove `with lines` (using `set style data lines`
> > > > instead and replace `linecolor` and `dashtype` with `lc` and `dt`,
> > > > respectively. This is why I say it seems to be somehow related to the
> > > > length/number of characters of a command.
> > > >
> > > > Thanks,
> > > > Bjorn
> > > >
> > > >
> > > > On Sun, Mar 29, 2026 at 5:28 AM Philipp K. Janert <ph...@ja...
> >
> > > > wrote:
> > > >
> > > > > On Sat, 28 Mar 2026 22:13:40 +0100
> > > > > Bjorn Buckwalter <bjo...@gm...> wrote:
> > > > >
> > > > > > HI all,
> > > > >
> > > > > How long (in characters) are the command lines that
> > > > > you are using? Mine frequently run long, and it has
> > > > > never been a problem.
> > > > >
> > > > > Is it possible that you have problems with embedded
> > > > > newlines, or that something goes awry if your command
> > > > > line runs into a new line in your terminal?
> > > > >
> > > > > Best,
> > > > >
> > > > > Ph.
> > > > >
> > > > > >
> > > > > > I rather often run into a problem of my plot commands being too
> > > > > > long, typically resulting in a not-very-helpful error message
> > > > > > such as:
> > > > > >
> > > > > > "$plot_polar" line 21: invalid character \
> > > > > >
> > > > > > It took a lot of head scratching to realize the root of the
> > > > > > problem. I assume there are strong reasons for both the
> > > > > > limitation on command length and the poor error message.
> > > > > >
> > > > > > I cannot be the only one running into this problem. The situation
> > > > > > being what it is, what are the rest of you doing to manage when
> > > > > > you run up against this limit? Replacing `linecolor` with `lc`,
> > > > > > etc, will only get me so far and at the expense of readability.
> > > > > >
> > > > > > Many thanks,
> > > > > > Bjorn
> > > > > >
> > > > > > _______________________________________________
> > > > > > gnuplot-info mailing list
> > > > > > gnu...@li...
> > > > > > Membership management via:
> > > > > > https://lists.sourceforge.net/lists/listinfo/gnuplot-info
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > Philipp K. Janert
> > > > > www.janert.me
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > gnuplot-info mailing list
> > > > > gnu...@li...
> > > > > Membership management via:
> > > > > https://lists.sourceforge.net/lists/listinfo/gnuplot-info
> > > > >
> > >
> > >
> > >
> > > --
> > >
> > > Philipp K. Janert
> > > www.janert.me
> > >
> > >
> > > _______________________________________________
> > > gnuplot-info mailing list
> > > gnu...@li...
> > > Membership management via:
> > > https://lists.sourceforge.net/lists/listinfo/gnuplot-info
> > >
> >
> > _______________________________________________
> > gnuplot-info mailing list
> > gnu...@li...
> > Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-info
> >
>
>
>
>
>
|
