4DOS 7.50, the most recent major release of JP Software's alternate command shell for DOS, no longer supports the /Y startup option. In this file I discuss that change, its implications for users of 4DOS 7.50 under DOS, and some possible workarounds.
In September of 1993, Microsoft released version 6.20 of its MS-DOS operating system. This was a fairly minor update to MS-DOS 6.0 which offered relatively few improvements. One, however, would prove useful to writers of batch files: COMMAND.COM's new /Y startup option, which caused COMMAND.COM to single-step through batch files until the prompt appeared. As each line was read from the batch file, the user would be presented with the option to execute it or not. Doubtless intended primarily as a way to sidestep fatal problems in AUTOEXEC.BAT, the /Y option also proved useful as a tool for chasing down errors in other batch files as well. You could single-step through a misbehaving batch by launching a secondary command shell:
c:\dos\command.com /y /c buggy.bat
COMMAND.COM supports this /Y option in MS-DOS 6.20 or later, including Windows 95 and 98; IBM's PC DOS 6.3 or later; and some recent versions of DR DOS. Note that whether it is used to single-step through AUTOEXEC.BAT or some other batch file, single-stepping is invoked the same way: a /Y in the command shell's arguments. If you request an interactive boot by pressing F8 at the "Starting MS-DOS..." prompt, DOS itself adds the /Y to any arguments listed in the SHELL= directive of CONFIG.SYS.
4DOS gained an essentially similar single-stepping ability with version 5.0 in November of 1993. Like COMMAND.COM it can be invoked with /Y on the shell's command line, meaning that you can single-step through AUTOEXEC.BAT and 4START.BTM in MS-DOS 6.2 or PC DOS 6.3 or later. This ability can also be invoked via SETDOS /Y1 -- unlike COMMAND.COM, you can enable it without launching another shell:
setdos /y1 ^ buggy.btm
In 4DOS 5.0 and 5.5x, the /Y option had much the same functionality as in COMMAND.COM: a simple step-by-step, yes-or-no, do-or-don't-do addition to command processing in batch files. 4DOS 6.0, however, introduced something much more powerful and sophisticated: a full-fledged batch debugger. It's now possible to execute subroutines and auxiliary batch files (GOSUB, CALL) atomically instead of tracing into them if we wish. We can also view the values of variables or aliases in a popup window, display the current command line after expansion of variables and functions, LIST an arbitrary text file, scroll through the current batch file in its entirety, and so on.
The new batch debugger is invoked in the same ways that the more primitive stepwise confirmation mode was: via /Y on 4DOS's command line, or the SETDOS /Y1 command. The practical upshot is that if you are using 4DOS version 6.0x or 7.0x on a recent version of DOS and you do an interactive boot, AUTOEXEC.BAT will be processed in the full-on batch debugger.
In the new version 7.50, /Y is inoperative. The batch debugger is still present and can be invoked via SETDOS /Y1. According to Rex Conn, this change was deliberate -- an intentional change to make it easier for system administrators to prevent lusers from viewing or bypassing startup scripts. We can argue whether this was a good choice: perhaps /Y should be enabled or disabled via .INI directive, maybe SWITCHES=/N in CONFIG.SYS would be sufficient, perhaps there should be a separate version of 4DOS for use as a padded cell -- but, better or worse, the decision has been made and is extremely unlikely to be reversed.
For most batch files, this change is a nonissue. Launching a whole new command shell is kind of dumb when you can simply adjust the operation of the current one. (Firing up another shell takes memory and time, and the reprocessing of 4START.BTM may have implications.) The only difficulty is with the startup scripts, AUTOEXEC.BAT and the primary shell's 4START.BTM. DOS knows nothing of 4DOS's SETDOS command and requests step-by-step processing of AUTOEXEC.BAT the only way it can: via the /Y option, which 4DOS now ignores. So when you do an interactive boot with the latest version of 4DOS installed as your primary shell, AUTOEXEC.BAT is processed normally -- without the batch debugger or any other easy means provided for the user to bypass problematic lines.
Even so, this may not be an issue for you. If your AUTOEXEC.BAT file never changes, or if it consists mainly of PATH and PROMPT, then the absence of interactive AUTOEXEC.BAT handling probably won't bother you in the least. But if you do complex things in AUTOEXEC.BAT, or if you load possibly unstable software at startup, then you may need the debugger. Option /Y is no longer available; we'll have to use SETDOS /Y1 instead. Here are some suggestions on how to do it.
One very simple approach would be to use some kind of a flag file to indicate that the debugger is desired. If the file exists, SETDOS /Y1 to start the debugger. It might also be convenient to delete the flag file at the same time. In AUTOEXEC.BAT:
rem AUTOEXEC.BAT
if exist c:\dbgflag ( setdos /y1 %+ del /q c:\dbgflag )
Or we might do the same thing in 4START.BTM, so we can also run (most of) 4START in the debugger as well:
rem 4START.BTM
if %_shell == 0 if exist c:\dbgflag ( setdos /y1 %+ del /q c:\dbgflag )
This approach is straightforward and robust, but creating a flag file may not be convenient, especially on a bootable floppy or CD-ROM when you can't be sure that the machine will always have a hard drive partition useable from DOS. From the user's standpoint, it would be easier just to hit a key to indicate that AUTOEXEC.BAT should be run in the debugger. One of the keyboard's toggle keys would be ideal, and Scroll Lock is seldom used:
if "%@execstr[keybd | tail /n1]" == "scroll=on" ( setdos /y1 %+ keybd /s0 )
This is pretty handy to use. It's independent of DOS's interactive startup; you can just hit Scroll Lock to debug AUTOEXEC.BAT without stepping through CONFIG.SYS, or F8 to step through CONFIG.SYS without running AUTOEXEC.BAT in the debugger. The down side is that it needs disk space for the temporary files created by the pipes, making it less than ideal for a boot disk. (Most boot floppies deal with pipe files by pointing the TEMP, TMP or TEMP4DOS variables to a RAMdrive; but this is typically done sometime during AUTOEXEC.BAT....)
Perhaps a neater approach would be to re-implement the /Y option ourselves. DOS is still passing a /Y to 4DOS; 4DOS just isn't acting on it. The primary shell's PSP remains in memory, along with the original command-line arguments. 4DOS has no function or variable to report these, but it's not too difficult to write an external utility to get them for us. One strategy would be to return 4DOS's arguments and have the batch file look for the /Y. Assuming a hypothetical utility GET4ARGS which simply dumps the primary shell's command-line arguments to standard output:
if %@index[%@execstr[a:\4dos\get4args],/y] ne -1 setdos /y1
But we're back to pipes and temporary files again, and 4DOS really isn't the ideal tool for handling arbitrary strings anyway. A better solution would be for the external utility to parse the command line itself and report a yes-or-no result in its exit code, eliminating the need for temporary files:
a:\4dos\4dbghelp && setdos /y1
How much of which batch files are seen in the debugger depends on where we place the call to SETDOS, of course. If SETDOS /Y1 is the last command in 4START.BTM, then all of AUTOEXEC.BAT and none of 4START.BTM will be available in the batch debugger. Put the SETDOS /Y1 at the start of 4START.BTM, and the remainder of 4START.BTM will be visible in the debugger. If the SETDOS /Y1 is in the middle of AUTOEXEC.BAT, then you can only debug the lines following it. Where you choose to put the SETDOS is up to your own good taste and judgment; just remember that while AUTOEXEC.BAT is only processed once by the primary shell, 4START.BTM is called by every instance of 4DOS launched.
Also bear in mind that if some external utility is launched from very early in AUTOEXEC.BAT or 4START.BTM, the search path may not yet be defined. Specify the complete path to the utility. If 4DOS cannot find the external utility, an effective ERRORLEVEL of 2 will be returned; this is worth considering when selecting return values for such a utility.
I am making a copy of the source and executable for a small 4DBGHELP.COM available here: 4dbghelp.zip Other implementations are certainly possible.
This page is by Charles Dye, raster@highfiber.com. Copyright © 2004, Charles Dye. All rights reserved. Last update 2004-04-27.
This page not requested, sanctioned or paid for by JP Software or anybody else. All opinions and errors are entirely my own.