ECHOing custom prompt messages [LONG]

[William Allen]

======The ExitPrompt method (devised by Benny Pedersen)

In June this year, Benny Pedersen devised a new, compact, versatile,
and simple way of ECHOing custom prompt messages. The Original post
reference for the ExitPrompt method is given in Note 1).

This article develops some simple ideas from that post.

The lowly DOS prompt, given hardly a glance by many $p$g (default)
prompt users, can be customised in a number of ways, the (unusual)
uses of which may not be immediately apparent. Apart from the addition
of standard text messages, there are a number of special function
codes provided that extract information from the Operating System
and load it into the Prompt. These are:

$Q = (equal sign)
$$ $ (dollar sign)
$T Current time
$D Current date
$P Current drive and path
$V Windows or MS-DOS version number
$N Current drive
$G > (greater-than sign)
$L < (less-than sign)
$B | (pipe)
$H Backspace (erases previous character)
$E Escape code (ASCII code 27)
$_ Carriage return and linefeed

By combining the information from these into a custom prompt,
the lowly DOS prompt can be pushed into service to create
specialised batch files, Debug scripts, and other useful items.

To see how the ExitPrompt technique works, try this:

At a DOS prompt, type the command line shown:
============Screen capture
C:\WORK>echo.exit|command/k prompt This is a custom prompt

This is a custom promptexit

C:\WORK>
============End screen capture

Note. The | character is the pipe operator. If you have trouble
typing it at the DOS prompt, see my post mentioned in Note 2.

The first thing to notice is that this doesn't change your
current prompt. The "This is a custom prompt" message is set
as the prompt in the child command shell that COMMAND/K opens.

Piping EXIT into this child command shell causes it to echo
the prompt there once, followed by the text "exit". The piped
EXIT message then causes the child command shell to close, and
the prompt change there is lost. This is why your current prompt
isn't affected (parent shells don't inherit environment changes,
such as prompt changes, from child shells).

Although this doesn't seem much at first, it opens up all sorts
of possibilities. The first thing you can do is to move the "exit"
onto another line. Since $_ is the special function to insert a
CarriageReturn Linefeed into a custom prompt, try adding it like this:

============Screen capture
C:\WORK>echo.exit|command/k prompt This is a custom prompt$_

This is a custom prompt
exit

C:\WORK>
============End screen capture

An improvement. Notice that the "exit", which is echoed immediately
after whatever is in the prompt message has been interpreted, is
now on a new line.

The output of the ExitPrompt technique can be redirected to a file
in the normal way. You can write the output to a file called HOME
like this:

============Screen capture
C:\WORK>echo.exit|command/k prompt This is a custom prompt$_>HOME

C:\WORK>type home

This is a custom prompt
exit

C:\WORK>
============End screen capture

The file you redirect to could (and often will) be a temporary
batch script. To take a simple example, in a main Batch script,
it's often necessary to make a new folder and/or drive current
by using CD. When you do this the original current folder that
the script started in is lost to you. To change back you need
to execute the two separate commands:

DriveLetter:
CD OriginalFolderName

Of course, you won't in general know what these were, since
your main script could be started with any folder you please
as the current one.

However, the special function codes for the prompt contain
what you need.
$N Current drive
$P Current drive and path
and of course,
$_ Carriage return and linefeed
to insert a [newline] between items.

Try this custom prompt with the ExitPrompt technique:

============Screen capture
C:\WORK>echo.exit|command/k prompt $N$_$P$_

C
C:\WORK
exit

C:\WORK>
============End screen capture

That is nearly there. If we add a colon after the $N and "CD "
(notice the [Space]) in front of the $P we have the two commands
to change back to the current "Home" folder. Like this:

============Screen capture
C:\WORK>echo.exit|command/k prompt $N:$_CD $P$_

C:
CD C:\WORK
exit

C:\WORK>
============End screen capture

Try redirecting that into a batch file called HOME.BAT (don't
run the resulting batch file yet). Like this:

============Screen capture
C:\WORK>echo.exit|command/k prompt $N:$_CD $P$_>HOME.BAT

C:\WORK>type home.bat

C:
CD C:\WORK
exit

C:\WORK>
============End screen capture

The HOME.BAT file is almost there. The remaining problem is
the "exit" at the end, which we need to remove. We could use
the FIND command to filter it out, but there is no need in
this case. Remember that the "exit" follows immediately on
from whatever is in the custom Prompt message. Since we're
using this to create HOME.BAT as a temporary batch file, we
can "remove" the "exit" by turning it into a label that we
don't use. We simply need a : (colon) in front of it. To put
a colon in front of it, just add the colon as the last thing
in the ExitPrompt custom prompt. Like this:

============Screen capture
C:\WORK>echo.exit|command/k prompt $N:$_CD $P$_:>HOME.BAT

C:\WORK>type home.bat

C:
CD C:\WORK
:exit

C:\WORK>
============End screen capture

The spurious "exit" message is now converted to a (non-functioning)
label inside the temporary HOME.BAT file.

