romeynj wrote: > I have a script that works fine for Win95/98, however it needs to be > modified to also work for NT/2000. The script currently uses the "choice" > command to ask the user several questions. Based on their responses, > different version of software are then installed onto their machines. Can > any of you point me in the right direction to find some information on > alternatives for using "choice"? Thanks for any help you can give.
You can copy CHOICE from Win95/98 to c:\winnt\system32 and it will work. However, in NT/2000 you should ONLY use it for capturing single-keystroke responses from the user in an interactive process. Don't use it in a non-interactive process as a method of delaying up to 99 seconds. You must avoid using it as a delay because, in the multi-tasking environment of NT/2000, sooner or later two or more concurrent instances of CHOICE (one interactive waiting for user input, one or more non-interactive delays) will execute and they will all clobber each other; you will never be able to figure out what happened.
romeynj wrote: > Thanks for the suggestion. However, I don't always know what OS the user is > using when running the script (It could be 95, 98, NT or 2000). We're > trying to make the script as seamless as possible without requiring the user > to load additional code to his machine before continuing with execution of > the script. Is there an alternative to using choice?
You mean a single alternative, other than CHOICE, that works on any version of Windows? I can't think of one.... Why not have your script determine which environment the user is in? If it's Win2000, you can use 'SET /P' to read input. If it's NT4.0, you can use a batch file to get user input. Otherwise, assume that the environment is Win9x and that CHOICE is available.
> Phil Robyn wrote in message <3AA00AD5.AD7A4...@uclink.berkeley.edu>...
> >You can copy CHOICE from Win95/98 to c:\winnt\system32 and it > >will work. However, in NT/2000 you should ONLY use it for capturing > >single-keystroke responses from the user in an interactive process. > >Don't use it in a non-interactive process as a method of delaying up > >to 99 seconds. You must avoid using it as a delay because, in the > >multi-tasking environment of NT/2000, sooner or later two or more > >concurrent instances of CHOICE (one interactive waiting for user > >input, one or more non-interactive delays) will execute and they will > >all clobber each other; you will never be able to figure out what happened.
> > Thanks for the suggestion. However, I don't always know what OS the user is > > using when running the script (It could be 95, 98, NT or 2000). We're > > trying to make the script as seamless as possible without requiring the user > > to load additional code to his machine before continuing with execution of > > the script. Is there an alternative to using choice?
> You mean a single alternative, other than CHOICE, that works on any version > of Windows? I can't think of one.... Why not have your script determine > which environment the user is in? If it's Win2000, you can use 'SET /P' to > read input. If it's NT4.0, you can use a batch file to get user input. Otherwise, > assume that the environment is Win9x and that CHOICE is available.
> > Phil Robyn wrote in message <3AA00AD5.AD7A4...@uclink.berkeley.edu>...
> > >You can copy CHOICE from Win95/98 to c:\winnt\system32 and it > > >will work. However, in NT/2000 you should ONLY use it for capturing > > >single-keystroke responses from the user in an interactive process. > > >Don't use it in a non-interactive process as a method of delaying up > > >to 99 seconds. You must avoid using it as a delay because, in the > > >multi-tasking environment of NT/2000, sooner or later two or more > > >concurrent instances of CHOICE (one interactive waiting for user > > >input, one or more non-interactive delays) will execute and they will > > >all clobber each other; you will never be able to figure out what happened.
How about "ASK" from Norton?? Or search the web or search zdnet?
> > > Thanks for the suggestion. However, I don't always know what OS the user is > > > using when running the script (It could be 95, 98, NT or 2000). We're > > > trying to make the script as seamless as possible without requiring the user > > > to load additional code to his machine before continuing with execution of > > > the script. Is there an alternative to using choice?
> > You mean a single alternative, other than CHOICE, that works on any version > > of Windows? I can't think of one.... Why not have your script determine > > which environment the user is in? If it's Win2000, you can use 'SET /P' to > > read input. If it's NT4.0, you can use a batch file to get user input. Otherwise, > > assume that the environment is Win9x and that CHOICE is available.
> > > Phil Robyn wrote in message <3AA00AD5.AD7A4...@uclink.berkeley.edu>...
> > > >You can copy CHOICE from Win95/98 to c:\winnt\system32 and it > > > >will work. However, in NT/2000 you should ONLY use it for capturing > > > >single-keystroke responses from the user in an interactive process. > > > >Don't use it in a non-interactive process as a method of delaying up > > > >to 99 seconds. You must avoid using it as a delay because, in the > > > >multi-tasking environment of NT/2000, sooner or later two or more > > > >concurrent instances of CHOICE (one interactive waiting for user > > > >input, one or more non-interactive delays) will execute and they will > > > >all clobber each other; you will never be able to figure out what happened.
> How about "ASK" from Norton?? > Or search the web or search zdnet?
> LB
I think the original poster said he didn't want any third-party software.
> > using when running the script (It could be 95, 98, NT or 2000). We're > > trying to make the script as seamless as possible without requiring the user > > to load additional code to his machine before continuing with execution of > > the script. Is there an alternative to using choice?
>> I have a script that works fine for Win95/98, however it needs to be >> modified to also work for NT/2000. The script currently uses the "choice" >> command to ask the user several questions. Based on their responses, >> different version of software are then installed onto their machines. Can >> any of you point me in the right direction to find some information on >> alternatives for using "choice"? Thanks for any help you can give.
>You can copy CHOICE from Win95/98 to c:\winnt\system32 and it >will work. However, in NT/2000 you should ONLY use it for capturing >single-keystroke responses from the user in an interactive process. >Don't use it in a non-interactive process as a method of delaying up >to 99 seconds. You must avoid using it as a delay because, in the >multi-tasking environment of NT/2000, sooner or later two or more >concurrent instances of CHOICE (one interactive waiting for user >input, one or more non-interactive delays) will execute and they will >all clobber each other; you will never be able to figure out what happened.
I am interested in your remarks about concurrency. Is this experience or can you point to a URL giving the experience. What is the mechanism? Why the different behavior? -- Walter Briscoe
Walter Briscoe wrote: > In article <3AA00AD5.AD7A4...@uclink.berkeley.edu> of Fri, 2 Mar 2001 > 13:04:21 in alt.msdos.batch.nt, Phil Robyn <pro...@uclink.berkeley.edu> > writes > >romeynj wrote:
> >> I have a script that works fine for Win95/98, however it needs to be > >> modified to also work for NT/2000. The script currently uses the "choice" > >> command to ask the user several questions. Based on their responses, > >> different version of software are then installed onto their machines. Can > >> any of you point me in the right direction to find some information on > >> alternatives for using "choice"? Thanks for any help you can give.
> >You can copy CHOICE from Win95/98 to c:\winnt\system32 and it > >will work. However, in NT/2000 you should ONLY use it for capturing > >single-keystroke responses from the user in an interactive process. > >Don't use it in a non-interactive process as a method of delaying up > >to 99 seconds. You must avoid using it as a delay because, in the > >multi-tasking environment of NT/2000, sooner or later two or more > >concurrent instances of CHOICE (one interactive waiting for user > >input, one or more non-interactive delays) will execute and they will > >all clobber each other; you will never be able to figure out what happened.
> I am interested in your remarks about concurrency. > Is this experience or can you point to a URL giving the experience. > What is the mechanism? Why the different behavior?
This is experience gained from attempting to synchronize two separate but interrelated processes, each utilizing CHOICE to effect a fixed-length delay to wait for the other to complete an action. The invocation of CHOICE by the second process clobbers the CHOICE previously invoked by the first process. In a multi-tasking system there can be any number of processes running simultaneously; however, there seems to be only one keyboard buffer....
Example: Process A writes frequent messages to a log file, and Process B (see retail.cmd below) displays the last n lines of the log file every so many seconds. If line 38 below is changed to utilize CHOICE to implement the delay, the process will be clobbered as soon as any other CHOICE command is issued by another process. If a TEST version of Process A (the process that writes entries to the file that is being monitored by Process B) is implemented using CHOICE to effect a delay, then the 'clobbering' behavior will be immediately demonstrated.
==========begin file C:\cmd\TEST\retail.cmd ========== 001. @echo off 002. if [%1]==[?] goto :syntax 003. if [%1]==[/?] goto :syntax 004. if not exist "%2" goto :nofile 005. goto :begin 006. :nofile 007. echo File "%2" does not exist. 008. echo. 009. echo Press any key to EXIT. 010. pause > nul 011. goto :EOF 012. :syntax 013. echo. 014. echo %0 - run tail every x seconds 015. echo. 016. echo syntax: RETAIL {num of seconds} {file name} {num of lines} 017. echo. 018. echo usage: to monitor the 'tail' of a file (e.g., a system log file) 019. echo in a separate console window. To start the separate 020. echo console, type the following command at the CMD prompt: 021. echo. 022. echo start cmd /c c:\cmd\test\retail.cmd 5 \\bai3\data\bfs\ctmajf.log 10 023. echo. 024. echo where '5' is the number of seconds between displays 025. echo '\\bai3\data\bfs\ctmajf.log' is the file being monitored 026. echo '10' is the number of lines to be displayed from the end 027. echo of the file 028. echo. 029. goto :EOF 030. :begin 031. title monitoring file %2 032. set /a conlines = %3 + 2 033. mode con lines=%conlines% cols=100 034. color 1e 035. :LOOP 036. cls 037. call tail %2 %3 038. call c:\cmd\util\wait %1 039. goto :LOOP 040. :EOF 041. ==========end file C:\cmd\TEST\retail.cmd ==========
The called TAIL command is ==========begin file C:\cmd\TEST\tail.cmd ========== 001. @echo off 002. :: 003. :: show tail of {file} [ for {nnn} lines ] 004. :: 005. if [%1]==[] echo You must enter a file name.&goto :EOF 006. if not exist %1 echo File %1 does not exist.&goto :EOF 007. setlocal 008. set /a lines=%2 009. if not defined lines set /a lines=15 010. call wccount %1 011. if %lines% GTR %wccount% set /a lines=15 012. if %lines% GTR %wccount% set startline=1&goto :display 013. set /a startline = wccount - lines 014. 015. :display 016. more /e +%startline% %1 017. endlocal ==========end file C:\cmd\TEST\tail.cmd ==========
The called WCCOUNT command is ==========begin file C:\cmd\TEST\wccount.cmd ========== 001. @echo off 002. :: 003. :: new reccount using 'wc' from the Resource Kit 004. :: 005. if not exist %1 goto :NoFile 006. setlocal 007. set infile=%1 008. for /f "tokens=1* delims= " %%a in ( 009. 'wc %1' 010. ) do set recs=%%a 011. if "%2"=="." ( 012. echo File %1 contains %recs% records. 013. ) 014. endlocal&set %~n0=%recs%&goto :EOF 015. :NoFile 016. echo. File %1 does not exist. 017. goto :EOF 018. :EOF 019. ==========end file C:\cmd\TEST\wccount.cmd ==========
