I hate cmd.exe

[aogail]

set foo=bar
if "true" == "true" (
    set foo=baz
    echo %foo% should equal baz
)

...but it doesn't.

[dabean]

set foo=bar
if "true" == "true" set foo=baz
echo %foo% should equal baz

It's not exactly a full-fledged programming language. 

[AbbydonKrafts]

It is funny like that:

set foo=bar
if "true" == "true" (
   set foo=baz
   @echo Inside if: foo=%foo%
   )
@echo Outside if: foo=%foo%

Results in:

C:\>set foo=bar

C:\>if "true" == "true" (
set foo=baz

)
Inside if: foo=bar
Outside if: foo=baz

[CDarklock]

How odd. I'm going to go off and play with this for a while.

[AbbydonKrafts]

Looks like it has to go all the way back to the base level. This:

set foo=bar
if "true" == "true" (
   if "true" == "true" (
      set foo=baz
      @echo Inside if #2: foo=%foo%
   )
   @echo Inside if #1: foo=%foo%
)
@echo Outside if: foo=%foo%

Still only works when it gets back to the base level:

C:\>set foo=bar
C:>if "true" == "true" (

if "true" == "true" (

set foo=baz
)
)

Inside if #2: foo=bar

Inside if #1: foo=bar

Outside if: foo=baz

[aogail]

@dabean said:

It's not exactly a full-fledged programming language. 

That's a pretty poor excuse for failing to read the correct value of a variable inside an if block. ;P

[belgariontheking]

@CDarklock said:

How odd. I'm going to go off and play with this for a while.

<channeling person="Michael Scott">That's what she said!</channeling>

[CDarklock]

My son says that all the time. He's almost four.

He also does the "You know what? Chicken butt!" joke.

[AbbydonKrafts]

@CDarklock said:

How odd. I'm going to go off and play with this for a while.

I have this odd feeling that I'm going to spend time at least once a week trying to think up some insane batch files that do not rely on new-fangled technology such as scripts. I remember creating some beasts back on DOS 6.



I guess it'll make good fodder for my new tech blog (trying to keep topics separate now).

[Guest]

@aogail said:

set foo=bar
if "true" == "true" (
    set foo=baz
    echo %foo% should equal baz
)

...but it doesn't.

cmd.exe is crippled and retarded and doesn't support what you're trying to do.  However, your batch file works perfectly as-is with 4NT.exe from   [url]www.jpsoft.com[/url]

Apprently they've changed the name to "Take Command Console" with the most recent version.   I've been using this program for many years -- going all the way back to their 4DOS program back in the early 90's..  I have no association with them -- just a satisfied customer for 15 years.

[dabean]

 @aogail said:

@dabean said:

It's not exactly a full-fledged programming language. 

That's a pretty poor excuse for failing to read the correct value of a variable inside an if block. ;P

 Sorry, didn't read the question properly. Set /? provides explanation:

 

Finally, support for delayed environment variable expansion has been
added.  This support is always disabled by default, but may be
enabled/disabled via the /V command line switch to CMD.EXE.  See CMD /?

Delayed environment variable expansion is useful for getting around
the limitations of the current expansion which happens when a line
of text is read, not when it is executed.  The following example
demonstrates the problem with immediate variable expansion:

    set VAR=before
    if "%VAR%" == "before" (
        set VAR=after
        if "%VAR%" == "after" @echo If you see this, it worked
    )

would never display the message, since the %VAR% in BOTH IF statements
is substituted when the first IF statement is read, since it logically
includes the body of the IF, which is a compound statement.  So the
IF inside the compound statement is really comparing "before" with
"after" which will never be equal.  Similarly, the following example
will not work as expected:

    set LIST=
    for %i in () do set LIST=%LIST% %i
    echo %LIST%

in that it will NOT build up a list of files in the current directory,
but instead will just set the LIST variable to the last file found.
Again, this is because the %LIST% is expanded just once when the
FOR statement is read, and at that time the LIST variable is empty.
So the actual FOR loop we are executing is:

    for %i in () do set LIST= %i

which just keeps setting LIST to the last file found.

Delayed environment variable expansion allows you to use a different
character (the exclamation mark) to expand environment variables at
execution time.  If delayed variable expansion is enabled, the above
examples could be written as follows to work as intended:

    set VAR=before
    if "%VAR%" == "before" (
        set VAR=after
        if "!VAR!" == "after" @echo If you see this, it worked
    )

    set LIST=
    for %i in (*) do set LIST=!LIST! %i
    echo %LIST%

 

