gnuplot-info — For questions and discussion about gnuplot

Re: [Gnuplot-info] Managing long/complicated plot commands?

[Bjorn B. <bjo...@gm...>]

Thank you Hernán for the further elaboration and the provided example!

On Sun, Mar 29, 2026 at 7:53 PM Hernán De Angelis <
var...@gm...> wrote:

> Hi Bjorn,
>
> Yes, you understood correctly. Here you can see a very simple example
> using Perl (but almost any other scripting language works):
>
> https://github.com/dhdeangelis/lcplot
>
> where the script downloads data, parses it in groups meant to be plotted
> as different sets of points and chooses visually pleasant (for me) tic
> parameters. This is written into a gnuplot script that is then passed as
> argument for gnuplot.
>
> Arbitrarily complex gnuplot scripts can be efficiently written this way as
> long as they respect gnuplot's syntax. Not shown in this example, but care
> is necessary to adequately scape any eventual special character like "\",
> "&". In Perl for example the sigils "$", "@", and "%" need to be escaped
> when writing a gnuplot file using "\". Other precautions may apply in other
> languages.
>
> Many script languages hace wrapper modules for gnuplot that may make life
> easier. I personally prefer the above method though.
>
> Best of luck
>
> Hernán
>
>
> Den 2026-03-29 kl. 19:32, skrev Bjorn Buckwalter:
>
> Hi Hernán and thanks for the suggestion.
>
> Do I understand correctly that you propose using a script written in
> another language to generate the gnuplot script (the "configuration file")?
> This may indeed be a good option, to generate a verbose and repetitive but
> straight-forward gnuplot script.
>
> I will admit that I was rather happy to have my plotting infrastructure
> being only self-contained gnuplot code, but I will seriously consider this.
>
> Thanks,
> Bjorn
>
>
>
>
>
> On Sun, Mar 29, 2026 at 12:23 PM Hernán De Angelis <
> var...@gm...> wrote:
>
>> You may already had this suggestion, as in using variables, but consider
>> that given the length and complexity of your command, it is perhaps a
>> better idea to use a script to do all steps from building your set of
>> plot instructions, writing them to a configuration file, and then
>> running the gnuplot command. I do this all the time to a good effect.
>>
>> /H.
>>
>> Den 2026-03-29 kl. 11:49, skrev Bjorn Buckwalter:
>> > Thanks Jesper and Philpp. Jespers suggestion with variables can likely
>> help
>> > – I will try it!
>> >
>> > 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
>> >>
>> > _______________________________________________
>> > 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
>>
>
>

Re: [Gnuplot-info] Managing long/complicated plot commands?

[Hernán De A. <var...@gm...>]

Hi Bjorn,

Yes, you understood correctly. Here you can see a very simple example 
using Perl (but almost any other scripting language works):

https://github.com/dhdeangelis/lcplot

where the script downloads data, parses it in groups meant to be plotted 
as different sets of points and chooses visually pleasant (for me) tic 
parameters. This is written into a gnuplot script that is then passed as 
argument for gnuplot.

Arbitrarily complex gnuplot scripts can be efficiently written this way 
as long as they respect gnuplot's syntax. Not shown in this example, but 
care is necessary to adequately scape any eventual special character 
like "\", "&". In Perl for example the sigils "$", "@", and "%" need to 
be escaped when writing a gnuplot file using "\". Other precautions may 
apply in other languages.

Many script languages hace wrapper modules for gnuplot that may make 
life easier. I personally prefer the above method though.

Best of luck

Hernán


