create a file using a batch file?

[Phil]

does anybody know of a way to create a file from a batch file?
ie can I have batch1.bat create batch2.bat so that batch2.bat does some sort
of action?
EG:

[William Allen]

Phil wrote in message

> does anybody know of a way to create a file from a batch file?
> ie can I have batch1.bat create batch2.bat so that batch2.bat
> does some sort of action?

Yes, you can write text to another file with redirection.

ECHO.This is a message
displays a message: This is a message

ECHO.This is a message>FILENAME.BAT
writes the text to a new file FILENAME.BAT

ECHO.This is a message>>FILENAME.BAT
appends the text to an existing file FILENAME.BAT
or creates a new one if it doesn't exist already.

This simple script demonstrates the ideas involved.
Call it MYBATCH1.BAT

::====MYBATCH1.BAT
@ECHO OFF

:: Create a second batch file

ECHO.@ECHO OFF>MYBATCH2.BAT
ECHO.ECHO. This is the second batch file>>MYBATCH2.BAT
ECHO.:: It can contain commands, for example>>MYBATCH2.BAT
ECHO.DIR MYBATCH?.* /b>>MYBATCH2.BAT
ECHO.:: And command line parameters>>MYBATCH2.BAT
ECHO.:: but double up on %% signs>>MYBATCH2.BAT
ECHO.ECHO.%%1 %%2 %%3 %%4 %%5>>MYBATCH2.BAT

ECHO. This is the first batch file
ECHO. It has just created a second batch file: MYBATCH2.BAT
ECHO. The first batch file can run the second, by using
ECHO. the CALL command, like this:
ECHO.
CALL MYBATCH2

ECHO.
ECHO. When you use CALL, control is returned to the calling
ECHO. batch processs. If you want control to stay with the
ECHO. second process, just use the name alone, like this:
ECHO.
MYBATCH2 This was a direct reference
ECHO. This line will not be executed. Control went to MYBATCH2
::====

--
William Allen

[Outsider]

<LOL>

A good one <g>.

That's one of the main purposes of batch files.

--
<!-Outsider//->
MS-DOS 6.22, Windows for Workgroups 3.11, Netscape Navigator 4.08

[William Allen]

William Allen wrote in message
...snip

> Yes, you can write text to another file with redirection.

Lesson 2
========

Once you get the idea of the previous post, try this idea:

In a Windows DOS box, type the command:
mem
You'll see something like this:
C:\WORK>mem

Memory Type Total Used Free
---------------- -------- -------- --------
Conventional 640K 24K 616K
Upper 83K 78K 5K
Reserved 384K 384K 0K
Extended (XMS) 64,429K 201K 64,228K
---------------- -------- -------- --------
Total memory 65,536K 688K 64,848K

Total under 1 MB 723K 102K 620K

Largest executable program size 616K (630,416 bytes)
Largest free upper memory block 5K (4,656 bytes)
MS-DOS is resident in the high memory area.

=====
Your memory details will vary from mine.

Notice, say, the line:
Largest executable program size 616K (630,416 bytes)

You can filter the output of "mem" with "find" to show only that line:
C:\WORK>mem | find "program size"
Largest executable program size 615K (629,360 bytes)

The slight loss of memory is because the command combo
that produced and filtered this report was running along with mem.

Now suppose you write that line to a file, we'll call it TEMP.BAT
because it's going to be transient
C:\WORK>mem | find "program size">TEMP.BAT

Look at that file with TYPE
C:\WORK>type temp.bat
Largest executable program size 615K (629,360 bytes)

We both know it's not a batch file, it's just a text file we wrote.
However, Windows doesn't know that.

If we run TEMP.BAT, Windows tries to execute it as a batch file
Try it:
C:\WORK>temp

C:\WORK>Largest executable program size 615K (629,360 bytes)
Bad command or file name

So far, so bad. It fails to do anything because "Largest" isn't
a command that Windows knows.

Suppose we now write a file called LARGEST.BAT
Let's write the text: ECHO. I know the largest program size is %%4

C:\WORK>ECHO.ECHO.The largest program size is %%4>LARGEST.BAT

See what LARGEST.BAT says:
C:\WORK>type largest.bat
ECHO.The largest program size is %4

OK, now there IS a command "largest" and it will use whatever
is the fourth text element on its calling line in that message

Of course TEMP.BAT contains several text elements, remember
C:\WORK>type temp.bat
Largest executable program size 615K (629,360 bytes)

The fourth element (after the word "largest") is 615K

Now think about this.
If we run TEMP.BAT again, this time Windows WILL find
a "largest" command, the batch file we've just written.

And that will pull the fourth element off the line in TEMP.BAT
so we can use it. Try now:
C:\WORK>temp

C:\WORK>Largest executable program size 615K (629,360 bytes)

C:\WORK>ECHO.The largest program size is 615K
The largest program size is 615K

That should give you some ideas. It forms the basis of the
most common way of getting information into environment
variables, which is the most convenient way to hold it.

Here, we call this technique:
"Inceptive intermediary"

Inceptive=first lexical element in a group
Intermediary=because it uses an intermediary batch file
with the name of the first lexical element on the line.

--
William Allen

[Larry__Weiss]

Did your message get truncated? What did you mean by "EG:" ?

- Larry Weiss

[Outsider]

Håkan Björkström wrote:
>
> Lesson 2 is a good example to show that you must know in which operating
> system you run it. The example runs in Win9x but NOT in WinNT, because MEM
> in WinNT reports
> 628088 largest executable program size.
>
> It does not either work in OS other than English

This is not an NT group. Naturally, you cannot expect DOS solutions
to work in NT.

[William Allen]

Håkan Björkström wrote in message
...snip

> It does not either work in OS other than English

Yes it does. The principle works, and is very useful indeed.

I was teaching the _principle_ of inceptive intermediaries.

The point of my post was teaching HOW to to create such
scripts, precisely so you DON'T have to cut and paste them.

In other languages, you must translate the lesson text.
BUT you have to translate ALL the words, including the
relevant inceptive lexical items, generated by commands,
and (possibly) recount the positions of later occuring
lexical elements on command line output.

The downside of inception is language dependence.
The upside is that, if you know what language your
machine is using - and most people do - you can
apply the principle. It's often very useful indeed.

For a change, my post wasn't about how to cut-and-paste
weird scripts you don't really understand. It was about how to
write your own, _understanding_ why they work.

--
William Allen

[Phil]

sorry, no, i was going to try and explaing it more, but i couldn't and i
forgot to delete the "EG:"

[Ted Davis]

On Tue, 10 Apr 2001 09:03:35 +0100, "William Allen"
<ma...@mayfly13.fsnet.co.uk> wrote:

>For a change, my post wasn't about how to cut-and-paste
>weird scripts you don't really understand. It was about how to
>write your own, _understanding_ why they work.

Keep it up - that was excellent. More! More!

You will find that you can't win, though: there are those who want
cookbooks, and will complain about a tutorial not giving them code
thay can use as-is, and others who will complain that cookbooks don't
actually teach concepts.

There are enough pro-concept people around here to make the effort
worth while, but you can expect a wide range of reactions.

I *strongly* suggest making Web pages out of your essays - simple,
plain text pages will do nicely (I get a quarter million or more
accesses of my plain text batch pages per year).

T.E.D. (tda...@gearbox.maem.umr.edu - e-mail must contain "batch" in the subject or my .sig in the body)