Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#364 command line arguments to gnuplot script

None
closed-out-of-date
nobody
None
5
2013-09-24
2013-05-25
Ryo
No

People (including me) sometimes want to pass arguments to a gnuplot script like

$ gnuplot script.gp arg1 anotherarg yetanother

Since gnuplot already has the "call" mechanism, I wish that mechanism be accessible from the command line in one way or another. For example, we could make

$ gnuplot --call script.gp arg1 arg2 arg3 #--(1)

equivalent to

$ gnuplot -e 'call "script.gp" arg1 arg2 arg3' #--(2)

There are a few reasons why (1) is better than (2).

Using shell variables is rather tedious with (2):

$ gnuplot -e 'call "script.gp" '$shelvar' '$shelvar2

(have I gotten it right?) and it's impossible (or tedious) to include blanks in the arguments. Imagine doing this

$ gnuplot --call script.gp "arg with blank" "arg with $shelvar"

in the style of (2).

Another reason why (1) (or something like that) is better is that it would become possible to write a gnuplot-script executable: Call this script "myplot.gp"

#!/usr/bin/gnuplot --call
plot "$0" title "$1"

and then you could use it from the command line as

$ ./myplot.gp data1.dat "title of the plot"

Cheers,
Ryo

Discussion

1 2 > >> (Page 1 of 2)
  • Ethan Merritt
    Ethan Merritt
    2013-05-29

    It isn't gnuplot's job to sort out your command line syntax.
    Seems to me that your request boils down to a question about how to conveniently wrap calls to gnuplot in a script. Here's a ridiculously simple 3 line perl script that implements your first syntax above. The other variants are left as an exercise for the reader.
    #!\usr/bin/perl -w
    open(GNUPLOT, "|gnuplot -e '@ARGV'") or die "can't find gnuplot";
    close GNUPLOT;

     
    Last edit: Ethan Merritt 2013-05-29
  • Ryo
    Ryo
    2013-05-29

    It isn't gnuplot's job to sort out your command line syntax.

    I don't think that's a useful answer, because what I'm saying is that my proposal would make gnuplot more useful than it currently is. Do you object to improvements in usability? Or do you have a particular reason why it is better not to allow for a more convenient command line?

    If you search Google about this problem, you'll find many people asking the same question: How to pass command line arguments to a gnuplot script? Sometimes answers like your perl script are provided and sometimes not. I'm perfectly capable of coming up with such solutions as yours, but not all people are. Why not provide the most "obvious" solution (see below)?

    Moreover, it is a very COMMON practice that a command interpreter (which gnuplot is) passes arguments to the script:

    ruby script.rb arg1 arg2 arg3
    perl script.pl arg1 arg2 arg3
    gnuplot script.gp arg1 arg2 arg3 # why not?

    To be honest, it's inconceivable to me that gnuplot is not designed with this use in mind, because it's so obvious an extension. "What to do if one (non-optional) argument is given?" "Let's treat it as a script and execute it." "What if there are more than one argument?" "Well, let the rest be arguments to the script." "Good idea." --- This is too obvious to me to think otherwise. (I'm pretty sure that the creators of other command interpreters reasoned along these lines.)

    Even if you already treat the remaining arguments differently, you can still emulate the above behavior by something like what I originally proposed (something like "gnuplot --call script.gp arg1 . . .).

    In short, making gnuplot behave this way wouldn't harm anybody but it would enhance its usefulness.

     
  • Ethan Merritt
    Ethan Merritt
    2013-05-29

    One reason is that "gnuplot arg1 arg2 arg3" is already a valid command but has a different meaning. It means execute script arg1 and then execute script arg2 and then execute script arg3.

    You sort of sidestepped the question of whether a suitable script would suffice for the use you describe. If so, it could be distributed along with gnuplot for people who can't or don't want to write their own.

     
  • Ryo
    Ryo
    2013-06-06

    One reason is that "gnuplot arg1 arg2 arg3" is already a valid
    command but has a different meaning. It means execute script arg1
    and then execute script arg2 and then execute script arg3.

    I agree that is valid reason. I don't argue that we should break
    backward compatibility.

    You sort of sidestepped the question of whether a suitable script
    would suffice for the use you describe. If so, it could be
    distributed along with gnuplot for people who can't or don't want to
    write their own.

    That is very good idea. Shall I try to write such a script?
    You could review and test it and if you are satisfied you could
    distribute it.

    Ryo

     
  • Ryo
    Ryo
    2013-06-06

    Christoph,

    Shigeharu proposed a patch to add a '-c' command line parameter, see
    https://sourceforge.net/p/gnuplot/patches/622/

    Thanks for letting me know! -Ryo

     
  • Ethan Merritt
    Ethan Merritt
    2013-06-19

    A couple of thoughts after trying Shige's patch.

    1) Passing anything with quotes from the command line is problematic. This is made even worse by the current action of the "load" command, which strips quote characters. As the documentation says, this will change in a future version of gnuplot. If we start adding new commands or options that are sensitive to this, I think we had better sort out the "load" command itself as a first step.

    2) Would it provide most or all of the requested capability to make *argv[] available from inside the program? One way might be to load $1 = argv[1]; $2 = argv[2]; ... on entry. Another would be to re-use the macro syntax: @1 would be replaced with the contents of argv[1], @2 would be replaced with the contents of argv[2], and so on.

    A possible variant of (2) would be to add something like the -c command line option that has the effect of renumbering the internal copies of the argv[] contents. So
    gnuplot -e 'set term x11' -c A B C D
    would internally report @1 as A @2 as B and so on. That way you could add command line options in front of the -c parameters without messing up how they are refered to in a script.

     
  • Ethan Merritt
    Ethan Merritt
    2013-06-19

    A couple of thoughts after trying Shige's patch.

    1) Passing anything with quotes from the command line is problematic. This is made even worse by the current action of the "load" command, which strips quote characters. As the documentation says, this will change in a future version of gnuplot. If we start adding new commands or options that are sensitive to this, I think we had better sort out the "load" command itself as a first step.

    2) Would it provide most or all of the requested capability to make *argv[] available from inside the program? One way might be to load $1 = argv[1]; $2 = argv[2]; ... on entry. Another would be to re-use the macro syntax: @1 would be replaced with the contents of argv[1], @2 would be replaced with the contents of argv[2], and so on.

    A possible variant of (2) would be to add something like the -c command line option that has the effect of renumbering the internal copies of the argv[] contents. So
    gnuplot -e 'set term x11' -c A B C D
    would internally report @1 as A @2 as B and so on. That way you could add command line options in front of the -c parameters without messing up how they are refered to in a script.

     
  • Ethan Merritt
    Ethan Merritt
    2013-06-19

    Correction: I meant the "call" command, obviously, not the "load" command.

     
  • Ethan Merritt
    Ethan Merritt
    2013-09-13

    I've added a version of Shige's -c command line option to CVS. So
    gnuplot -persist -c 'script1' arg1 arg2 arg3
    is equivalent to
    gnuplot> call 'script1' arg1 arg2 arg3

    However, I still feel that the convention of macro-like substitution of the arguments for $1 .. $9 has serious limitations. This is largely because the idea long predated support for strings and string variables. For example, so far as I can see there is no way to write a script that can handle both these call sites:
    site 1:
    call 'myscript' "some.filename" ARG1 ARG2
    site 2:
    do for [file in "andy.dat beth.dat curt.dat dave.dat"] {
    call 'myscript' file ARG1 ARG2
    }

    The problem is that the first case would have to be handled as something like
    plot "$0" using ...
    whereas the second case would have to be
    plot $0 using ...
    Note the different quoting.

    I also find it very non-intuitive that
    call 'myscript' 3+4
    loads $0 with 3, $1 with +, and $2 with 4 rather than loading $0 with 7

    I am playing with a patchset that introduces a more C-like calling convention, under which that command would load ordinary gnuplot variables
    ARGC = 1
    ARG0 = "myscript"
    ARG1 = 7

    I.e., the script name at the call site would be followed by a comma-separated list of arguments that are parsed and evaluated as expressions.

     
1 2 > >> (Page 1 of 2)