V10 debugging problems

[Steve Fabian]

The V10 operation of the debugger causes multiple failures.

1/ Since the introduction of the BDEBUGGER command, this worked: bdebugger
%@search[jpget] when jpget was the name of a batch file on the path. It
fails in V10, because it prefixes %_CWDS to the value of %@search[jpget].

2/ The debugger cannot handle "include .\xxx.ini" in an .INI file - it
starts in a different directory than TCC.

3/ My alias is: copy is an alias : *copy/[!descript.ion]/efgrhv/net; I used
it in the form
copy/[ddate_and_time]/s ftp:
The /ne and /e options were ignored, received MANY "There are no more files"
messages, and for each empty source directory a message "The system cannot
find the file specified."

I managed to utilize the debugger by starting it in the directory containing
all .INI files, and using full path for the batch file to be debugged. This
would not have worked if the batch file had not already contained a CDD
command to do its work in its target directory.
--
Steve

 

[mtotman]

...
3/ My alias is: copy is an alias : *copy/[!descript.ion]/efgrhv/net; I used
it in the form
copy/[ddate_and_time]/s ftp:
The /ne and /e options were ignored, received MANY "There are no more files"
messages, and for each empty source directory a message "The system cannot
find the file specified."
...

Maybe the parser is finally starting to balk at all those flags/options not having their own slashes? Rex has always maintained that form is "deprecated".

 

[Steve Fabian]

mtotman wrote:
| ---Quote (Originally by Steve Fábián)---
| ...
|| 3/ My alias is: copy is an alias : *copy/[!descript.ion]/efgrhv/net;
|| ...
|| The /ne and /e options were ignored, received MANY "There are no more
|| files"
|| messages, and for each empty source directory a message "The system
|| cannot
|| find the file specified."
| ...
| ---End Quote---
| Maybe the parser is finally starting to balk at all those
| flags/options not having their own slashes? Rex has always
| maintained that form is "deprecated".

No, they work fine from the command line and also in batch files outside the
debugger.
--
Steve

 

[rconn]

Steve Fábián wrote:

> The V10 operation of the debugger causes multiple failures.
>
> 1/ Since the introduction of the BDEBUGGER command, this worked: bdebugger
> %@search[jpget] when jpget was the name of a batch file on the path. It
> fails in V10, because it prefixes %_CWDS to the value of %@search[jpget].

Doesn't have anything to do with BDEBUGGER; it's because the line is
being passed as-is (no variable expansion) to IDE.EXE, which then tries
to normalize the unknown name.

This was discussed and kicked back and forth several times during the
beta; the problem is that the line cannot be expanded before calling the
debugger unless you're willing to give up the ability to change the
variable values before debugging.

However, I have made a change for the next build to allow expansion of
the first argument (only).

> 2/ The debugger cannot handle "include .\xxx.ini" in an .INI file - it
> starts in a different directory than TCC.

WAD. The .INI include files are obsolete (and useless); all documented
support was dropped for them two versions ago and the remaining
undocumented support will definitely be removed in the next major version.

The relative path syntax was never documented or supported; if it worked
for you before it was only by chance. Use explicit paths, or better
yet, remove the includes altogether.

> 3/ My alias is: copy is an alias : *copy/[!descript.ion]/efgrhv/net; I used
> it in the form
> copy/[ddate_and_time]/s ftp:
> The /ne and /e options were ignored, received MANY "There are no more files"
> messages, and for each empty source directory a message "The system cannot
> find the file specified."

Well, your syntax is atrocious but that's probably not the cause of your
problem. But it's impossible to decipher this without some more context
-- what exactly are you trying to do?

Rex Conn
JP Software

 

[Steve Fabian]

rconn wrote:
| Steve Fábián wrote:
|| 2/ The debugger cannot handle "include .\xxx.ini" in an .INI file -
|| it starts in a different directory than TCC.

| WAD. The .INI include files are obsolete (and useless); all
| documented support was dropped for them two versions ago and the
| remaining undocumented support will definitely be removed in the next
| major version.

I found the "include" directive most useful, so I can avoid having many
versions of 100-line files, differing from one another in just a few places,
substantially reducing software maintenance problems, just like shared
header files do. It is esp. useful to allow pre-V9 sharing of directives
between 4NT and TCMD.

If you remove INCLUDE support in a future version, please at least provide a
method to create a new configuration file using the settings of an existing
configuration file as the default, without modifying the original file,
e.g., add a "save as" feature to the OPTION dialog. We would still be faced
with the need to make identical changes in multiple files, when we decide
that we want to change one directive for a new class of situations.

| The relative path syntax was never documented or supported; if it
| worked for you before it was only by chance. Use explicit paths, or
| better
| yet, remove the includes altogether.

I started using them in support of portable ("inikey") versions, so I can
have them on plug-in devices that have a different explicit path sometimes
even on the same machine. Undocumented - yes. Determined to work - by
experiment. And yes, they do work when a new TCC 10 instance is started in a
manner which specifies an explicit path for the top-level configuration
file. Only the TCC instance created by the new BDEBUGGER command has this
problem.

|| 3/ My alias is: copy is an alias : *copy/[!descript.ion]/efgrhv/net;
|| I used it in the form
|| copy/[ddate_and_time]/s ftp:
|| The /ne and /e options were ignored, received MANY "There are no
|| more files" messages, and for each empty source directory a message
|| "The system cannot find the file specified."
| ---End Quote---
| Well, your syntax is atrocious but that's probably not the cause of
| your problem. But it's impossible to decipher this without some more
| context -- what exactly are you trying to do?

