Problems for a neophyte

[JimBrandley]

I am a neophyte with respect to CMD files. I have inherited several large files that appear to have been poorly crafted, and was pleasantly surprised someone had created an IDE and debugger. While taking Take Command for a test spin, I observed the following:

• The tutorials provide an extremely brief introduction to the debugger.
• Searching the help file for "debug" produced no results.
• Searching the on-line FAQs for "debug" produced no results.
• Executing a prompt for a database instance name caused part of the response to appear in the prompt and part to be returned to the environment variable.
• I found no way to alter the value of an environment variable from the debugging session.
• If I select Debug/Jump to this line, thereafter, the highlighted line in the script display does not correspond to the line to execute.

Any help is appreciated.

Jim

 

[mikea]

I have v.11 on one machine and an upgrade to v.12 on another. With both of these, typing debug into the search window and clicking "List topics" produced a number of search hits, with the first being BDEBUGGER/IDE, the commands that open the TCC batch debugger. Do you get a message-box with "No topics found," instead? You might try a search for BDEBUGGER or IDE instead and see if that works.

That entry in the help file is fairly "bare-bones," to be sure.

Generally the help material related to batch file debugging is minimalist and I wish there were a lot more information available about it. I used the pre-TCC batch debugging system extensively, for years, and I still find the TCC batch debugging tool sometimes hard to wrap my mind around -- it's so very different from the old one and it isn't obvious to me how to do everything in it that I want to do.

As for:

Executing a prompt for a database instance name caused part of the response to appear in the prompt and part to be returned to the environment variable

...could you provide an example? You've referred there to "the environment variable" but it's impossible to tell what it is or how it was used.

These .cmd files you've inherited -- they are actual .cmd batch files and not 4NT/TCC .btm files, correct? My experience with the JP Software products -- which goes back quite a long time -- has been that they've done as much as possible to keep 4NT/TCC compatible with cmd.exe's batch files. But there isn't 100% compatibilty and sometimes .cmd files just plain confound 4NT or TCC.

At work we were handed a collection of extremely nasty .cmd files (containing no comments at all -- and may he who wrote them burn with shame forever for that). They're so grim that they've been handed off to an actual development team for debugging. They are having a terrible time with those batch files. I have been tempted to suggest that we load them into the TCC batch debugger -- maybe that would give us something of a head-start, as there's never been such a thing as a real debugger for cmd.exe batch files. But these batch files are so gross, I'm not sure if we'd even be able to get too far with the TCC debugger.

 

[rconn]

At work we were handed a collection of extremely nasty .cmd files (containing no comments at all -- and may he who wrote them burn with shame forever for that). They're so grim that they've been handed off to an actual development team for debugging. They are having a terrible time with those batch files. I have been tempted to suggest that we load them into the TCC batch debugger -- maybe that would give us something of a head-start, as there's never been such a thing as a real debugger for cmd.exe batch files. But these batch files are so gross, I'm not sure if we'd even be able to get too far with the TCC debugger.

The only potentially significant area of incompatibility with TCC and CMD is in the treatment of variables. TCC only requires a single leading %; CMD requires enclosing %'s, or sometimes just a single leading %, or sometimes two leading %'s. TCC can guess 99.99% of the time what the developer wants, but if they're concatenating several variables (especially a combination of environment variables with a trailing % and FOR variables with one or two leading %'s and no trailing %) it's possible for TCC to get confused. (Though perhaps not as confused as the original developer ...)

However, you can tell TCC to use the CMD variable syntax with the "CMDVariables=Yes" directive in your TCMD.INI. This breaks compatibility with TCC batch files and aliases, but if you're only running CMD files in the debugger it's your best bet.

The only other incompatibilities I've seen have been with people using undocumented CMD behavior (which I've usually then emulated), or relying on a bug in a particular version of CMD (which I've usually *not* emulated).

If these batch files don't run in the debugger (with CMDVariables=Yes), I'd be interested in seeing the relevant bits of them to know why.

 

[mikea]

The only potentially significant area of incompatibility with TCC and CMD is in the treatment of variables. TCC only requires a single leading %; CMD requires enclosing %'s, or sometimes just a single leading %, or sometimes two leading %'s. TCC can guess 99.99% of the time what the developer wants, but if they're concatenating several variables (especially a combination of environment variables with a trailing % and FOR variables with one or two leading %'s and no trailing %) it's possible for TCC to get confused.