Den 2026-03-29 kl. 19:32, skrev Bjorn Buckwalter:
> Hi Hernán and thanks for the suggestion.
>
> Do I understand correctly that you propose using a script written in 
> another language to generate the gnuplot script (the "configuration 
> file")? This may indeed be a good option, to generate a verbose and 
> repetitive but straight-forward gnuplot script.
>
> I will admit that I was rather happy to have my plotting 
> infrastructure being only self-contained gnuplot code, but I will 
> seriously consider this.
>
> Thanks,
> Bjorn
>
>
>
>
> On Sun, Mar 29, 2026 at 12:23 PM Hernán De Angelis 
> <var...@gm...> wrote:
>
>     You may already had this suggestion, as in using variables, but
>     consider
>     that given the length and complexity of your command, it is perhaps a
>     better idea to use a script to do all steps from building your set of
>     plot instructions, writing them to a configuration file, and then
>     running the gnuplot command. I do this all the time to a good effect.
>
>     /H.
>
>     Den 2026-03-29 kl. 11:49, skrev Bjorn Buckwalter:
>     > Thanks Jesper and Philpp. Jespers suggestion with variables can
>     likely help
>     > – I will try it!
>     >
>     > 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 <http://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
>
>     _______________________________________________
>     gnuplot-info mailing list
>     gnu...@li...
>     Membership management via:
>     https://lists.sourceforge.net/lists/listinfo/gnuplot-info
>

Re: [Gnuplot-info] Managing long/complicated plot commands?

[Bjorn B. <bjo...@gm...>]

Hi Hernán and thanks for the suggestion.

Do I understand correctly that you propose using a script written in
another language to generate the gnuplot script (the "configuration file")?
This may indeed be a good option, to generate a verbose and repetitive but
straight-forward gnuplot script.

I will admit that I was rather happy to have my plotting infrastructure
being only self-contained gnuplot code, but I will seriously consider this.

Thanks,
Bjorn





On Sun, Mar 29, 2026 at 12:23 PM Hernán De Angelis <
var...@gm...> wrote:

> You may already had this suggestion, as in using variables, but consider
> that given the length and complexity of your command, it is perhaps a
> better idea to use a script to do all steps from building your set of
> plot instructions, writing them to a configuration file, and then
> running the gnuplot command. I do this all the time to a good effect.
>
> /H.
>
> Den 2026-03-29 kl. 11:49, skrev Bjorn Buckwalter:
> > Thanks Jesper and Philpp. Jespers suggestion with variables can likely
> help
> > – I will try it!
> >
> > 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
> >>
> > _______________________________________________
> > 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
>

Re: [Gnuplot-info] Managing long/complicated plot commands?

[Bjorn B. <bjo...@gm...>]

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. 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
>

Re: [Gnuplot-info] Managing long/complicated plot commands?

[hchiPer <hc...@gm...>]

I'm willing to test your plot command, but I can't because it is full of 
functions, parameters, script arguments and referenced files that you 
don't provide:
I get an 'undefined function: lon' error, not 'invalid character \'

I was only able to find world_110m.txt from this page: 
https://gnuplotting.org/tag/parametric/ (I presume it's the one you are 
using but I'm not sure).

Le 28/03/26 à 22:13, Bjorn Buckwalter a écrit :
> HI all,
>
> 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

Re: [Gnuplot-info] Managing long/complicated plot commands?

[Philipp K. J. <ph...@ja...>]

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

Re: [Gnuplot-info] Managing long/complicated plot commands?

[Werner L. <wer...@pe...>]

I use plot-commands ext6ending over 200 - 300 lines, never had a problem.

Just my 5 Cents.


Enjoy your Sunday!
_________________________________________________
Dr. Werner Lippert

Founder
peaq GmbH                                       Mobile +41 79 218 84 26
Neugutstrasse 12                                wer...@pe...
CH-8304 Wallisellen                                          www.peaq.ch
_________________________________________________
Get the most out of your Hitachi Storage Systems
With peaq IOportal, SAM4H, Crosscharging and Lifecycle Services

On 29 Mar 2026, at 11:49, Bjorn Buckwalter <bjo...@gm...> wrote:

Thanks Jesper and Philpp. Jespers suggestion with variables can likely help
– I will try it!

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


_______________________________________________
gnuplot-info mailing list
gnu...@li...
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-info

Re: [Gnuplot-info] Managing long/complicated plot commands?

[Hernán De A. <var...@gm...>]

You may already had this suggestion, as in using variables, but consider 
that given the length and complexity of your command, it is perhaps a 
better idea to use a script to do all steps from building your set of 
plot instructions, writing them to a configuration file, and then 
running the gnuplot command. I do this all the time to a good effect.

/H.

Den 2026-03-29 kl. 11:49, skrev Bjorn Buckwalter:
> Thanks Jesper and Philpp. Jespers suggestion with variables can likely help
> – I will try it!
>
> 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
>>
> _______________________________________________
> gnuplot-info mailing list
> gnu...@li...
> Membership management via:https://lists.sourceforge.net/lists/listinfo/gnuplot-info

Re: [Gnuplot-info] Managing long/complicated plot commands?

[Bjorn B. <bjo...@gm...>]

Thanks Jesper and Philpp. Jespers suggestion with variables can likely help
– I will try it!

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
>

Re: [Gnuplot-info] Managing long/complicated plot commands?

[Philipp K. J. <ph...@ja...>]

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

Re: [Gnuplot-info] Managing long/complicated plot commands?

[Philipp K. J. <ph...@ja...>]

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] Managing long/complicated plot commands?

[Bjorn B. <bjo...@gm...>]

HI all,

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

Re: [Gnuplot-info] system independent access to home folder and script folder?

[theozh <th...@gm...>]

what about an if/else statement? Something like...

myHomeDir = GPVAL_SYSNAME[1:7] eq "Windows" ? system("echo %userprofile%") : system("echo ~")

Maybe you could also use the gnuplot variable GPVAL_PWD instead, which is the current working directory, but not necessarily the home directory.

[Gnuplot-info] Warning: slow font initialization

[Alan <ala...@gm...>]

Just updated to Gnuplot 6.0 patch level 4 (on Windows).
Running scripts now intermittently produces:
  Warning: slow font initialization
  qt_processTermEvent received a GE_fontprops event. This should not have
happened

Re: [Gnuplot-info] system independent access to home folder and script folder?

[Alan <ala...@gm...>]

Hello Ethan,

Thank you very much for noticing this thread!

Your solution does not work for me on Windows, for two separate reasons.

First of all, although Windows honors the forward slash as a path separator
(even cmd does!),
it seems Gnuplot doesn't always do path normalization,
so using the tilde in a forward slashed path on Windows fails.
Yet for shared scripts, of course I want to use the more standard forward
slash.

Second of all, if I do start a backslashed (i.e., Windows style) path
with a tilde, Gnuplot expands the tilde not to my home directory
but rather to my AppData\Roaming directory.
I would like access to the actual user home directory.

Thank you again for your help.
Alan Isaac


On Thu, Feb 26, 2026 at 2:36 PM Ethan Merritt <eam...@gm...> wrote:

