Re: W2K Terminal Services and multiple users running X

[Igor Pechtchanski <pechtcha at cs dot nyu dot edu>]

On Thu, 25 Mar 2004, Harold L Hunt II wrote:

> Igor Pechtchanski wrote:
>
> > 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))
>
> Huh... I have never heard of this being supported in NT's cmd.  Are you
> sure that you can actually get the value stored into an env var?

Yep.  Try it (from the command line):

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

%val% will be set to the name of the last modified file in the current
directory.  Of course, for the batch file we'll use "%%G" instead of "%G".

> >>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.
>
> Possibly.  It might be a good idea to have a pure batch solution
> available so that people could adapt it if they had good reason to.  The
> default should probably just be a shell script though.
>
> Harold

Yes, but then the default batch should check the OS and bail out if it's
Win9x/ME.
	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