HOME.BAT is now a batch file that will take your main script
home to the original drive and folder whenever it is executed.

In a main Batch script, it's conventional (though usually not
really necessary) to run COMMAND.COM by expanding the COMSPEC
system variable. So this version comes to the same thing. Try it:

============Screen capture
C:\WORK>echo.exit|%comspec%/k prompt $N:$_CD $P$_:>HOME.BAT

C:\WORK>type home.bat

C:
CD C:\WORK
:exit

C:\WORK>
============End screen capture

Is that all there is to it? Not quite. It's possible that your
script may be run on a system with low environment memory set.
And the custom prompt you're creating in the child COMMAND shell
takes up (but only momentarily) perhaps a few dozen bytes of the
environment space - depends on how long the current folder name is.

You can add a switch, /e:4096 to COMMAND to make sure there is
plenty of environment space as your custom Return Home prompt is
momentarily echoed into the HOME.BAT file. Like this:

============Screen capture
C:\WORK>echo.exit|%comspec%/e:4096/k prompt $N:$_CD $P$_:>HOME.BAT

C:\WORK>type home.bat

C:
CD C:\WORK
:exit

C:\WORK>
============End screen capture

Notice that the /K switch must be the last of the COMMAND switches
when used. It's not necessary to leave spaces between the %COMSPEC%
and the switches, but it looks neater in a script if you do.

After you've used HOME.BAT to take your main script home to the
original drive and folder, HOME.BAT isn't needed anymore.

A tidy and compact way of executing then deleting a temporary
batch file all in one line is:

FOR %%C IN (CALL DEL) DO %%C HOME.BAT

This FOR IN DO line first CALLs then DELetes the file HOME.BAT

If you wish, you can locate your temporary ReturnHome script
in the system TEMP folder. The normal way to access the TEMP
folder is by expanding the TEMP variable with the construct:

%TEMP%.\

The .\ is an "emending suffix" that corrects the contents of
TEMP in the event a particular user has added a spurious backslash
character to their TEMP folder setting.

So you would use %TEMP%.\HOME.BAT as your temporary script name.

Putting all that together makes this useful two-working-line clip
for use in your main Batch scripts:

=================================
@ECHO OFF
:: Create return HOME script for current drive and folder
ECHO.EXIT|%COMSPEC% /e:4096 /k PROMPT $N:$_CD $P$_:>%TEMP%.\HOME.BAT

:: Work in another folder for a while

:: Go back to original folder
FOR %%C IN (CALL DEL) DO %%C %TEMP%.\HOME.BAT
=================================

In Windows 95/98/ME, you can add "quotes" around the $P part
so that the CD "Original Folder" part of the HOME.BAT script
will work if you are operating in folders that have spaces in
their names.

================================Long folder name version
@ECHO OFF
:: Create return HOME script for current drive and folder
ECHO.EXIT|%COMSPEC% /e:4096 /k PROMPT $N:$_CD "$P"$_:>%TEMP%.\HOME.BAT

:: Work in another folder for a while

:: Go back to original folder
FOR %%C IN (CALL DEL) DO %%C %TEMP%.\HOME.BAT
=================================

This simple two-line clip uses only one temporary file and is neat
and compact in use. It's just one of the useful applications of
Benny Pedersen's ExitPrompt technique.

Two other examples:

You can set the PROMPT to be "SET DATE=$D" and the $D
will be interpreted as the current system date.

You can set the PROMPT to be "SET TIME=$T" and the $T
will be interpreted as the current system time.

So the ideas above can be used to build and execute temporary
scripts that load these items into environment variables, as here:

=================================
@ECHO OFF

:: Example 1 - getting the DATE into an environment variable
:: Create ExitPrompt script to load DATE into variable D
ECHO.EXIT|%COMSPEC% /e:4096 /k PROMPT SET DATE=$D$_:>%TEMP%.\DATE.BAT

:: Execute and delete the temporary script
FOR %%C IN (CALL DEL) DO %%C %TEMP%.\DATE.BAT

ECHO. The date is %DATE%

:: Example 2 - getting the TIME into an environment variable
:: Create ExitPrompt script to load TIME into variable T
ECHO.EXIT|%COMSPEC% /e:4096 /k PROMPT SET TIME=$T$_:>%TEMP%.\TIME.BAT

:: Execute and delete the temporary script
FOR %%C IN (CALL DEL) DO %%C %TEMP%.\TIME.BAT

ECHO. The time is %TIME%
=================================

============

Are there any disadvantages of the ExitPrompt technique compared
with the conventional rather clumsier ways of echoing custom prompt
messages? Yes, two, but they are only minor.

1) While it makes many things possible on one command line, that
command line can get very long with more specialised uses, such
as creating on-the-fly debug scripts.

2) The "exit" piped into the /K shell to make it transient is
loaded into your current DosKey history, so take note when using
DosKey after using ExitPrompt.

--
William Allen

Note 1:
Original ExitPrompt Idea: Benny Pedersen
Date: 2001-06-27 17:22:38
Message-ID: <KLu_6.416$It4....@news.get2net.dk>