> Gnuplot uses the linux/unix convention that ~ (tilde) represents the
> user's home directory.
> This is taken from the environmental variable HOME on linux and
> USERPROFILE on windows.
> So
>      gnuplot>   load "~/myscript.gp"
> loads myscript.gp from the user's home directory.
>      gnuplot>   set print "~/sub/output.txt"
>      gnuplot>   print "# New script"
>      gnuplot>   print "# that doesn't do anything"
>      gnuplot>   unset output
> will create and write to a new file in a subdirectory of the user's HOME
> directory.
>
>     Ethan
>
>
>
> On Thu, Feb 26, 2026 at 10:06 AM Alan <ala...@gm...> wrote:
>
>> Thanks for helping to look for a workaround, but I do not think so.
>>
>> Too many different computers and people involved.
>>
>> Let me ask this differently.
>> According to the manual (p.64), "The program then looks in the user’s HOME
>> directory".
>> So after launching, Gnuplot has already determined the location of the
>> home
>> directory.
>> Is there any way to ask Gnuplot for its value (as a string)?
>> If not, is there any reason for developers to avoid adding such a feature?
>>
>> Thanks, Alan
>>
>> On Thu, Feb 26, 2026 at 10:51 AM Peter Rockett <p.r...@sh...
>> >
>> wrote:
>>
>> > OK. Is the GNUPLOT_LIB environment variable what you need? Or the
>> > .gnuplot & GNUPLOT.INI startup files?
>> >
>> > P.
>> >
>> > On 26/02/2026 14:12, Alan wrote:
>> > > I would like to have data stored both
>> > > relative to the script file and more importantly relative to the home
>> > > directory,
>> > > and I would like an easy way to find the data on multiple systems
>> > > where the same relative relationships hold.
>> > >
>> > > Most important is being able to find the home directory
>> > > in the gnuplot script in a system independent way.
>> > > For example, I'd like my home and work computers
>> > > to have an output folder that is fixed relative to the home directory,
>> > > and I'd like Gnuplot to be able to find it without relying on
>> `system`,
>> > > which requires a different commands depending on the shell.
>> > > (Powershell or cmd on Windows, vs zsh on Mac, vs bash or dash on
>> Linux,
>> > > etc.)
>> > >
>> > > Also desirable is for the script to be able to find data
>> > > relative to the script's location, no matter what the
>> > > current working directory from which Gnuplot is launched.
>> > > As a simple example, suppose I am in folder `a` and do
>> > > gnuplot ./gnuplot/myscript.gpi
>> > > Then the pwd for Gnuplot becomes `a`, not the script directory.
>> > > In the script, I'd like to ask Gnuplot for the script directory.
>> > >
>> > > Hope that's clearer, Alan
>> > >
>> > > On Thu, Feb 26, 2026 at 7:34 AM Peter Rockett via gnuplot-info <
>> > > gnu...@li...> wrote:
>> > >
>> > >> Not totally clear of the objective here, but FWIW, you can specify a
>> > >> path using "./abc/efg/hij" (i.e. using a forward slash) on both
>> Windows
>> > >> /and/ Unix/Linux, whereas Unix does not understand the '\' character
>> in
>> > >> this context. So the forward slash is system independent.
>> > >>
>> > >> P.
>> > >>
>> > >> On 25/02/2026 18:10, Alan wrote:
>> > >>> Does Gnuplot offer a system independent way to
>> > >>> create directory names relative to the home folder (especially)
>> > >>> and also relative to the script folder?
>> > >>>
>> > >>> I am aware of `system`, but that depends on the OS shell.
>> > >>> I'm not a C programmer, but I believe the tricks to retrieve this
>> > >>> information in a system independent way are pretty standard. (?)
>> > >>>
>> > >>> Thank you.
>> > >>>
>> > >>> _______________________________________________
>> > >>> 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
>> > >>
>> > > _______________________________________________
>> > > 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
>>
>

Re: [Gnuplot-info] system independent access to home folder and script folder?

[Philipp K. J. <ja...@ie...>]

On Thu, 26 Feb 2026 14:22:58 -0500
Alan <ala...@gm...> wrote:

Have you checked out the built-in "pwd" command?

