Microsoft has caused me sooo much trouble over the years due to a bad piece of documentation
-
On a serious note, this is indeed poorly documented. Here a good source :
https://www.robvanderwoude.com/condexec.php -
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.
-
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.
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.
-
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. :)
-
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.
@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 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 $resultThat 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.
-
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.
@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...
-
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. :)
Well, neither Windows nor Linux is the right tool, but they're what's currently popular.
-
@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...
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.
-
This post is deleted!
-
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!
