Re: W2K Terminal Services and multiple users running X
David, Please do not send Cygwin-related questions by private e-mail. All Cygwin questions should be sent to the appropriate Cygwin mailing list (see http://cygwin.com/lists.html). I have forwarded this question to the appropriate list, and set the Reply-To: accordingly. FYI, you can both post to the general Cygwin and Cygwin/X lists without subscribing, and read them via the web archives (see the links from http://cygwin.com/lists.html), or use the Gmane list-news interface (http://gmane.org/, or see the link from the main Cygwin page). Igor On Fri, 17 Sep 2004, David Suarez wrote: I am in planning on using Cygwin/X over terminal services. I was actually thinking of using the netstat command to determine the ports in use and infer from that the display numbers in use. I see that you guys had a discussion about scripting Cygwin/X on Terminal services but the conversations seemed to end with no conclusion. I was wondering if one of you has come up with a best practice for doing this since the mailing list discussion? Was an windows command shell deemed preferable to running a cygwin bash script? Did the lock files work well? What do you think are the +/- of using port numbers to do the same? I am not part of the cygwin mailing list, hope you don't mind that I am mailing you directly off list. Regards...djsuarez -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Happiness lies in being privileged to work hard for long hours in doing whatever you think is worth doing. -- Dr. Jubal Harshaw
Re: W2K Terminal Services and multiple users running X
Joel, Each user needs a unique display number, which is specified as N in the following: XWin :N Such as: XWin :0 (default display zero) XWin :1 (display one) You can either hard-code these in startup scripts for each user, or you can help us with the feature that automatically assigns display numbers... 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. Harold Joel Moots wrote: I am able to successfully run XWin after logging onto a W2K Server via Terminal Services, but if another user attempts to do the same thing at the same time, she is not allowed. Is there some way to set this up so that 2 instances of XWin can be running at the same time? Do we each need our own Cygwin /tmp dir? I found many references to Terminal Services in the mail list archives but none pertaining to multiple users. TIA, -joel
Re: W2K Terminal Services and multiple users running X
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 On Wed, 24 Mar 2004, Harold L Hunt II wrote: Joel, Each user needs a unique display number, which is specified as N in the following: XWin :N Such as: XWin :0 (default display zero) XWin :1 (display one) You can either hard-code these in startup scripts for each user, or you can help us with the feature that automatically assigns display numbers... 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. Harold Joel Moots wrote: I am able to successfully run XWin after logging onto a W2K Server via Terminal Services, but if another user attempts to do the same thing at the same time, she is not allowed. Is there some way to set this up so that 2 instances of XWin can be running at the same time? Do we each need our own Cygwin /tmp dir? I found many references to Terminal Services in the mail list archives but none pertaining to multiple users. TIA, -joel -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,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
Re: W2K Terminal Services and multiple users running X
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
Re: W2K Terminal Services and multiple users running X
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? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,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
Re: W2K Terminal Services and multiple users running X
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. 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. 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
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/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,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
Re: W2K Terminal Services and multiple users running X
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
Re: W2K Terminal Services and multiple users running X
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
--
