1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

IDE unexpectedly exits inside this batch file

Discussion in 'Support' started by Stefano Piccardi, Sep 20, 2011.

  1. Stefano Piccardi

    Joined:
    May 31, 2008
    Messages:
    376
    Likes Received:
    2
    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.
     
  2. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,883
    Likes Received:
    29
    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.
     
  3. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,883
    Likes Received:
    29
    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!
     
  4. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,804
    Likes Received:
    82
    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).
     
  5. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,883
    Likes Received:
    29
    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?
     
  6. Stefano Piccardi

    Joined:
    May 31, 2008
    Messages:
    376
    Likes Received:
    2
    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:
    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
     
  7. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,804
    Likes Received:
    82
    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.
     
  8. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,804
    Likes Received:
    82
    Yes.

    It can, it just requires a few hundred lines of new code.
     
  9. Stefano Piccardi

    Joined:
    May 31, 2008
    Messages:
    376
    Likes Received:
    2
    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.
     
  10. Jay Sage

    Joined:
    Jun 2, 2008
    Messages:
    284
    Likes Received:
    1
    On 9/21/2011 8:35 AM, rconn wrote:

    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
     
  11. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,804
    Likes Received:
    82
    Yes, but -- instead of using an undocumented .INI directive, why not use the documented (and supported) "ALIAS /L" command instead?
     
  12. Stefano Piccardi

    Joined:
    May 31, 2008
    Messages:
    376
    Likes Received:
    2
    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
    Would this NAME overwrite another existing alias NAME, if any?
    Would this NAME survive after ENDLOCAL?
     
  13. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,883
    Likes Received:
    29
    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
     
  14. samintz

    samintz Scott Mintz

    Joined:
    May 20, 2008
    Messages:
    1,188
    Likes Received:
    11
    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:



    NAME, if any?



     
  15. Stefano Piccardi

    Joined:
    May 31, 2008
    Messages:
    376
    Likes Received:
    2
    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?
     
  16. David Marcus

    Joined:
    Jun 4, 2008
    Messages:
    646
    Likes Received:
    1
    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.
     
  17. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,883
    Likes Received:
    29
    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.
     
  18. David Marcus

    Joined:
    Jun 4, 2008
    Messages:
    646
    Likes Received:
    1
    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...
     

Share This Page