Nick Dokos <ndo...@gmail.com> writes: > Eric Schulte <schulte.e...@gmail.com> writes: > > >> The attached works fine for me (using sh since I don't have octave). >> >> #+name: uptime >> #+begin_src sh >> paste <(echo -e "1\n5\n15") <(uptime|sed 's/^.*average: //;s/,//g'|tr ' ' >> '\n') >> #+end_src >> > > Just an fyi: I had to set org-babel-sh-command to "bash" for this to > work. Why is "sh" the default value of this variable? >
I think sh is more portable, but I guess almost any system should have bash as well, I've just changed this default to bash. Cheers, > >> #+RESULTS: uptime >> | 1 | 0.02 | >> | 5 | 0.06 | >> | 15 | 0.05 | >> >> #+begin_src gnuplot :var data=uptime :results silent >> set xrange [0:] >> set yrange [0:] >> set title "uptime" >> set xlabel "minutes ago" >> set ylabel "load" >> plot data w lines >> #+end_src >> >> Ensure that the data you're passing into gnuplot is a table and not a >> string. Gnuplot blocks handle tables by writing them to a file, and >> then replacing the variable with the file name. As I recall gnuplot >> blocks assume string data already is a file name, so the variable is >> replaced directly. >> > > Ah, that explains everything! I also didn't have octave on this machine > so I wrote a python block. Initially, I had > > --8<---------------cut here---------------start------------->8--- > #+name: foo > #+begin_src python > x = ((1, 1), (2, 4), (3, 9)) > return "\n".join(["|%d | %d |" % (y[0], y[1]) for y in x]) > #+end_src > > > #+RESULTS: foo > | 1 | 1 | > | 2 | 4 | > | 3 | 9 | > --8<---------------cut here---------------end--------------->8--- > > which looks like a table, but isn't: the gnuplot block was blowing > up just like Eric F's. I replaced it with > > --8<---------------cut here---------------start------------->8--- > #+name: foo > #+begin_src python > x = ((1, 1), (2, 4), (3, 9)) > return x > #+end_src > > > #+RESULTS: foo > | 1 | 1 | > | 2 | 4 | > | 3 | 9 | > --8<---------------cut here---------------end--------------->8--- > > and everything is working. The only problem is that the results > *look* the same, so it's hard to see what the type is. > > Nick > > > > -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