It has been a while since I tried running a "pure" .cmd file under TCC or 4NT. There have been some (.cmd files wrapped around Perl scripts -- there's a thread about it here at the moment) that utterly confounded both JPS command processors. So with those, I just launch 'em with "cmd /c" and the problem is solved for the short term.

I also have had problems running .cmd files in 4NT/TCC when the person who wrote them tried not to defeat, but to use, delayed variable expansion (which I think of as a spawn of Satan). Sometimes "for" loops have been problematic, especially when they contain "tokens=" and "delims=".

(Though perhaps not as confused as the original developer ...)

:-)

However, you can tell TCC to use the CMD variable syntax with the "CMDVariables=Yes" directive in your TCMD.INI. This breaks compatibility with TCC batch files and aliases, but if you're only running CMD files in the debugger it's your best bet.

Thanks for the reminder. It's something I never think about...

If these batch files don't run in the debugger (with CMDVariables=Yes), I'd be interested in seeing the relevant bits of them to know why.

I'll pass along those relevant bits if ever I can persuade people to let me try this. As you might recall from past exchanges of e-mail, people at the place where I work have been extremely resistant to using anything that isn't cmd.exe -- a source of great frustration for me. I used 4NT and now TCC almost exclusively for tasks of my own. Well, perhaps if they become desperate enough trying to cope with these grim .cmd files, they'll take my suggestion. Then again, if they'd rather struggle, they won't... weird to me, how C++ and C# devs seem to just love cmd.exe batch files. One of them was pleased as punch with himself when he wrote a batch file with a recursive function. Ok, fine, so it was clever, but it was still a batch file. (Oh, don't get me started...)

 

[Charles Dye]

I also have had problems running .cmd files in 4NT/TCC when the person who wrote them tried not to defeat, but to use, delayed variable expansion (which I think of as a spawn of Satan). Sometimes "for" loops have been problematic, especially when they contain "tokens=" and "delims=".

Those are at least documented features. It's when they rely upon out-and-out bugs that you really want to slap their faces off.

 

[JimBrandley]

Guys - Thank you all for your responses. These scripts are used by our customers to install a new database or upgrade an existing DB to a new version. So, I must adhere strictly to CMD compatibility.

The prompt that failed was:
IF [%database%]==[] SET /P database="Please specify the Delmia Operations database (press Enter to Skip):"

And the environment variable I tried to correct was "database". If my terminology is incorrect, please let me know.

Thanks,

Jim

 

[Charles Dye]

The prompt that failed was:
IF [%database%]==[] SET /P database="Please specify the Delmia Operations database (press Enter to Skip):"

Why not just

IF NOT DEFINED DATABASE SET /P database="Please specify the Delmia Operations database (press Enter to Skip):"

Doesn't even CMD.EXE understand DEFINED?

 

[DMcCunney]

On Sun, Jul 31, 2011 at 12:21 PM, JimBrandley <> wrote:

> Guys - Thank you all for your responses. These scripts are used by our customers to install a new database or upgrade an existing DB to a new version. So, I must adhere strictly to CMD compatibility.
>
> The prompt that failed was:
> IF [%database%]==[] SET /P database="Please specify the Delmia Operations database (press Enter to Skip):"

How does it fail? Pasting that line into a TCC session here prints
the expected prompt.

> And the environment variable I tried to correct was "database". If my terminology is incorrect, please let me know.

How is that variable normally set? The test above prints the prompt
if it isn't defined.

> Jim

______
Dennis

 

[JimBrandley]

Rex - I do not see a ini file or cfg file (except updater.ini), or any other file that is updated when I save preferences. My installation is just a trial, and not registered. That may have an impact.

Here is a script that demonstrates another failure mode.

