Why is powershell so trash?

Like how the fuck can you fuck up something that badly?
Let's start with command names
>Get-Items -> ls
>Select-String -Pattern x -> grep x
Weird fucking casing
>just look at it
Nonstandard arithmetic operators
> -eq, -ne, -gt
Some types return "-" if you try to do 1 - 1 =

Attached: Autistic_Screeching.png (507x400, 276K)

Other urls found in this thread:

docs.microsoft.com/en-us/dotnet/api/system.io.file.readallbytes?view=netframework-4.7.2
twitter.com/NSFWRedditGif

You kind of have to know how to use it for it to really shine. I don't think it's as approachable for a beginner as bash. Powershell does have some good ideas though. For instance:

Instead of having utilities like awk it replaces these by treating the output of most programs as objects that have inbuilt functions that can be manipulated.
Switches for every common utility support a full word argument which in my opinion makes shell scripts more readable since you don't have to remember if -v means version or verbose for that particular utility.
It has more inbuilt execution safety (multiple different execution policies are possible based on configuration).
Also object oriented programming within shell scripts is enabled natively (you don't need to use some goofy workaround with setting environment variables like bash).

My biggest problem with it is that windows processes don't return proper error codes. If you fork a process and it fails it just returns "false" and you can't actually see what wen't wrong by checking the error code.

Thanks for the insight, good post

You make some good points there, but you forgot to mention the documentation...
I've no idea who made it, but it seems like it's generated by a AI

Attached: BANTER_STOPS.jpg (602x709, 67K)

It's the combination of being inspired by Bash the Trash and MS being unable to create proper scripting languages since forever. But since almost everybody is unable to create proper scripting languages for their specific usecase, that's excusable.

As for a utility oriented point of view, see More important though is, that its .net API is(are) trash.

>I've no idea who made it, but it seems like it's generated by a AI
It's really weird that Microsoft isn't ashamed to keep their machine translated docs around.

>More important though is, that its .net API is(are) trash
Why?

>can embed PS into C#
>can run scripts, using several undocumented APIs
>can decide between session types
but
>can't pass a delegate to PS

As far as I'm aware the only way is to
>create an IPC interface in your application
>create a separate assembly with wanted functions that can talk to said IPC interface
>execute snippet in host application to load said assembly
seems to me that the APIs solely exist so MS could write their shitty PS "IDE"

>Readable command names
>Commands return objects instead of strings so it's possible to change things like the output order / add fields without breaking existing scripts and you don't have to pipe everything through awk or perl every time
>Commands follow a convention and autocompletion is amazing so you can easily find the command you're searching for as long as you're not a complete and utter brainlet
>Autocompletion is a first class feature

Truly I pity the bashtards.

What's confusing about this?

Attached: ZYvOL.png (1091x172, 14K)

PS is what happens when zoomers are too retarded to learn awk and sed

>text manipulation
kek
I'll take objects any day of the week, thanks.

Thank you for proving my point

>"hurr durr you use something more versatile and objectively superior"
What a brainlet. Get with the modern times.

No thx

Attached: 1551622726482.png (1091x871, 1.44M)

>Instead of having utilities like awk it replaces these by treating the output of most programs as objects that have inbuilt functions that can be manipulated.

That makes creating new tools very hard and less flexible because you need to make them aware of all sorts of object types, no?

I guess you simply don't get it. That's OK. There's scripting languages for the disabled too.

Attached: 1551310590993.png (817x891, 32K)

> I don't know how to use a thing so it's shit.
I like using PowerShell to build config XML's on the fly.

>There's scripting languages for the disabled too.
Yeah, like this one

Opfag here, i'm not saying it is bad per se.
The promise is great, basically it could eliminate a part of those brainlet windows server sysadmins.
It's just that there are some very weird design decisions made while creating PS.

Attached: 15495473186070.png (311x350, 101K)

I spent 2 hours trying to figure out how to search for specific bytes in a file with PS but it is not possible
there is nothing even close to grep and there is no standard way to escape hex numbers and the incredibly verbose way I found ignores certain bytes completely such as 0x00

literal fucking dogshit made for retarded pajeets to manage their enterprise boxes and nothing more

Why not use chad csv or json?

Attached: xml-json-csv.png (962x370, 11K)

Parameters can have accepted object types specified, so any other type of object would cause the function or cmdlet to fail. It's only a problem if the object type isn't specified (which you shouldn't do) or abstracted object types are accepted without additional validation (like plain "psobject" but you shouldn't do that as well). Generally functions with properly defined parameters will fail before something dumb is done.
There have been lots of modules written, it's not hard and packaging functions as one could be as simple as loading a folder with the same name as the .ps1 file. Many administrative tasks that were once gui-operated moved to using powershell scripts.

Powershell being born in 2004 predates the zoomer era.

>you need to make them aware of all sorts of object types, no?


No, since it's a dynamic language. You can just use duck-typing.

>I spent 2 hours trying to figure out how to search for specific bytes in a file with PS but it is not possible

Pro-tip: anything you can do in C#, you can do in PowerShell.

docs.microsoft.com/en-us/dotnet/api/system.io.file.readallbytes?view=netframework-4.7.2

Now, do you know how to search for specific bytes in an array of bytes?

And before you point out that this is shit for big files with the desired bytes early in the file, you could always optimize with the Stream classes to read the bytes incrementally, it's just not a one-liner like File.ReadAllBytes().

Try the gnuwin packages
wait, sorry that should be GNU/win or as I have recently taken to calling it, GNU plus Windows

You can write all that yourself. In my experience it's most performant to compile the methods written in C# and then call those in Powershell when large arrays are concerned. I'm not sharing it though.

There was a reason Plan9 chose to keep bytestreams. It was a Unix feature that was actually worth keeping.
It's absolutely far superior to the C# API hell that is Windows.
That said, Powershell is a good tool for dealing with the shithole that is Windows.

>Why not use chad csv or json?
I build Windows unattend.xml on the fly using the DSC module in PowerShell and pass it over to Hyper-V.

I don't like SCVMM and have built my own version.

That naming convention is pajeet-tier as fuck

They aid in discoverability as the functionality on most ocassions is spread across several commands so finding others is very important. But there are aliases as well.

PowerShell is also slow as fuck. I open bash in my 15 year old Linux laptop and it opens faster than PowerShell on my 2018 work computer with an i7. It's not just opening, but executing a command is slow and even tab completion is slow as balls! I hit tab, and then feels like I'm waiting a full second for it to complete my command and I literally could've just typed it out instead.