Note 2:
Typing the pipe character | correctly in a DOS box
From: "William Allen"
Newsgroups: alt.msdos.batch
Subject: Re: The |
Date: Sat, 22 Sep 2001 11:09:06 +0100
Message-ID: <9oho4d$d01bq$1...@ID-55970.news.dfncis.de>

Note 3:
The ExitPrompt idea was used in a particularly innovative way in a
script to parse the sytem date, removing non-numeric characters
from the $D prompt function, in a recent post by Laura Fairhead:

From: (laura fairhead)
Newsgroups: alt.msdos.batch
Subject: Re: Zipping a file file into a new file named as todays date
Date: Wed, 03 Oct 2001 19:33:02 GMT
Message-ID: <3bbb67ed...@news.cis.dfn.de>

(Laura Fairhead's alt.msdos.batch posts are always worth studying)

You can read old Usenet posts at:
http://groups.google.com/advanced_group_search

Note: Google search by Message-ID is usually the quickest.
Message-ID search works with or without <angle> brackets.
Simply cut-and-paste the Message-ID into Google page above

[William Allen]

William Allen wrote in message
...snip

> In June this year, Benny Pedersen devised a new, compact, versatile,
> and simple way of ECHOing custom prompt messages. The Original post
> reference for the ExitPrompt method is given in Note 1).

Benny, I wrote this article because it seemed that (with the usual
honorable exception of Laura Fairhead!) this was another really
useful new idea from you that not many people were using yet.

I've written it to show the development of the compact HOME.BAT
script that I discussed with you at the time you posted the original
ExitPrompt (ECHO.EXIT | %COMSPEC% /k prompt) discovery.

--
William Allen

The original HOME.BAT idea based on ExitPrompt was outlined in post:

From: "William Allen"
Newsgroups: alt.msdos.batch

Subject: Re: Demo.bat -- Replace a two-liners with an one-liner.
Date: Thu, 28 Jun 2001 21:24:18 +0100
Message-ID: <9hg3rp$dn8do$1...@ID-55970.news.dfncis.de>

[William Allen]

William Allen wrote in message
...snip

> In a main Batch script, it's conventional (though usually not
> really necessary) to run COMMAND.COM by expanding the COMSPEC
> system variable. So this version comes to the same thing. Try it:
>
> ============Screen capture
> C:\WORK>echo.exit|%comspec%/k prompt $N:$_CD $P$_:>HOME.BAT
>
> C:\WORK>type home.bat
>
> C:
> CD C:\WORK
> :exit
>
> C:\WORK>
> ============End screen capture

Users of legacy MS-DOS prior to 7.0 should note that, in their
systems, environment variables are not expanded when working
in immediate mode at the prompt, so tutorial items such as the
above can't be used for practice. You need to place the item in a
script and then run it with ECHO ON to get an idea of what happens.

--
William Allen

[Outsider]

William Allen wrote:
>
> William Allen wrote in message
> ...snip
> > In a main Batch script, it's conventional (though usually not
> > really necessary) to run COMMAND.COM by expanding the COMSPEC
> > system variable. So this version comes to the same thing. Try it:
> >
> > ============Screen capture
> > C:\WORK>echo.exit|%comspec%/k prompt $N:$_CD $P$_:>HOME.BAT

...snip

> Users of legacy MS-DOS prior to 7.0 should note that, in their
> systems, environment variables are not expanded when working
> in immediate mode at the prompt, so tutorial items such as the
> above can't be used for practice. You need to place the item in a
> script and then run it with ECHO ON to get an idea of what happens.
>

Great! Thanks for the note :).

It may also be noted that command.com can be used.

If command.com is in path:
echo.exit|command/k prompt $N:$_CD $P$_:>HOME.BAT

If not in path, include the path to where the file resides:
echo.exit|c:\dos\command/k prompt $N:$_CD $P$_:>HOME.BAT

Command may also be used in DOS 7.x versions in the same manner.

--
<!-Outsider//->
MS-DOS 6.22, Windows for Workgroups 3.11, Netscape Communicator 4.08
"Supposing a tree fell down, Pooh, when we were underneath it?"
"Supposing it didn't," said Pooh after careful thought. -- A. A. Milne

[Timo Salmi]

William Allen <ma...@mayfly13.fsnet.co.uk> wrote:
> ======The ExitPrompt method (devised by Benny Pedersen)

> :: Example 1 - getting the DATE into an environment variable

> :: Create ExitPrompt script to load DATE into variable D
> ECHO.EXIT|%COMSPEC% /e:4096 /k PROMPT SET DATE=$D$_:>%TEMP%.\DATE.BAT

Indeed. A nice idea, doing away with one intermediate phase. Thus to
give another version of the very similar method covered in my FAQ
advice and many postings here, we can have e.g. following the
rendition in the next version

@echo off
echo.exit|command /k prompt @set date_=$d$_rem >tmp$$$.bat
call tmp$$$.bat
echo %date_%
for %%f in (tmp$$$.bat) do if exist %%f del %%f
set date_=