> I believe (?) your suggestion is equivalent to using `system`,
> so it is not a cross-platform solution. E.g., on Windows:
> 
> gnuplot> print "`echo $HOME`"  
> $HOME
> 
> (Note that $HOME is valid in PowerShell, but sadly
> cmd remains the Windows default shell, and changing
> that remains fraught.)
> 
> 
> 
> On Thu, Feb 26, 2026 at 1:46 PM Michael Schuh <
> Mic...@bo...> wrote:  
> 
> > How about this?
> >
> > michael@argon:~/tmp$ cat p.gnu
> > home = "dogrun"
> > print home
> > home = "`echo $HOME`"
> > print home
> >
> >
> > michael@argon:~/tmp$ gnuplot p.gnu
> > dogrun
> > /home/michael
> >
> > On Thu, Feb 26, 2026 at 10:06 AM Alan <ala...@gm...> wrote:
> >  
> >> Thanks for helping to look for a workaround, but I do not think so.
> >>
> >> Too many different computers and people involved.
> >>
> >> Let me ask this differently.
> >> According to the manual (p.64), "The program then looks in the
> >> user’s HOME directory".
> >> So after launching, Gnuplot has already determined the location of
> >> the home
> >> directory.
> >> Is there any way to ask Gnuplot for its value (as a string)?
> >> If not, is there any reason for developers to avoid adding such a
> >> feature?
> >>
> >> Thanks, Alan
> >>
> >> On Thu, Feb 26, 2026 at 10:51 AM Peter Rockett
> >> <p.r...@sh...  
> >> >  
> >> wrote:
> >>  
> >> > OK. Is the GNUPLOT_LIB environment variable what you need? Or the
> >> > .gnuplot & GNUPLOT.INI startup files?
> >> >
> >> > P.
> >> >
> >> > On 26/02/2026 14:12, Alan wrote:  
> >> > > I would like to have data stored both
> >> > > relative to the script file and more importantly relative to
> >> > > the home directory,
> >> > > and I would like an easy way to find the data on multiple
> >> > > systems where the same relative relationships hold.
> >> > >
> >> > > Most important is being able to find the home directory
> >> > > in the gnuplot script in a system independent way.
> >> > > For example, I'd like my home and work computers
> >> > > to have an output folder that is fixed relative to the home
> >> > > directory, and I'd like Gnuplot to be able to find it without
> >> > > relying on  
> >> `system`,  
> >> > > which requires a different commands depending on the shell.
> >> > > (Powershell or cmd on Windows, vs zsh on Mac, vs bash or dash
> >> > > on  
> >> Linux,  
> >> > > etc.)
> >> > >
> >> > > Also desirable is for the script to be able to find data
> >> > > relative to the script's location, no matter what the
> >> > > current working directory from which Gnuplot is launched.
> >> > > As a simple example, suppose I am in folder `a` and do
> >> > > gnuplot ./gnuplot/myscript.gpi
> >> > > Then the pwd for Gnuplot becomes `a`, not the script directory.
> >> > > In the script, I'd like to ask Gnuplot for the script
> >> > > directory.
> >> > >
> >> > > Hope that's clearer, Alan
> >> > >
> >> > > On Thu, Feb 26, 2026 at 7:34 AM Peter Rockett via gnuplot-info
> >> > > < gnu...@li...> wrote:
> >> > >  
> >> > >> Not totally clear of the objective here, but FWIW, you can
> >> > >> specify a path using "./abc/efg/hij" (i.e. using a forward
> >> > >> slash) on both  
> >> Windows  
> >> > >> /and/ Unix/Linux, whereas Unix does not understand the '\'
> >> > >> character  
> >> in  
> >> > >> this context. So the forward slash is system independent.
> >> > >>
> >> > >> P.
> >> > >>
> >> > >> On 25/02/2026 18:10, Alan wrote:  
> >> > >>> Does Gnuplot offer a system independent way to
> >> > >>> create directory names relative to the home folder
> >> > >>> (especially) and also relative to the script folder?
> >> > >>>
> >> > >>> I am aware of `system`, but that depends on the OS shell.
> >> > >>> I'm not a C programmer, but I believe the tricks to retrieve
> >> > >>> this information in a system independent way are pretty
> >> > >>> standard. (?)
> >> > >>>
> >> > >>> Thank you.
> >> > >>>
> >> > >>> _______________________________________________
> >> > >>> 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
> >> > >>  
> >> > > _______________________________________________
> >> > > 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
> >>  
> >  
> 
> _______________________________________________
> gnuplot-info mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-info

Re: [Gnuplot-info] system independent access to home folder and script folder?

[Ethan M. <eam...@gm...>]

Gnuplot uses the linux/unix convention that ~ (tilde) represents the user's
home directory.
This is taken from the environmental variable HOME on linux and USERPROFILE
on windows.
So
     gnuplot>   load "~/myscript.gp"
loads myscript.gp from the user's home directory.
     gnuplot>   set print "~/sub/output.txt"
     gnuplot>   print "# New script"
     gnuplot>   print "# that doesn't do anything"
     gnuplot>   unset output
will create and write to a new file in a subdirectory of the user's HOME
directory.

    Ethan



On Thu, Feb 26, 2026 at 10:06 AM Alan <ala...@gm...> wrote:

