Writing Terminal Service Based Scripts (Part 12)

If you would like to read the other parts in this article series please go to:

  • Writing Terminal Service Based Scripts (Part 2)
  • Writing Terminal Service Based Scripts (Part 3)
  • Writing Terminal Service Based Scripts (Part 4)
  • Writing Terminal Service Based Scripts (Part 5)
  • Writing Terminal Service Based Scripts (Part 6)
  • Writing Terminal Service Based Scripts (Part 7)
  • Writing Terminal Service Based Scripts (Part 8)
  • Writing Terminal Service Based Scripts (Part 9)
  • Writing Terminal Service Based Scripts (Part 10)
  • Writing Terminal Service Based Scripts (Part 11)
  • Writing Terminal Service Based Scripts (Part 13)
  • Writing Terminal Service Based Scripts (Part 14)
  • Shortly after writing the previous article in this series, I realized that I had gotten ahead of myself. I had begun writing a script in part 10 that I had never finished. Being that the techniques that I had intended to use to finish the script in part 10 is also going to be used in some of the remaining scripts in this series, I want to take a step back and complete the script that I started in part 10.

    So What’s Missing?

    The biggest problem with our script as it exists right now is that it allows you to create a log, and view the log file’s contents, but it only allows you to view the current log. We need to modify the script so that you can view and print previous log files. Otherwise, there is no point in creating a logging mechanism that uses unique file names for each log.

    The biggest challenge in being able to view or print previous log file entries is that the user needs to be able to enter the file name of the log file that they want to view or print. Accepting user input has always been a bit of a challenge for the batch scripting language that we are using. Until the release of Windows 2000 there was simply no easy way of accepting user input. There were roundabout ways of accepting user input, and then acting on that input, but they were very tedious to code. Fortunately, Microsoft augmented the Set command to include the /P switch. This switch allows user input to be assigned to a variable. Although this which was originally a part of Windows 2000, it has been included in every subsequent version of Windows.

    The command syntax is fairly simple. It looks like this:

    Set /P variable=Prompt string

    In the command above, you would replace the word variable with the actual variable name that you want to use. The prompt string is actually a place where you can enter the text that you want Windows to display prior to asking the user for input. One hint that I will give you about the prompt string is that I recommend that you make sure that the last character of the prompt string is a space. Otherwise, the user input will “bump into” the last word of the prompt string.

    To get a feel for how this command works, take a look at the three lines of code below:

    @echo off
    set /P var=type something
    echo %var%

    This simple script asks the user to type something, and then displays whatever was typed. In the first line of the script, we are simply issuing the @echo off command as a way of removing the clutter from the script’s output.

    The second line actually asks for the user’s input. In this case, I have used var as the variable, and my prompt string simply says “Type Something”.

    The last line of the script uses the echo command to display the contents of our variable. Notice that I have enclosed the variable in percentage signs.

    Now that you know how to accept user input, and how to reference the variable that the user input has been written to, let’s put this technique to work in our script. As you may recall, as our script currently exists, a user enters menu option B to view a previous report. Upon doing so, the script calls a subroutine named :sub_view that looks like this:

    :sub_view
    echo You chose to view a report
    for /F “tokens=2,3,4 delims=/ ” %%i in (‘date /t’) do set datefile=%%i%%j%%k.log
    Type  %datefile%.log |More
    goto:eof

    In its current form, the subroutine simply calculates a file name based on today’s date, and then displays the file name. However, we can easily modify this subroutine so that it asks the user to enter the month, day, and year of the report that they wish to view. Once the user has entered this information, we can use the information to construct a file name, and then retrieve the desired report. The code for doing so looks like this:

    :sub_view
    echo You chose to view a report
    set /P mth=Please enter the month in a two digit format (01 to 12)
    set /p dy=Please enter the day on which the report was created in a two digit format (01 to 31)
    set /p yr=Please enter the year of the report in a four digit format (2008)
    set datefile=%mth%%dy%%yr%.log
    echo.
    Type  %datefile% |More
    goto:eof

    Admittedly, this code leaves a lot to chance in its current form. After all, we are not doing anything to validate the input and make sure that valid numerical ranges are being entered. I will try to address input validation later on in the series. For right now I wanted to show you how I was able to accept multiple lines of input, and then concentrate that input into a single environment variable, which I was able to use for a file name.

    In this particular case, I used the variable name mth to hold the month value. I used dy to store a value for the day of the month, and I used yr as the variable for the year. Unfortunately, I could not just spell out month, day, and year because those are reserved words, and you cannot use reserved words as variable names.

    Once I finished accepting user input, I simply joined the variables together using the set command, and then appended .log to the end of the variable string to form a file name. I then assign the file name to the variable named datefile. All of this happens in the following line of code:

    set datefile=%mth%%dy%%yr%.log

    If you look at Figure A, you can see what the script looks like when it runs.


    Figure A:
    This is what the script currently looks like when it executes

    The last thing I want to talk about in this article is menu option C, which allows us to print a report. So far, we have not written any code for this particular menu option. The reason for this is that the code that we will use is almost identical to the code that we use to view a log file. If you look at the subroutine that we have been working with, you can see that the second to the last line of code is the one that actually displays the contents of the log file. By making one simple adjustment of this line of code, we can redirect the output from the screen to the printer.

    Below are two lines of code. The first one displays our log file on the screen. The second command prints the same log file to the printer. By placing the line side-by-side, you can see how similar they are to one another.

    Type  %datefile% |More
    Type  %datefile% >lpt1

    In the batch programming language that we are using, the > sign tells the script to perform redirection. The LPT1 told the script to perform redirection to the printer. There are two caveats that you need to be aware of though.

    First, for this technique to work, LPT1 must be captured to a printer. Second, some printers require a form feed in order to complete a print job. If you run into this situation, then you will need to add the following line of code:

    Echo .&10h >lpt1

    You can see the completed code here:

    @echo off
    set _menu=D
    :Loop
    cls
    Echo What do you want to do?
    Echo A: Create a new Query Users report|
    Echo B: View a Previous Report
    Echo C: Print a Previous Report
    Echo.
    Echo D: Quit
    Echo.

    Set /P _menu=Please enter your choice:

    if not “%_menu%”==”” set _menu=%_menu:~0,1%
    REM echo %_menu%

    If /i “%_menu%”==”A” goto sub_create
    If /i “%_menu%”==”B” goto sub_view
    If /i “%_menu%”==”C” goto sub_print
    if /I “%_menu%”==”D” goto:eof
    goto:loop

    :sub_create
    echo You chose to create a report
    @Echo Off
    Echo Creating log file.
    for /F “tokens=2,3,4 delims=/ ” %%i in (‘date /t’) do set datefile=%%i%%j%%k.log
    Query User > %datefile%
    Echo Log file created successfully.

    goto:eof

    :sub_view
    echo You chose to view a report
    set /P mth=Please enter the month in a two digit format (01 to 12)
    set /p dy=Please enter the day on which the report was created in a two digit format (01 to 31)
    set /p yr=Please enter the year of the report in a four digit format (2008)
    set datefile=%mth%%dy%%yr%.log
    echo.
    Type  %datefile% |More
    goto:eof

    :sub_print
    echo You chose to print a report
    set /P mth=Please enter the month in a two digit format (01 to 12)
    set /p dy=Please enter the day on which the report was created in a two digit format (01 to 31)
    set /p yr=Please enter the year of the report in a four digit format (2008)
    set datefile=%mth%%dy%%yr%.log
    echo.
    Type  %datefile% >lpt1
    Echo .&10h >lpt1
    goto:eof

    Conclusion

    In this article, I have shown you how to accept and use user input within your scripts. In the next article, I will show you how to apply this concept to the script that I began creating in Part 11.

    If you would like to read the other parts in this article series please go to:

  • Writing Terminal Service Based Scripts (Part 2)
  • Writing Terminal Service Based Scripts (Part 3)
  • Writing Terminal Service Based Scripts (Part 4)
  • Writing Terminal Service Based Scripts (Part 5)
  • Writing Terminal Service Based Scripts (Part 6)
  • Writing Terminal Service Based Scripts (Part 7)
  • Writing Terminal Service Based Scripts (Part 8)
  • Writing Terminal Service Based Scripts (Part 9)
  • Writing Terminal Service Based Scripts (Part 10)
  • Writing Terminal Service Based Scripts (Part 11)
  • Writing Terminal Service Based Scripts (Part 13)
  • Writing Terminal Service Based Scripts (Part 14)
  • About The Author

    Leave a Comment

    Your email address will not be published. Required fields are marked *

    This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

    Scroll to Top