Note the slight generalization in doing away with the superfluous
exit. Tested on 6.22.

All the best, Timo

--
Prof. Timo Salmi ftp & http://garbo.uwasa.fi/ archives 193.166.120.5
Department of Accounting and Business Finance ; University of Vaasa
mailto:t...@uwasa.fi <http://www.uwasa.fi/~ts/> ; FIN-65101, Finland
Timo's FAQ materials at http://www.uwasa.fi/~ts/http/tsfaq.html

[William Allen]

William Allen wrote in message
...snip

> Is that all there is to it? Not quite. It's possible that your
> script may be run on a system with low environment memory set.
> And the custom prompt you're creating in the child COMMAND shell
> takes up (but only momentarily) perhaps a few dozen bytes of the
> environment space - depends on how long the current folder name is.

Correction:
Since only the code for the foldername = $P is stored, not the
name itself, the extra prompt overhead is _not_ dependent on the
foldername length.

Although the overhead is quite small, and /e:4096 seems
a huge space to reserve for a dozen or two bytes, it _can_
be necessary. The new environment space is reserved only
for an instant, then released (so there's no system overhead).
However, the transient environment starts by inheriting the
current contents of the existing user-environment.

For a real-world case where problems arose, see my post

From: "William Allen"
Newsgroups: alt.msdos.batch

Subject: Re: Right click command calling batch script
Date: Fri, 28 Sep 2001 10:07:55 +0100
Message-ID: <9p1eod$g3hei$2...@ID-55970.news.dfncis.de>

In the solution to this OP's problem I had used a 30-byte prompt
echo (old method, since the ExitPrompt version of the command
line needed for this would have been rather long for Usenet). This
created a small Universal Prefixer debug script.

I used a 1Kbyte byte child environment space to create the prompt.
This worked on my system, but the OP had several Kbytes of custom
variables set for JAVA programming work with Batch files. The initial
solution failed with "out of environment space". A simple modification
to /e:4096 for the transient shell fixed the problem immediately.

--
William Allen

Note: You can read old Usenet posts at:
http://groups.google.com/advanced_group_search

Note: Google search by Message-ID is usually the quickest.
Message-ID search works with or without <angle> brackets.

Simply cut-and-paste the Message-ID into Google page above.

[Charles Dye]

"William Allen" <ma...@mayfly13.fsnet.co.uk> wrote in message news:<9pp97l$jfrjf$1...@ID-55970.news.dfncis.de>...

> In a main Batch script, it's conventional (though usually not
> really necessary) to run COMMAND.COM by expanding the COMSPEC
> system variable.

I would strongly recommend using %COMSPEC% instead of assuming
COMMAND.COM for two reasons. First, not everybody uses the
default Microsoft shell, and some of us don't even have it on
our system. Second, careless DOS upgrades occasionally leave
two or more incompatible versions of COMMAND.COM on the same
hard drive -- sounds farfetched, but I have actually seen this
on more than one user's machine. If the wrong version appears
first in the path, the resulting failure can be very frustrating
for a neophyte to figure out.

> ============Screen capture
> C:\WORK>echo.exit|%comspec%/k prompt $N:$_CD $P$_:>HOME.BAT
>
> C:\WORK>type home.bat
>
> C:
> CD C:\WORK
> :exit
>
> C:\WORK>
> ============End screen capture

William, I've been meaning to ask this for some time, and this
is a good opportunity. Why do you use a period as the separator
between ECHO and its first argument? This actually works as
intended on every command shell on my machine, but relying on
undocumented behavior like this strikes me as risky. I'm curious;
you must have some reason for doing it this way, but I can't for
the life of me figure out what.

--
Charles Dye ras...@highfiber.com

[Benny Pedersen]

"William Allen" <ma...@mayfly13.fsnet.co.uk> wrote news:9ppb3s$js8jc$1...@ID-55970.news.dfncis.de...

Thanks.
I appreciate you explain stuff I can't in English.

ECHO :EXIT [comment] | %COMSPEC% /e:4096 /k PROMPT ECHO TIME $T$_>%TEMP%.\TIME.BAT
ECHO:: colon in front instead of the $_: also works.

Benny, (PS. Can you see what this is :)

File.sdc (StarOffice 5.2)
___________________________________
| A B C D E F G H I J
|1| 0 0 0 0 0 0 24 17 257 1
|2| ----------------------
|3|

----Formula i1:
=A1*10^7+B1*10^6+C1*10^5+D1*10^4+E1*10^3+F1*10^2+G1*10^1+H1*10^0

----Formula j1,
I think that the below word HELTAL in Danish is the same as INTEGER:
=A1*10^7+B1*10^6+C1*10^5+D1*10^4+E1*1000+F1*100+G1*10+H1-256*HELTAL
((A1*10^7+B1*10^6+C1*10^5+D1*10^4+E1*1000+F1*100+G1*10+H1)/256)

[William Allen]

Charles Dye wrote in message

> "William Allen" wrote in message
...snip

> > ============Screen capture
> > C:\WORK>echo.exit|%comspec%/k prompt $N:$_CD $P$_:>HOME.BAT