> Thanks for helping to look for a workaround, but I do not think so.
>
> Too many different computers and people involved.
>
> Let me ask this differently.
> According to the manual (p.64), "The program then looks in the user’s HOME
> directory".
> So after launching, Gnuplot has already determined the location of the home
> directory.
> Is there any way to ask Gnuplot for its value (as a string)?
> If not, is there any reason for developers to avoid adding such a feature?
>
> Thanks, Alan
>
> On Thu, Feb 26, 2026 at 10:51 AM Peter Rockett <p.r...@sh...>
> wrote:
>
> > OK. Is the GNUPLOT_LIB environment variable what you need? Or the
> > .gnuplot & GNUPLOT.INI startup files?
> >
> > P.
> >
> > On 26/02/2026 14:12, Alan wrote:
> > > I would like to have data stored both
> > > relative to the script file and more importantly relative to the home
> > > directory,
> > > and I would like an easy way to find the data on multiple systems
> > > where the same relative relationships hold.
> > >
> > > Most important is being able to find the home directory
> > > in the gnuplot script in a system independent way.
> > > For example, I'd like my home and work computers
> > > to have an output folder that is fixed relative to the home directory,
> > > and I'd like Gnuplot to be able to find it without relying on `system`,
> > > which requires a different commands depending on the shell.
> > > (Powershell or cmd on Windows, vs zsh on Mac, vs bash or dash on Linux,
> > > etc.)
> > >
> > > Also desirable is for the script to be able to find data
> > > relative to the script's location, no matter what the
> > > current working directory from which Gnuplot is launched.
> > > As a simple example, suppose I am in folder `a` and do
> > > gnuplot ./gnuplot/myscript.gpi
> > > Then the pwd for Gnuplot becomes `a`, not the script directory.
> > > In the script, I'd like to ask Gnuplot for the script directory.
> > >
> > > Hope that's clearer, Alan
> > >
> > > On Thu, Feb 26, 2026 at 7:34 AM Peter Rockett via gnuplot-info <
> > > gnu...@li...> wrote:
> > >
> > >> Not totally clear of the objective here, but FWIW, you can specify a
> > >> path using "./abc/efg/hij" (i.e. using a forward slash) on both
> Windows
> > >> /and/ Unix/Linux, whereas Unix does not understand the '\' character
> in
> > >> this context. So the forward slash is system independent.
> > >>
> > >> P.
> > >>
> > >> On 25/02/2026 18:10, Alan wrote:
> > >>> Does Gnuplot offer a system independent way to
> > >>> create directory names relative to the home folder (especially)
> > >>> and also relative to the script folder?
> > >>>
> > >>> I am aware of `system`, but that depends on the OS shell.
> > >>> I'm not a C programmer, but I believe the tricks to retrieve this
> > >>> information in a system independent way are pretty standard. (?)
> > >>>
> > >>> Thank you.
> > >>>
> > >>> _______________________________________________
> > >>> 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
> > >>
> > > _______________________________________________
> > > 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
>

Re: [Gnuplot-info] system independent access to home folder and script folder?

[Michael S. <Mic...@bo...>]

Correct, I wrote and tested my suggestion on a Debian system.  I didn't
test it on a Windows system.  Unfortunately, it sounds like my
suggestion will not work as written on a Windows system.

Michael

On Thu, Feb 26, 2026 at 11:23 AM Alan <ala...@gm...> wrote:

> I believe (?) your suggestion is equivalent to using `system`,
> so it is not a cross-platform solution. E.g., on Windows:
>
> gnuplot> print "`echo $HOME`"
> $HOME
>
> (Note that $HOME is valid in PowerShell, but sadly
> cmd remains the Windows default shell, and changing
> that remains fraught.)
>
>
>
> On Thu, Feb 26, 2026 at 1:46 PM Michael Schuh <
> Mic...@bo...> wrote:
>
> > How about this?
> >
> > michael@argon:~/tmp$ cat p.gnu
> > home = "dogrun"
> > print home
> > home = "`echo $HOME`"
> > print home
> >
> >
> > michael@argon:~/tmp$ gnuplot p.gnu
> > dogrun
> > /home/michael
> >
> > On Thu, Feb 26, 2026 at 10:06 AM Alan <ala...@gm...> wrote:
> >
> >> Thanks for helping to look for a workaround, but I do not think so.
> >>
> >> Too many different computers and people involved.
> >>
> >> Let me ask this differently.
> >> According to the manual (p.64), "The program then looks in the user’s
> HOME
> >> directory".
> >> So after launching, Gnuplot has already determined the location of the
> >> home
> >> directory.
> >> Is there any way to ask Gnuplot for its value (as a string)?
> >> If not, is there any reason for developers to avoid adding such a
> feature?
> >>
> >> Thanks, Alan
> >>
> >> On Thu, Feb 26, 2026 at 10:51 AM Peter Rockett <
> p.r...@sh...
> >> >
> >> wrote:
> >>
> >> > OK. Is the GNUPLOT_LIB environment variable what you need? Or the
> >> > .gnuplot & GNUPLOT.INI startup files?
> >> >
> >> > P.
> >> >
> >> > On 26/02/2026 14:12, Alan wrote:
> >> > > I would like to have data stored both
> >> > > relative to the script file and more importantly relative to the
> home
> >> > > directory,
> >> > > and I would like an easy way to find the data on multiple systems
> >> > > where the same relative relationships hold.
> >> > >
> >> > > Most important is being able to find the home directory
> >> > > in the gnuplot script in a system independent way.
> >> > > For example, I'd like my home and work computers
> >> > > to have an output folder that is fixed relative to the home
> directory,
> >> > > and I'd like Gnuplot to be able to find it without relying on
> >> `system`,
> >> > > which requires a different commands depending on the shell.
> >> > > (Powershell or cmd on Windows, vs zsh on Mac, vs bash or dash on
> >> Linux,
> >> > > etc.)
> >> > >
> >> > > Also desirable is for the script to be able to find data
> >> > > relative to the script's location, no matter what the
> >> > > current working directory from which Gnuplot is launched.
> >> > > As a simple example, suppose I am in folder `a` and do
> >> > > gnuplot ./gnuplot/myscript.gpi
> >> > > Then the pwd for Gnuplot becomes `a`, not the script directory.
> >> > > In the script, I'd like to ask Gnuplot for the script directory.
> >> > >
> >> > > Hope that's clearer, Alan
> >> > >
> >> > > On Thu, Feb 26, 2026 at 7:34 AM Peter Rockett via gnuplot-info <
> >> > > gnu...@li...> wrote:
> >> > >
> >> > >> Not totally clear of the objective here, but FWIW, you can specify
> a
> >> > >> path using "./abc/efg/hij" (i.e. using a forward slash) on both
> >> Windows
> >> > >> /and/ Unix/Linux, whereas Unix does not understand the '\'
> character
> >> in
> >> > >> this context. So the forward slash is system independent.
> >> > >>
> >> > >> P.
> >> > >>
> >> > >> On 25/02/2026 18:10, Alan wrote:
> >> > >>> Does Gnuplot offer a system independent way to
> >> > >>> create directory names relative to the home folder (especially)
> >> > >>> and also relative to the script folder?
> >> > >>>
> >> > >>> I am aware of `system`, but that depends on the OS shell.
> >> > >>> I'm not a C programmer, but I believe the tricks to retrieve this
> >> > >>> information in a system independent way are pretty standard. (?)
> >> > >>>
> >> > >>> Thank you.
> >> > >>>
> >> > >>> _______________________________________________
> >> > >>> 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
> >> > >>
> >> > > _______________________________________________
> >> > > 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
> >>
> >
>
> _______________________________________________
> gnuplot-info mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-info
>

