|
From: Hernán De A. <var...@gm...> - 2026-03-29 17:53:26
|
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 > |