W2K Terminal Services and multiple users running X

[Harold L Hunt II]

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?

>>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