My actual syntax is:
copy %x /s ftp:
where %x is either undefined (to download all files), or of the form
/[[email protected]], and COPY is aliased as above. The command is
executed after a successful IFTP command, and the local default directory,
the command's target, is empty.

The purpose is to download only files newer than a specified date and time.
For sites using unix-style file systems, e.g., ftp.jpsoft.com, and which use
default commands to upload files to the site, any files uploaded to the site
after my previous download - even if their contents are many years old -
will have newer timestamps.

The problem, of course, is that WHEN RUNNING IN THE DEBUGGER everything is
correctly executed, only the files of interest are copied, but unwanted
messages are not suppressed. While in other circumstances these messages
could report problems, in the actual event they report normal, expected, but
irrelevant conditions. The options to suppress these messages were created
over the years exactly to cover this situation, and the benefit of
suppressing them is that actual problems - if they occur - do not get easily
overlooked.
--
Steve

 

[rconn]

Steve Fábián wrote:

> My actual syntax is:
> copy %x /s ftp:
> where %x is either undefined (to download all files), or of the form
> /[[email protected]], and COPY is aliased as above. The command is
> executed after a successful IFTP command, and the local default directory,
> the command's target, is empty.
>
> The purpose is to download only files newer than a specified date and time.
> For sites using unix-style file systems, e.g., ftp.jpsoft.com, and which use
> default commands to upload files to the site, any files uploaded to the site
> after my previous download - even if their contents are many years old -
> will have newer timestamps.
>
> The problem, of course, is that WHEN RUNNING IN THE DEBUGGER everything is
> correctly executed, only the files of interest are copied, but unwanted
> messages are not suppressed. While in other circumstances these messages
> could report problems, in the actual event they report normal, expected, but
> irrelevant conditions. The options to suppress these messages were created
> over the years exactly to cover this situation, and the benefit of
> suppressing them is that actual problems - if they occur - do not get easily
> overlooked.

Do you have a minimal batch file example I can test?

Rex Conn
JP Software

 

[Steve Fabian]

rconn wrote:
| Do you have a minimal batch file example I can test?

alias copy=*copy/[!descript.ion]/efgrhv/net
set r=/[d2009-02-25@19:00]
iftp ftp://jpsoft.com
copy%r/s ftp:

Notes:
1/ timestamp variable r in date range is arbitrary
2/ start in any empty directory

The batch file works in all versions when executed at the command line; it
also works via BDEBUGGER command in V9 and earlier.

Needed the debugger in the code determining the actual timestamp to be used,
and in the code to determine what to do after the COPY.
--
Steve

 

[rconn]

Steve Fábián wrote:

> rconn wrote:
> | Do you have a minimal batch file example I can test?
>
> alias copy=*copy/[!descript.ion]/efgrhv/net
> set r=/[d2009-02-25@19:00]
> iftp ftp://jpsoft.com
> copy%r/s ftp:
>
> Notes:
> 1/ timestamp variable r in date range is arbitrary
> 2/ start in any empty directory
>
> The batch file works in all versions when executed at the command line; it
> also works via BDEBUGGER command in V9 and earlier.
>
> Needed the debugger in the code determining the actual timestamp to be used,
> and in the code to determine what to do after the COPY.

That batch file doesn't work either at the command prompt or in the
debugger.

The problem is the "copy%r/s ftp:" - that will translate to:

copy/[d2009-02-25@19:00]/s ftp:

and NOT expand the COPY alias. Aliases cannot be delimited by a %; to
allow the alias expansion you need to replace the line with:

copy %r/s ftp:

which (although your syntax is still execrable and certain to fail in
future versions) works exactly the same at the command line and in the
debugger in my testing.

The reason you cannot expect names with an embedded % to be truncated
and expanded as an alias is to allow you to define aliases in variables
-- the variable expansion will call alias expansion if it replaces the
first argument on the command line. (Yes, this is documented and it has
worked this way for the last 15 years.)

Rex Conn
JP Software

 

[Steve Fabian]

rconn wrote:
| That batch file doesn't work either at the command prompt or in the
| debugger.
|
| The problem is the "copy%r/s ftp:" - that will translate to:
|
| copy/[d2009-02-25@19:00]/s ftp:
|
| and NOT expand the COPY alias. Aliases cannot be delimited by a %; to
| allow the alias expansion you need to replace the line with:
|
| copy %r/s ftp:
|
| which (although your syntax is still execrable and certain to fail in
| future versions) works exactly the same at the command line and in the
| debugger in my testing.

Thanks for the explanation. I'll modify my file accordingly.
|
| The reason you cannot expect names with an embedded % to be truncated
| and expanded as an alias is to allow you to define aliases in
| variables -- the variable expansion will call alias expansion if it
| replaces the first argument on the command line. (Yes, this is
| documented and it has worked this way for the last 15 years.)

Do you mean I could have done this to achive my goal:

set z=copy%r
%z/s ftp:

I did not find the HELP topic where above nuance of alias expansion is
explained, probably because I did not search long enough. Which topic is it?
--
Steve

 

[rconn]

Steve Fábián wrote:

> Do you mean I could have done this to achive my goal:
>
> set z=copy%r
> %z/s ftp:

Well, yes, you *could*, though I can't fathom why you *would* -- unless
your intent is to create unreadable scripts. (And you'd better put a
space before the /s.)

But not inserting whitespace following the COPY and before the variable
name is absolutely, positively, going to bite you over and over and over
again.

Rex Conn
JP Software