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

SignUp Now!

Call "batch" without 'call'?

I've been stumbling over this issue for years, and never gotten happy with it.

At the command line, the usual convention is that the first text-clump names a "command", and the rest of the line, modulo redirection and compound shell command structure, provides parameters. The "command" does whatever it does, then ultimately returns control to the invoking context.

The exception, dreamed up by the same weak mind(s) responsible for so many other silly features of command.com, cmd.exe, etc., is when the first text-clump names a "batch" file. Then, and only for the DOS/Windows OS family, control is not returned to the invoking context. If you want control returned, you have to type "call whatever". However, (at least according to TCC help), the "call" prefix only applies to batch files. It happens to do the right thing with other executable file types, but I cannot tell whether this is a quirk or something we can rely upon.

What is troubling about the DOS/Windows convention is that when writing batch files, you have to know whether the invokee is a batch file or not in order to regain control. Sometimes, this is-a-batch fact changes, after invoking scripts are written. For example, I often reduce %PATH% clutter or settle path setting wars by removing paths from %PATH% and creating a wrapper .btm, having the same basename as what was found as a .exe. This wrapper modifies the path and invokes the .exe, sometimes with added parameter. Unfortunately, it breaks any batch file already written which depended upon the .exe invocation's ultimate return of control

Is there some way to write a batch file that acts like every other kind of executable, by returning control to an invoker even when no "call" is used?

If not, I would suggest that 'RETURN' could be overloaded. Instead of throwing an error when there is no pending GOSUB return, it would return to the (putative) calling context.

Alternatively, it would be a usable mitigation, (albeit a clumsy one), for 'CALL' to always be a legal prefix in an invocation. Its new meaning would be "Do this thing and return here, even if that need not be explicitly specified."