...snip

> William, I've been meaning to ask this for some time, and this
> is a good opportunity. Why do you use a period as the separator
> between ECHO and its first argument? This actually works as
> intended on every command shell on my machine, but relying on
> undocumented behavior like this strikes me as risky. I'm curious;
> you must have some reason for doing it this way, but I can't for
> the life of me figure out what.

With ECHO. usage

1) Legibility/clarity of script
If there are following spaces that are intended to indent
the output text, this is immediately apparent. And the
number of spaces _is_ the number used for indentation.

2) Consistency/Reliability
ECHO is often used to send text or expanded variable contents
to STDOUT and without the period separator as routine, you must
remember to use it whenever the text or variable does or conceivably
may begin with the two characters [O] and [N] followed by [Space]
[=] [,] [;], or the three characters [O] [F] [F] followed any of
those same characters.
In these cases ECHO enters command mode and full text content
is not echoed. If the ON[delimiter] or OFF[delimiter] fragments are
followed by further text, the command mode entry is bad, and the
OFF or ON command may not be executed, but the text echoing is
still corrupted. In a long recursive script echoing variables dynamically,
this can be tiresome to spot. If you know you _must_ occasionally (but
unpredictably) use ECHO. you may as well always use ECHO. and
avoid hard-to-locate bugs.

3) Macro usage in text editors
I often create part/all of a batch script with a regular expression or
macro in TextPad or UltraEdit (now added to our standard editor suite)
So for example, having constructed a script for, say Debug, and checked
it, converting to ECHO.>SCR form is more reliably done with ECHO. since
any blank lines in the script are handled correctly.

Notes:
1)

> but relying on
> undocumented behavior like this strikes me as risky

I don't "rely" on anything, whether documented by Microsoft or not. Very
little of the Batch language as usefully employed is actually documented
by Microsoft. Part of my current job here is to document specific Batch features
of Windows 95/98/ME, which is especially poorly documented in official
material (and done so in a highly scattered way). So I document, test,
redocument, test in a continuous iteration. To use only "Microsoft
documented" behaviour would be a contradiction. I use the behaviour
that I am documenting, as established so far.

Relying on (what will always in the end be) your own interpretation
of the Human Language in a program document is not without risk.
The program is the program. The documentation is someone else's
English essay on the subject of the program, filled with metaphore,
trope, allusion, errors, ommissions, and countless words each with
more than one "documented" meaning.

Glance briefly at (don't linger on) the dialogue of the deaf in amb
between those who don't define terms and those who make them
up as they please. Here is displayed the fallacy of "documentation".

2) Special characters with the ECHO command
There are twelve special immediate-suffix characters for the ECHO
command that are not themselves ECHOed when immediately
suffixed to ECHO

They fall into three Groups:

Group One
[Space]
[Comma]
[Semi-colon]
[EqualSign]
[Colon]

Group Two
[Period]
[\]
[+]
["]
[ character itself
] character itself

Group Three
[/]

Group One features:
The five immediate suffix characters in Group One do not suppress
the action of a following ON or OFF and do not prevent bad command
mode entry if those "commands" are followed by, but delimited from,
other text.

Group Two features:
The six in Group Two _do_ stop the action of a following
ON or OFF and _do_ prevent bad command mode entry if those
"commands" are followed by, but delimited from, other text.

Group Three features:
The one character in Group Three has the properties of Group Two
in that it _does_ stop the action of a following ON or OFF and
_does_ prevent bad command mode entry if those "commands"
are followed by, but delimited from, other text. It has the further
property (not shared by the other eleven) that it suppresses the
action of the brief help /? command:

============Screen capture in Windows 95
C:\WORK>set v=/?

C:\WORK>echo.%v%
Displays messages, or turns command-echoing on or off.

ECHO [ON | OFF]
ECHO [message]

Type ECHO without parameters to display the current echo setting.

C:\WORK>echo %v%
Displays messages, or turns command-echoing on or off.

ECHO [ON | OFF]
ECHO [message]

Type ECHO without parameters to display the current echo setting.

C:\WORK>echo/%v%
/?

C:\WORK>
============End screen capture

I don't use the Group Three character as the text separator, thus:
ECHO/This text is echoed
since, although very marginally less likely to produce spurious
errors, the / character has other special functions which
may lead to unexpected conflicts, and it simply looks messy.

--
William Allen

[William Allen]

Benny Pedersen wrote in message
...snip

> Benny, (PS. Can you see what this is :

No. Further explanation/context would save time :-)

--
William Allen

[Outsider]

Charles Dye wrote:
>
> "William Allen" <ma...@mayfly13.fsnet.co.uk> wrote in message news:<9pp97l$jfrjf$1...@ID-55970.news.dfncis.de>...
>
> > In a main Batch script, it's conventional (though usually not
> > really necessary) to run COMMAND.COM by expanding the COMSPEC
> > system variable.
>
> I would strongly recommend using %COMSPEC% instead of assuming
> COMMAND.COM for two reasons. First, not everybody uses the
> default Microsoft shell, and some of us don't even have it on
> our system. Second, careless DOS upgrades occasionally leave
> two or more incompatible versions of COMMAND.COM on the same
> hard drive -- sounds farfetched, but I have actually seen this
> on more than one user's machine.