[WeatherGod]

@dabean said:

 ..snip full explanation...

 

so, who is on first again? 

[aogail]

Wow, thanks dabean; I did not expect the cmd.exe help to include an explanation of this insane behavior. The fact that cmd.exe /V exists actually makes this even more of a WTF than it was originally.




Let me get this straight. MS:

• implemented stupid, arguably buggy behavior in their variable expansion code;
• decided to "fix" the buggy behavior, but only if you invoke cmd.exe with a brand new argument; and
• decided not only would you need to invoke cmd.exe with /V, but in doing so you would have to write scripts that use syntax that is invalid under normal cmd.exe operation

W.T.F.

[Eternal_Density]

@WeatherGod said:

@dabean said:

 ..snip full explanation...

 

so, who is on first again? 

I don't know

[Spacecoyote]

cmd.exe is the product of years of laziness and back-burner development at microsoft.

DOS started out a clone of CP/M. Microsoft didn't bother with multitasking or even anything above primitive batch processing, and instead just threw BASIC on there as DOS's "killer app". Oddly enough, both the IBM PC and BASIC took off, carrying DOS with it. By then MS had a more fully featured Unix clone called Xenix (based on Version 7 Unix), but DOS had become so big and Microsoft were looking at OS/2 so Xenix was abandoned by Microsoft (SCO picked it up and went on to become infamous).

The Macintosh was doing big things for Apple, and threatening to slowly but surely kill the IBM PC. It seemed almost too late when Microsoft stepped in and released Windows 3, their first offering to even come close to the user friendliness of the Mac, with DOS as sort of a glorified bootloader. But due to the sheer size of the IBM PC market Windows took off. So the big thing was GUI and Microsoft didn't make any noteworthy improvements since to the command prompt. Recently Microsoft has released Windows Powershell, a more more fully featured shell than cmd.exe, but non-standard (unless you call vbscript a standard) to say the least.

I say screw both of them. BASH ftw!

[lolwtf]

The real WTF is no Unicode support.

[Pidgeot]

@aogail said:

decided to "fix" the buggy behavior, but only if you invoke cmd.exe with a brand new argument; and

decided not only would you need to invoke cmd.exe with /V, but in doing so you would have to write scripts that use syntax that is invalid under normal cmd.exe operation

Microsoft are INSANE about backwards compatibility. This way, a legacy script will only produce a different result if it tries to use !varname!, and varname is a variable that exists (a situation they clearly deem less likely than a script relying on the old behavior).

I'm not saying that necessarily makes the solution good, or any less of a WTF, but this is pretty much what they do for any change that has the possibility to break something - and if the goal is to maximize backwards compatibility, I don't see how they could have done things any differently.

Of course, since you wouldn't be writing a script that relies on !-expansion without knowing this requires /V, it would be trivial to make your script launch a new cmd.exe process with the appropriate parameters, if /V is not activated:

set SOMESPECIALVARNAME=test
if not "!SOMESPECIALVARNAME!" == "test" (
  cmd /v /c %0 %*
  goto EOF
)
rem Insert your script here