Re: [Gnuplot-info] system independent access to home folder and script folder?

[Alan <ala...@gm...>]

I believe (?) your suggestion is equivalent to using `system`,
so it is not a cross-platform solution. E.g., on Windows:

gnuplot> print "`echo $HOME`"
$HOME

(Note that $HOME is valid in PowerShell, but sadly
cmd remains the Windows default shell, and changing
that remains fraught.)



On Thu, Feb 26, 2026 at 1:46 PM Michael Schuh <
Mic...@bo...> wrote:

> How about this?
>
> michael@argon:~/tmp$ cat p.gnu
> home = "dogrun"
> print home
> home = "`echo $HOME`"
> print home
>
>
> michael@argon:~/tmp$ gnuplot p.gnu
> dogrun
> /home/michael
>
> On Thu, Feb 26, 2026 at 10:06 AM Alan <ala...@gm...> wrote:
>
>> Thanks for helping to look for a workaround, but I do not think so.
>>
>> Too many different computers and people involved.
>>
>> Let me ask this differently.
>> According to the manual (p.64), "The program then looks in the user’s HOME
>> directory".
>> So after launching, Gnuplot has already determined the location of the
>> home
>> directory.
>> Is there any way to ask Gnuplot for its value (as a string)?
>> If not, is there any reason for developers to avoid adding such a feature?
>>
>> Thanks, Alan
>>
>> On Thu, Feb 26, 2026 at 10:51 AM Peter Rockett <p.r...@sh...
>> >
>> wrote:
>>
>> > OK. Is the GNUPLOT_LIB environment variable what you need? Or the
>> > .gnuplot & GNUPLOT.INI startup files?
>> >
>> > P.
>> >
>> > On 26/02/2026 14:12, Alan wrote:
>> > > I would like to have data stored both
>> > > relative to the script file and more importantly relative to the home
>> > > directory,
>> > > and I would like an easy way to find the data on multiple systems
>> > > where the same relative relationships hold.
>> > >
>> > > Most important is being able to find the home directory
>> > > in the gnuplot script in a system independent way.
>> > > For example, I'd like my home and work computers
>> > > to have an output folder that is fixed relative to the home directory,
>> > > and I'd like Gnuplot to be able to find it without relying on
>> `system`,
>> > > which requires a different commands depending on the shell.
>> > > (Powershell or cmd on Windows, vs zsh on Mac, vs bash or dash on
>> Linux,
>> > > etc.)
>> > >
>> > > Also desirable is for the script to be able to find data
>> > > relative to the script's location, no matter what the
>> > > current working directory from which Gnuplot is launched.
>> > > As a simple example, suppose I am in folder `a` and do
>> > > gnuplot ./gnuplot/myscript.gpi
>> > > Then the pwd for Gnuplot becomes `a`, not the script directory.
>> > > In the script, I'd like to ask Gnuplot for the script directory.
>> > >
>> > > Hope that's clearer, Alan
>> > >
>> > > On Thu, Feb 26, 2026 at 7:34 AM Peter Rockett via gnuplot-info <
>> > > gnu...@li...> wrote:
>> > >
>> > >> Not totally clear of the objective here, but FWIW, you can specify a
>> > >> path using "./abc/efg/hij" (i.e. using a forward slash) on both
>> Windows
>> > >> /and/ Unix/Linux, whereas Unix does not understand the '\' character
>> in
>> > >> this context. So the forward slash is system independent.
>> > >>
>> > >> P.
>> > >>
>> > >> On 25/02/2026 18:10, Alan wrote:
>> > >>> Does Gnuplot offer a system independent way to
>> > >>> create directory names relative to the home folder (especially)
>> > >>> and also relative to the script folder?
>> > >>>
>> > >>> I am aware of `system`, but that depends on the OS shell.
>> > >>> I'm not a C programmer, but I believe the tricks to retrieve this
>> > >>> information in a system independent way are pretty standard. (?)
>> > >>>
>> > >>> Thank you.
>> > >>>
>> > >>> _______________________________________________
>> > >>> 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
>> > >>
>> > > _______________________________________________
>> > > 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
>>
>

Re: [Gnuplot-info] system independent access to home folder and script folder?

[Michael S. <Mic...@bo...>]