This is a non-argument if I ever saw one. the liklihood of having two
different versions of command.com interferring with this technique is
miniscule to the point of being microsopic. People who will use this
technique are certainly NOT the "clueless" users you speak of, but
people that (at least) have an idea of what they are doing.

If a computer user has installed a specialized command interpreter,
do you really think s/he is too stupid to know about it? Or do you
think that if a person momentarily forgets and tries "command"
without success, s/he will be too stupid to realize what happened?

> If the wrong version appears
> first in the path, the resulting failure can be very frustrating
> for a neophyte to figure out.

Give it a rest already.

> > ============Screen capture
> > C:\WORK>echo.exit|%comspec%/k prompt $N:$_CD $P$_:>HOME.BAT
> >
> > C:\WORK>type home.bat
> >
> > C:
> > CD C:\WORK
> > :exit
> >
> > C:\WORK>
> > ============End screen capture
>
> William, I've been meaning to ask this for some time, and this
> is a good opportunity. Why do you use a period as the separator
> between ECHO and its first argument? This actually works as
> intended on every command shell on my machine, but relying on
> undocumented behavior like this strikes me as risky. I'm curious;
> you must have some reason for doing it this way, but I can't for
> the life of me figure out what.

All you need to do is place two comparison lines in a batch file, ie.

@ECHO off
ECHO this is a line without a dot
ECHO. this is a line with a dot
ECHO.
ECHO. Did you see the difference?
::

[William Allen]

Charles Dye wrote in message

...snip

> Why do you use a period as the separator
> between ECHO and its first argument? This actually works as
> intended on every command shell on my machine

Out of interest, it would help me if you have time to list the exact
command shells you tested the "ECHO.SomeText" construct on.

--
William Allen

[William Allen]

William Allen wrote in message

> ECHO is often used to send text or expanded variable contents
> to STDOUT and without the period separator as routine, you must
> remember to use it whenever the text or variable does or conceivably
> may begin with the two characters [O] and [N] followed by [Space]
> [=] [,] [;], or the three characters [O] [F] [F] followed any of
> those same characters.

Or, of course, whenever there is a possibility the ECHOed variable
may be empty or contain only delimiters.

--
William Allen

[Todd Vargo]

"Outsider" <nonvali...@yahoo.com> wrote in message
news:3BC14198...@yahoo.com...

> Charles Dye wrote:
> >
> > "William Allen" <ma...@mayfly13.fsnet.co.uk> wrote in message
news:<9pp97l$jfrjf$1...@ID-55970.news.dfncis.de>...
> >
> > > In a main Batch script, it's conventional (though usually not
> > > really necessary) to run COMMAND.COM by expanding the COMSPEC
> > > system variable.
> >
> > I would strongly recommend using %COMSPEC% instead of assuming
> > COMMAND.COM for two reasons. First, not everybody uses the
> > default Microsoft shell, and some of us don't even have it on
> > our system. Second, careless DOS upgrades occasionally leave
> > two or more incompatible versions of COMMAND.COM on the same
> > hard drive -- sounds farfetched, but I have actually seen this
> > on more than one user's machine.
>
> This is a non-argument if I ever saw one. the liklihood of having two
> different versions of command.com interferring with this technique is
> miniscule to the point of being microsopic. People who will use this
> technique are certainly NOT the "clueless" users you speak of, but
> people that (at least) have an idea of what they are doing.
>
> If a computer user has installed a specialized command interpreter,
> do you really think s/he is too stupid to know about it? Or do you
> think that if a person momentarily forgets and tries "command"
> without success, s/he will be too stupid to realize what happened?

Back when W95 came out, some OEMs were shipping systems with upgrades from
DOS6.xx/Win3.xx installed, leaving the old OS files in place. I'm sure it's
possible there are some people reading here that may have bought those
computers second hand (third hand even) by now.

>
>
> > If the wrong version appears
> > first in the path, the resulting failure can be very frustrating
> > for a neophyte to figure out.
>
> Give it a rest already.

I wouldn't use that argument, but certainly, if the wrong version is located
in the current directory (and yes I have done this myself) the batch will
fail.

> >
> > William, I've been meaning to ask this for some time, and this
> > is a good opportunity. Why do you use a period as the separator
> > between ECHO and its first argument? This actually works as
> > intended on every command shell on my machine, but relying on
> > undocumented behavior like this strikes me as risky. I'm curious;
> > you must have some reason for doing it this way, but I can't for
> > the life of me figure out what.

The usage of a period to create a blank line is a documented feature.

http://2dos.homepage.dk/batutil/help/ECHO_N.HTM

Echoing a blank line

To echo a blank line on the screen, you can type ECHO and then a period
(ECHO.). There must be no intervening space.

I doubt M$ is going to break this documented feature, not intentionally
anyway.

