...And I'd say that this displays a problem with the PowerShell design more than anything else. No, not that the curl and wget aliases exist: it made sense at the time, and no longer does, that's fine. The problem is that PS, unlike every other shell out there, handles structured data, which means it necessarily has to live in its own little world, with its own commandset, because even if it uses external commands, they're not going to be expecting structured data, because that's not how external commands work. So, by necessity, PowerShell is semi-monolithic, and doesn't integrate well with the rest of the system on UNIX, and integrates poorly with regular CLI apps on Windows.
This is an unavoidable problem with what PowerShell is trying to do. It doesn't make PS bad, but it causes problems.
Your comment ignores the major integration that PowerShell does provide: .NET. PowerShell can invoke any .NET code and work with the objects returned therefrom. Yes, it has terrible integration with text-based tools, because it's not a text-based shell. It has great integration with the .NET object-based environment, because it's a .NET object-based shell.
(This is also completely ignoring the fact that you can still call any executable; you'll just receive a bunch of strings back. The only failing here is that PowerShell doesn't have the developed string-manipulation tools like sed, awk, etc. because working with text is typically unnecessary.)
The only failing here is that PowerShell doesn't have the developed string-manipulation tools like sed, awk, etc. because working with text is typically unnecessary.)
What kind of tools does it not have? It has all the .Net style string methods (split, trim, and so on), all the .Net regex methods, built in arrays and hashtables, looping over lines of text shortcuts.
It's pretty trivial to do small scale ad-hoc text parsing, cut lines by a character, take element 4, cast to 'datetime' and add +4 days to it, handwave a counter into existance and +1 it, match a regex and do some replacement or group some fields.
It doesn't go as far as sed "in-place text replace" or awk records, but saying it "doesn't have developed string-manipulation like sed" is like saying that of Python. And if you were writing Python you wouldn't need to call out to awk because you'd just use Python string processing and basic data structures for what you were doing, right?
I meant exactly that "it doesn't go as far as sed... or awk...". PowerShell has what I would term the primitives of string manipulation, inherited from .NET -- substring, trim, regex replace, etc. But it does not have the advanced methodologies that sed and awk provide. Especially in regards to editing, since PowerShell also inherits .NET's immutable strings.
This. AWK is the best tool for record DSV record manipulation I've ever used. Some would say that it has since been surpassed by other scripting languages, but I disagree. It's fast to learn, and is incredibly good at what it does, with a very simple and elegant design. Simple AWK scripts can read like descriptions of what you want done. Like this script that prints all users in /etc/passwd that have home directories in /home:
If your sole argument is that .NET has weak integration on platforms for which version 1.0 of the core runtime was only released two months ago, then I don't really have anything to add. Of course it's going to have a weaker integration than a tool set that has existed and been developed together for decades.
However, your original argument was more along the lines of PowerShell being a walled-garden of cmdlets. Which is patently wrong -- it works with any .NET code. It also works with the standardized structured text formats of CSV, JSON, and XML.
It does not currently have tools to work with the two-dimensional text structures typically found on *nix machines, because until this week it was not even available in those environments. We might very well see creation of tools to ease this process.
Weeell, Unix commands also live in their own world, with their own commandset, where everything expects structured data — only the data are streams of bytes.
The problem is at the interface between these two modes of operation (and it'd be just as bad with a third mode, e.g. S-expressions or something else).
Honestly, it'd probably better for PowerShell to only deal with PowerShell commands, and Unix commands to only deal with Unix commands, with a well-defined interface between these two very different ecosystems.
Yeah, but streams of text are standard: every programming language can handle text streams. Even brainf*ck can do that. PowerShell objects are PowerShell specific.
>Honestly, it'd probably better for PowerShell to only deal with PowerShell commands, and Unix commands to only deal with Unix commands, with a well-defined interface between these two very different ecosystems.
Well, yeah, but that would make PowerShell even less useful on UNIX than it already is.
> Yeah, but streams of text are standard: every programming language can handle text streams.
What makes you think PowerShell can't handle streams of text? You'll get an array of System.String objects, one for each line, to do with as you please.
> PowerShell objects are PowerShell specific.
PowerShell objects are .NET objects living in the .NET runtime, and can be passed to any other .NET code. Yes, some object types live in the PowerShell namespace, because they expose PowerShell-specific functionality. But, for instance, `ls` returns System.IO.DirectoryInfo and System.IO.FileInfo objects, which is exactly what you would use in C# or VB.NET or managed C++ or F# to represent the same information.
Exactly right. It's so funny when people cite one of Powershell's selling points as the fact that it's "extensible", meaning that you have to write programs specifically designed to be compatible with it.
a) You don't, it can read text through stdin from any utility which outputs text.
b) Other shell utilities aren't magically compatible with each other, they have to be "specifically designed" to output representations of information in compatible text forms. Which is an ad-hoc thing, hence the existance of parameters like -0 makes the output null terminated instead of newline terminated, for compatibility with tools x,y,z.
This is an unavoidable problem with what PowerShell is trying to do. It doesn't make PS bad, but it causes problems.