Environment variable expansion occurs when the command is read

re: Environment variable expansion occurs when the command is read

Tom M — Wed, 23 Aug 2006 17:39:34 GMT

So the problem was that ERRORLEVEL was 0 at the point the batch script was loaded?

re: Environment variable expansion occurs when the command is read

Mark — Wed, 23 Aug 2006 17:51:13 GMT

No, at the point the line - which spills onto multiple lines by using ( ) - was read. Think of it as:

for ... do IsVarMap.exe ... & echo %ERRORLEVEL%

re: Environment variable expansion occurs when the command is read

Mike — Wed, 23 Aug 2006 18:04:36 GMT

Are "procedures" inlined/precompiled too (I suspect not)? If not, could one potential solution be to "call" a "procedure" (a label) in the same batch file, assuming this is for NT5 or later?

In a way, it reminds me of the pattern of C++ std::for_each, where you give start, end and a function to call for each iteration.

re: Environment variable expansion occurs when the command is read

KJK::Hyperion — Wed, 23 Aug 2006 18:27:50 GMT

Mike: "call :label" effectively reparses the batch file and resets the state - even the %0, %1, ... constants are reset. You even have to call "setlocal" at the beginning of a procedure, or your variables are going to spill into the caller's context

So, yes, you can "call :label <arguments>" in a loop, even recursively, but I don't recommend it, as string escaping gets funky across a call

re: Environment variable expansion occurs when the command is read

Arlie Davis — Wed, 23 Aug 2006 18:28:57 GMT

Must... destroy... CMD.EXE...

Destroy...

too late...

re: Environment variable expansion occurs when the command is read

dave — Wed, 23 Aug 2006 19:03:45 GMT

The issue arises when you start programming in a language not originally intended for programming.

"Proper" programming languages tend to be a little clearer about the difference between lexical processing and command interpretation. And anyone who's used a decent macrogenerator (not the C preprocessor) gets the concept.

But command languages originally designed for people to type tend to create a little more confusion.