You might want to add a check to ensure that it doesn't go into an infinite loop if run on a system that doesn't support it, and possibly define your own label, but this should run unmodified on XP and later (don't know about Win2000).

@lolwtf said:

The real WTF is no Unicode support.

Actually, it supports Unicode just fine, it's just that Lucida Console doesn't contain Unicode characters, and there is no font link defined, so Windows doesn't know what font to use instead. I've set up Vista to use Meiryo for Japanese characters in the shell, and it works great (you can do this with XP as well, but due to the design of MS Gothic, it doesn't render properly) - all that's needed is an entry in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink and a reboot.

Programs (at least those that aren't part of Windows), however, tend to not support it, even though UTF-8 is available as a codepage you can change to (chcp 65001).

[Faxmachinen]

It's very simple. Environment variables are interpolated before the command is executed. Consider the following Perl snippet:

$foo = 'bar';
$command = <<IF;
if ('true' == 'true') {
	$foo = 'baz';
	print "$foo should be equal to baz";
}
IF
print $command;

This outputs:

if ('true' == 'true') {
	bar = 'baz';
	print "bar should be equal to baz";
}

Which obviously won't eval in Perl, but I'm sure you get the point.

[KenW]

@aogail said:

Wow, thanks dabean; I did not expect the cmd.exe help to include an explanation of this insane behavior. The fact that cmd.exe /V exists actually makes this even more of a WTF than it was originally.

Let me get this straight. MS:

• implemented stupid, arguably buggy behavior in their variable expansion code;
• decided to "fix" the buggy behavior, but only if you invoke cmd.exe with a brand new argument; and
• decided not only would you need to invoke cmd.exe with /V, but in doing so you would have to write scripts that use syntax that is invalid under normal cmd.exe operation

W.T.F.

 

Let me get this straight. MS:

• implemented new functionality to overcome a shortcoming that has existed for decades;
• did so in a way that maintains backward compatibility so that existing batch files don't break;
• documented the change thoroughly enough that even you should have been able to understand it.

And you still complain about it.

What an ass. 

[DaveK1]

@Eternal Density said:

@WeatherGod said:

@dabean said:

 ..snip full explanation...

 

so, who is on first again? 

I don't know

 

<font color="red" size="48">EPIC FAIL</font>

 

It's supposed to go:

@WeatherGod said:

@dabean said:

 ..snip full explanation...

 

so, who is on first again? 

No, who's on second.

Now get your ass back to school and learn yourself some culture!

[MasterPlanSoftware]

@KenW said:

And you still complain about it.

What an ass. 

 

Agreed. Looks like we have picked up another MS bashing troll with nothing intelligent to even argue about.

 

We can just blame MFD for attracting them! </sarcasm>

[morbiuswilters]

@Spacecoyote said:

cmd.exe is the product of years of laziness and back-burner development at microsoft.

DOS started out a clone of CP/M. Microsoft didn't bother with multitasking or even anything above primitive batch processing, and instead just threw BASIC on there as DOS's "killer app". Oddly enough, both the IBM PC and BASIC took off, carrying DOS with it. By then MS had a more fully featured Unix clone called Xenix (based on Version 7 Unix), but DOS had become so big and Microsoft were looking at OS/2 so Xenix was abandoned by Microsoft (SCO picked it up and went on to become infamous).

The Macintosh was doing big things for Apple, and threatening to slowly but surely kill the IBM PC. It seemed almost too late when Microsoft stepped in and released Windows 3, their first offering to even come close to the user friendliness of the Mac, with DOS as sort of a glorified bootloader. But due to the sheer size of the IBM PC market Windows took off. So the big thing was GUI and Microsoft didn't make any noteworthy improvements since to the command prompt. Recently Microsoft has released Windows Powershell, a more more fully featured shell than cmd.exe, but non-standard (unless you call vbscript a standard) to say the least.

I say screw both of them. BASH ftw!

Aw, fuck, we've already been through this.  Batch scripts kind of suck, but you should probably just use vbscript or one of the other standard MS languages. DOS didn't support multitasking because even single tasking was pretty sophisticated for the consumer market at the time.  DOS wasn't competing with UNIX mainframes or minicomputers.  Bash is a stronger shell because UNIX has a stronger command-line legacy, but it's still pretty shitty for anything but the most trivial programs.  If my bash script is going to be longer than 10 lines, I will usually just use perl.

[aogail]

@MasterPlanSoftware said:

@KenW said:

And you still complain about it.

What an ass. 

 

Agreed. Looks like we have picked up another MS bashing troll with nothing intelligent to even argue about.

 

We can just blame MFD for attracting them! </sarcasm>

Hooray for MS apologists.

Do you really love MS so much that you overlook even this ridiculous behavior? No one in their right mind would expect a shell to not properly support variable changes inside if blocks. By the way, adding new and incompatible syntax to work around a bug doesn't count as fixing the bug.

[MasterPlanSoftware]

@aogail said:

Do you really love MS so much that you overlook even this ridiculous behavior?

 

If there is a good reason and it is documented? Yes. What else would you expect?

Are you really such an MS basher that you can't understand this simple concept?

[Lingerance]

@MasterPlanSoftware said:

What else would you expect?

Honestly one would have expected it to not have happened in the first place, which I believe the entire point of the argument is. Yes they "fixed" it, and it still works backwards.

[DaveK1]

@aogail said:

Hooray for MS apologists. Do you really love MS so much that you overlook even this ridiculous behavior? No one in their right mind would expect a shell to not properly support variable changes inside if blocks. By the way, adding new and incompatible syntax to work around a bug doesn't count as fixing the bug.

You're right, this is yet another stupid MS non-standard behaviour isn't it?  I mean, look at how something nice and standardised and POSIX compliant like bash would handle the situation:

@Same example in bash shell said:

 

/tmp $ export FOO=baz

/tmp $ if [ "true" == "true" ] ; then set FOO=bar ; echo "${FOO}" should be bar; fi

baz should be bar

/tmp $

Whoops!   What went wrong?  Should we blame MS for this too?

NO!   We should blame YOU, for being a fricken' moron.  You're the kind of lousy shell coder who sets an environment variable inside a bracketed or backticked expression and doesn't even understand you're operating in a child process and the results won't be visible in the parent.  The simple fact is that YOU don't understand how shell command-lines are parsed in cmd.exe or any other shell, and you are blaming MS, when for once it's not their fault.

@aogail said:

No one in their right mind would expect a shell to not properly support variable changes inside if blocks.

So, what you say here is utter garbage.  *ANYONE* in their right mind would expect that, because anyone in their right mind would RTFM rather than expecting to just magically know how shell coding works. If YOU don't RTFM, then it's YOUR fault that YOU don't know how shells work.

[Lingerance]

@DaveK said:

@Same example in bash shell said:

/tmp $ export FOO=baz

/tmp $ if [ "true" == "true" ] ; then export FOO=bar ; echo "${FOO}" should be bar; fi

bar should be bar

/tmp $

bash --version
GNU bash, version 3.2.33(1)-release (i686-pc-linux-gnu)
Copyright (C) 2007 Free Software Foundation, Inc.

[aogail]

@Lingerance said:

@DaveK said:

@Same example in bash shell said:

/tmp $ export FOO=baz

/tmp $ if [ "true" == "true" ] ; then export FOO=bar ; echo "${FOO}" should be bar; fi

bar should be bar

/tmp $

bash --version
GNU bash, version 3.2.33(1)-release (i686-pc-linux-gnu)
Copyright (C) 2007 Free Software Foundation, Inc.

ROFLMAO

DaveK, if you are going to call me a "moron" and say I need to "RTFM", you might want to do the same yourself. You obviously don't know that cmd.exe's "set" is quite different from POSIX "set".

But wait, you used "export" on the first line and "set" in the if block. Did you actually think that would deceive anyone? You're even worse of an MS fanboy than MasterPlanSoftware and KenW.

[MasterPlanSoftware]

@aogail said:

@Lingerance said:

@DaveK said:

@Same example in bash shell said:

/tmp $ export FOO=baz
/tmp $ if [ "true" == "true" ] ; then export FOO=bar ; echo "${FOO}" should be bar; fi
bar should be bar
/tmp $

bash --version GNU bash, version 3.2.33(1)-release (i686-pc-linux-gnu) Copyright (C) 2007 Free Software Foundation, Inc.

ROFLMAO

DaveK, if you are going to call me a "moron" and say I need to "RTFM", you might want to do the same yourself. You obviously don't know that cmd.exe's "set" is quite different from POSIX "set".

But wait, you used "export" on the first line and "set" in the if block. Did you actually think that would deceive anyone? You're even worse of an MS fanboy than MasterPlanSoftware and KenW.

 

Why don't you just go troll somewhere else. Really. Oh, and grow up.

[AbbydonKrafts]

@aogail said:

By the way, adding new and incompatible syntax to work around a bug doesn't count as fixing the bug.

Who needs batch scripts? It's Windows!

Dim foo
foo="bar"
Wscript.StdOut.WriteLine "foo is currently " & foo
If true=true Then
  foo="baz"
  Wscript.Echo "foo is now " & foo
End If
Wscript.StdOut.WriteLine "foo is still " & foo

C:\>cscript test.vbs
Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.
foo is currently bar

foo is now baz

foo is still baz
C:>

Bonus! Two ways to output.

[morbiuswilters]

@AbbydonKrafts said:

@aogail said:

By the way, adding new and incompatible syntax to work around a bug doesn't count as fixing the bug.

Who needs batch scripts? It's Windows!

Dim foo
foo="bar"
Wscript.StdOut.WriteLine "foo is currently " & foo
If true=true Then
  foo="baz"
  Wscript.Echo "foo is now " & foo
End If
Wscript.StdOut.WriteLine "foo is still " & foo

C:\>cscript test.vbs
Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.
foo is currently bar

foo is now baz

foo is still baz
C:>

Bonus! Two ways to output.

Seriously, this is the same tired argument we had last week.  Batch files suck at scripting -- use vbs instead.  Also, bash might not be as primitive as DOS, but it's still a pain in the fucking ass.

 

OMG, check out this perl WTF guize!!!

#!/usr/bin/perl

if ("x" == "y") {

    print "true\n";

}

 

Yes, it prints true!!  This is phenomenall!!!!!  I'm going to be famous!

 

Wait, what's that?  == is only used for numeric comparison in perl?  I didn't RTFM?  Yeah, same as the OP, I guess. 

[MasterPlanSoftware]

@morbiuswilters said:

 

Wait, what's that?  == is only used for numeric comparison in perl?  I didn't RTFM?  Yeah, same as the OP, I guess. 

 

No way! You are just wrapped around MS's little finger!

 

What's that you say? You are a very experienced member of the Linux community?

 

*Head Pops*

[aogail]

@MasterPlanSoftware said:

@morbiuswilters said:

 

Wait, what's that?  == is only used for numeric comparison in perl?  I didn't RTFM?  Yeah, same as the OP, I guess. 

 

No way! You are just wrapped around MS's little finger!

 

What's that you say? You are a very experienced member of the Linux community?

 

Head Pops

Nice straw man, guys! Keep it up!

[bstorer]

@morbiuswilters said:

 

OMG, check out this perl WTF guize!!!

#!/usr/bin/perl

if ("x" == "y") {

    print "true\n";

}

Yes, it prints true!!  This is phenomenall!!!!!  I'm going to be famous!

Wait, what's that?  == is only used for numeric comparison in perl?  I didn't RTFM?  Yeah, same as the OP, I guess. 

Clearly this is proof we should all be using Python!  I don't care what all the Larry Wall lovers say.

[MasterPlanSoftware]

@aogail said:

Nice straw man, guys! Keep it up!

This coming from someone too dumb to write a functional batch script.

My guess would be he found this condition somewhere else and decided to spam any forum he could...

Of course, he leaves a nice trail of MS bashing, so it is not like he is looking for any credibility anywhere.

http://digg.com/users/aogail/

Just another Apple fanboy trolling with anti-MS crap.

[morbiuswilters]

@aogail said:

Nice straw man, guys! Keep it up!

Thank you for the link.  I have never heard the phrase "straw man" before.  Is it French?

 

I'm no Microsoft fanboi.  I fully believe they are a very professional, responsible and successful company with some of the best engineers in the world working for them.  I respect their achievments, but I am willing to call them out when they make errors.  However, I also look at things like this in context.  By today's standards is Windows 3.1 a good OS?  Hell no, I'd rather shoot myself in the arm than use that P.O.S.!  Eighteen years ago, though, it was cutting edge.  Of course, I was five at the time and from what Saturday morning cartoons had taught me, computers should be able to make witty quips while they "searched their files" for information on the bad guys, but I digress.

 

The overall point is that batch scripts are the wrong tool for the job.  My first PC was a 286 that ran DOS 3.3.  The machine itself was one year older than I was at the time.  I taught myself how to write batch scripts, though.  I think it's absurd that 15 years later people are complaining about the lack of power in a "language" that I found unsuitable then!  I quickly taught myself basic so I could write more expressive programs.  Yes, bash is more powerful, but it's apples vs. oranges, man.  VBS is quite expressive and is standard with Windows.  The .net framework is a free, easy-to-install download and probably as ubiqitous as perl is in the UNIX world.  I just cannot sit here and listen to people complain about the lack of scripting options for a platform that has a plethora (pardon my French) of them.  I think there are legitimate complaints one can make about Microsoft's products.  I also think there are legitimate complaints my own customers could make about the software I have written.  By focusing on the inadequacy of batch scripts, though, you don't contribute anything useful.  We already know the DOS shell is fairly weak.  This is not a major revelation.  By harping on such an insignificant topic (one that you can "win" by bringing up bash without even knowing that much about UNIX) you ignore the more tangible problems that Microsoft faces and are not helping to improve the state of our art.

[MasterPlanSoftware]

@morbiuswilters said:

...

 

*Golf Clap*

[Renan_S2]

@morbiuswilters said:

Eighteen years ago, though, it was cutting edge.

 

 

Hmmm... Windows 3.1 was released in 1992, IIRC. 

[morbiuswilters]

@Renan_S2 said:

Hmmm... Windows 3.1 was released in 1992, IIRC. 

Shit, you're right, I was just making a swag at it.  I knew Windows 3.0 significantly influenced the development of NT which was started in 1988, so I guessed Win3.1 came out around 1990.  Still, 16 years ago it was cutting edge as well. 

[Spacecoyote]

@morbiuswilters said:

bash might not be as primitive as DOS, but it's still a pain in the fucking ass.

Exactly what, pray tell, makes bash a pain in the ass? 

[morbiuswilters]

@Spacecoyote said:

@morbiuswilters said:

bash might not be as primitive as DOS, but it's still a pain in the fucking ass.

Exactly what, pray tell, makes bash a pain in the ass? 

Well, for starters, you have to call to external programs to do most everything for you.  There's no telling what version of that program will be available or what arguments it will like or choke on.  Also, there are differing formats for arguments to these programs like grep, sed and awk.  Additionally, handling variable is pain.  Want to compare strings?  Oh, that's a different syntax than comparing numbers, unless you're using double-brackets!  Better make sure you encase all strings in double-quotes and prepend with a dummy character just in case one of the strings is null!  Oh, you want to atomically lock a resource?  You're gonna need to write an external program in C to handle that so you can use O_EXCL.

 

I'm not saying bash is worse than batch scripts, just that if I find myself writing any non-arbitrary program in bash, I quickly convert it to perl because it will be easier.  Also, I realize that my original script will probably grow to be 2 to 3 times larger in the maintenace phase and any developer caught adding features will curse me for writing it in in bash instead of a proper programming language.  Does this satisfy you? 

[aogail]

@MasterPlanSoftware said:

Just another Apple fanboy trolling with anti-MS crap.

That's right, I'm an Apple fanboy... who happens to also run OpenBSD, Gentoo Linux, WinXP, and Win Vista. Seems like I'm actually a "best OS for the job" fanboy, but that doesn't fit into your straw man, does it?

Please, keep 'em coming.

[aogail]

Finally, a response that warrants an actual reply...

@morbiuswilters said:

Thank you for the link.  I have never heard the phrase "straw man" before.  Is it French?

...mostly, anyway.

Next time just skip the fallacies, and I won't feel compelled to link.

@morbiuswilters said:

I'm no Microsoft fanboi.  I fully believe they are a very professional, responsible and successful company with some of the best engineers in the world working for them.  I respect their achievments, but I am willing to call them out when they make errors.  However, I also look at things like this in context.  By today's standards is Windows 3.1 a good OS?  Hell no, I'd rather shoot myself in the arm than use that P.O.S.!  Eighteen years ago, though, it was cutting edge.  Of course, I was five at the time and from what Saturday morning cartoons had taught me, computers should be able to make witty quips while they "searched their files" for information on the bad guys, but I digress.

That's all fine and good. That doesn't change the fact that cmd.exe is still the only CLI that's available on all NT systems, nor the fact that this behavior, which should have been changed two decades ago, is still around in Vista.

@morbiuswilters said:

The overall point is that batch scripts are the wrong tool for the job.

Are you saying that there is no job for which cmd scripts are the best tool? Not even, say, controlling a program for which there is only a command line interface? Regardless, I'm stuck modifying one, and this behavior sucks. It isn't "Oh hey, equality operators are implemented differently across various languages" suck; it's "this is the most ridiculous behavior I've ever seen in a scripting environment" suck. As soon as I realized what was going on, it was a simple matter to modify the control structure of the script to work around it. The point is that I shouldn't have had to do that.

@morbiuswilters said:

My first PC was a 286 that ran DOS 3.3.  The machine itself was one year older than I was at the time.  I taught myself how to write batch scripts, though.  I think it's absurd that 15 years later people are complaining about the lack of power in a "language" that I found unsuitable then!  I quickly taught myself basic so I could write more expressive programs.  Yes, bash is more powerful, but it's apples vs. oranges, man.  VBS is quite expressive and is standard with Windows.  The .net framework is a free, easy-to-install download and probably as ubiqitous as perl is in the UNIX world.  I just cannot sit here and listen to people complain about the lack of scripting options for a platform that has a plethora (pardon my French) of them.  I think there are legitimate complaints one can make about Microsoft's products.  I also think there are legitimate complaints my own customers could make about the software I have written.  By focusing on the inadequacy of batch scripts, though, you don't contribute anything useful.  We already know the DOS shell is fairly weak.  This is not a major revelation.  By harping on such an insignificant topic (one that you can "win" by bringing up bash without even knowing that much about UNIX) you ignore the more tangible problems that Microsoft faces and are not helping to improve the state of our art.

I didn't complain about the "lack of scripting options" for Windows. Like you said, there are many. Does that mean that this one had to stay crippled for two decades? No.

I also never said, "Wow, the DOS shell is fairly weak." As you say, that's obvious. I said, "This specific behavior is so far out of left field I don't see how MS could justify not (truly) fixing it 20 years ago." The other cmd script idiosyncrasies I've run into have mostly been mere implementation differences.

Finally, unlike you, I did not experience the joy of cmd scripting in the era of Windows 3.0. What's it to you if I'm the latest victim of this lame behavior?

[aogail]

@bstorer said:

Clearly this is proof we should all be using Python!  I don't care what all the Larry Wall lovers say.

While we're at it, let's debate the virtues of vim over emacs :D

[MasterPlanSoftware]

@aogail said:

@MasterPlanSoftware said:

Just another Apple fanboy trolling with anti-MS crap.

That's right, I'm an Apple fanboy... who happens to also run OpenBSD, Gentoo Linux, WinXP, and Win Vista. Seems like I'm actually a "best OS for the job" fanboy, but that doesn't fit into your straw man, does it?

Please, keep 'em coming.

 

Oh boy is this word of the day or what?

Do you think these are new vocabulary for us or something?

[MasterPlanSoftware]

@aogail said:

That doesn't change the fact that cmd.exe is still the only CLI that's available on all NT systems

 

That is blatantly not true. From the .NET frameworks download page:

Supported Operating Systems: Windows 2000 Service Pack 3; Windows 98; Windows 98 Second Edition; Windows ME; Windows Server 2003; Windows XP Service Pack 2

http://www.microsoft.com/downloads/details.aspx?FamilyID=0856eacb-4362-4b0d-8edd-aab15c5e04f5&displaylang=en

@aogail said:

Are you saying that there is no job for which cmd scripts are the best tool?

I know of no case where another option wouldn't be a better choice. A batch file might be quicker/easier, but I wouldn't say it is the 'better tool'.

@aogail said:

The point is that I shouldn't have had to do that.

Agreed. Had you actually known what you were doing, you would have gotten it right the first time.

@aogail said:

What's it to you if I'm the latest victim of this lame behavior?

Because YOU came HERE to complain about something you clearly know nothing about. If you had a clue of the context of something as vast as OS backwards compatibility it would almost be worth arguing with you.

But as it stands, you know as well as we do you are just here to troll. 

[MasterPlanSoftware]

@aogail said:

While we're at it, let's debate the virtues of vim over emacs :D

 

Sorry the rest of us are here for better conversation than the obvious trolling you are accustomed to.

[aogail]

@MasterPlanSoftware said:

Sorry the rest of us are here for better conversation than the obvious trolling you are accustomed to.

I love how you claim that only I am trolling, in reference to a joking reply I made to a virtually identical comment (python vs. perl) made by someone else.

[MasterPlanSoftware]

@aogail said:

@MasterPlanSoftware said:

Sorry the rest of us are here for better conversation than the obvious trolling you are accustomed to.

I love how you claim that only I am trolling, in reference to a joking reply I made to a virtually identical comment (python vs. perl) made by someone else.

 

A quick look at your posting history tells me all I need to know.

[aogail]

@MasterPlanSoftware said:

@aogail said:

That doesn't change the fact that cmd.exe is still the only CLI that's available on all NT systems

 

That is blatantly not true. From the .NET frameworks download page:

Supported Operating Systems: Windows 2000 Service Pack 3; Windows 98; Windows 98 Second Edition; Windows ME; Windows Server 2003; Windows XP Service Pack 2

http://www.microsoft.com/downloads/details.aspx?FamilyID=0856eacb-4362-4b0d-8edd-aab15c5e04f5&displaylang=en

I fail to see how .NET gives me a scripting interface that is always available on all NT systems. All NT systems includes NT 4. Also, .NET is not installed by default on all but the most recent NT systems.