::----------------------------------------------
:: Test DB prompt
::----------------------------------------------
@ECHO OFF
SET LOGFILE=Upgrade_output.log
SET ERRORFILE=Upgrade_error.log
:: Parameters
SET database=%1
SET server=%2
SET ptdatabase=%3
SET StopOnError=%4
ECHO Note: 
ECHO You must have permissions to create objects in the target database.
ECHO The Pertinence Suite and/or Performance Tracker database must already exist. 
ECHO.
:: Prep the log file
ECHO. & ECHO. > %LOGFILE%
IF [%server%]==[] SET /P server="Please specify the server (press Enter to run locally):"
IF [%server%]==[] ECHO No server parameter provided - running locally & ECHO No server parameter provided - running locally >> %LOGFILE%
IF [%database%]==[] SET /P database="Please specify the Delmia Operations database (press Enter to Skip):"
IF [%database%]==[] ECHO No Delmia Operations database parameter provided - it will not be upgraded & ECHO No Delmia Operations database parameter provided - it will not be upgraded >> %LOGFILE%
IF [%ptdatabase%]==[] SET /P ptdatabase="Please specify the Performance Tracker database (press Enter to Skip):"
IF [%ptdatabase%]==[] ECHO No Performance Tracker database parameter provided - it will not be upgraded & ECHO No Performance Tracker database parameter provided - it will not be upgraded >> %LOGFILE%
ECHO "Selected instance name = "%database%
ECHO.

I press enter for the first prompt, then type Eagan1 for the second. This is the result from the TCC Prompt window:

TCC 12.11.72 x64 Windows 7 [Version 6.1.7600]
Copyright 2011 Rex Conn & JP Software Inc. All Rights Reserved
Your evaluation period expires in 28 days.
You can buy Take Command at [URL]http://jpsoft.com[/URL]
Note:
You must have permissions to create objects in the target database.
The Pertinence Suite and/or Performance Tracker database must already exist.
 
"Please specify the server (press Enter to run locally):"
No server parameter provided - running locally
"Please specify the Delmia Operatio[COLOR=red]agan1[/COLOR]tabase (press Enter to Skip):"E
TCC: Unknown command "agan1"
[C:\Program Files\JPSoft\TCMD12x64]

Note the red text that appeared in the middle of the prompt.

Thanks for your help.

Jim

 

[JimBrandley]

Charles - It is this way because that's what I inherited. If that's wrong, I will change it. Users can place the server and databse names on the command line. Our product installer does that. Hence, the values can come in as %1, %2, etc. If we just double-click the CMD file, we need to then get the names interactively.

Jim

 

[JimBrandley]

Why not just

IF NOT DEFINED DATABASE SET /P database="Please specify the Delmia Operations database (press Enter to Skip):"

Doesn't even CMD.EXE understand DEFINED?

I just tested this syntax - It works in the same way in ordinary CMD processing, and fails in the same way in the debugger.

Jim

 

[Charles Dye]

Charles - It is this way because that's what I inherited. If that's wrong, I will change it.

Not wrong. It looks a bit awkward to me, but I guess that's just a matter of taste.

 

[mikea]

Those are at least documented features. It's when they rely upon out-and-out bugs that you really want to slap their faces off.

Hmm. I don't remember having run across a .cmd file in which someone deliberately exploited a cmd.exe bug. Most people just seem to struggle to overcomes its weird limitations.

 

[Charles Dye]