[Very true. I doubt anybody actually enjoys writing batch files. It's not so much a programming language as a script. -Raymond]

re: Environment variable expansion occurs when the command is read

James — Wed, 23 Aug 2006 19:16:46 GMT

For extra pain - er, credit - try a .cmd script which generates registry entries (with variable substitution) which will then be executed. Some of them, via cmd.exe. Oh, you need to pipe variable stuff into another command while you're doing it.

(Oh, the joys of building a setup which partitions, formats and installs a system automatically - with different partitioning schemes for different arguments, and different applications installed depending on the machine's DNS entry!)

re: Environment variable expansion occurs when the command is read

OrsoYoghi — Wed, 23 Aug 2006 19:26:45 GMT

I'm missing something..

why is SETLOCAL ENABLEDELAYEDEXPANSION required ?
I mean, cmd.exe can already tell between the twos because all old code is %WRITTENTHISWAY% while code using the new expansion style is !WRITTENTHISWAY! ...

re: Environment variable expansion occurs when the command is read

pcooper — Wed, 23 Aug 2006 19:43:25 GMT

OrsoYoghi: I assume that's for backward compatibility with old batch files that assumed that text between exclamation points was just text between exclamation points. You can't just suddenly change the syntax of the file without requiring people to opt into the new functionality.

re: Environment variable expansion occurs when the command is read

Jonathan — Wed, 23 Aug 2006 19:49:13 GMT

@OrsoYoghi: Yes, but what if old code depended on !STUFF_WRITTEN_LIKE_THIS! being treated as a literal string? The only backwords-compatible way is to use the old method with an option to enable the new one.

(Then again, couldn't you enable the new method by default in .cmd files, and leave .bat files alone?)

[Making it on by default for .cmd files would break compatibility with NT4 .cmd files (which expected ! to mean !.) -Raymond]

re: Environment variable expansion occurs when the command is read

Jonathan — Wed, 23 Aug 2006 19:51:30 GMT

I guess I was too slow. :) Sorry pcooper.

re: Environment variable expansion occurs when the command is read

Stu — Thu, 24 Aug 2006 00:47:10 GMT

That's interesting; the CMD team seem to think that it's ok to implement features that break compatability, as long as you make them opt-in.
The rest of Microsoft just uses "it will break back-compatability" as a reason not to improve things...

[cmd.exe is a much more tightly-scoped problem. Command scripts communicate with other command scripts only through environment variables and the command line. Command scripts can't inject themselves into other command scripts. There are no "cmd.exe plug-ins". -Raymond]

re: Environment variable expansion occurs when the command is read

Sven Groot — Thu, 24 Aug 2006 01:17:52 GMT

I'd just like to say, thank God for Monad. :)

re: Environment variable expansion occurs when the command is read

Mark Yocom — Thu, 24 Aug 2006 03:30:30 GMT

[Very true. I doubt anybody actually enjoys writing batch files. It's not so much a programming language as a script. -Raymond]

Oh, I dunno - I enjoy writing them. CMD is like your weird Uncle Harold. He's fun to be around, despite his quirks.

re: Environment variable expansion occurs when the command is read

Barry Kelly — Thu, 24 Aug 2006 04:23:40 GMT

Ah yes, yet another reason I use bash / rxvt / Cygwin.

re: Environment variable expansion occurs when the command is read

Cooney — Thu, 24 Aug 2006 04:31:02 GMT

Yes, thank god for bash. cmd.exe isn't a script so much as a juiced up command.com. No wonder people hate the command line.

re: Environment variable expansion occurs when the command is read

geffner — Thu, 24 Aug 2006 09:22:37 GMT

> For extra pain - er, credit - try a .cmd
> script which generates registry entries
> (with variable substitution) which will then
> be executed. Some of them, via cmd.exe. Oh,
> you need to pipe variable stuff into another
> command while you're doing it.

James, it sounds like you're using a batch file to write .reg files and execute them. It's much easier to use "%windir%\system32\reg.exe" from a batch file instead.

re: Environment variable expansion occurs when the command is read

James — Thu, 24 Aug 2006 12:19:31 GMT

Geffner: I am using reg, rather than creating .reg files; the 'will then be executed' refers to the entries themselves being RunOnceEx entries which get run after the second reboot. The stuff I'm piping into another command is a diskpart script, not a set of registry entries.

Nothing too painful, just a fiddly set of scripts to tie all the partitioning and installation together. Especially now we have two virtual machines and a dual-boot Linux setup to contend with, and could be running anywhere from the labs (a dozen new user accounts created/deleted each day, permanent Net connection, everything from AutoCAD to Visual Studio running) to staff laptops (one user, usually offline).

A bit more work upfront, but since the hardware's all heterogenous, a single "install" command with literally everything else automated saves enough staff time to justify it quite easily.

re: Environment variable expansion occurs when the command is read

dave — Thu, 24 Aug 2006 16:07:22 GMT

The real question is, of course, why sane people bother trying to program in a jumped-up MS-DOS 'batch' (which of course isn't a batch system at all) language when they could just install Perl.

Perl has the benefit of bizarre syntax, thus giving ex-batch-programmers a warm and fuzzy feeling that there's something else for them to be puzzled over, but at the same time actually having the capabilities one needs.

;-)

re: Environment variable expansion occurs when the command is read

Batchman — Thu, 24 Aug 2006 17:50:27 GMT

Dave: Why don't you consider ms-dos batch files as a batch system at all?

re: Environment variable expansion occurs when the command is read

mikeb — Thu, 24 Aug 2006 19:12:53 GMT

>> The real question is, of course, why sane people bother trying to program in a jumped-up MS-DOS 'batch' (which of course isn't a batch system at all) language when they could just install Perl. <<

The reason is quite simple - because the cmd scripts will work without having to bother the user with installing Perl (or whatever other tool).

The real problem with cmd scripting is that the syntax and semantics of the scripting language has been enhanced since the MS-DOS days in an ad-hoc manner rather than designing the language in a more formal manner. At least that's what it looks like.

The other big problem (at least for me) is that applications are responsible for parsing command lines instead of having the shell parse the commad line, so it can be a nightmare to convince some tools to accept parameters that contain special characters which need escaping (particularly quotes) that is also acceptable to cmd.exe.

re: Environment variable expansion occurs when the command is read

mikeb — Thu, 24 Aug 2006 19:22:01 GMT

re: Environment variable expansion occurs when the command is read

steveg — Fri, 25 Aug 2006 08:04:22 GMT

No offence to the cmd team, but MS could've done it "properly" years ago. The big mistake IMHO was NT (3.51) maintained DOS cmd compatibility -- I'll let the Win9x family off the hook. Although perhaps the ultimate blame lies with OS2.

It would've been very very useful if shell-level scripting had been built into the Window Manager right from the start (imagine being able to test/manipulate your UI from a script supported by the OS? App.Window[1].Maximise (as an aside it would've been awesome if Noah Webster had had another hobby apart from butchering the english language)).

As for the "just use [perl|cygwin|.*]" argument, it doesn't always work in large organisations where introducing a new technology into the production environment is a long slow process requiring meetings of dozens, evaluation committees etc. .bat is very very good compared to facing that rubbish (maybe that's only the Australian Govt for you).

re: Environment variable expansion occurs when the command is read

steveg — Fri, 25 Aug 2006 08:09:57 GMT

Before anyone mentions it vba makes a good scripting language not.

re: Environment variable expansion occurs when the command is read

Jules — Mon, 28 Aug 2006 18:35:34 GMT

Raymond, your explanation of why this behaviour is the default doesn't make sense. You say "prior to Windows NT, that was the only type of expansion supported by the command interpreter." But prior to NT, the command interpreter only supported executing a single command per line read, so the question of when variables were expanded never arose: it happened immediately prior to execution, which also happened to be immediately after reading them.

When the NT interpreter was written, somebody decided that this way was the best way of doing it. I'm sure that CMD.EXE has always been written in C or some other high-level language, so the complexity of doing it the other way can't have been that bad. So I still wonder why this decision went the way it did, when the other way is much more useful.

[It also had to be compatible with OS/2 batch files, and OS/2's command interpreter was written in assembly language as I vaguely recall. -Raymond]

re: Environment variable expansion occurs when the command is read

Rexxx — Thu, 31 Aug 2006 11:00:43 GMT

OS/2 batch files = Rexx
Quite superior to Batch.

Using DOS command to Auto-Pick today’s wallpaper « maonet technotes

Using DOS command to Auto-Pick today’s wallpaper « maonet technotes — Tue, 02 Oct 2007 18:13:46 GMT

PingBack from http://maonet.wordpress.com/2007/10/01/using-dos-command-to-auto-pick-todays-wallpaper/