Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

IDE unexpectedly exits inside this batch file

version 13.00.21 Windows XP Pro SP3
start IDE (no parameters)
type in this script
PHP:
setlocal
option //localAliases=Yes
setdos /X-4
alias action=`%cp% "%1" "%2"`
action nul nul
endlocal
Start the debugger then single step through. When I step into the alias definition line IDE exits immediately, and I'm back into the console window where IDE was started. There are no error messages; the console just echos the four lines that were stepped through.
 
On Tue, 20 Sep 2011 18:09:47 -0400, Stefano Piccardi <>
wrote:

|version 13.00.21 Windows XP Pro SP3
|start IDE (no parameters)
|type in this script
|
|PHP:
|---------
|setlocal
|option //localAliases=Yes
|setdos /X-4
|alias action=`%cp% "%1" "%2"`
|action nul nul
|endlocal
|---------
|Start the debugger then single step through. When I step into the alias definition line IDE exits immediately, and I'm back into the console window where IDE was started. There are no error messages; the console just echos the four lines that were stepped through.

On Win7, I get the JIT debug (crash) dialog when I step out of the ALIAS
command.
 
I don't know what's happening but I can simplify it some.

At a TCC command line (don't need IDE) ...

Code:
v:\> option //LocalAliases=Yes

v:\> alias a=b
... crash!
 
> At a TCC command line (don't need IDE) ...
>
> Code:
> ---------
> v:\> option //LocalAliases=Yes
>
> v:\> alias a=b
> ---------
> ... crash!

Yup, that'll blow it up (and always has, don't need v13).

You should never, ever, ever, use OPTION //LocalAliases (or
//LocalFunctions). TCC has to reconfigure all of its memory buffers, but it
doesn't know that it needs to do it if you don't do a save from OPTION (or
set it in TCMD.INI).
 
On Wed, 21 Sep 2011 00:00:39 -0400, rconn <> wrote:

|---Quote---
|> At a TCC command line (don't need IDE) ...
|>
|> Code:
|> ---------
|> v:\> option //LocalAliases=Yes
|>
|> v:\> alias a=b
|> ---------
|> ... crash!
|---End Quote---
|Yup, that'll blow it up (and always has, don't need v13).
|
|You should never, ever, ever, use OPTION //LocalAliases (or
|//LocalFunctions). TCC has to reconfigure all of its memory buffers, but it
|doesn't know that it needs to do it if you don't do a save from OPTION (or
|set it in TCMD.INI).

Would the change to LocalAliases(/Functions) have taken place immediately (and
correctly) if it had been done with the OPTION dialog? If so, why can't "OPTION
//Local..." do the same thing without the "save" part? If not, does that mean
you can't make that change on the fly?
 
Yup, that'll blow it up (and always has, don't need v13).
That kind of code used to work just fine in TCC9 and TCCLE10. It's part of a script that I've used for years. Now in TCC13 that script doesn't crash (even though it sets //LocalAliases=Yes) but it displays another unexpected error.
PHP:
setlocal
option //localAliases=Yes
setdos /X-4
...
alias action=`%[cp] %2 "%[src]%3" "%[tgt]"`
...
    switch %key%
      case ...
echo on
ver /r
alias action
set selector
set wildcard
set cp
        action /do %selector% %wildcard%
echo off
      default
        ...
    endswitch

When TCC13 runs it I get an unexpected "unknown command" error:
TCC 13.00.21 Windows XP [Version 5.1.2600]
TCC Build 21 Windows XP Build 2600 Service Pack 3
alias action
%[cp] %2 "%[src]%3" "%[tgt]
set selector
/A:
set wildcard
TCC: V:\TCC\duplicate_one.btm [102] Not in environment "wildcard*"
set cp
*copy /G /H /K /L /Nt /LD /O
%[cp] %2 "%[tgt]"
TCC: V:\TCC\duplicate_one.btm [104] Unknown command "%[cp]"
echo off
Why does it say that %[cp] is unknown? I thought something in SETDOS /X-4 had changed between TCC9 / TCCLE10 and TCC13, but given the IDE crash I'm not sure.

In TCC9 and TCCLE10 my script correctly outputs
TCC 9.02.157 Windows XP [Version 5.1.2600]
TCC Build 157 Windows XP Build 2600 Service Pack 3
alias action
%[cp] %2 "%[src]%3" "%[tgt]
set selector
/A:
set wildcard
TCC: V:\TCC\duplicate_one.btm [102] Not in environment "wildcard*"
set cp
*copy /G /H /K /L /Nt /LD /O
copy /G /H /K /L /Nt /LD /O /A: "B:\Sc.xls" "B:\Sc copy 002.xls"
B:\Sc.xls => B:\Sc copy 002.xls
1 file copied
 
That kind of code used to work just fine in TCC9 and TCCLE10.

That could never have worked (even in v9 & v10), because there simply isn't any code to reset the alias lists if you use the //option format. (If it didn't crash previously it was purely random chance.)

I can add support for that, but it'll require a couple hundred lines of code.
 
That could never have worked (even in v9 & v10), because there simply isn't any code to reset the alias lists if you use the //option format. (If it didn't crash previously it was purely random chance.)

I can add support for that, but it'll require a couple hundred lines of code.
Right on, my grandma used to say I would be really lucky in my life :-)
Don't worry about adding those lines of code. Thanks.
 
On 9/21/2011 8:35 AM, rconn wrote:

