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/ |\ _,,,---,,_ [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