--
Todd Vargo (body of message must contain my name to reply by email)

[William Allen]

Todd Vargo wrote in message
...snip

> The usage of a period to create a blank line is a documented feature.

That is not relevant. I'm sure Charles Dye is perfectly well aware
that "help echo" (notes section) in the MS-DOS 6.22 help system
documents ECHO. _on_its_own_ for echoing blank lines.

He is querying my use of constructs such as:
ECHO. SomeText
and that isn't documented by Microsoft. If you can't see the
distinction between ECHO with (possible) command sequences that
are, or are not, followed by further text, look at this screen capture:

============Screen capture
C:\WORK>ECHO. ECHO OFF is documented to turn echo off
ECHO OFF is documented to turn echo off

C:\WORK>echo off
*
*
*
*
echo on

C:\WORK>echo off is not
OFF

C:\WORK>
============End screen capture

Lines with the added * mark the four times that I pressed [Return]

ECHO OFF
turns off echoing

ECHO OFF futher text
fails to turn echoing off, and is partially echoed instead. This
is what I called "bad" entry to command mode in my post.

I have stated my basis for consistent use of ECHO.SomeText
in my posts:

Subject: Re: ECHOing custom prompt messages [LONG]
Message-ID: <9prerk$k554u$1...@ID-55970.news.dfncis.de>
and
Subject: Re: ECHOing custom prompt messages [LONG]
Message-ID: <9prltv$jj4h4$1...@ID-55970.news.dfncis.de>

--
William Allen

[Charles Dye]

On Mon, 8 Oct 2001 08:32:00 +0100, "William Allen"
<ma...@mayfly13.fsnet.co.uk> wrote:

>Charles Dye wrote in message
>...snip
>> Why do you use a period as the separator
>> between ECHO and its first argument? This actually works as
>> intended on every command shell on my machine

