Thanks for the suggestion, Michael. Reading it led to a bit of a forehead
slap.
Unfortunately, that didn't work either. Curiously, it appears that
the "show()" command does not return.
----- CODE SECTION -------------
#!/usr/local/bin/python
import os,sys
import pylab
def main():
x = pylab.linspace(-10,10,100)
y = pylab.sin(x)
pylab.plot(x,y)
sys.stderr.write("Begun.")
pylab.show()
sys.stderr.write("Done.")
if __name__ == "__main__":
main()
---- END CODE -------------
When executed from the command line:
$ ./test.py &
. . . the plot displays; clicking on the X closes it, but the process keeps
on running.
When executed as an argument to python:
$ python test.py &
. . . the same behavior (except it's a python process which hangs).
The two sys.stderr.write() statements are for debugging. The first one
executes; the second does not. My conclusion is that the show() command does
not return.
···
----------
When I operate interactively,
the command "pylab.plot(x,y)" opens a widow labeled "Figure 1".
. . . then . . .
the command "show()" writes the plot to that window (i.e., sine plot).
Clicking the X in the figure window causes the window to disappear, but
the "show()" command fails to return.
--------------
So . . . I figure that the lack of show() returning is the root problem.
Any suggestions?
I'm running Fedora 8, python 2.5.1, and matplotlib 0.91.2-1.fc8 from the yum
repository. Backend is set to GTKAgg in my matplotlibrc file.
James
-------
On Monday 07 July 2008 17:29:16 you wrote:
Why do you want to "fork" the process? If you just run it in the
background it should have the desired effect:<begin tst.py>
from pylab import *
x = linspace(-10,10,100) # or load data from a file.
y = sin(x)
plot(x,y)
show()
<end tst.py>$ python tst.py&
Process remains in background running until the user closes the plot
window, at which point it terminates.Michael.
On 7 Jul 2008, at 2:30 PM, James K. Gruetzner wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'm not sure if this is the right venue for this question. I've
> searched the
> archives, but without success so far. If this is covered there (or
> elsewhere
> on the web), I'd apprciate a pointer to it so it doesn't duplicate
> bandwidth
> here.
>
> Anyway, what I'd like to do is have a python script which reads
> data from a
> file, displays an image/plot/whatever made from the data, and then
> exits,
> keeping the image displayed.
>
> I'm running Fedora 8, python 2.5.1, and matplotlib 0.91.2-1.fc8
> from the yum
> repository. Backend is set to GTKAgg in my matplotlibrc file.
>
> My initial attempt used the "double fork" method from the python
> cookbook:
>
> - -------------Code follows----------------------
> if __name__ == "__main__":
>
> #From Python Cookbook
> try:
> pid = os.fork()
> if pid > 0:
> # Exit first parent
> sys.exit(0)
> except OSError, e:
> print >>sys.stderr, "fork #1 failed: %d (%s)" %(e.errno,
> e.strerror)
> sys.exit(1)
>
> # Decouple from parent environment
> #os.chdir("/")
> os.setsid()
> os.umask(0)
>
> # Do second fork
> try:
> pid = os.fork()
> if pid > 0:
> # Exit from second parent; print eventual PID before exiting
> print "Image PID %d" % pid
> sys.exit(0)
> except OSError, e:
> print >>sys.stderr, "fork #2 failed: %d (%s)"%(e.errno,
> e.strerror)
> sys.exit(1)
>
> # Start the main loop to display image
> main()
>
> - --------------END CODE--------------------------------------
>
> The main() function reads the values appropriately into the
> variable "myarr",
> and then calls imshow and show:
>
> - ------------ Code follows -------------------
>
>
> pylab.imshow(myarr)
> pylab.show()
> - --------------END CODE--------------------------------------
>
> . . . and then exits.
>
> All works well until I try to kill the figure/image by clicking on
> the X in
> the upper-right corner. It disappears alright, but the process
> remains
> running, and I have to manually kill it with the kill -SIGTERM
> <pid> command.
>
> I'd like the process to die when I close the window.
>
> I'm really an application programmer, not a system programmer, and
> usually
> don't delve this deeply into process management, so I'm probably doing
> something extremely ignorant. Help is appreciated.
>
> Thanks!
>
> James
>
>
-------------------------------------------------------