How about this?

michael@argon:~/tmp$ cat p.gnu
home = "dogrun"
print home
home = "`echo $HOME`"
print home


michael@argon:~/tmp$ gnuplot p.gnu
dogrun
/home/michael

On Thu, Feb 26, 2026 at 10:06 AM Alan <ala...@gm...> wrote:

> Thanks for helping to look for a workaround, but I do not think so.
>
> Too many different computers and people involved.
>
> Let me ask this differently.
> According to the manual (p.64), "The program then looks in the user’s HOME
> directory".
> So after launching, Gnuplot has already determined the location of the home
> directory.
> Is there any way to ask Gnuplot for its value (as a string)?
> If not, is there any reason for developers to avoid adding such a feature?
>
> Thanks, Alan
>
> On Thu, Feb 26, 2026 at 10:51 AM Peter Rockett <p.r...@sh...>
> wrote:
>
> > OK. Is the GNUPLOT_LIB environment variable what you need? Or the
> > .gnuplot & GNUPLOT.INI startup files?
> >
> > P.
> >
> > On 26/02/2026 14:12, Alan wrote:
> > > I would like to have data stored both
> > > relative to the script file and more importantly relative to the home
> > > directory,
> > > and I would like an easy way to find the data on multiple systems
> > > where the same relative relationships hold.
> > >
> > > Most important is being able to find the home directory
> > > in the gnuplot script in a system independent way.
> > > For example, I'd like my home and work computers
> > > to have an output folder that is fixed relative to the home directory,
> > > and I'd like Gnuplot to be able to find it without relying on `system`,
> > > which requires a different commands depending on the shell.
> > > (Powershell or cmd on Windows, vs zsh on Mac, vs bash or dash on Linux,
> > > etc.)
> > >
> > > Also desirable is for the script to be able to find data
> > > relative to the script's location, no matter what the
> > > current working directory from which Gnuplot is launched.
> > > As a simple example, suppose I am in folder `a` and do
> > > gnuplot ./gnuplot/myscript.gpi
> > > Then the pwd for Gnuplot becomes `a`, not the script directory.
> > > In the script, I'd like to ask Gnuplot for the script directory.
> > >
> > > Hope that's clearer, Alan
> > >
> > > On Thu, Feb 26, 2026 at 7:34 AM Peter Rockett via gnuplot-info <
> > > gnu...@li...> wrote:
> > >
> > >> Not totally clear of the objective here, but FWIW, you can specify a
> > >> path using "./abc/efg/hij" (i.e. using a forward slash) on both
> Windows
> > >> /and/ Unix/Linux, whereas Unix does not understand the '\' character
> in
> > >> this context. So the forward slash is system independent.
> > >>
> > >> P.
> > >>
> > >> On 25/02/2026 18:10, Alan wrote:
> > >>> Does Gnuplot offer a system independent way to
> > >>> create directory names relative to the home folder (especially)
> > >>> and also relative to the script folder?
> > >>>
> > >>> I am aware of `system`, but that depends on the OS shell.
> > >>> I'm not a C programmer, but I believe the tricks to retrieve this
> > >>> information in a system independent way are pretty standard. (?)
> > >>>
> > >>> Thank you.
> > >>>
> > >>> _______________________________________________
> > >>> 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
> > >>
> > > _______________________________________________
> > > 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
>

Re: [Gnuplot-info] system independent access to home folder and script folder?

[Alan <ala...@gm...>]

Thanks for helping to look for a workaround, but I do not think so.

Too many different computers and people involved.

Let me ask this differently.
According to the manual (p.64), "The program then looks in the user’s HOME
directory".
So after launching, Gnuplot has already determined the location of the home
directory.
Is there any way to ask Gnuplot for its value (as a string)?
If not, is there any reason for developers to avoid adding such a feature?

Thanks, Alan

On Thu, Feb 26, 2026 at 10:51 AM Peter Rockett <p.r...@sh...>
wrote:

> OK. Is the GNUPLOT_LIB environment variable what you need? Or the
> .gnuplot & GNUPLOT.INI startup files?
>
> P.
>
> On 26/02/2026 14:12, Alan wrote:
> > I would like to have data stored both
> > relative to the script file and more importantly relative to the home
> > directory,
> > and I would like an easy way to find the data on multiple systems
> > where the same relative relationships hold.
> >
> > Most important is being able to find the home directory
> > in the gnuplot script in a system independent way.
> > For example, I'd like my home and work computers
> > to have an output folder that is fixed relative to the home directory,
> > and I'd like Gnuplot to be able to find it without relying on `system`,
> > which requires a different commands depending on the shell.
> > (Powershell or cmd on Windows, vs zsh on Mac, vs bash or dash on Linux,
> > etc.)
> >
> > Also desirable is for the script to be able to find data
> > relative to the script's location, no matter what the
> > current working directory from which Gnuplot is launched.
> > As a simple example, suppose I am in folder `a` and do
> > gnuplot ./gnuplot/myscript.gpi
> > Then the pwd for Gnuplot becomes `a`, not the script directory.
> > In the script, I'd like to ask Gnuplot for the script directory.
> >
> > Hope that's clearer, Alan
> >
> > On Thu, Feb 26, 2026 at 7:34 AM Peter Rockett via gnuplot-info <
> > gnu...@li...> wrote:
> >
> >> Not totally clear of the objective here, but FWIW, you can specify a
> >> path using "./abc/efg/hij" (i.e. using a forward slash) on both Windows
> >> /and/ Unix/Linux, whereas Unix does not understand the '\' character in
> >> this context. So the forward slash is system independent.
> >>
> >> P.
> >>
> >> On 25/02/2026 18:10, Alan wrote:
> >>> Does Gnuplot offer a system independent way to
> >>> create directory names relative to the home folder (especially)
> >>> and also relative to the script folder?
> >>>
> >>> I am aware of `system`, but that depends on the OS shell.
> >>> I'm not a C programmer, but I believe the tricks to retrieve this
> >>> information in a system independent way are pretty standard. (?)
> >>>
> >>> Thank you.
> >>>
> >>> _______________________________________________
> >>> 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
> >>
> > _______________________________________________
> > gnuplot-info mailing list
> > gnu...@li...
> > Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-info
>