[Several reasons, the most important being the possibility
of ECHOing a variable which might be empty or start with the
word "ON" or OFF"]

Thanks; you piqued my curiosity.

>Out of interest, it would help me if you have time to list the exact
>command shells you tested the "ECHO.SomeText" construct on.

I've decided to take a "mental health" day, so I don't have access
to my NT machine or a few truly obscure shells. (Who remembers
Landmark DOS for Windows? Who cares?) But on my home box, I can
confirm that your technique works as intended in the current
shipping releases of 4DOS, 4NT and Take Command/32, as well as every
version of 4DOS back to v2.00b in early 1989, and also the NDOS which
shipped with Norton Utilities 8. In the very earliest release of
4DOS in my possession, ECHO.%EMPTY% shows a spurious percent
sign, but that's not caused by the period. I think it's safe to say
that your technique will work under any JP Software shell which
anybody is likely to use.

It also works correctly in COMMAND.COM from Caldera DR-DOS 7.03 and
DR DOS 6.0. It should therefore be supported in all the releases
between, including Novell DOS and OpenDOS. It also works as
intended under the only version of Win95Cmd I have -- VER reports
nothing useful; the file size is 307,472 bytes. This handling of a
nonspace delimiter is undocumented, as far as I can tell, but it
appears to be widely emulated.

The only COMMAND.COM-sorta-compatible shell I have which would not
accept ECHO.ANYTHING is FlexShell 1.20. I would be very surprised
to learn that anybody on the planet still uses that one.

--
Charles Dye ras...@highfiber.com

"There is a Rose with a Worm in its Breast, who laughs with a
ghastly Suicide; there is a Cheese full of Holes who pretends fear of
the Plate and Knife; there are two Houses Afire who are cool to one
another; there is a Starry Night, there is a sheaf of wheat, a horse,
a cloud."

[Charles Dye]

On Mon, 8 Oct 2001 05:09:35 -0400, "Todd Vargo" <t...@birdlover.com>
wrote:

>> Charles Dye wrote:
>> >
>> > I would strongly recommend using %COMSPEC% instead of assuming
>> > COMMAND.COM for two reasons. First, not everybody uses the
>> > default Microsoft shell, and some of us don't even have it on
>> > our system. Second, careless DOS upgrades occasionally leave
>> > two or more incompatible versions of COMMAND.COM on the same
>> > hard drive -- sounds farfetched, but I have actually seen this
>> > on more than one user's machine.
>

>Back when W95 came out, some OEMs were shipping systems with upgrades from
>DOS6.xx/Win3.xx installed, leaving the old OS files in place. I'm sure it's
>possible there are some people reading here that may have bought those
>computers second hand (third hand even) by now.

Nor were all the upgrades done by OEMs.

Using %COMSPEC% is even more important when using real programming
languages, as opposed to batch scripts. I have, honest to God, seen
expensive commercial software do important file-maintenance tasks by
shelling out to C:\DOS\COMMAND.COM -- yes, with the path hard-coded
into the executable -- and handing it a /C WHATEVER.BAT to execute.
One example was a leading professional dental-accounting package. You
can imagine what happened to that program when Windows 95 came out.

"Hey! How come I can't back up my transactions anymore!?"

--
Charles Dye ras...@highfiber.com

[Charles Dye]

On Mon, 8 Oct 2001 10:44:37 +0100, "William Allen"
<ma...@mayfly13.fsnet.co.uk> wrote:

>Todd Vargo wrote in message
>...snip
>> The usage of a period to create a blank line is a documented feature.
>
>That is not relevant. I'm sure Charles Dye is perfectly well aware
>that "help echo" (notes section) in the MS-DOS 6.22 help system
>documents ECHO. _on_its_own_ for echoing blank lines.

As does the MS-DOS 5 user guide. The feature itself is older than
that. An OEM copy of MS-DOS 3.1 supports it; IBM DOS 2.0 does not.

--
Charles Dye ras...@highfiber.com

[Outsider]

Charles Dye wrote:
>
> On Mon, 8 Oct 2001 05:09:35 -0400, "Todd Vargo" <t...@birdlover.com>
> wrote:
>
> >> Charles Dye wrote:
> >> >
> >> > I would strongly recommend using %COMSPEC% instead of assuming
> >> > COMMAND.COM for two reasons. First, not everybody uses the
> >> > default Microsoft shell, and some of us don't even have it on
> >> > our system. Second, careless DOS upgrades occasionally leave
> >> > two or more incompatible versions of COMMAND.COM on the same
> >> > hard drive -- sounds farfetched, but I have actually seen this
> >> > on more than one user's machine.
> >
> >Back when W95 came out, some OEMs were shipping systems with upgrades from
> >DOS6.xx/Win3.xx installed, leaving the old OS files in place. I'm sure it's
> >possible there are some people reading here that may have bought those
> >computers second hand (third hand even) by now.
>
> Nor were all the upgrades done by OEMs.
>
> Using %COMSPEC% is even more important when using real programming
> languages, as opposed to batch scripts.

Oh my.

> I have, honest to God, seen
> expensive commercial software do important file-maintenance tasks by
> shelling out to C:\DOS\COMMAND.COM -- yes, with the path hard-coded
> into the executable -- and handing it a /C WHATEVER.BAT to execute.
> One example was a leading professional dental-accounting package. You
> can imagine what happened to that program when Windows 95 came out.
>
> "Hey! How come I can't back up my transactions anymore!?"

And what happens when "your users" clear the comspec variable or change
it's value?

[Benny Pedersen]

"William Allen" <ma...@mayfly13.fsnet.co.uk> skrev i en meddelelse news:9prerm$k554u$2...@ID-55970.news.dfncis.de...

it is a calculator for Errorlevels but since the formulas
is in Danish, then I don't think it can be used on other
StarOffice 5.2 versions except the Danish version.
I have a copy here: http://users.cybercity.dk/~bse26236/batutil/Levels.sdc

Benny.

[Proprclr]

ras...@highfiber.com (Charles Dye)
writes:

<snip>

>Nor were all the upgrades done by OEMs.

>Using %COMSPEC% is even more important when using real programming
>languages, as opposed to batch scripts. >I have, honest to God, seen
expensive commercial software do >important file-maintenance tasks by
>shelling out to C:\DOS\COMMAND.COM -- yes, with the path hard-coded
>into the executable -- and handing it a /C WHATEVER.BAT to execute.
>One example was a leading professional dental-accounting package. You
>can imagine what happened to that program when Windows 95 came out.

> "Hey! How come I can't back up my transactions anymore!?"

It gets worse if the program relies on "backup" and "restore" from earlier
Dos programs. Sure, someone can write an adapter batch file or
an executable binary (if .com or .exe is hard coded in) to use PKzip
of something to get past this, but I can't see why any programmer would
rely on something like this, instead of writing his/her own backup routines. Is
it really that hard for a programmer to do this simple task?
--
How a geek makes an icon

@echo off
:: Vent icon
set j_)11308=photo jmp !_!41
set j_)10=photo jmp 5530
call photo {vent}
set j_)11308=
set j_)10=

[Charles Dye]

On 10 Oct 2001 14:19:54 GMT, prop...@aol.com (Proprclr) wrote:

> ras...@highfiber.com (Charles Dye)
>writes:

>
>>Using %COMSPEC% is even more important when using real programming
>>languages, as opposed to batch scripts. I have, honest to God, seen
>>expensive commercial software do important file-maintenance tasks by
>>shelling out to C:\DOS\COMMAND.COM -- yes, with the path hard-coded
>>into the executable -- and handing it a /C WHATEVER.BAT to execute.
>>One example was a leading professional dental-accounting package. You
>>can imagine what happened to that program when Windows 95 came out.
>

> It gets worse if the program relies on "backup" and "restore" from earlier
>Dos programs.

Which is *exactly* what the said dental package was doing. Really it
should have started misbehaving as soon as users began upgrading to
DOS 6.x. But as it happened, copies of the old BACKUP.EXE and
RESTORE.EXE were present in the search path, and the SETVER table
included them by default, so the whole mess accidentally failed to
malfunction....

I never thought to ask how much that package cost.

--
Charles Dye ras...@highfiber.com