Menu ▾ ▴

#300 Detect (non-) interactive mode in script

open
nobody
None
5
2025-05-12
2025-04-17
Daniel Dan K.
No

Hello,

please help in figuring out how to detect whether a gnuplot script runs in batch mode, i.e., called from bash (Unix) or command interpreter (Windows) or has been loaded from the gnuplot console (i.e. using call command).

For example, it would be great if a variable, e.g., interactive, would be set if the console is open. Based on detecting this variable the code could execute conditionally. This example is explained in more details here: https://psy.swansea.ac.uk/staff/carter/gnuplot/gnuplot_batch.htm

Thanks.
Daniel

PS: This is a follow-up to #290

Discussion

  • Ethan Merritt

    Ethan Merritt - 2025-04-17

    It would be possible to provide a user-visible version of gnuplot's internal state variable "interactive". However I very much suspect that this doesn't exactly match what you want. For example gnuplot considers itself to be "not interactive" while it is executing a load <file> command, even if the load command was typed interactively by the user. Conversely, gnuplot can switch to what it considers interactive mode even when running in batch mode or from a pipe, if it needs to handle possible user/mouse/keyboard input.

    I am afraid "... when the console is open" doesn't mean anything to me. Is that a Windows thing? If so then I think you need some query to the Windows environment, not to gnuplot, although maybe you could invoke that query from inside gnuplot via a system() command. But it would not be portable.

     

    • Daniel Dan K.

      Daniel Dan K. - 2025-04-19

      With "when the console is open" I mean that gnuplot offers a line input where the user can type in commands, e.g., when gnuplot is called without any options.

      Compare this to "batch mode" when gnuplot is called with a filename of a file containing gnuplot commands. Here, the use cannot type in any commands as no line input (my term: "console") is available.

      Does that explain what I mean with "interactive"?

       

      • Ethan Merritt

        Ethan Merritt - 2025-04-19

        Yeah, but as I said that doesn't exactly match what "interactive" means to gnuplot. To first approximation what gnuplot knows is whether the input stream it is expecting to read the next command from is a terminal.  Code excerpt from start of program here:

        #if defined(_WIN32) && !defined(WGP_CONSOLE)
                TextShow(&textwin);
                interactive = TRUE;
#else
                interactive = isatty(fileno(stdin)); 
#endif

        But then the "interactive" flag is reevaluated every time the input source changes, which includes load commands and some function calls. So if you were to put some conditional code in a script or function definition, it might well always report interactive FALSE even though the program is running from a terminal.

         

  • Daniel Dan K.

    Daniel Dan K. - 2025-05-09

    OK, thanks for the explanation.
    I think my request boils down to be able to detect whether the script runs in an environment where the user can enter commands or not.
    For example if I execute gnuplot as follows: gnuplot -c plot.gp datafile.txt , the user cannot enter commands as there's no tty attached to the input.
    Compare this to executing gnuplot and then entering call "plot.gp" "datafile.txt". Here, obviously, the user is able to enter gnuplot commands as a tty is attached to gnuplots stdin and the script should be able to query this state.

    So there's a difference between the two execution environments and it should be programmatically detectable if command input by the user is possible. That state may be semantically different from the "interactive" variable in gnuplot code.

    But I admit there are more important things to work on in gnuplot :-)

     

    • Ethan Merritt

      Ethan Merritt - 2025-05-09

      I think that what you are asking for is impossible.

      How would the program know whether you will be able to type commands in the future? Let us say you have a script setup.gp containg a bunch of preliminary stuff you want to do before making a plot. This setup operation might plausibly want to use your hypothetical command to check whether the following plot command will be coming from the user or from another file. But consider the following two scenarios:
      gnuplot setup.gp file2.gp
      gnuplot setup.gp -
      In the case of the first scenario the subsequent plot will be made by loading a file. As I understand it you want your hypothetical test for "interactive" to return FALSE. In the case of the second scenario, after the program executes the setup script further input will come from stdin, which probably would be the user typing to the console. In this case your hypotheical command would return TRUE. But how is the program to know while executing setup.gp which of the two futures will occur?

      For further fun, and to show that even inspection of the shell command from inside the program would not help, consider a third possibility:
      gnuplot setup.gp - < file3.gp
      As in scenario 2 after the setup further commands will come from stdin but this time stdin is not the console but another file.

       

      Last edit: Ethan Merritt 2025-05-09

  • Hiroki Motoyoshi

    Hiroki Motoyoshi - 2025-05-10

    Perhaps what the original poster of this ticket truly wants is not to know whether the current state of gnuplot is interactive, but rather to be able to specify at startup whether the script being executed should behave interactively or not.

    If that's the case, how about adding the following lines at the beginning of your script?

    if ( ARGC >= 1 && ARGV[1] eq "-i" ) { interactive = 1 }

if ( exist("interactive") ) {
  <Actions in Interactive Mode>
} else {
  <Actions in Not-Interactive Mode>
}

    You can run the script in different modes as follows:

    gnuplot -c script.gp -i    ### => Interactive
gnuplot -c script.gp       ### => Not-Interactive
gnuplot script.gp          ### => Not-Interactive
gnuplot -e "interactive=1" script.gp ### => Interactive

    With this approach, you can change the script's behavior depending on the mode. On Windows, you could use "/i" instead of "-i", and there are probably other variations as well.

    Sorry if I'm off the mark here, but I hope this might be of some help.

     

    • Daniel Dan K.

      Daniel Dan K. - 2025-05-12

      Dear Hiroki-san,

      Thank you for your contribution. Considering the complexity described by Ethan, I think yours is a simple, good and pragmatic solution.

      That will do.

      Best regards,
      Dan

       

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.