> I can add support for that, but it'll require a couple hundred lines of code.

I should think that would be a very desirable feature (I wasn't aware
that it did not work). If one is using global aliases and changes an
alias definition in a batch file, that change will affect all other TCC
sessions, perhaps with undesirable effects.

I used to have some batch files that unaliased everything to make sure
that no built-in commands would be aliased. I think I discovered that
that was a problem, so I just started putting "*" in front of all
commands that might be aliased, and I used weird names for any aliases
defined in the batch file. It would be nice if one could switch to local
aliases on the fly. On the other hand, I guess I've learned to live with
things as they are now.

-- Jay
 
I should think that would be a very desirable feature (I wasn't aware
that it did not work). If one is using global aliases and changes an
alias definition in a batch file, that change will affect all other TCC
sessions, perhaps with undesirable effects.

Yes, but -- instead of using an undocumented .INI directive, why not use the documented (and supported) "ALIAS /L" command instead?
 
Yes, but -- instead of using an undocumented .INI directive, why not use the documented (and supported) "ALIAS /L" command instead?
I'm confused...

Help topic Local and Global Aliases: With a local alias list, any changes made to the aliases will only affect the current copy of TCC. They will not be visible in other shells or other sessions.

Help topic Setlocal: SETLOCAL does not override the Local Aliases configuration option. Consequently changing aliases inside a SETLOCAL / ENDLOCAL pair affects the definition of aliases of other concurrently executing sessions of TCC.

So, if in a batch file I have
SETLOCAL
ALIAS /L
ALIAS NAME=`ECHO %1`
ENDLOCAL

Would this NAME overwrite another existing alias NAME, if any?
Would this NAME survive after ENDLOCAL?
 
So, if in a batch file I have

Code:
SETLOCAL
ALIAS /L
ALIAS NAME=`ECHO %1`
ENDLOCAL
Would this NAME overwrite another existing alias NAME, if any?
Would this NAME survive after ENDLOCAL?

NAME, with a prior global definition will survive and be in effect after the ENDLOCAL.

Code:
v:\> type lalias.btm & lalias.btm
alias foo bar
alias foo
alias /l
setlocal
alias foo dog
alias foo
endlocal
alias foo

bar
dog
bar
 
Vince,

You would have gotten the same results
without the ALIAS /L.

SETLOCAL/ENDLOCAL will save and restore
the aliases that were changed. By using ALIAS /L, any modifications
stay local to the current shell. Otherwise, other shells will see
the modifications between SL and EL.

-Scott

vefatica <> wrote on 09/21/2011
07:32:55 PM:


> Quote:
>
> Originally Posted by Stefano Piccardi [image removed]
> So, if in a batch file I have


> Code:
> SETLOCAL
> ALIAS /L
> ALIAS NAME=`ECHO %1`
> ENDLOCAL
> Would this NAME overwrite another existing alias
NAME, if any?

> Would this NAME survive after ENDLOCAL?
>
> NAME, with a prior global definition will survive and be in effect


> after the ENDLOCAL.


> Code:
> v:\> type lalias.btm & lalias.btm
> alias foo bar
> alias foo
> alias /l
> setlocal
> alias foo dog
> alias foo
> endlocal
> alias foo
>
> bar
> dog
> bar
>
>
 
You would have gotten the same results
without the ALIAS /L.

SETLOCAL/ENDLOCAL will save and restore
the aliases that were changed. By using ALIAS /L, any modifications
stay local to the current shell. Otherwise, other shells will see
the modifications between SL and EL.

Are we talking about static vs dynamic scoping of local aliases?
Could we say that SL/EL affect static scoping of local AND global aliases, so aliases which are in effect before SL will be in effect after EL?
And could we say that ALIAS /L affects dynamic scoping of GLOBAL aliases, in the sense that w/o ALIAS /L a script/session changes aliases in the global list (if there is one) which affect all other CONCURRENT sessions that rely on global aliases?

If so, then adding ALIAS /L within SL/EL does make a difference, because it prevents the currently running script from changing other open sessions, even temporarily.

Did I get it?
 
If so, then adding ALIAS /L within SL/EL does make a difference, because it prevents the currently running script from changing other open sessions, even temporarily.

Although, TCC will be left with local aliases when the the script ends. If you want global aliases, then

startlocal
alias /l
alias foo bar
alias /g
endlocal

seems to work. Without the startlocal/endlocal, foo will be added to the global alias list. If a script could tell whether local or global aliases was in effect, it could figure out whether it needed to switch to local aliases. Not sure how to do that.
 
Although, TCC will be left with local aliases when the the script ends. If you want global aliases, then

startlocal
alias /l
alias foo bar
alias /g
endlocal

seems to work. Without the startlocal/endlocal, foo will be added to the global alias list. If a script could tell whether local or global aliases was in effect, it could figure out whether it needed to switch to local aliases. Not sure how to do that.

If you "alias /g" before "endlocal" then for the time between, concurrent sessions and newly-started ones will see the temporary alias. Test this with a PAUSE between "alias /g" and "endlocal"; during the pause, see what aliases a concurent session and a new session have.
 
Seems to me it would make more sense if alias /g used whatever aliases were in the global aliases rather than replacing the global aliases with whatever the current TCC has for aliases.

Or: If global aliases are in effect, setlocal should create a local copy of the aliases that endlocal would then discard.

Maybe there is a good reason this isn't the way it works...
 

Similar threads

Back
Top