Re: [Gnuplot-info] Generatin of function with non linear scale

[Patrick D. <pd...@gm...>]

OK,

Exactly what I wanted.
>
> > 
> > NO,
> > set logscale only set a log scale
> > I want to have the x values following a log scale like
> > 
> > 0.01 0.1 1 10 100 1000
> > 
> > I export the function to a file
> 
> Hi Patrick,
> Not sure, what exactly you are aiming for...
> What about the following?
> If you set samples 6, you will get the values you mentioned.
> Best, Theo.
> 
> reset session
> set logscale x
> set samples 11
> set xrange[0.01:1000]
> set table $Data
>      plot '+' u 1 w table
> unset table
> print $Data
> 
> Result:
>   0.01
>   0.0316228
>   0.1
>   0.316228
>   1
>   3.16228
>   10
>   31.6228
>   100
>   316.228
>   1000
> 
> 
> 
> 
> _______________________________________________
> gnuplot-info mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-info
> 

Re: [Gnuplot-info] system independent access to home folder and script folder?

[Alan <ala...@gm...>]

I would like to have data stored both
relative to the script file and more importantly relative to the home
directory,
and I would like an easy way to find the data on multiple systems
where the same relative relationships hold.

Most important is being able to find the home directory
in the gnuplot script in a system independent way.
For example, I'd like my home and work computers
to have an output folder that is fixed relative to the home directory,
and I'd like Gnuplot to be able to find it without relying on `system`,
which requires a different commands depending on the shell.
(Powershell or cmd on Windows, vs zsh on Mac, vs bash or dash on Linux,
etc.)

Also desirable is for the script to be able to find data
relative to the script's location, no matter what the
current working directory from which Gnuplot is launched.
As a simple example, suppose I am in folder `a` and do
gnuplot ./gnuplot/myscript.gpi
Then the pwd for Gnuplot becomes `a`, not the script directory.
In the script, I'd like to ask Gnuplot for the script directory.

Hope that's clearer, Alan

On Thu, Feb 26, 2026 at 7:34 AM Peter Rockett via gnuplot-info <
gnu...@li...> wrote:

> Not totally clear of the objective here, but FWIW, you can specify a
> path using "./abc/efg/hij" (i.e. using a forward slash) on both Windows
> /and/ Unix/Linux, whereas Unix does not understand the '\' character in
> this context. So the forward slash is system independent.
>
> P.
>
> On 25/02/2026 18:10, Alan wrote:
> > Does Gnuplot offer a system independent way to
> > create directory names relative to the home folder (especially)
> > and also relative to the script folder?
> >
> > I am aware of `system`, but that depends on the OS shell.
> > I'm not a C programmer, but I believe the tricks to retrieve this
> > information in a system independent way are pretty standard. (?)
> >
> > Thank you.
> >
> > _______________________________________________
> > 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
>

Re: [Gnuplot-info] Generatin of function with non linear scale

[<th...@gm...>]

> 
> NO,
> set logscale only set a log scale
> I want to have the x values following a log scale like
> 
> 0.01 0.1 1 10 100 1000
> 
> I export the function to a file

Hi Patrick,
Not sure, what exactly you are aiming for...
What about the following?
If you set samples 6, you will get the values you mentioned.
Best, Theo.

reset session
set logscale x
set samples 11
set xrange[0.01:1000]
set table $Data
     plot '+' u 1 w table
unset table
print $Data

Result:
  0.01
  0.0316228
  0.1
  0.316228
  1
  3.16228
  10
  31.6228
  100
  316.228
  1000

Re: [Gnuplot-info] system independent access to home folder and script folder?

[Peter R. <p.r...@sh...>]

Not totally clear of the objective here, but FWIW, you can specify a 
path using "./abc/efg/hij" (i.e. using a forward slash) on both Windows 
/and/ Unix/Linux, whereas Unix does not understand the '\' character in 
this context. So the forward slash is system independent.

P.

On 25/02/2026 18:10, Alan wrote:
> Does Gnuplot offer a system independent way to
> create directory names relative to the home folder (especially)
> and also relative to the script folder?
>
> I am aware of `system`, but that depends on the OS shell.
> I'm not a C programmer, but I believe the tricks to retrieve this
> information in a system independent way are pretty standard. (?)
>
> Thank you.
>
> _______________________________________________
> gnuplot-info mailing list
> gnu...@li...
> Membership management via:https://lists.sourceforge.net/lists/listinfo/gnuplot-info