newinst is a small proof of concept program with which you can create a new instance of an already running task.
Download the source using mercurial:
$ hg clone http://bitbucket.org/panzi/newinst
Or any download manager:
$ wget http://bitbucket.org/panzi/newinst/get/tip.tar.bz2 $ tar xvjf tip.tar.bz2
Compile and run:
$ cd newinst $ make $ ./newinst --help
Usage: ./newinst [--fork] [--pid] PID ./newinst [--fork] --wid WID ./newinst [--fork] --select [--frame] OPTIONS: -h, --help display this help message -p, --pid make new instance of the process denoted by PID (process id) -w, --wid make new instance of the process denoted by WID (window id) -s, --select select a window with the mouse to determine the process of which a new instance shall be created --frame when using --select, get the WID of the window frame -f, --fork fork new process
In order to get a crosshair with which you can click a window of which you want to create a new instance do:
$ ./newinst --fork --select
--fork the process will not block your shell.
There are several issues with this proof of concept. I don't think they can be overcome.
The window manager has to set the _NET_WM_PID X-Window property of windows in order to work. E.g. kwin (and most modern window managers) do this, it seems there are cases where an application can screw this up. E.g. gvim forks so a shell from which it was started isn't blocked. It seem to do this after the window is created and thus the _NET_WM_PID property contains an old PID that doesn't exist any more. In the best case this program just fails, in the worst case another (wrong!) program has acquired this PID and gets copied instead. This way an other user might trick you into executing an application with your access rights!
From the last point one can derive that this only works on X11 platforms.
Actually this program only works on Linux (+X11) because these files in the /proc filesystem are accesed:
/proc/$PID/cmdline /proc/$PID/environ /proc/$PID/exe
There are possible race conditions during the lookup of the executable file. Similar like what I've mentioned in _NET_WM_PID Support it might happen that the process in question quits during the execution of this program and another process acquires the same PID, though this is very unlikely.
Remote Windows and Faked PIDs
If the denoted window is from a tunneled X11 client the PID might point to a process within the context of the remote machine. Any local process of the same PID will be used instead, which is plain wrong. Also it seems like it is possible for the X11 client to manipulate the _NET_WM_PID property, possibly faking a PID. See also RaceConditions.
Chroot and Sandboxes
This program does not detect whether the process to copy is in a chroot environment, sandbox or similar, thus all paths might point to completely different files or the newly started process has more access rights than intended. See also RaceConditions.