Give it up MS and just get on with your raison d'etre - ruthlessly making money for your shareholders.
Exploit them by all means, but please don't bother trying to reinvent wheels that have been invented better elsewhere.
It has been a good week for Microsoft. While beancounters counted their cloudy cash, the rest of the Redmond kept itself busy. A Quantum of coders Though uptake of Windows 10 continues to hover around the 700 million mark (quite some way behind the billion promised at the operating system's launch back in 2015), the Microsoft …
"How is piping text between commands better than piping objects?"
It's by far easier to implement, particularly cross programming language as different programming languages tend to have different ideas on what an "object" is. (or in fact different programmers of the same language)
Text is the lowest common denomitor. You can process in any language, and you can both easily read and write it by hand.
Simplicity is important, it's what made Multics and OLE on Windows basically disappear.
Ohh BTW, one should not forget that programmers and language designers can have different ideas on what an object is. Recently quite some Java programmers realized they had a somewhat different idea about objects than the language designers. The result was that they happily piped around objects over the network resulting in lots of pwnage.
So it's not better, you're just familiar with doing it the old way. I don't have a problem with that. My problem was with the original "invented better elsewhere" comment.
Powershell is different to most command lines because of it's piping and it's state management. That's worth investigation if you're interested in technology, however familiar you are with your current way of working.
"How is piping text between commands better than piping objects"
because there are a LOT of text-massaging POSIX utilities that are tried+true, well understood, and relatively easy to work with. I can, for example, use 'awk' 'cut' 'sed' or 'grep' to massage any reasonably-formatted text data, and the result of piped text data can also be assigned to a shell variable within something like bash, or in a language like Perl, where you can do even more with it programatically.
"An Object" is, unfortunately, too vaguely defined for such utilities to work with. Passing objects (rather than text-based data) would be denying yourself the ability to make use of the standard POSIX command line tools, the very things that have made the POSIX command line shells *SUPERIOR* to anything on DOS or windows for DECADES.
But if you want to do everything "the Micro-shaft way" instead of using POSIX tools, have at it.
Is as dumb as bash on Windows. I know bash and don't know Powershell, but if I had to write scripts that would be long lived and supported for Windows machines, I'd either learn enough Powershell to get the job done or (this would be my first option) hand it to a Windows guy who already knows it. I'd only use bash on Windows if I was writing some quick and dirty scripts for my use alone.
Using bash on Windows or Powershell on Linux just leaves a future support headache as you reduce the audience of people who are able to understand/modify the scripts, and you have a special environment that needs special handling rather than being a native part of the OS like bash on Linux or Powershell on Windows.
In fact I had this dilemma years ago when I was writing scripts to extract/massage data off DMX arrays all over the world. The tools were installed on Windows boxes at some sites, and the path of least resistance was to install an SSH server on them with certificate login allowed from a single host (approved by security after countless meetings I was billing a lot for :)) and created a VM as a Linux scripting host. It used ssh to grab the data it needed from Linux & Windows hosts, and scripts were processed in Linux.
bash on windows works really well in Cygwin. So do the other POSIX tools.
If MIcro-shaft would simply support a built-in X11 server for windows, with Cygwin pre-installed, a LOT of compatibility and cross-platform problems would be solved (they used to go the 'subsystem' route for things like OS/2, why not POSIX and X11 and use Cygwin rather than INTERIX/SFU/SUA ?). But NOOOooo, they have to go down the "Embrace, Extend, Extinguish" path. 'Power Hell' for Linux is exactly _THAT_. If it weren't so obvious that Micro-shaft is trying to take over the Linux environment, so they can control, extend, and then DESTROY what it used to be [in favor of some subscription-based spyware infested 'adware or paywall' version], maybe Micro-shaft might get away with it.
But the "Linux community" knows better, especially those of us who WENT TO LINUX (and other POSIX systems like FreeBSD) because of what Micro-shaft was up to early this century (the '.Not' initiative being the first of the worst, and it goes downhill from there).
I'm like a "former windows fan" who was BETRAYED back at the beginning of the century, when Micro-shaft took a wrong turn beginning with the '.Net' initiative. So I saw the writing on the wall, and learned how to work with POSIX systems instead, seeing as Apple also went with POSIX for OS/X, so there were really just two kinds of operating systems to learn and master.
(and I wonder how many OTHER betrayed windows fans switched to POSIX / Linux operating systems?)
I beg to differ.
Your argument is completely valid, but ir relies on an assumption: That knowledge of BASH scripts in the Windows sysadmin population is either constant or decreasing. I am seing the exact opposite in the real world. It might easily be, that legacy PowerShell scripts will be just another account in the technical debt department, when POSIX-type shell scripts are still the de facto standard.
"That knowledge of BASH scripts in the Windows sysadmin population is either constant or decreasing."
Well Powershell is the defacto scripting language for Windows, O365, Azure and vSphere (which moved from Bash!) So I think it's safe to say that Powershell is relevant for way more SAs that Bash is these days.
This post has been deleted by its author