On Wed, 24 Mar 2004, Harold L Hunt II wrote:
Igor Pechtchanski wrote:
Harold,
... but the true difficulty in that is communicating the assigned
display number back to the shell from which XWin was launched so that X
programs can know the correct display to connect to.
Why not have XWin write its display number to a file in /var/run, e.g.,
/var/run/XWin.$$.display, where "$$" stands for the PID of the XWin
process? Since anyone who started XWin in the background from a shell
script will have access to its PID via $!, the following idiom will work:
XWin -multiwindow -emulate3buttons &
XWINPID=$!
DISPLAY_FILE=/var/run/XWin.$XWINPID.display
while [ ! -e "$DISPLAY_FILE" ]; do sleep 1; done
DISPLAY="`cat "$DISPLAY_FILE"`"
Unfortunately, this approach won't work from .bat scripts (since they
aren't aware of Cygwin process IDs). It also won't work if "cygstart
XWin" is used. Any ideas on how to address it?
Igor
Batch scripts was more of my concern... it would be possible to do from
a Cygwin shell like you describe (though I did not have all of the
tricks in mind).
Maybe the solution is to make the batch files just launch a shell script
to do the heavy lifting... sort of cheating but if it makes it possible
then it is acceptable to me.
Harold
Harold,
It might be possible to have the batch file check for the existence of the
display file. A rather crude first approximation would be (1) "sleep" for
a bit, then (2) do "dir /b /o:-d c:\cygwin\var\run\XWin.*.display" and (3)
extract the first file, then (4) "type" this file to get the display
number.
There may also be a way of guessing whether the file was created by the
current instance of XWin I don't have it fleshed out yet, but something
like: (1) check if c:\cygwin\var\run\XWin.lock.display exists, (2) if not,
create it, (3) run XWin, (4) sleep in a loop while the first file returned
by "dir /b /o:-d c:\cygwin\var\run\XWin.*.display" is XWin.lock.display;
finally, (5) extract the first file and (6) "type" the file to get the
display number. The XWin.lock.display will serve as both a lock file for
concurrent invocations (still not foolproof, but much better than
nothing), and also as a marker (it will be the newest such file until XWin
creates one, so it will be first in the list). Of course, step (7) is to
remove the lock file...
Hope this makes sense. I think I can implement the above with the NT
command subset (cmd.exe commands). I'm not sure if the limited
expressiveness of command.com on Win9x systems will allow this. Any
takers?