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

Running another batch file without CALL

Discussion in 'Support' started by p.f.moore, Jun 24, 2008.

  1. p.f.moore

    Joined:
    May 30, 2008
    Messages:
    122
    Likes Received:
    1
    As documented under the CALL command, two batch files

    ---- a.bat ----
    echo starting a
    b
    echo ending a
    ---- b.bat ----
    echo running b
    ---- ----

    the line "ending a" will never be printed, as if you don't use CALL,
    the second batch file is chained (goto) not called.

    Is there any way of turning off this (frankly, horrible) behaviour? It
    makes using batch file wrappers for executables (say, to set some
    required environment variables) unworkable, as you can't use the batch
    file transparently - you have to use CALL from other batch files. I
    recently spent *ages* debugging a problem caused by this :-(

    I know it's for CMD compatibility, and I know it can't be off by
    default, but is there *any* way round it? If not, could it be added as
    an option in v10?

    I'd have thought using an executable extension, like "set .bat=call"
    would work, but it appears not. Why is that?

    Paul.
     
  2. MickeyF

    Joined:
    Jun 3, 2008
    Messages:
    76
    Likes Received:
    1
    First, any possible future option would have to have a default of working the way it currently works (equivalent of GOTO instead of GOSUB). Batch files would be broken left and right otherwise.

    Second, you can always get around this problem by using aliases. In your example, set an alias for b:
    alias b=call b.bat
    Then when a calls b, it will do what you want it to do. Of course, if a.bat were to call b.bat using the full name (b.bat) instead of just b, then the alias doesn't get invoked.

    ->type a.bat
    echo starting a
    b
    echo finishing a

    ->type b.bat
    echo running b

    ->alias b
    call b.bat

    ->a
    starting a
    running b
    finishing a

    ->edit a.bat

    ->type a.bat
    echo starting a
    b.bat
    echo finishing a

    ->a
    starting a
    running b

     
  3. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,859
    Likes Received:
    83
    p.f.moore wrote:

    Nobody's ever asked for that, but since it's behaved that way for more
    than 25 years (back to DOS 2.0) I doubt anybody ever thought about
    changing it. It would definitely render third-party batch files
    inoperable on your system.


    PATHEXT overrides EE's -- remove ".BAT" from your PATHEXT environment
    variable.

    Rex Conn
    JP Software
     
  4. joshjeppson

    Joined:
    Jun 2, 2008
    Messages:
    42
    Likes Received:
    0
    Except of course, this doesn't work. If you will remember, I brought this up a few months ago: .BAT, .BTM and .CMD do NOT respect EE's properly. They sometimes work and sometimes don't, depending on whether the extension is specified or not. I suspect, but have not verified, that the other 'integrated' executable types (.EXE, .COM, etc.) won't always work as EE's either.

    Why would someone be crazy enough to want EE's to work with .BAT and .CMD files? Well, the above scenario of always using call to execute them or my original scenario of always using CMD to execute them.

    Please, please, please make them work properly and then the above issue (and mine) can be neatly solved.


    - Josh
     
  5. joshjeppson

    Joined:
    Jun 2, 2008
    Messages:
    42
    Likes Received:
    0
    Please pardon the self response.

    A quick verification test yielded the following:

    Executable extensions do not work with .BAT, .BTM, .CMD, .COM and .EXE until the PathExt option of TCC is turned on and those extensions are removed from %PathExt.

    Furthermore, all five only work as EE's when their extension is NOT specified. For example:

    Code:
     
    TCC  9.02.151   Windows XP [Version 5.1.2600]
    [D:\Temp]echo %@option[pathext]
    Yes
    [D:\Temp]set pathext
    .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PSC1
    [D:\Temp]eset pathext
    PATHEXT=.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PSC1
    [D:\Temp]set .cmd=c:\windows\system32\cmd.exe /c
    [D:\Temp]type test.cmd
    @ver
    [D:\Temp]test
    Microsoft Windows XP [Version 5.1.2600]
    [D:\Temp]test.cmd
    TCC  9.02.151   Windows XP [Version 5.1.2600]
    [D:\Temp]set .exe=`echo ExecExtInUse %+ %0`
    [D:\Temp]ipconfig
    ExecExtInUse
    Windows IP Configuration
    ...Snipped to protect the innocent...
    [D:\Temp]ipconfig.exe
    Windows IP Configuration
    ...Snipped to protect the innocent...
    
    Btw, if pathext is unset, then EE's for these five extensions don't work at all:

    Code:
     
    [D:\Temp]unset pathext
    [D:\Temp]set .cmd=c:\windows\system32\cmd.exe /c
    [D:\Temp]type test.cmd
    @ver
    [D:\Temp]test
    TCC  9.02.151   Windows XP [Version 5.1.2600]
    [D:\Temp]test.cmd
    TCC  9.02.151   Windows XP [Version 5.1.2600]
    [D:\Temp]set .exe=`echo ExecExtInUse %+ %0`
    [D:\Temp]ipconfig
    Windows IP Configuration
    ...Snipped to protect the innocent...
    [D:\Temp]ipconfig.exe
    Windows IP Configuration
    ...Snipped to protect the innocent...
    

    - Josh
     
  6. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    | Please, please, please make them work properly and then the above
    | issue (and mine) can be neatly solved.

    Sorry, they DO work properly - as the language interpreted by the
    COMMAND.COM component of IBM's PC-DOS and its successors, including JPsoft's
    4DOS, 4OS2, 4NT, TCMD32, and TCC, were designed. The language is imperfect,
    but so many of my several hundred batch programs would fail if the chaining
    were changed to your redesign of the language. It may not be what you are
    used to from command processors on other platforms, but is so deeply
    ingrained here that it would be very dangerous to change it.

    BTW, in JPsoft command processors you can use CALL to invoke a binary
    program (.COM or .EXE) and it behaves exactly as it would without the
    keyword CALL. You could just use CALL for any program you expect to return!

    --
    Steve
     
  7. nikbackm

    Joined:
    May 30, 2008
    Messages:
    194
    Likes Received:
    1
    It seems to work the same way in cmd.exe as well.
    You can use CALL for both external commands and internal ones like DIR.
     
  8. p.f.moore

    Joined:
    May 30, 2008
    Messages:
    122
    Likes Received:
    1
    On 25/06/2008, rconn <> wrote:

    I'm aware that it's been like that forever, and that it has to stay
    that way by default for compatibility.

    I don't know if I'd set an option like this permanently, I'd likely
    just set it in batch files where I needed it.

    As far as impact is concerned, I'd have to say that I use very few 3rd
    party batch files, and I'm pretty sure that none of them rely on the
    chaining behaviour.


    Hmm, doesn't seem to work. If I change a.bat as follows:

    @echo off
    setlocal
    option //PATHEXT=Yes
    set PATHEXTset .bat=call
    echo Starting a
    b
    echo Ending a
    endlocal

    it still chains to b.bat. (BTW, is there a way of making OPTION
    settings local, like SETLOCAL does for environment changes?)

    Just to clarify, the reason I have this issue is that I have a number
    of build and test scripts which I use with the Mercurial DSCM - but
    depending on which installation of Mercurial I use, the executable is
    either hg.exe or hg.bat (the latter a wrapper for a development
    version). Now as Steve pointed out, I can use CALL hg in all cases,
    but I have to say, that seems pretty ugly to me - and it requires me
    to know that there's a possibility of this. I can't just use hg
    because of the chaining issue - hence my request.

    Essentially, I want a way of writing a script "wrapper" round an
    executable which can be transparently used in place of the executable
    itself.

    Paul
     

Share This Page