This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: W2K Terminal Services and multiple users running X


On Wed, 24 Mar 2004, Harold L Hunt II wrote:

> Igor Pechtchanski wrote:
>
> > 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?
>
> I'm pretty sure you would still be messed up by batch files not having
> the concept of assigning the output of a program to an environment
> variable.

Well, the point was that the NT command subset *does* have this concept.
The syntax would be something like (this prints it, but you get the
point):

FOR /F "tokens=*" %%G IN ('dir /b /o:-d') DO @(IF NOT DEFINED notfirst (echo %%G & call SET notfirst=1))

> There is a hack you can sort of do, which I have done, which
> is to have your program generate a batch file that sets the value of an
> env var, then CALL that batch file from your original batch file.  Of
> course, this do nothing to solve the mutli-user problem since you would
> have to know the name of the batch file that was assigned, which is a
> nice Catch-22 back to the problem of not being able to assign the output
> of programs to an env var.

As mentioned above, we may need to resort to this hack for Win9x.

> I'm pretty sure it wouldn't be possible unless we had XWin.exe launched
> directly, then have it pre-process, write out to a temp file, and run a
> specified batch script.  Sounds kinda weird to me and like just using
> shell scripts would be easier and less to maintain.
>
> What do you think?
> Harold

Nah, we probably should just call a shell script on Win9x...
Fortunately, we can test the output of "VER" to see if we're on Win9x...
Unfortunately, if we do go to the trouble of writing the shell script, we
might as well use it everywhere.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]