Microsoft has caused me sooo much trouble over the years due to a bad piece of documentation

PIEBALDconsult

In the absence of being able to post a Tip at this time...

I work primarily at the command line, always have, always will. And I have had to deal with spawning processes via CMD.EXE , so I have needed the documentation for it and I trusted it to be accurate. But a few months ago, I finally found that it is not.

cmd.exe /?
help cmd

What has been the issue is the statement, "Note that multiple commands separated by the command separator '&&' are accepted for string if surrounded by quotes." This is not only unclear, but it is also misleading at best, and wrong at worst.

It turns out that, as far as cmd.exe is concerned, && is not just a "command separator". As in C-like languages it's the short-circuiting AND boolean operator. And, when I finally realized that, I said, "of course it is". I tested it with a single & and it is a non-short-circuiting AND boolean operator (which is what I've wanted all along). I tested it with || and it is a short-circuiting OR boolean operator. A single | is, of course, the pipe operator and not a boolean operator at all.

That's all fine, but it also means that cmd.exe has a mechanism to distinguish a 'true' (or successful) return code from a 'false' (or unsuccessful) return code. And, of course, it's the opposite from C-like languages -- a zero return code is seen as true (successful), while any other return code is seen as false (unsuccessful). Of course, you who drink the Microsoft Kool-Aid think that's reasonable, while I don't. But that's another whole barrel of monkeys.

So, now I know to use a single & "command separator" for what I do. (Stupid Microsoft and their poor documentation.)

Rage

@PIEBALDconsult said in Microsoft has caused me sooo much trouble over the years due to a bad piece of documentation:

I work primarily at the command line

Wow, not only is CodeProject back, but it also made a jump back in time of 40 years :-p

Rage

On a serious note, this is indeed poorly documented. Here a good source :
https://www.robvanderwoude.com/condexec.php

dandy72

Personally I never fully got the hang of cmd.exe's (or even DOS's) quirks and generally shy away from batch file-type of syntax.

When PowerShell came along I figured there was no point in trying to learn cmd.exe's idiosyncrasies.

PS isn't without its own quirks, but at least in most cases, if I sit back and think about them, I end up agreeing they make sense and move on.

And PS is a lot more powerful. And if that's not enough, you can tap into .NET.

PIEBALDconsult

I'm not a fan of PowerShell.
I just looked at how to spawn a process in PowerShell. It looks like there are a few ways, but I would likely still call cmd.exe from it, the other options don't seem to do what I need and I don't have a need to learn new tricks.

The first time I used PowerShell, it was because someone gave me a script to demonstrate the use of an API for some third-party software. Once I confirmed that it worked, I rewrote it in C# -- which meant I had a lot more control.

There was another time I wrote a PowerShell script to test whether or not some remote systems were healthy, but I simply called it from the command line.

Afzaal Ahmad Zeeshan

I never liked CMD or PowerShell; the only terminals that made sense were from the Linux environments — bash, etc. However, the Windows Terminal did bring me a little closer to the terminal world on Windows. Otherwise, I prefer to use Linux when I must use a terminal.

Right tool for the right job. :)

Graeme_Grant

@PIEBALDconsult said in Microsoft has caused me sooo much trouble over the years due to a bad piece of documentation:

The first time I used PowerShell, it was because someone gave me a script to demonstrate the use of an API for some third-party software. Once I confirmed that it worked, I rewrote it in C# -- which meant I had a lot more control.

You can use C# directly in a powershell script!

Add-Type -TypeDefinition @"
public class HelloWorld {
    public static string SayHello(string name) {
        return "Hello, " + name + "!";
    }
}
"@

# Use the C# method from PowerShell
$result = [HelloWorld]::SayHello("PIEBALDconsult")
Write-Output $result

PIEBALDconsult

That is interesting. I'll have to try it.

I had a boss who favored Python* (over C#) because you deploy the source code (to a server or other remote system) rather than a compiled executable (a point of view I understand, but disagree with).

I have/had an idea of writing a framework which would run on a remote system and compile C# code which has been deployed to it in an as-needed basis. Now what you tell me is that PowerShell already does that, so I'm glad I didn't waste my time working on it.

He is one of many people I have encountered who think Python can do anything all on its own, without acknowledging that Python often relies on packages written in other (better / more powerful) general purpose languages. Which is one of its strengths, as a glue language.

Graeme_Grant

@PIEBALDconsult said in Microsoft has caused me sooo much trouble over the years due to a bad piece of documentation:

I had a boss who favored Python* (over C#) because you deploy the source code (to a server or other remote system) rather than a compiled executable (a point of view I understand, but disagree with).

Have you seen the new support for C# apps that run with the coming DotNet tool? No projects just C# with 'dotnet run' - This should blow your boss' mind. C# can do what Python can do...

PIEBALDconsult

Well, neither Windows nor Linux is the right tool, but they're what's currently popular.

PIEBALDconsult

Hadn't heard of it. I like compiling and deploying executables. But I'll give it a look.

Edit: I just tried it with my work laptop and I was unsuccessful. I'll have to try it at home. It's probably not something I'd use anyway.

jawadulhassan1810

This post is deleted!

jawadulhassan1810

Yeah, Microsoft’s documentation can definitely be confusing at times. Good catch on the difference between &, &&, and ||—a lot of people miss how cmd.exe actually treats return codes. Thanks for breaking it down so clearly!