Thanks everybody for the input! Lots of interesting suggestions/ideas.
I think the proposed solutions generally fall into four categories:
1. Always use ECHO OFF without the @ and don't worry about it
2. Try to fix the problem before it happens
3. Just let the problem happen and "fix" the screen afterwords
4. Create distinct AUTOEXEC.BAT files for every situation and don't
try to create a "master" version
As far as I can tell, none of the suggestions will do #2 (at least not reliably
in all cases). I think almost every suggestion that tries to do #2 just
replaces the unwanted "ECHO OFF" on the screen with something else unwanted
(like an "@ECHO OFF" or a "CTTY NUL" or an "IF ...").
I'll try to address my thoughts on all of them received thus far in this single
response.
*************************************************************
Mercury Thirteen:
> Would it be feasible to throw together an "@ECHO.COM" application
> which would manually execute a normal "ECHO OFF" line if the DOS
> version is below 3.3 and simply terminate otherwise? The only caveat
> to this is that I''m not 100% certain that a command executed from
> within a .COM file from within a batch file like this would
> work back "upstream" and turn ECHOes off for the rest of the
> original batch file.
I thought of this, but unfortunately it won't work. First of all, it needs to
test for more than just the basic DOS version since things like DR-DOS and
PTS-DOS (and even FreeDOS to a lesser degree) can get "weird" since they are
not always as compatible as they should be.
In addition, you would still see the "@ECHO OFF" line, so all you're doing is
replacing "ECHO OFF" with an errant "@ECHO OFF" and would still need to issue a
real ECHO OFF (without the "@") to actually turn ECHO OFF.
An @ECHO.COM (or .EXE) file could be interesting, though, except it would
actually need to legitimately tell the command/batch processor to turn ECHO OFF
and I don't think there's a way to do that from inside an executable file. It
would be nice if there were some INT 21h functions to manipulate the ECHO state
(and perhaps also other things like determining if you are running from a
command-line or batch file or being EXEC'd from another program, or determining
the state of the CALL stack if being run from a batch file, or other similar
things) but none of that exists.
An executable file could manipulate the screen (similar to the V8 Power tools
suggested below by Jerome) but since it can't actually manipulate the ECHO
state it won't do any good.
*************************************************************
Jose Senna:
> I have not used any DOS for some months but, as far as I
> remember, @ECHO OFF worked with DR-DOS 5.
I don't have DR-DOS 5 installed. But I do have DR-DOS 6, 7, and 8 installed
and the "@" trick does not work with any of those. It's conceivable it works
with DR-DOS 5, but I really doubt it.
*************************************************************
Jim Hall:
> The simplest solution is to use ECHO OFF without the @ at the start
> of your BAT file. That will work everywhere. If you don't like
> seeing this line on the screen at boot, you could run CLS after
> that.
Running a CLS afterwords is sort of a "nuclear option" to fix a small problem.
I normally want to see all the output of the various programs and CLS blows
away everything, including things I want to see. Jerome's V8 power tools
suggestion below I think is a better option than CLS since it only does a
"selective cleaning", but it's definitely more complicated than a simple CLS.
> I suppose another way to solve this is with a simple tool that
> detects the DOS version.
Unfortunately, this would not be a "simple" tool. I've never seen a tool that
reliably detects all the different manufacturers and versions of DOS. If
there's one out there, I've not seen it.
> So your MKENV program would detect the DOS version and write a BAT
> file that looks like:
>
> SET VENDOR=MS
> SET MAJOR=5
> SET MINOR=0
That's what I do now (albeit manually) with the individual AUTOEXEC.BAT files
(except I call the environment variables DOSMfg, DOSMajor, and DOSMinor), but
same idea).
> If you need AUTOEXEC to do different things depending on the DOS
> version, you could carry the MKENV idea further by having a set of
> "stubbed" AUTOEXEC files like AUTOEXEC\MS50.BAT, and so on for other
> versions, that you could load as needed. But I'll leave that for
> you.
Again, that's basically what I'm doing now, except in the reverse order. I do
the OS-specific stuff in a small AUTOEXEC.BAT file and the jump to the "master"
or "common" AUTOEXEC.BAT file. Your suggestion is to try and create more
levels of complication (more "levels" of batch files) instead of creating a
"master" like I'm trying to do. The problem with that is when I want to make a
"global" change to what I'm trying to do (like add or remove one more utility
to all OS's while booting) I need to make changes in a bunch of different
places instead of just one.
*************************************************************
Travis Siegel:
> Why not use the @echo off syntax, then simply use the cls command to
> clear the screen before moving on to the later pieces of the
> autoexec. It then won't show the @echo off command on the screen.
> The caveat of course is that all driver messages also get erased,
> but that may or may not be an issue depending on what you're
> loading, and how important it is to see those messages.
See above.
> The other solution may be to put the ver command into a variable,
> then check that to see if the @echo off will work.
Again, see above. Plus, all that does is replace the unwanted "ECHO OFF" with
an unwanted "IF ..." line that tests the Environment variable.
> Barring those solutions, you could always redirect the @echo off
> line to null, which would prevent it from displaying on the screen.
No, that doesn't prevent the @ECHO OFF from being displayed. The "> NUL"
redirects the OUTPUT of a command to NUL. "@ECHO OFF" (when it works) doesn't
output any kind of message at all (so the "> NUL" is redundant), and when it
doesn't work it displays an error message (to STDERR) and the "> NUL" only
redirects STDOUT and not STDERR.
> Honestly I'd love to have a setup like yours, that would be the best
> toy ever.
I don't think VCOM (the maker of System Commander) is around any more, so you
can't purchase a new version. If I were trying to create a similar setup today
and I didn't already have System Commander, I think I would try to use the
Ranish Partition Manager (available at
https://www.majorgeeks.com/files/details/ranish_partition_manager.html). It
uses a different approach to the whole thing. It supposedly allows a hard
drive to have up to 30 primary partitions instead of just 4 like a "normal"
MBR, and it creates different boot options by hiding and exposing partitions
instead of by manipulating files like System Commander does.
There are also various places on the Internet where you can download boot disks
for different manufacturers and versions of DOS, though I'm not sure it's
kosher to list any of them here on FreeDOS given the official stance towards
FOSS.
> Did you ever purchase PTS dos? That could be another one to add to
> your list of os versions as well.
I think I did experiment with PTS-DOS a long time ago, but don't remember the
details. At least one of the sites mentioned above has a boot disk for PTS-DOS
you can download.
*************************************************************
Frank Haeseler:
> I have a very very similar surrounding, with a bunch of different
> versions of DOS, only difference is: I have a Live-CDROM booting
> the different DOS from floppy disk images (via ELTORITO), but all
> systems share a common env. on the CDROM, with lots of batch
> files...
>
> The only DOS before v3.3 which I use is MS-DOS v3.21, but I had the
> same "problems" as you decribe.
>
> I have (somehow) solved it with a dummy program "@ECHO.COM" (only
> for MS-DOS 3.21, on the boot floppy, i.e. only in the PATH of MS-DOS
> 3.21).
>
> Furthermore MS-DOS v3.21 (only) sets an env. variable "VER" in its
> autoexec.bat (set VER=MSD321).
> So most of my (common) batch files on the CDROM do start with the
> following first two lines:
>
> @ECHO OFF
> if "%VER%"=="MSD321" ECHO OFF
>
> At least this stops annoying screen messages.
That sort of works, but in MS-DOS 3.21 you still see the "@ECHO OFF" line (and
its associated error messages if they show up). I'm guessing you maybe follow
that up with a "CLS" to immediately clear the screen (which I wouldn't want to
do)?
> Feel free to try my code, if it helps:
> (start of echo.asm)
>
> ; Dummy program for MS-DOS before v3.3
> ; to avoid stupid error messages in batch files
> ; starting with "@ECHO OFF".
> ; Memo: DOS COMMAND.COM before 3.3 doesn't know "@ECHO".
> ; Frank Haeseler 2018.
> ; See the help message for more information, or just
> ; try the tool :-). Compiler: nasm.sourceforge.net,
> ; To compile, do: nasm -o @echo.com echo.asm
>
>
> org 100h
> start:
> mov si,81h ; start of command line
> cline: mov ax,[si]
> inc si
> cmp al,9 ; ignore tab
> jz cline
> cmp al,' ' ; ignore spaces
> jz cline
> jb help ; end of commandline reached but no argument > yet
> cmp al,'/' ; user tried to do /? or similar
> jz help
> jmp main ; else assume that the argument starts here
>
> help: mov ah,9 ; show help string
> mov dx,helpmsg
> int 21h
> mov ax,4c01h ; return with EL 1 (EL not really needed)
> int 21h
>
> main:
> mov ax,4c00h ; do nothing, exit with EL 0 (EL not needed)
> int 21h
>
>helpmsg:
> db "@ECHO.COM - dummy program for MS-DOS before v3.3",13,10
> db " (avoids error messages in batch files)",13,10
> db 13,10
> db "Usage:",13,10
> db " @ECHO.COM [/? | text]",13,10
> db 13,10
> db " /? prints this help text",13,10
> db " /h prints this help text",13,10
> db 13,10
> db "All other arguments, e.g. '@ECHO OFF', are ignored.",13,10
> db "$"
>
> (send of echo.asm)
This wouldn't actually solve my problem, but it's a good attempt. All this
does is create an @ECHO.COM program that doesn't actually do anything useful,
but simply prevents DOS from displaying the "bad command" error message. As
noted above, if it could actually turn ECHO OFF it might be possible to use as
a start to solve my particular problem, but as it is now it really wouldn't
help me.
*************************************************************
Jerome Shidel:
> Well, I guess I'll put in two cents worth of a non-standard
> solution.
> If you don't want to have the echo off on the screen and don't want
> to clear the screen either, you can do it using two utilities in
> V8Power tools (available and provided with FreeDOS).
>
> It would look something this.
>
> TEST.BAT
>
> echo off
> vgotoxy up
> vecho /n /e
> echo hi
>
> END
>
> So what happens is this:
>
> echo off # displays the command echo off
> vgotoxy up # moves the cursor back up one line
> vecho /n /e # tells vecho not to perform a CRLF when
> finished and tells it to clear
> everything from the cursor to the end of the line.
> echo hi # prints hi where echo off originally
> was located.
>
> While technically, echo off is printed then erased. It happens very
> quickly.
> Also, if you redirect output to a file, you will see the echo off
> that appears first.
>
> Oh, one more thing...
>
> It could also possibly be a one-liner, like so:
>
> echo off | vgotoxy up | vecho /n /e
>
> But, it will display all of that before erasure. Also, I have no
> idea if there would be compatibility issues under some DOS platforms
> or their different versions. But, it works fine in FreeDOS as a
> one-liner.
This to me seems like a solution that could actually do what I'm wanting to
accomplish. I may experiment with that and see what happens. As you note,
there may be compatibility issues with some DOS versions (V8 power tools may
not work with older versions of DOS).
*************************************************************
Joao Silva:
> Have you tested with a command with @ ex: @dir ?
In later versions of DOS that support "@" to hide lines, that will always work.
As alluded to in my initial post, the "@" is sort of like an "ECHO OFF" for
single line in a batch file, while "ECHO OFF" is sort of like an "@" for every
line in the batch file. But the "@" options only works in certain DOS's.
*************************************************************
Travis Siegel:
> It seems trying to redirect the echo off command (at least under
> windows in a cmd prompt) does indeed create the echoed test on the
> screen because of the STDERR being directed to the screen as stated
> above. Regular echo commands however do redirect just fine
I think you're confusing what ECHO does with what redirection ("> NUL") does.
"ECHO OFF" (or "ECHO ON") only applies inside a single BATCH file. When ECHO
is ON (the default), each line of the batch file is echoed to the screen as it
is executed, so what you see on the screen is sort of like what you would see
if you were typing each line of the batch file by hand at the command-line. In
a sense, it is "copying" the batch file to the screen as it is being processed.
On the other hand, when you redirect the output, you are simply redirecting
the output of the program that is being executed and has nothing to do with
what happens at the command-line.
As an example, if ECHO is ON (the default) and you do a DIR command inside a
batch file, you would see both the "DIR" and the list of files appear on the
screen. If ECHO if OFF, you would just see the list of files but not see the
"DIR". If you do a "DIR > NUL" you don't see the list of files, but you may
see the "DIR > NUL" (depending on the current ECHO state).
At least here in America, we sometimes use the term "Watching the sausage being
made" as the idiom for what "ECHO ON" does. Most of the time, you just want to
eat the sausage (see the results) and not watch the entire gory process.
*************************************************************
userbeitrag:
> I don't think that this can be solved -- because there are so many
> different command interpreters out there, and every one acts at
> least a tiny little bit differently...
I think you're basically correct. I don't think there's any "universal" way to
keep it from happening in the first place, but I think it might be possible to
use the V8 Power tools suggestion above (or something similar to it) to "erase"
the problem after it happens.
> I just tried "SET ECHO=@ECHO OFF" and "%ECHO%" in a batch file with
> 4DOS (a replacement for the COMMAND.COM command interpreter of any
> given DOS) and it worked.
That's interesting. Apparently 4DOS expands all the environment variables
before it processes the line in the batch file (including the potential "@" at
the beginning), while the other DOS's must process the "@" before they expand
the environment variables. It seems like the 4DOS way is more versatile.
> How about using 4DOS as a default SHELL, i.e. set SHELL= in
> CONFIG.SYS (you already rely on SET ECHO for your batch files...)
> and this will solve your issue on every DOS, regardless of the exact
> version.
I used to to 4DOS and I _really_ liked it. The reason I stopped using it was
because hardly anybody else did, and I wanted my system setup to develop and
test programs to be as much like everybody else's as a I could. As alluded to
in my first post, I'm trying to set up all my different test environments in
their "native" format (default kernel and command processor), so this really
isn't a viable option.
If I were strictly a user and not interested in program development and
testing, I think I might go back to using 4DOS. But then I think I would also
be less effective at helping others who don't "upgrade" to 4DOS.
By the way, at least some of the later versions of the Norton Utilities for DOS
came with NDOS, which was just 4DOS with a different name.
*************************************************************
Bob Pryor:
> Once you have debugged ALL your batch files you can place `CTTY NUL'
> before the command(s) and `CTTY CON' after to avoid output to
> screen.
This is an interesting concept, and I've used the CTTY NUL/CTTY CON "trick"
before myself. As you've noted, it's a very dangerous place to go if you're
not VERY careful since once you do a "CTTY NUL' your keyboard doesn't work any
more until you issue a "CTTY CON" and you can't manually enter a "CTTY CON"
since you've disabled the keyboard.
There are also some "technical" problems with this solution as discussed below.
> CONFIG.SYS
> REM Set environment to 1536 and direct console I/O to NUL.
> SHELL=C:\COMMAND.COM NUL /E:1536 /P
>
> AUTOEXEC.BAT
> echo off
> REM Re-establish normal console I/O (i.e. change NUL to CON)
> CTTY CON
>
> This is documented back to PC-DOS 2.0. Type COMMAND /? to see that
> the second optional parameter to it is a device name, used for input
> and output.
I don't know if the "SHELL=COMMAND.COM NUL ..." would work in all versions of
DOS. It theoretically _should_ work, but I'd actually be surprised if modern
versions of DOS even did any testing to verify.
But, this seems like it could be a good option to handle AUTOEXEC.BAT. As
discussed below, however, this approach really doesn't work for anything other
than AUTOEXEC.BAT.
Your suggestion to handle things other than AUTOEXEC.BAT:
> COMMAND NUL /C some.bat
> or
> COMMAND NUL /C call some.bat]
> [It should stay NUL until the chain/call ends, then return to CON.]
>
> COMMAND NUL /C ....
> gives the same results as
> CTTY NUL
> ....
> CTTY CON
There are several issues with this approach. First of all it would be simpler,
easier, and use less memory to simply do a:
CTTY NUL
Some.Bat (or CALL Some.Bat)
in the calling batch file and then the first three lines of the called batch
file would be:
CTTY NUL
ECHO OFF
CTTY CON
You still need the CTTY NUL at the beginning of the called batch file in case
you run it stand-alone instead CALLing it. If it is called you won't see the
"CTTY NUL" but if you run it stand-alone you will. As noted elsewhere,
essentially all you've done is replaced the unwanted "ECHO OFF" on the screen
with an unwanted "CTTY NUL", so that doesn't really fix the problem. If the
secondary batch file is "jumped to" instead of CALLed, you also need to make
sure you end it with an EXIT so the secondary command processor is properly
halted.
The other thing to note, and most people don't realize, is that if you use the
option that starts with the "COMMAND NUL" instead of just the simpler "CTTY
NUL", you will have environment issues. Whenever you load a secondary command
processor, the environment from the previous command process is simply _copied_
to the new processing environment. If you make any changes to the environment
(adding/deleting/modifying environment variables) then those changes are
deleted when you EXIT the secondary processing environment. The changes do not
get passed back to the previous (or ultimately the master) environment.
Any batch file that could potentially be issued from a secondary command
process shouldn't mess with environment variables that are intended to be
"permanent". In my particular case, the small, unique AUTOEXEC.BAT files only
set up a few environment variables (the ones needed to identify which OS is
running), but most of the "real" environment variables are set up in the
"master" or "common" AUTOEXEC.BAT file. So the "COMMAND NUL" thing won't work.
*************************************************************
tom ehlert:
>> Once you have debugged ALL your batch files you can place `CTTY
>> NUL' before the command(s) and `CTTY CON' after to avoid output to
>> screen.
>
> excellent idea.
>
> now you have exchanged the annoying
>
> echo off
>
> for the much better
>
> CTTY NUL
>
> in addition, neither I nor you know if 'CTTY NUL' works on MSDOS 3.0
Touche, Tom. See above.
*************************************************************
Robert Riebisch:
> The original requirement was MSDOS <3.30.
> I tested with MSDOS 3.21 and it worked.
>
> Test with MSDOS 3.0 was okay too.
>
> But as you already mentioned above, it won't help to prevent display
> of the first line of a batch file.
Touche as well, Robert.
*************************************************************
Tom Ehlert:
> correcting myself, CTTY NUL probably always worked, from MSDOS 1.0,
> as MSDOS was supposed (I never tested) to be able to run on a serial
> terminal.
>
> so
>
> CTTY COM1
>
> would redirect input and output to COM1. and you could move the
> cursor on the screen (and other stuff) using ESCape sequences.
> ANSI.SYS was used to simulate this (I think a VT100 terminal) on the
> CGA display, so software could be written that would work
> 'everywhere'.
It was supposed to work even before there were VT100 terminals -- back in the
days of teletype machines where you couldn't move backwards at all (not even on
a single line). In fact, that's where the "CTTY" nomenclature came from
(Change TeleTYpe) and why DOS came with EDLIN (a line editor instead of a
visual editor).
Like you, I've never seen DOS used with a serial connection (either with a
teletype or a VT100), though in theory it should work. In the ancient past, I
have used teletypes and VT100's (and punch cards and other things less archaic
people have probably never even seen in real life) with larger computer
systems, but never with DOS.
***********************
After thinking about this some more, I began to wonder why when processing
CONFIG.SYS the default is equivalent to "ECHO OFF" (you don't see the
CONFIG.SYS lines being displayed), and there is no equivalent to "ECHO ON" for
CONFIG.SYS. You can (in later versions of DOS) press F8 to single-step through
CONFIG.SYS, but you can't do the equivalent of an "ECHO ON".
With batch files, including AUTOEXEC.BAT, the default is "ECHO ON", which is
backwards from what CONFIG.SYS does. Anyway, I was wondering if it might not
be a good idea in a future version of FreeDOS to have something like a
"BATCHECHO=OFF/ON" and "CONFIGECHO=OFF/ON" setting (probably in CONFIG.SYS) to
set the default ECHO values for those, and maybe have the "@" do the opposite
of what it does now when ECHO=OFF (display a line instead of hide it). Just a
thought (maybe a stupid one).
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