It works as expected here (but I'm not running x64 Windows.)

Out of curiosity, do you have InputColors defined? What are the dimensions of your console window?

 

[Charles Dye]

Note the red text that appeared in the middle of the prompt.

Um. Are you saying that that text appeared in red on your screen, or did you highlight the offending text in red to make it stand out?

 

[JimBrandley]

Charles - No changes to colors or dimensions. The window is the default that appears when running tcmd.exe.

I suppose this could be a 64-bit issue. I am running 64-bit Windows 7 Enterprise edition. Would it be better to run the 32-bit version of tcmd.exe?

Jim

 

[JimBrandley]

Um. Are you saying that that text appeared in red on your screen, or did you highlight the offending text in red to make it stand out?

Sorry - that was not very clear. I changed the color to emphasize the text. The red overwrote what was originally at that position in the prompt when I entered the DB name.

Jim

 

[JimBrandley]

Not wrong. It looks a bit awkward to me, but I guess that's just a matter of taste.

I know what you mean. I have been a programmer since 1973, and I am picky about style too. CMD files are new to me, so I am too ignorant to have much of an opinion here.

Jim

 

[mikea]

The prompt that failed was:
IF [%database%]==[] SET /P database="Please specify the Delmia Operations database (press Enter to Skip):"

This might have no bearing on the problem at hand, but: once in a while I have found that the presence of '(' and ')' in text that is ECHO'd to the console causes cmd.exe to act up. I usually 'escape' parens as '^(' or '^)', or just use square brackets -- e.g. '[press Enter to Skip]'.

The characters shouldn't cause a problem in ECHO'd text (and they never do under 4NT or TCC) but once in a while I have found them troublesome in cmd.exe.

 

[Charles Dye]

Sorry; my misunderstanding. So InputColors probably isn't relevant.

 

[Charles Dye]

I suppose this could be a 64-bit issue. I am running 64-bit Windows 7 Enterprise edition. Would it be better to run the 32-bit version of tcmd.exe?

I won't say that it would be better, but it might worth trying, just for debugging purposes. If the 32-bit version doesn't have the issue, then it's possible that you have discovered an issue with the 64-bit build.

 

[JimBrandley]

On Sun, Jul 31, 2011 at 12:21 PM, JimBrandley <> wrote:



How does it fail? Pasting that line into a TCC session here prints
the expected prompt.




How is that variable normally set? The test above prints the prompt
if it isn't defined.



______
Dennis

Dennis - Please see my response at 13:06. It appears that the problem may be specific to the 64-bit version of tcmd.exe.

Jim

 

[JimBrandley]

This might have no bearing on the problem at hand, but: once in a while I have found that the presence of '(' and ')' in text that is ECHO'd to the console causes cmd.exe to act up. I usually 'escape' parens as '^(' or '^)', or just use square brackets -- e.g. '[press Enter to Skip]'.

The characters shouldn't cause a problem in ECHO'd text (and they never do under 4NT or TCC) but once in a while I have found them troublesome in cmd.exe.

mikea - Thanks for the tip! I changed my test script to this:

::------------------------------------
:: Test DB prompt
::------------------------------------
@ECHO OFF
SET LOGFILE=Upgrade_output.log
SET ERRORFILE=Upgrade_error.log
:: Parameters
SET database=%1
SET server=%2
SET ptdatabase=%3
SET StopOnError=%4
ECHO Note: 
ECHO   You must have permissions to create objects in the target database.
ECHO   The Pertinence Suite and/or Performance Tracker database must already exist.  
ECHO.
:: Prep the log file
ECHO. & ECHO. > %LOGFILE%
IF [%server%]==[] SET /P server="Please specify the server (press Enter to run locally):"
IF [%server%]==[] ECHO No server parameter provided - running locally & ECHO No server parameter provided - running locally >> %LOGFILE%
IF NOT DEFINED database SET /P database="Please specify the Delmia Operations database [press Enter to Skip]:"
IF [%database%]==[] ECHO No Delmia Operations database parameter provided - it will not be upgraded & ECHO No Delmia Operations database parameter provided - it will not be upgraded >> %LOGFILE%
IF [%ptdatabase%]==[] SET /P ptdatabase="Please specify the Performance Tracker database (press Enter to Skip):"
IF [%ptdatabase%]==[] ECHO No Performance Tracker database parameter provided - it will not be upgraded & ECHO No Performance Tracker database parameter provided - it will not be upgraded >> %LOGFILE%
ECHO "Selected instance name = "%database%
ECHO.

It still failed, but the failure changed. I pressed Enter for the first prompt and types Eagan1 for the second. Here's the output from the TCC Prompt window:

TCC  12.11.72 x64   Windows 7 [Version 6.1.7600]
Copyright 2011  Rex Conn & JP Software Inc.  All Rights Reserved
Your evaluation period expires in 28 days.
You can buy Take Command at [URL]http://jpsoft.com[/URL]
Note:
  You must have permissions to create objects in the target database.
  The Pertinence Suite and/or Performance Tracker database must already exist.

"Please specify the server (press Enter to run locally):"
No server parameter provided - running locally
"Please specify the Delmia Operatio[COLOR=red]E[/COLOR]s database [press Enter to Skip]:"agan1
"Please specify the Performance Tracker database (press Enter to Skip):"
TCC: Unknown command "E"
[C:\Program Files\JPSoft\TCMD12x64]

Note the red E (I changed color for visibility). That was not in the prompt. It appeard there when I entered the response to the prompt.

Jim

 

[JimBrandley]

Sorry; my misunderstanding. So InputColors probably isn't relevant.

Charles - No worries. I have found that some off-the-wall suggestion that makes me challenge some "obviously true" assumption is often the key to solving a problem. Consequently, I appreciate all suggestions.

Jim

 

[JimBrandley]

I won't say that it would be better, but it might worth trying, just for debugging purposes. If the 32-bit version doesn't have the issue, then it's possible that you have discovered an issue with the 64-bit build.

I uninstalled the 64-bit version and downloaded and installed the 32-bit version. The prompt failure with the test script is unchanged.

Jim

 

[rconn]

• Executing a prompt for a database instance name caused part of the response to appear in the prompt and part to be returned to the environment variable.

Can you clarify some points for me:

1) When you run the batch file from the command line (i.e., not using the debugger), does it work?

