Running another batch file without CALL

[p.f.moore]

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.

 

[MickeyF]

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

​

 

[rconn]

p.f.moore wrote:

> 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?

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.

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

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

Rex Conn
JP Software

 

[joshjeppson]

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

Paul.

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

Rex Conn
JP Software

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

 

[joshjeppson]

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

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:

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:

[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

 

[Steve Fabian]

| 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

 

[nikbackm]

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!

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.

 

[p.f.moore]

On 25/06/2008, rconn <> wrote:

> > 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?
>
> 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.

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.

> > I'd have thought using an executable extension, like "set .bat=call"
> > would work, but it appears not. Why is that?
>
> PATHEXT overrides EE's -- remove ".BAT" from your PATHEXT environment
> variable.

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