Several environment variables each with the same name
William Allen
====================================
Real and Protected mode (= Dos Virtual Machine, aka DOS box)
Normally (as far as I am aware), you don't set several environment
variables all having the same name, but each with different contents.
Nor do you normally set environment variables with mixed case, or
lower case, names (such as the "windir" and "winbootdir" in Win9x),
nor do you normally set variables whose names have leading spaces.
You can do all these using the environment variable splitting
technique that I posted in:
From: "William Allen"
Newsgroups: alt.msdos.batch
Subject: Re: Long line - was (Re: One line exit (Was Re: Character))
Date: Tue, 19 Sep 2000 18:42
This enables "synthetic" environment variables to be set. By
"synthetic" I mean normal environment variables with a name that
you choose, but that can't be set with the SET command.
(The term comes from so-called "synthetic" programming
techniques where special effects are achieved by splitting
instructions - as in programming some calculators, eg the HP41C).
See the PPS for a more detailed explanation of how it works.
When there's more than one variable with the same name, for
example TESTVAR, DOS accesses only the first occurrence,
as in display (ECHO %TESTVAR%) and deletion (SET TESTVAR=).
This allows unusual looping methods, and may have a number
of ramifications for building environment variable stacks, or
otherwise using variables indirectly.
For convenience, I have converted the Synthetic variable setting routine
to a CALLed subroutine form, so it can be called many times in the
same script. You could equally well use %RET% form as discussed in:
From: "William Allen"
Newsgroups: alt.msdos.batch
Subject: Re: Coding style (was Re: Help! DOS6 test needed)
Date: Thu, 9 Nov 2000 11:39
This simple demo script shows six environment variables, all called
TESTVAR, all set at the same time, but each with different contents.
It then uses a loop to clear them each progressively, demonstrating
the "first occurrence" rule. Lines that don't begin with two spaces
have accidentally wrapped in transmission.
::====SAMENAME.BAT
@ECHO OFF
:: William Allen 22 November 2000
:: Simple demo - several environment variables with SAME name
:: Possible uses are: stacking or unusual looping
IF [%1]==[GOTO:SYNVAR] %1
CALL %0 GOTO:SYNVAR TESTVAR TheFirstTime
CALL %0 GOTO:SYNVAR TESTVAR TheSecondTime
CALL %0 GOTO:SYNVAR TESTVAR TheThirdTime
CALL %0 GOTO:SYNVAR TESTVAR TheFourthTime
CALL %0 GOTO:SYNVAR TESTVAR TheFifthTime
CALL %0 GOTO:SYNVAR TESTVAR TheSixthTime
:: Demo line
ECHO There are six environment variables all called TESTVAR
SET | find "TESTVAR"
ECHO.
ECHO Now delete each in turn with a loop until they're gone
ECHO DOS uses first remaining occurrence on each run-through.
:LOOP
ECHO %TESTVAR%
SET TESTVAR=
IF NOT [%TESTVAR%]==[] GOTO LOOP
ECHO.
GOTO END
:SYNVAR
:: Usage CALL GOTO:SYNVAR varname varset
:: Synthetic environment variable setting
SET PROMPTWAS=%PROMPT%
ECHO PROMPT PROMPT=XX%2=%3>%TEMP%.\{TEMP}.BAT
ECHO e10f 00>%TEMP%.\}SCRIPT
FOR %%F IN (w q) DO ECHO %%F>>%TEMP%.\}SCRIPT
debug %TEMP%.\{TEMP}.BAT<%TEMP%.\}SCRIPT>NUL
CALL %TEMP%.\{TEMP}.BAT
PROMPT %PROMPTWAS%
SET PROMPTWAS=
deltree /y %TEMP%.\{TEMP}.BAT %TEMP%.\}SCRIPT>NUL
:END
::====
Notes: In the above code, I ensure that a dummy prompt
environment variable is present during the fraction of a
second for which I hijack the PROMPT command and then
immediately restore it. This is merely safety-first, to prevent
unwanted peculiar side-effects of loss of the PROMPT variable
for a fraction of a second that may conceivably occur in
some multi-tasking applications.
--
William Allen
PS
Other Synthetic environment variable examples:
=Set a normal environment variable that contains = (equals) signs
See:
From: "William Allen"
Newsgroups: alt.msdos.batch
Subject: Re: '=' in environnement variable
Date: Tue, 21 Nov 2000 23:36:
=Set an environment variable that has a lower case name
See:
From: "William Allen"
Newsgroups: alt.msdos.batch
Subject: Another pointless thing (was Re: '=' in environnement
variable
Date: Wed, 22 Nov 2000 00:37
=Set an environment variable that has leading spaces in its name
See:
From: "William Allen"
Newsgroups: alt.msdos.batch
Subject: Environment variable beginning with a space (was Re: '=' in environnement variable
Date: Wed, 22 Nov 2000 01:10
PPS
Variable splitting in detail:
============================
First, you need to understand how environment variables work.
DOS puts them in strings as:
ENVARNAME=envar contents[NUL]
where [NUL] means the ASCII character value zero.
DOS uses the NUL character to separate the variables.
The "envar contents" part can contain = signs, and DOS itself
will accept strange names, or multiple occurrences of the
same name: that part is no problem. The tiresome part is that
there seems to be no way of "escaping" a second = sign in the
SET command, nor does there seem to be a way of making
the SET command set several variables with the same name.
Nor does SET allow you to set environment variable names in
lower case or with leading spaces in the names.
However PROMPT and PATH both allow you to set such strings
in the environment, and thus bypass SET. PATH will capitalise its
contents, so bear that in mind.
You appear to be stuck with the environment variable name having to
be PROMPT or PATH - which is somewhat limiting or plain useless.
Unless... you split the variable you need off from one of those two.
If you force a NUL into an environment variable, DOS will split it
in two for you. That's because DOS uses the NUL as a separator, so
after setting the NUL containing string in one piece, DOS then treats
it as two (or more) environment variables set in that one operation.
In these circumstances, the second variable name and contents were
set bypassing the SET command entirely, so lowercase names, mutiple
variables with the same name, variable names with leading spaces,
and ordinary variables containing = (equals) signs all become possible.
PPPS
In the demo, I have used debug to place a NUL into the required
string, so that anyone can run the demo. I see no reason why a
batch script writer shouldn't instead use an Editor able to
set NULs directly into a script in suitable circumstances.
--
William Allen
William Allen
...snip
> If you force a NUL into an environment variable, DOS will split it
> in two for you. That's because DOS uses the NUL as a separator, so
> after setting the NUL containing string in one piece, DOS then treats
> it as two (or more) environment variables set in that one operation.
>
> In these circumstances, the second variable name and contents were
> set bypassing the SET command entirely, so lowercase names, mutiple
> variables with the same name, variable names with leading spaces,
> and ordinary variables containing = (equals) signs all become possible.
For the avoidance of doubt, I point out that in _accessing_ lower case or
mixed case variable names in the normal way, DOS _does_not_
distinguish between names that differ only in case.
I demonstrated this in my post:
From: "William Allen"
Newsgroups: alt.msdos.batch
Subject: Another pointless thing (was Re: '=' in environnement
variable
Date: Wed, 22 Nov 2000 00:37
However, by piping through FIND from SET, you can distinguish
between them if you wish. Since you can use synthetic variable
setting to create (all in the same DOS session) multiple
environment variables such as:
TESTvar
TeSTVaR
TestVar
and so on, all set simultaneously, and each with different contents,
this may also have applications. For example, where you had set
all of the above synthetically, but because of the nature of the script
you couldn't predict the order in which they would be set, piping
through FIND from SET would enable you to predict the order in
which DOS will delete them.
Research continues.
--
William Allen
William Allen
Synthetic variables with mixed case or lower case names
=========================================
These are undeletable by the SET VAR= command.
Any equivalent named variables in all Upper Case are
selectively deleted in reverse order of creation instead.
This modified routine demonstrates a stack of environment
variables all named TESTVAR (except for one case difference).
The mixed case one is not deleted when its turn comes, but
the Upper Case equivalents are deleted instead.
Note: this demo is a one-shot in the current DOS session, since
(of course), the mixed case variable in the stack isn't deleted.
To run it a second time, launch a fresh DOS session.
::====NODELETE.BAT
@ECHO OFF
:: William Allen 22 November 2000
:: Simple demo - Undeletable environment variable in
:: a stack of same-named variables.
IF [%1]==[GOTO:SYNVAR] %1
CALL %0 GOTO:SYNVAR TESTVAR TheFirstTime
CALL %0 GOTO:SYNVAR TESTVAR TheSecondTime
CALL %0 GOTO:SYNVAR TESTVAR TheThirdTime
:: Use a mixed or lower case variant of the name this time
CALL %0 GOTO:SYNVAR TESTVAr ThisFourthOneIsUndeletable
CALL %0 GOTO:SYNVAR TESTVAR TheFifthTime
CALL %0 GOTO:SYNVAR TESTVAR TheSixthTime
:: Demo line
ECHO.
:LOOP
CLS
ECHO The following variables are called TESTVAR
SET | find/i "TESTVAR" | find/v/i "cmdline"
ECHO.
ECHO DOS currently accesses TESTVAR as %TESTVAR%
IF [%TESTVAR%==[ThisFourthOneIsUndeletable SET ACTION=will not
IF NOT [%TESTVAR%==[ThisFourthOneIsUndeletable SET ACTION=will
ECHO A SET TESTVAR= command %ACTION% delete it
ECHO Please press RETURN to attempt deletion
IF NOT [%ACTION%]==[will] ECHO Instead any next remaining is deleted
PAUSE>NUL
SET | find "TESTVAR">NUL
SET TESTVAR=
IF NOT ERRORLEVEL 1 GOTO LOOP
ECHO.
ECHO There were no deletable ones remaining.
GOTO END
:SYNVAR
:: Usage CALL GOTO:SYNVAR varname varset
:: Synthetic environment variable setting
SET PROMPTWAS=%PROMPT%
ECHO PROMPT PROMPT=XX%2=%3>%TEMP%.\{TEMP}.BAT
ECHO e10f 00>%TEMP%.\}SCRIPT
FOR %%F IN (w q) DO ECHO %%F>>%TEMP%.\}SCRIPT
debug %TEMP%.\{TEMP}.BAT<%TEMP%.\}SCRIPT>NUL
CALL %TEMP%.\{TEMP}.BAT
PROMPT %PROMPTWAS%
SET PROMPTWAS=
deltree /y %TEMP%.\{TEMP}.BAT %TEMP%.\}SCRIPT>NUL
:END
::====
--
William Allen
William Allen
>
> Synthetic variables with mixed case or lower case names
> =========================================
>
> These are undeletable by the SET VAR= command.
One use of these is to create variables (like windir and
winbootdir in Win9x) in autoexec.bat that can be guaranteed
to persist even if code accidentally tries to delete them.
Although undeletable, synthetic environment variables with mixed
case or lower case names remain fully accessible and testable.
So, for example, if you use several standard environment variables
set in your autoexec.bat file, and you want to be certain that any
batch script run later will _not_ delete them or alter them, set them
as synthetic environment variables with the usual name, but use
the lower case version of the name.
::====KEEPVAR.BAT
@ECHO OFF
:: William Allen 22 November 2000
:: Demo Undeletable environment variable
SET PROMPTWAS=%PROMPT%
ECHO PROMPT PROMPT=XXtest=UndeletableVariable>{TEMP}.BAT
ECHO e10f 00>}SCRIPT
FOR %%F IN (w q) DO ECHO %%F>>}SCRIPT
debug {TEMP}.BAT<}SCRIPT>NUL
CALL {TEMP}.BAT
PROMPT %PROMPTWAS%
SET PROMPTWAS=
DEL {TEMP}.BAT
ECHO Enviroment variable TEST is: %TEST%
ECHO This variable is not deletable.
ECHO Try setting another instance of TEST afterwards.
ECHO It will appear in the SET display, but will not
ECHO be accessed by normal test or ECHO.
ECHO Any SET TEST= command will delete only a
ECHO normal Uppercase instance of TEST you have set.
ECHO Thus the lower case version of test remains
ECHO protected against accidental deletion, and will
ECHO always be used in preference to same name variables
ECHO created afterwards.
::====
--
William Allen
Benny Pedersen
> William Allen wrote in message
> > Further results on Synthetic Environment Variables
> >
> > Synthetic variables with mixed case or lower case names
> > =========================================
> >
> > These are undeletable by the SET VAR= command.
>
> One use of these is to create variables (like windir and
> winbootdir in Win9x) in autoexec.bat that can be guaranteed
> to persist even if code accidentally tries to delete them.
>
> Although undeletable, synthetic environment variables with mixed
> case or lower case names remain fully accessible and testable.
>
> So, for example, if you use several standard environment variables
> set in your autoexec.bat file, and you want to be certain that any
> batch script run later will _not_ delete them or alter them, set them
> as synthetic environment variables with the usual name, but use
> the lower case version of the name.
>
> ::====KEEPVAR.BAT
> :: William Allen 22 November 2000
> SET PROMPTWAS=%PROMPT%
> ECHO PROMPT PROMPT=XXtest=UndeletableVariable>{TEMP}.BAT
> ECHO e10f 00>}SCRIPT
> FOR %%F IN (w q) DO ECHO %%F>>}SCRIPT
> debug {TEMP}.BAT<}SCRIPT>NUL
> PROMPT %PROMPTWAS%
> SET PROMPTWAS=
> DEL {TEMP}.BAT
> ECHO Enviroment variable TEST is: %TEST%
> ECHO This variable is not deletable.
> ECHO Try setting another instance of TEST afterwards.
> ECHO It will appear in the SET display, but will not
> ECHO be accessed by normal test or ECHO.
> ECHO Any SET TEST= command will delete only a
> ECHO normal Uppercase instance of TEST you have set.
> ECHO Thus the lower case version of test remains
> ECHO protected against accidental deletion, and will
> ECHO always be used in preference to same name variables
> ECHO created afterwards.
> ::====
>
> --
> William Allen
Hi William
Something to examine (soon I'll). Maybe you suddenly/abrupt find lot of stuff which looks/is very interesting. Hmmm - One of the
following days, I must visit http://www.deja.com/usenet and see what else your have done in the past :)
Benny
if not %wiLliAm%==%WiLlIaM% goto wonder
William Allen
...snip
> Something to examine (soon I'll). Maybe you suddenly/abrupt
> find lot of stuff which looks/is very interesting.
I think you cleverly picked the part (undeletable environment
variables) that has the most useful application so far<G>. We
thought it was worth re-working that part as a new thread with a
proper batch script to set Write-Protected variables. We've already
posted the application batch script for this under new thread:
Write-Protected User-chosen Environment Variables
- A Synthetic Application (long)
It seems to me that Write-Protected environment variables could be
the most useful first application of Synthetic environment
variables. The functionality is already in Windows (for windir and
winbootdir). All I'm doing is hi-jacking that functionality. If you
find out anything on the write-protected variables, perhaps best to
post to the Write-Protected thread.
> Hmmm - One of the following days, I must visit
> http://www.deja.com/usenet and see what else
> your have done in the past :)
Noooo<G>. Don't go there<G>! The last time I checked properly, the
Deja index _alone_ for our little team had nearly 100 pages!
Fortunately Dejanews seems to have taken the pre-December 1999
database off-line so most are gone<G>. They were mostly about
Windows 9x, some about quotations, and a few about the Flame of
Oroladian. We didn't know that much about batch scripts until we
decided to learn properly a few months ago.
--
William Allen
Outsider
>
>
> Noooo<G>. Don't go there<G>! The last time I checked properly, the
> Deja index _alone_ for our little team had nearly 100 pages!
> Fortunately Dejanews seems to have taken the pre-December 1999
> database off-line so most are gone<G>. They were mostly about
> Windows 9x, some about quotations, and a few about the Flame of
> Oroladian. We didn't know that much about batch scripts until we
> decided to learn properly a few months ago.
>
A serious question. What was your opinion of batch files before
you decided to investigate them "a few months ago", and what is
your current opinion?
--
<!-- Outsider //-->
MS-DOS 6.22, Windows for Workgroups 3.11, Netscape Navigator 4.08
William Allen
...snip
> A serious question. What was your opinion of batch files before
> you decided to investigate them "a few months ago",
Context:
I had some limited batch knowledge as a normal Win9x user prior to
20 July 2000, when I started to investigate the subject seriously by
regularly reading this NG in _detail_ (I had very occasionally
looked at it before). To give you an idea of my knowledge then, I
could have sat down and worked out how to get, say, the unparsed
date string output from DATE into a variable, but it would stop
there. I was aware of FOR IN DO, but hadn't really used it much at
all, being rather unclear on how many % signs to use and when. I was
quite familiar with the use of debug. I'd read a few of Tom Lavedas'
examples, and I'd managed to write a batch file to resolve files in
a directory that were above or below a given size (with heavy use of
debug). I'd written a few batch files to defrag the Windows 9x
registry in real mode, which were long, but elementary, and some
simple scripts to help with re-installing and backing up Win9x OS.
My opinion at the time was rather like my opinion of, say, Euclidean
Geometry: interesting if worn-out concept, some useful but very
limited functionality, and definitely a dead-end field that was
entirely worked out when the future was a GUI world. Also hideously
un-reusable. So it was probably going to be a waste of my time.
> and what is your current opinion?
I now think that batch scripting continues to develop new ideas and
techniques. And its limited command set, I am now far more inclined
to see as a _big_ advantage, for three reasons:
1) It gives batch scripting a very shallow learning curve for people
who prefer to (or need to) take things steadily.
2) It makes it an excellent learning tool for people who find the
jump from user to programmer too great to make in one step. It is
real programming, yet basic batch scripts are within almost
everyone's capabilities.
3) It strongly encourages (because it highly rewards) what I would
call lateral thinking (what Americans call "thinking outside the
box"), which is both a valuable and a transferable skill. I think
that batch scripting teaches this skill.
Also, I'm especially surprised at how very useful it is for
low-level work: for example the Phantom DOS (logical) Drive thread
(19 November), where I was able to take what had previously been a
long set of careful written-out instructions on how to run a debug
script, and turn it into a batch script that could collect precise
diagnostic data on low-level disk structures remotely, and allow me
to instantly make nearly as good diagnosis as I could with my hands
on the machine. Previously I'd had to put up with fewer data
because it was just too daunting for the remote user to handle all
the written instructions that were needed for a novice to use debug
properly on the Master Boot Record. If you know how to use debug,
you can transfer your knowledge to a batch script far, far more
easily and reliably than by explaining to a person with reams of
instructions.
And, of course, it allows considerable functionality to be packed
into floppy-disk-sized thinking.
Also, _wholly_ contrary to my view of a few months ago, you showed
me that code could be written to be re-usable, and modular, which is
the key to progress. The proper use of %TEMP% also seems to me an
important factor in stability of code (again, an idea taken from
you). _Without_ modularity and re-usability, a batch script user
finishes up with a huge directory of little .BAT files that
stretches into the mists, and yet still finds it easier (faced with
a new task) to develop (or post here asking for<G>) a new
single-task script in preference to re-using old _and_tested_ code.
And it _now_ seems to me, though you differ, that the changes in DOS
7.0 onwards improve batch scripting and allow it, if properly
formatted with some of the conventions I've started to develop
here, to be shaded progressively into other scripting languages.
This is important, because, currently, scripting is definitely the
way that routine process automation on PCs is going for the
forseeable future (my opinion). Because batch scripting is a common
denominator across all Win9x-style systems (and that's a huge slice
of the market), it unlocks easy access to the other scripting
formats, and that could be a big deal for learners.
Further, and _exactly_ contrary to what I thought four months ago,
_very_clever_and_very_tight_ batch scripts are a tiresome feature of
much batch code passed around (but not understood), and do damage to
the standing of batch scripting and fly in the face of its real
value as a learning tool. I plead guilty to trying to write some
even now, but I no longer see them as a role model to be admired,
nor would I dream of showing or recommending such stuff to a
learner. Most counterproductive. As I say, this script style
damages the whole subject (my view).
In short, my opinion has turned 180º in just over four months.
--
William Allen
Ted Davis
<ma...@mayfly13.fsnet.co.uk> wrote:
<snip>
>In short, my opinion has turned 180º in just over four months.
Congratulations - that was very well said indeed.
T.E.D. (tda...@gearbox.maem.umr.edu - e-mail must contain "batch" in the subject or my .sig in the body)
Outsider
>
[snipped]
> Also, _wholly_ contrary to my view of a few months ago, you showed
> me that code could be written to be re-usable, and modular, which is
> the key to progress. The proper use of %TEMP% also seems to me an
> important factor in stability of code (again, an idea taken from
> you). _Without_ modularity and re-usability, a batch script user
> finishes up with a huge directory of little .BAT files that
> stretches into the mists, and yet still finds it easier (faced with
> a new task) to develop (or post here asking for<G>) a new
> single-task script in preference to re-using old _and_tested_ code.
>
[snipped]
> Further, and _exactly_ contrary to what I thought four months ago,
> _very_clever_and_very_tight_ batch scripts are a tiresome feature of
> much batch code passed around (but not understood), and do damage to
> the standing of batch scripting and fly in the face of its real
> value as a learning tool. I plead guilty to trying to write some
> even now, but I no longer see them as a role model to be admired,
> nor would I dream of showing or recommending such stuff to a
> learner. Most counterproductive. As I say, this script style
> damages the whole subject (my view).
Most batch programmers have one or more of the following problems.
1)
Some batch programmers try to make batch look like something else
(another language) they are already familiar with. It's like this,
if you don't know a foreign language, it is ever so easy to ignore,
but once you are fluent in that language, it is almost impossible to
ignore. You just can't help it, the sounds just go in and your mind
automatically makes sense of them. I've even seen people indent batch
code to make it resemble a structured highlevel language! Total
nonsense, of course. Batch has a structure and this structure is
modular, which is basically composed of blocks of code.
You, William, have the (apparently) unique ability to cut through the
pre-conditioning (if you will) of other coding you know and recognize
that batch has its own structure.
2)
Some batch programmers seem to actually have a disdain for batch language
even though they may be highly accomplished and proficient, and see batch
as something to get over with as quickly as possible. Like a bitter pill
one has to swallow. Need I say more?
3)
Some batch programmers are stuck in the past when PC's had a single
floppy drive and no harddrive: absolute insistence on writing to the
current directory, for example.
4)
Some batch programmers are convinced that a batch must be as short and
tight as possible and carry it to (fanatical?) extremes, as you have
described very well in your second paragraph above.
5)
Some batch programmers erroneously believe that documentation slows
batch files down.
I measured the runtime of a batch at .21 seconds. After adding 500
lines with REM to the processing, the runtime increased to 1.04 seconds.
That's a 495% increase, nearly 5 times slower. After changing every REM
to double colons, the runtime was .21 seconds. No increase in runtime
even with 500 lines of documentation! Since documentation is free, the
only excuse not to document is laziness and that's no excuse at all.
6)
Some batch programmers insist on ignoring the %temp%.
One or more of the above may result in the following symptoms:
Insistence on writing to the current directory.
Neglecting to document the code.
Failure to include standard error-checking and/or safeguards.
Failure to include syntax, examples or explanation so the user can more
easily follow how it works.
Fail to include a built-in help function so it's easy to use.
Failure to recognize and/or use %temp%.
Writing anti-modular code.
Writing overly-specific code.
Convoluting or obfuscating code.
Using nonsensical label, variable, file and directory names.
etc...
Naturally, this doesn't mean all these things should always apply,
and certainly they wouldn't neccessarily apply to snippets.
Here is a good example. This batch was posted here Apr 25, 1999.
Subject: Re: Another way to get string length
@echo off
echo , | choice/c,%1, %0 x goto:loop, > 1---------.bat
%2 1---------
:loop
echo %4 >>2---------.bat
if not %6[==[ for %%? in (shift goto:loop) do %%?
for %%? in (2---------.bat) do find/c/v "00" %%? > 1---------.bat
echo > ----------.bat set len=%%2
for %%? in (1--------- del) do call %%? ?---------.bat
echo %len%
::
It's short and clever, but what good is it?
Now, here is a basic parsing routine, that can be used for almost
any parsing need.
:: parse.bat
@ECHO off
IF "%1"=="ReCuRs[" GOTO parse
IF "%1"=="" FOR %%V IN (ECHO GOTO:end) DO %%V Nothing to parse
ECHO ; | CHOICE.COM/S/C;%1; %0;ReCuRs>%temp%.\parse1.bat
%temp%.\parse1.bat
:parse
SHIFT
IF not "%1"=="]?" ECHO %1
IF not "%1"=="]?" GOTO parse
DEL %temp%.\parse1.bat
:end
::
Now, if I want to get a string length, why not use (re-use) the modular
code I already have? Very simple. [Line wrapping off, please]
:: strlngt.bat :string limit is 56
@ECHO off
IF "%1"=="ReCuRs[" GOTO parse
SET len=
IF "%1"=="" FOR %%V IN (ECHO GOTO:end) DO %%V No string entered; nothing to do
IF exist --------.bat FOR %%V IN (ECHO GOTO:end) DO %%V --------.bat in current; terminated
IF exist %temp%.\findstr1.tmp del %temp%.\findstr1.tmp
ECHO , | CHOICE/C,%1, %0,ReCuRs> %temp%.\findstr.bat
%temp%.\FINDSTR.BAT
:parse
SHIFT
IF "%1"=="]?" GOTO last
ECHO %1 >>%temp%.\findstr1.tmp
GOTO parse
:last
FIND.EXE/C/V "" %temp%.\findstr1.tmp> %temp%.\findstr.bat
ECHO set len=%%2> %temp%.\--------.bat
PATH>%temp%.\respath.bat
PATH %temp%;%path%
CALL %temp%.\findstr.bat %temp%.\--------.bat
CALL %temp%.\respath.bat
FOR %%V IN (%temp%.\findstr?.* %temp%.\--------.bat) DO DEL %%V
ECHO %len%
:end
::
I also insure the batch is not crippled in case it is run from
a non-writeable drive or slow-media drive.
--
<!-- Outsider //-->
MS-DOS 6.22, Windows for Workgroups 3.11, Netscape Navigator 4.08
"What is his accomplishment? That he's no longer an obnoxious drunk?"
--Ron Reagan, the former president's son, on George W. Bush
Outsider
>
> IF exist --------.bat
PS. You probably need to use 10 hyphens in DOS 7.x.
William Allen
...snip (useful post saved in full)
> I've even seen people indent batch code to make
> it resemble a structured highlevel language!
That's an interesting point. Some of the (few) scripts-to-keep that
I wrote (before July) were indented in this way. Without actually
realising why (before I read your remark), I've stopped doing that.
It tends to be misleading in batch scripts, because it _doesn't_
correspond to any formal isolation of the code. And, anyway,
indentation in batch scripts has two specialised uses which
"structured indenting" may conflict with:
1) The 2-space indent as prevention of line-wrap errors when sending
them plain in email or news messages.
2) DOS 7.n specific: the use of TAB indent to "comment out"
known-good code sections from command/y/c debugging.
Occasionally, during actual development of a long script, it can
help to 2-space or 3-space indent all code _except_ labels and
comments associated with them, to make flow tracing and label-naming
management easier. This _doesn't_ affect debugging - even in
DOS 7.n. However, I usually tidy the indents away when done.
--
William Allen
Benny Pedersen
> Outsider wrote:
> >
>
> > IF exist --------.bat
>
> PS. You probably need to use 10 hyphens in DOS 7.x.
Hi Outsider
I have wrote to William about the subject so, I can say that I agree with you about the compact thing. I don't know who started it.
Sometimes I get/got this temptation myself but it's OK to write a long batchfile with comments :-)
Here's a little snip (subject was: SED to insert link).
I even used a double label and blank lines:
:search country format
echo.| date 31-12-2000 > nul
echo.| date | find "31-12-2000" > nul
if not errorlevel 1 goto found country format
echo.| date 12-31-2000 > nul
echo.| date | find "12-31-2000" > nul
if not errorlevel 1 goto found country format
goto end
:found country format
:restore date
date < currentD.ATE > nul
erase currentD.ATE
--b.pedersen, http://2dos.homepage.dk
Ted Davis
<nonvali...@yahoo.com> wrote:
>
>1)
>Some batch programmers try to make batch look like something else
>(another language) they are already familiar with. It's like this,
>if you don't know a foreign language, it is ever so easy to ignore,
>but once you are fluent in that language, it is almost impossible to
>ignore. You just can't help it, the sounds just go in and your mind
>automatically makes sense of them. I've even seen people indent batch
>code to make it resemble a structured highlevel language! Total
>nonsense, of course. Batch has a structure and this structure is
>modular, which is basically composed of blocks of code.
It is customary in many languages to indent modular blocks. However,
batch language is intrinsically for along the lines of what is called
'spaghetti code' - modularity is a form of orginazation that cah be
applied to it, but is not intrinsic.
>
>2)
>Some batch programmers seem to actually have a disdain for batch language
>even though they may be highly accomplished and proficient, and see batch
>as something to get over with as quickly as possible. Like a bitter pill
>one has to swallow. Need I say more?
I think that was probably directed at me, but it misses the point
completely. I do not disdain batch, but I don't put it on a pedestal
either - it's one tool in my kit and may or may not be the most
appropriate tool for all or some part(s) of a task. Since my
overriding task is to get the machine in work out the door, to get a
system or group of systems back in service, to extract data and
manipulate blocks of files, or whatever in the least possible time,
batch language must be reserved for those parts of the problem where
it saves, not wastes, time. In many cases it is necessary to develop
the program under one OS but run it under another, and much of my work
has to be comprehensible to people who are not batch programmers.
>
>3)
>Some batch programmers are stuck in the past when PC's had a single
>floppy drive and no harddrive: absolute insistence on writing to the
>current directory, for example.
Not that worn out hobby horse again.
>
>4)
>Some batch programmers are convinced that a batch must be as short and
>tight as possible and carry it to (fanatical?) extremes, as you have
>described very well in your second paragraph above.
Well said - there is little to recommend incomprehensibility.
>
>5)
>Some batch programmers erroneously believe that documentation slows
>batch files down.
>I measured the runtime of a batch at .21 seconds. After adding 500
>lines with REM to the processing, the runtime increased to 1.04 seconds.
>That's a 495% increase, nearly 5 times slower. After changing every REM
>to double colons, the runtime was .21 seconds. No increase in runtime
>even with 500 lines of documentation! Since documentation is free, the
>only excuse not to document is laziness and that's no excuse at all.
My preferred method is to have few comments in the working code, and
to provide a separate documentation Web page that explains the code in
detail. If the program is a one-off for transient use, there is no
need for dicumentation; if it is part of a program that is to be used
for a long time and/or in many places, then documentation more
extensive than seems appropriate for inclusion in the file (too much
commenting hides the code) is appropriate, and generally needs to be
available separate from the working files (in a documentation
directory on the Web server, for example) - ideally it should indicate
where the working files are to be found so that when someone needs to
deal with it, the documentation can be easiy found, and from that, the
files themselves. Internal comments should identify what the file
does, what files it depends on, what programs depend on it (not always
knowable), and any other special information needed to decide at some
cleanout time in the future whether to delete the file or not.
<snip>
Outsider
>
>
> Occasionally, during actual development of a long script, it can
> help to 2-space or 3-space indent all code _except_ labels and
> comments associated with them, to make flow tracing and label-naming
> management easier. This _doesn't_ affect debugging - even in
> DOS 7.n. However, I usually tidy the indents away when done.
>
When I first began writing batch code I had no computer, so I
wrote them on paper. When I did get occasional access to a PC
(and a printer), I would re-write the batches I wrote on paper,
test them and save them on a diskette. Naturally, I would also
print out hard copies. However, I had a problem with the left
margin on the paper copies because I made holes in the print-outs
so I could save them in a binder and I didn't want to perforate the
code. Therefore, I elected to indent all lines five spaces. This
caused me grief when some of my code would fail for no apparent
reason. Unfortunately, I did not document this and cannot give an
immediate example, but when I removed the spaces at the front of
certain lines of code, the code functioned fine. So needless to
say, I don't indent anymore.
Outsider
>
> "Outsider" <nonvali...@yahoo.com> wrote news:3A20E4E1...@yahoo.com...
> > Outsider wrote:
> > >
> >
> > > IF exist --------.bat
> >
> > PS. You probably need to use 10 hyphens in DOS 7.x.
>
> Hi Outsider
>
> I have wrote to William about the subject so, I can say that I agree with you about the compact thing. I don't know who started it.
I am sure it began as a neccessity due to the fact that the original
PC's had a small slooow single floppy drive only and no harddisk.
In those days (not that I remember, but I can imagine), every extra
line of code was a penalty and best to avoid. Not only that, but with
the miniscule physical storage capacity available, files had to be kept
to a minimum for obvious reasons. Also, since there was only one drive
to write to (I don't know when RAM drives hit the scene), there was not
any other real options but writing to the current drive and therefore
(most logically) the current directory, likely where the batch resides.
My point is: these reasons no longer exist, yet many people are still
writing batch programs the same way they did 15 years ago.
Ok, I can see the "sport" of friendly competition to see who can write
a batch that satisfies a minimum set of requirements with the fewest
lines of code, but only for fun and learning, ie. the "sport" of it.
In the practical world, these batches just don't cut it because they
are too limited in scope and function, often lack important error
trapping, have little or no documentation and few or no safeguards.
I haven't got time for sport, myself, but it certainly has its place.
> Sometimes I get/got this temptation myself but it's OK to write a long batchfile with comments :-)
> Here's a little snip (subject was: SED to insert link).
> I even used a double label and blank lines:
>
> :search country format
> echo.| date 31-12-2000 > nul
> echo.| date | find "31-12-2000" > nul
> if not errorlevel 1 goto found country format
>
> echo.| date 12-31-2000 > nul
> echo.| date | find "12-31-2000" > nul
> if not errorlevel 1 goto found country format
> goto end
>
> :found country format
> :restore date
> date < currentD.ATE > nul
> erase currentD.ATE
>
Painless, wasn't it? ;-)
Ted Davis
<nonvali...@yahoo.com> wrote:
>I am sure it began as a neccessity due to the fact that the original
>PC's had a small slooow single floppy drive only and no harddisk.
>In those days (not that I remember, but I can imagine), every extra
>line of code was a penalty and best to avoid. Not only that, but with
>the miniscule physical storage capacity available, files had to be kept
>to a minimum for obvious reasons. Also, since there was only one drive
>to write to (I don't know when RAM drives hit the scene), there was not
>any other real options but writing to the current drive and therefore
>(most logically) the current directory, likely where the batch resides.
>
It should be noted that *every* PC that has/had at least one floppy
has/had at least drives A: and B: - if only one physical drive was
present, you are/were prompted to insert the disk for the other dirve.
I know RAMDRIVEs were available in PCDOS 3.something, but I can't find
my 3.x series manuals, just the 1.1, 2.0, 2.1, 4.0 - the 3's and 5's
are missing.
Mike Jones
"Ted Davis" <tda...@gearbox.maem.umr.edu> wrote in message
news:9ji32tkafntjt8pdv...@4ax.com...
*IBM* PCDOS 3.3 supplied vdisk.sys
MS ramdrive.sys is (was) there with 5.0
I can't say for MSDOS 3.3 (we were an IBM shop then :-)
Outsider
> > I know RAMDRIVEs were available in PCDOS 3.something, but I
> can't find
> > my 3.x series manuals, just the 1.1, 2.0, 2.1, 4.0 - the 3's
> and 5's
> > are missing.
>
> *IBM* PCDOS 3.3 supplied vdisk.sys
> MS ramdrive.sys is (was) there with 5.0
> I can't say for MSDOS 3.3 (we were an IBM shop then :-)
When were batch files introduced? Every DOS history I ever read,
fails to mention batch files.
William Allen
...snip
> fails to mention batch files.
Batch Interpreter:
System Batch-File Interpreter - DOS 1.0 and later
(introduced as simple program list interpreter/executer)
Batch PAUSE - DOS 1.0 and later
Batch REM - DOS 1.0 and later
Batch ECHO - DOS 2.0 and later
Batch FOR - DOS 2.0 and later
Batch GOTO - DOS 2.0 and later
Batch IF - DOS 2.0 and later
Batch SHIFT - DOS 2.0 and later
Source: Microsoft: The MS-DOS Encyclopedia
First Edition 1988 - Microsoft Press ISBN 1-55615-174-8
Batch commands and general DOS history well covered.
Quotes from above:
Page 19:
"... the new operating system (refers to DOS 1.0) ran on
the prototype for the first time in February 1981. In the six
months that followed, the system was continually refined
and expanded, and by the time of its debut in August 1981..."
Page 34:
"... Version 2.0 was released in March 1983..."
--
William Allen
William Allen
> Source: Microsoft: The MS-DOS Encyclopedia
> First Edition 1988 - Microsoft Press ISBN 1-55615-174-8
> Batch commands and general DOS history well covered.
>
> Quotes from above:
RAMDRIVE.SYS - DOS 3.2 and later
External - creates a virtual disk in memory.
Page 44
"In January 1986, Microsoft released another version of MS-DOS, 3.2 ..."
--
William Allen
Mike Jones
"Outsider" <nonvali...@yahoo.com> wrote in message
news:3A22468C...@yahoo.com...
> Mike Jones wrote:
> >
> > "Ted Davis" <tda...@gearbox.maem.umr.edu> wrote in message
>
> > > I know RAMDRIVEs were available in PCDOS 3.something, but I
> > can't find
> > > my 3.x series manuals, just the 1.1, 2.0, 2.1, 4.0 - the
3's
> > and 5's
> > > are missing.
> >
> > *IBM* PCDOS 3.3 supplied vdisk.sys
> > MS ramdrive.sys is (was) there with 5.0
> > I can't say for MSDOS 3.3 (we were an IBM shop then :-)
>
>
read,
> fails to mention batch files.
>
- Bat capability was in the first DOS, though I think FOR may
have come in later (but before DOS 3.3)
> --
> <!-- Outsider file://-->
Mike Jones
"William Allen" <ma...@mayfly13.fsnet.co.uk> wrote in message
news:8vtj9f$506fp$1...@ID-55970.news.dfncis.de...
memory from way back (i.e. mine :-)
Frank-Peter Schultze
news:8vtid9$5ljaf$1...@ID-55970.news.dfncis.de...
> Outsider wrote in message
> ...snip
> > fails to mention batch files.
>
> System Batch-File Interpreter - DOS 1.0 and later
> (introduced as simple program list interpreter/executer)
>
AFAIK, it was IBM who charged Microsoft to implement batch processing into
MS-DOS/PC-DOS 1.0
> Batch PAUSE - DOS 1.0 and later
>
> Batch REM - DOS 1.0 and later
>
> Batch ECHO - DOS 2.0 and later
>
> Batch FOR - DOS 2.0 and later
>
> Batch GOTO - DOS 2.0 and later
>
> Batch IF - DOS 2.0 and later
>
> Batch SHIFT - DOS 2.0 and later
>
> Source: Microsoft: The MS-DOS Encyclopedia
> First Edition 1988 - Microsoft Press ISBN 1-55615-174-8
> Batch commands and general DOS history well covered.
>
> Quotes from above:
> Page 19:
> "... the new operating system (refers to DOS 1.0) ran on
> the prototype for the first time in February 1981. In the six
> months that followed, the system was continually refined
> and expanded, and by the time of its debut in August 1981..."
>
> Page 34:
> "... Version 2.0 was released in March 1983..."
>
> --
> William Allen
>
>
--
__ _ _
|_ |_)(__ http://www.fpschultze.de
___| | ____)chultze_________________________________________________
I am logged in, therefore I am.
William Allen
> "William Allen" schrieb im Newsbeitrag
...snip
> > Batch Interpreter:
> > System Batch-File Interpreter - DOS 1.0 and later
> > (introduced as simple program list interpreter/executer)
>
> AFAIK, it was IBM who charged Microsoft to implement
> batch processing into MS-DOS/PC-DOS 1.0
The history of MS-DOS is extremely well documented.
The following account is abridged and/or verbatim from:
Microsoft: The MS-DOS Encyclopedia
First Edition 1988 - Microsoft Press ISBN 1-55615-174-8
On August 21,1980, a study group of IBM representatives from Boca
Raton, Florida, visited Microsoft. This group, headed by a man
called Jack Sams, told Microsoft of IBM's interest in developing a
computer based on a microprocessor.
One of IBM's solutions - the one outlined by Sam's group - was to
base the new machine on products from other manufacturers. All the
necessary hardware was available, but the same could not be said of
the software. Hence the visit to Microsoft with the question: ...
could Microsoft write a ROM BASIC for it by the following April?
One month later, Sams returned to Microsoft asking whether Gates and
Allen could, still by April 1981, provide not only BASIC but [other
languages that were impossible in the timescale]. This time the
answer was: No because although Microsoft BASIC had been uniquely
designed as a Stand-Alone product, the other languages would need an
operating system. Gates suggested to IBM that CP/M-86 could be used,
but the owners of CP/M-86, Digital Research, and IBM could not come
to a suitable agreement.
This was the state of indecision on Sunday September 28, 1980 when
Bill Gates, Paul Allen, and Kay Nishi (a Microsoft vice president
and president of ASCII corp of Japan) met in Gates' 8th floor office
in the Old National Bank Building in Bellvue, Washington.
Gates recalls:
Kay and I were just sitting there at night and Paul was on the
couch. Kay said: 'Got to do it, got to do it'. It was only 20 more K
of code at most - actually it turned out to be 12 more K on top of
the 400. It wasn't that big a deal, and once Kay said it, it was
obvious. We'd always wanted to do a low-end operating system...
At this point, Gates and Allen looked at Microsoft's proposal to
IBM. To add an operating system would require another 20Kb or so,
and they already knew of a working model for the 8086, Tim
Paterson's 86-DOS. Gates and Allen contacted Rod Brock at Seattle
Computer Products (SCP) and said they had an OEM customer for
86-DOS. SCP said they weren't in the software marketing business,
and so it was agreed to license 86-DOS to Microsoft (Eventually SCP
sold the 86-DOS operating system to Microsoft for $50,000). In
October 1980, with 86-DOS in hand, Microsoft submitted a new
proposal to IBM (to include an operating system this time) with
guaranteed delivery by the spring of 1981. In November 1980 IBM
signed its agreement to this.
Microsoft assisted IBM to write the BIOS for the new machine, and
Microsoft integrated the new operating system plus ROM BASIC with
the BIOS, the OS now to be called MS-DOS.
The MS-DOS programmers added batch processing to MS-DOS originally
in order to help IBM. IBM wanted to run batch scripts - sequences of
commands or other operations - one after the other to test various
functions of the system. To do this, the testers need an automated
method of calling routines sequentially. The result was the batch
processor, which later provided users with the convenience of saving
and running MS-DOS commands as batch files.
--
William Allen
Frank-Peter Schultze
> Frank-Peter Schultze wrote in message
> > "William Allen" schrieb im Newsbeitrag
> ...snip
> > > Batch Interpreter:
> > > System Batch-File Interpreter - DOS 1.0 and later
> > > (introduced as simple program list interpreter/executer)
> >
> > AFAIK, it was IBM who charged Microsoft to implement
> > batch processing into MS-DOS/PC-DOS 1.0
>
> The history of MS-DOS is extremely well documented.
> The following account is abridged and/or verbatim from:
> Microsoft: The MS-DOS Encyclopedia
> First Edition 1988 - Microsoft Press ISBN 1-55615-174-8
Thanks, William. When do you post the next chapter ;-)
Outsider
>
> "William Allen" <ma...@mayfly13.fsnet.co.uk> schrieb im Newsbeitrag
> news:8vtth6$5i2i0$1...@ID-55970.news.dfncis.de...
> > Frank-Peter Schultze wrote in message
> > > "William Allen" schrieb im Newsbeitrag
> > ...snip
> > > > Batch Interpreter:
> > > > System Batch-File Interpreter - DOS 1.0 and later
> > > > (introduced as simple program list interpreter/executer)
> > >
> > > AFAIK, it was IBM who charged Microsoft to implement
> > > batch processing into MS-DOS/PC-DOS 1.0
> >
> > The history of MS-DOS is extremely well documented.
> > The following account is abridged and/or verbatim from:
> > Microsoft: The MS-DOS Encyclopedia
> > First Edition 1988 - Microsoft Press ISBN 1-55615-174-8
> [snipped]
>
> Thanks, William. When do you post the next chapter ;-)
I think you might get a slightly different history lesson here:
William Allen
> Thanks, William. When do you post the next chapter ;-)
You're welcome :-) I think I'll pass on posting the entire
MS-DOS Encyclopedia. I _do_ need to find all the oportunities for
typing I can, so as to keep my touch-typing at full speed. But it
would test even my touch-typing patience: 1570 closely-printed
pages!
I wasn't even that interested in PCs when I purchased it (quite a
few years ago), I just tend to pick up reference books that have
that "you'll probably never see this again, you might regret not
buying it" look about them.
Suprisingly, I find myself referring to it quite a lot: it has
_masses_ of examples of source code (C and assembler) for writing
utilities to add to MS-DOS, and also for illustrating how MS-DOS
works. Quite detailed on elements like Debug and Symdeb (Microsoft
extension to simple debug). I've never seen it in bookshops around
here since.
Someone mentioned: Vdisk.sys
Extract from MS-DOS Encyclopedia:
Vdisk.sys - External IBM PC-DOS 3.0 and later
Creates a virtual disk in memory. This installable driver is
available only with PC-DOS.
It then goes on to detail changes in syntax in later PC-DOS
versions.
--
William Allen
William Allen
...snip
At a quick glance, the general account of events that I set out from
the MS-DOS Encyclopedia appears to be broadly supported.
--
William Allen
Frank-Peter Schultze
> I think you might get a slightly different history lesson here:
>
> http://www.kzin.com/pchist/
>
... after one hour or so I found myself in the the 'Chronology of Events'
(http://www.maxframe.com/HISZCOMP.HTM) reading:
"Even for the next ten years, [DOS] will have a significant role to play."
--Bill Gates, Oct 1990
We have Nov 2000...
William Allen
...snip
> Events' (http://www.maxframe.com/HISZCOMP.HTM) reading:
>
> "Even for the next ten years, [DOS] will have a significant role
> to play." --Bill Gates, Oct 1990
>
> We have Nov 2000...
Since it is still true (for example, the Win98SE OS still being
loaded in machines recently has real-mode DOS boot loader), that
seems to be suprisingly prescient.
--
William Allen
Jim Knopf
> [snipped]
>
>
>> I think you might get a slightly different history lesson here:
>>
>> http://www.kzin.com/pchist/
>>
>
>
> .... after one hour or so I found myself in the the 'Chronology of Events'
> (http://www.maxframe.com/HISZCOMP.HTM) reading:
>
>
>
> "Even for the next ten years, [DOS] will have a significant role to play."
> --Bill Gates, Oct 1990
>
>
>
> We have Nov 2000...
... and M$ simply 'disables' real-mode DOS in Windows 4.6 commonly known
as Windows ME. LOL
Outsider
>
> Outsider wrote in message
> I now think that batch scripting continues to develop new ideas and
> techniques. And its limited command set, I am now far more inclined
> to see as a _big_ advantage, for three reasons:
> 1) It gives batch scripting a very shallow learning curve for people
> who prefer to (or need to) take things steadily.
Also because batch uses ordinary language and recognizable symbols,
and standard DOS commands.
> 2) It makes it an excellent learning tool for people who find the
> jump from user to programmer too great to make in one step. It is
> real programming, yet basic batch scripts are within almost
> everyone's capabilities.
As I see it, batch files can save us huge amounts of both time and
effort - no small feat, but this is only the tip of the iceberg.
Batch can empower us with a control over our computer and programs
that most would never have thought possible. DOS becomes interesting
and Windows takes on a new dimension. All it takes is a little
knowledge and a good imagination and one can amaze oneself. It's
really quite astonshing that so few people know about batch files,
considering they are literally at nearly every computer users fingertips.
Batch files are truly the world's best kept computer secret.
> 3) It strongly encourages (because it highly rewards) what I would
> call lateral thinking (what Americans call "thinking outside the
> box"), which is both a valuable and a transferable skill. I think
> that batch scripting teaches this skill.
>
I might call it independent and logical thinking with the ability
to reason things out.
[snipped]
> And it _now_ seems to me, though you differ, that the changes in DOS
> 7.0 onwards improve batch scripting and allow it, if properly
> formatted with some of the conventions I've started to develop
> here, to be shaded progressively into other scripting languages.
> This is important, because, currently, scripting is definitely the
> way that routine process automation on PCs is going for the
> forseeable future (my opinion). Because batch scripting is a common
> denominator across all Win9x-style systems (and that's a huge slice
> of the market), it unlocks easy access to the other scripting
> formats, and that could be a big deal for learners.
>
There are some advantages in DOS 7.x, however one must also consider the
dis-advantages.
Paul Chitescu has previously reported: DOS 7.x - takes some protected
mode memory (for Registry/configuration/others) and is much less optimized
for performance than regular MS-DOS as it is used by Win 4.x as a bootstrap
loader only. In particular it runs up to 2x slower over networks or without
a disk cache.
Windows is much slower and more difficult to use compared to its predecessors,
DOS help is missing, DOS commands are missing, many batch programs are broken,
the undocumented FOR parsing switch is gone. I see allowing spaces in dir and
filenames is the biggest single problem; the only reason M$ did it was to
break compatibility with previous DOS versions. I also avoid DOS 7.x for
reasons of principle. I have made my stand against M$, I will not buy further
into it.
Outsider
> >Some batch programmers erroneously believe that documentation slows
> >batch files down.
> >I measured the runtime of a batch at .21 seconds. After adding 500
> >lines with REM to the processing, the runtime increased to 1.04 seconds.
> >That's a 495% increase, nearly 5 times slower. After changing every REM
> >to double colons, the runtime was .21 seconds. No increase in runtime
> >even with 500 lines of documentation! Since documentation is free, the
> >only excuse not to document is laziness and that's no excuse at all.
>
> to provide a separate documentation Web page that explains the code in
> detail. If the program is a one-off for transient use, there is no
> need for dicumentation; if it is part of a program that is to be used
> for a long time and/or in many places, then documentation more
> extensive than seems appropriate for inclusion in the file (too much
> commenting hides the code) is appropriate, and generally needs to be
> available separate from the working files (in a documentation
> directory on the Web server, for example) - ideally it should indicate
> where the working files are to be found so that when someone needs to
> deal with it, the documentation can be easiy found, and from that, the
> files themselves. Internal comments should identify what the file
> does, what files it depends on, what programs depend on it (not always
> knowable), and any other special information needed to decide at some
> cleanout time in the future whether to delete the file or not.
>
Hmmm. That is one approach, but way too complicated and impractical
in my view. Now think about this: Just how far would pkzip.exe have
gotten without the four built-in help screens. Documentation should
always (with few exceptions) be included in the batch.
Internal documentation (where clarification is warranted).
And preferrably, a *built-in* help function. Interactive or
automatic help is outrageously superior to any other kind
(think pkzip).
:: example.bat remarks can go here
@ECHO off %remarks can go here%
CLS remarks can go here
:: remarks can go here
%remarks can go here%
REM remarks can go here (not recommended!)
GOTO start remarks can go here
remarks
can
go
here
:start remarks can go here
COPY/Y file1 file2 %remarks can go here% >nul
COPY/Y file1 file2 >nul %remarks can go here%
COPY/Y file1 file2 |:: remarks can go here
CALL STDPRMPT.BAT remarks can go here (depending on the batch)
<snip>
Ted Davis
<nonvali...@yahoo.com> wrote:
>Hmmm. That is one approach, but way too complicated and impractical
>in my view. Now think about this: Just how far would pkzip.exe have
>gotten without the four built-in help screens. Documentation should
>always (with few exceptions) be included in the batch.
>
>Internal documentation (where clarification is warranted).
>And preferrably, a *built-in* help function. Interactive or
>automatic help is outrageously superior to any other kind
>(think pkzip).
I see your point of view: that batch files are for users. That is not
the case with mine - they are for programs to use as functions and
subfunctions. User interface is with an icon that launches the
program with the correct syntax as was determined from the
documentation consulted without reference to the file itself. The
exceptions are single use programs. My documentation is not for
users, it is for programers and administrators who are doing things
about rather than with the files. The users are told what to do
with/to the icon and it is given a descriptive name, no documentation
needed. Others are launched automatically by boot disks and are
prompt and menu driven. There the documentation needs to be somewhere
else because check sheets are generally involved, and those need to be
printed. Many other differences in how the programs are used,
created, and destroyed in the two contexts.
D'haveloose Rik
>
> On Mon, 27 Nov 2000 18:27:12 +0100, Outsider
>
> >in my view. Now think about this: Just how far would pkzip.exe have
> >gotten without the four built-in help screens. Documentation should
> >always (with few exceptions) be included in the batch.
> administrators who are doing things
> about rather than with the files. The users are told what to do
> with/to the icon and it is given a descriptive name, no documentation
> needed. Others are launched automatically by boot disks and are
> prompt and menu driven. There the documentation needs to be somewhere
> else because check sheets are generally involved, and those need to be
> printed. Many other differences in how the programs are used,
> created, and destroyed in the two contexts.
i believe you do forget the third possible group: those of users from
private or personal systems. Normally they are indeed users, but due to
the fact that it are personal systems, they are forced to become
administrators themselves (maybe because of the fact that very few
programmers really are competent enough to avoid all possible problems
on all possible different configurations, as there also may be some
wrong settings, out there, who just work fine, till...), or they start
to seek some way to automate certain (administrative) tasks (automating
is the great advantage of computers, imho, or should be).
Secondly, as standards do change rapidly within the OS world, one could
also consider that after 1 year already, some 'services' are no more
available, and without full documentation, some solution to some
unforseen bug could be found more easily, even by less experienced users
if documentation is complete. (not to say that some more general info
should be provided default by some installing and/or programs on how
they work, and which files belong where and how, iycgmd)
---
Lieve-Ri(n)ksken(s)
Greetings from Rumbeke-Belgium
g...@infinet.com
: When I first began writing batch code I had no computer, so I
: wrote them on paper. When I did get occasional access to a PC
: (and a printer), I would re-write the batches I wrote on paper,
: test them and save them on a diskette. Naturally, I would also
: print out hard copies. However, I had a problem with the left
: margin on the paper copies because I made holes in the print-outs
: so I could save them in a binder and I didn't want to perforate the
: code. Therefore, I elected to indent all lines five spaces. This
: caused me grief when some of my code would fail for no apparent
: reason. Unfortunately, I did not document this and cannot give an
: immediate example, but when I removed the spaces at the front of
: certain lines of code, the code functioned fine. So needless to
: say, I don't indent anymore.
If I recall correctly, early versions of COMMAND.COM required labels to
begin in the first column. Leading spaces prevented the labels from being
recognized.
--
Gary L. Smith g...@infinet.com
Columbus, Ohio
Outsider
>
> Outsider <nonvali...@yahoo.com> wrote:
[snipped]
> : code. Therefore, I elected to indent all lines five spaces. This
> : caused me grief when some of my code would fail for no apparent
> : reason. Unfortunately, I did not document this and cannot give an
> : immediate example, but when I removed the spaces at the front of
> : certain lines of code, the code functioned fine. So needless to
> : say, I don't indent anymore.
>
> If I recall correctly, early versions of COMMAND.COM required labels to
> begin in the first column. Leading spaces prevented the labels from being
> recognized.
>
The only version of DOS I have worked with extensively is MS-DOS 6.22.
The problem I reported with leading spaces had to do with active code,
ie. command lines within the batch, but was limited to certain cases.
I didn't document it and I don't have time to investigate and try to
replicate it, but I do remember the codelines affected were fairly long
and invoked a secondary command processor. The reason I noticed it was
because there were no problems with these lines _before_ I added the 5
leading spaces to them. It also took me a long time to figure out the
problem because these were batches that I seldom used and I didn't
believe leading spaces could cause a problem. I now wish I had
documented this behavior.
--
<!-- Outsider //-->
MS-DOS 6.22, Windows for Workgroups 3.11, Netscape Navigator 4.08
"I think we ought to raise the age at which juveniles can have a gun."
--G. W. Bush