2) When you run the batch file from a TCC session in Take Command, you have a problem with the SET /P statement?

3) If you run the batch file in the debugger from a stand-alone TCC session (i.e., not in a Take Command tab window) does it work? (You can start TCC.EXE in the Take Command installation directory from Explorer to get a stand-alone session.)

4) If you launch IDE.EXE (from your Take Command installation directory), load the batch file and start the debugger, does it work?

I'm unable to reproduce your problem here; I'm trying to narrow it down (and at least determine whether Take Command is involved, or it's in TCC.EXE or IDE.EXE).

• I found no way to alter the value of an environment variable from the debugging session.

Click on the Environment tab at the bottom of the debugger window, click on the variable you want to change, and edit it. Then click on the Reset button on the variables toolbar to replace the environment.

 

[rconn]

Rex - I do not see a ini file or cfg file (except updater.ini), or any other file that is updated when I save preferences. My installation is just a trial, and not registered. That may have an impact.

How are you invoking the debugger - with the BDEBUGGER command from a TCC window, or by clicking on the Edit/Debug button on the TCMD toolbar?

 

[JimBrandley]

How are you invoking the debugger - with the BDEBUGGER command from a TCC window, or by clicking on the Edit/Debug button on the TCMD toolbar?

Edit/Debug button.

 

[rconn]

Edit/Debug button.

Download the latest version (12.11.73) and let me know if you still have a problem.

 

[JimBrandley]

Can you clarify some points for me:

1) When you run the batch file from the command line (i.e., not using the debugger), does it work?

2) When you run the batch file from a TCC session in Take Command, you have a problem with the SET /P statement?

3) If you run the batch file in the debugger from a stand-alone TCC session (i.e., not in a Take Command tab window) does it work? (You can start TCC.EXE in the Take Command installation directory from Explorer to get a stand-alone session.)

4) If you launch IDE.EXE (from your Take Command installation directory), load the batch file and start the debugger, does it work?

I'm unable to reproduce your problem here; I'm trying to narrow it down (and at least determine whether Take Command is involved, or it's in TCC.EXE or IDE.EXE).



Click on the Environment tab at the bottom of the debugger window, click on the variable you want to change, and edit it. Then click on the Reset button on the variables toolbar to replace the environment.

1, 2 & 3. Prompt worked, but had some file access problems. Was unable to create a report file to track the processing.
4. Prompt worked, but was unable to open any of the files required for processing.