How to send input to feedgnuplot from a different shell

[vapniks]

If I run feedgnuplot in one of my tmux windows like this:

> feedgnuplot --terminal dumb --exit

I can enter some numbers, and then press Ctrl+d and it will print a graph.
But if instead I trying sending output to its STDIN file descriptor from another shell, e.g:

echo "1\n2\n3\n" > /proc/$(pgrep feedgnuplot)/fd/0

and then pressing Ctrl+d in the feedgnuplot terminal/tmux window, then I get this error:

gnuplot> plot
              ^
         line 0: function to plot expected

If, before pressing Ctrl+d I type print and exit into the feedgnuplot window (directly, not via /proc), like this:

1
2
3
print
enter

then it works, and prints a graph.
But if I try sending those commands along with the data via /proc I get the same error:

echo "1\n2\n3\nprint\nexit" > /proc/$(pgrep feedgnuplot)/fd/0

In the feedgnuplot window:

gnuplot> plot
              ^
         line 0: function to plot expected

What's going on here?
How can I send input to feedgnuplot from a different shell?

[dkogan]

Hi. This isn't a feedgnuplot question. You're asking about externally injecting input into an application, which is a very nonstandard thing to do. Use a named pipe. Use the "mkfifo" tool to make a pair of pipes. Connect the output end of the pipe to feedgnuplot, and write your data to the input. You can probably get it working the way you're doing it, but it'll be a hack. Start by switching from a tty to a bare pipe by "cat | feedgnuplot ..." instead of a bare feedgnuplot. Then writing to /proc/$(pgrep feedgnuplot)/fd/0 will work, except for the EOF, but you could probably still get that running somehow. This is a hack. Use named pipes.

[vapniks]

Thanks. Actually I have a different problem (trying to pipe output into feedgnuplot via an rlwrap filter), but noticed the previously mentioned behaviour while trying to debug that problem, and wanted to know what's going on.
I've read some stuff about tty's and shells, but I'm still not exactly sure why that behaviour occurs. I guess the tty line driver can somehow differentiate between input received from keypresses and input received from /dev/pty/N, and is only passing on the former to the shell process, or is it something feedgnuplot is doing?

[dkogan]

feedgnuplot isn't doing anything remotely interesting here, which is why I say that you're not seeing a feedgnuplot problem. I'm doing effectively this: ``` $pipe_in- = IO::Handle->new(); $pipe_in-->fdopen(fileno(STDIN), "r"); my $line = $pipe_in->getline(); ``` From what I understand about rlwrap is that it's connecting a tty (the human typing into a terminal) to a program that isn't a tty (feedgnuplot). So your simplified example shouldn't be doing any tty anything. Is your problem simply "rlwrap around feedgnuplot doesn't work"? It appears to work here. What, exactly are you trying to do?

[vapniks]

No, I'm not wrapping feedgnuplot, I'm wrapping another repl and trying to pipe the output to feedgnuplot using a filter I wrote.
The piping seems to work fine with other shell commands, but when I try to pipe a list of numbers to feedgnuplot it just hangs and I have to SIGKILL it. I'm trying to figure out what's going on.

[dkogan]

OK. This is a bit too involved for me to dig into it. feedgnuplot does nothing interesting here, so it shouldn't act any differently. If you want to debug, first figure out if you do or do not have a tty. do ls -l on the feedgnuplot stdin, or put in an isatty() call. I'd avoid messing with a tty, if you can.

[vapniks]

Guess I'll have to strace it.