"Redmond is vague about what is in that data"
Breach of GDPR, right there....
Microsoft has toasted Amazon announcing Lambda support for Powershell Core 6 by, er, flinging out version 6.1 in order to tempt Windows Powershell users into the open-source world. The big news in version 6.1, as the open-source version of PowerShell approaches its second anniversary, is the ability to run built-in Windows …
Them and various governments.
It's no wonder people are highly suspicious of intent or future usage.
If the info collected was listed plainly and without dissembling and not collected merely to sell or harass users like cheap annoying beach salesmen, I'm sure most people would be more willing to actively opt in.
How come they can't just learn bash, perl? Why must we inject Microsoft's insane model (read: power-hell and '.Not') and way of doing things into the world of POSIX shells and scripting lingos?
This is like building your house out of glass because you like windows. Yeah bad 'pun'ishment there. Careful not to play ball games in the yard [or throw stones].
At this Point, Not Invented here has reached an almost epidemic, even in OSS, which goes to far beyond merely having available alternatives like desktops to damage advantageous unified solutions, which is why we end up with three 'distro independent' packagers (appimage, snap amd flatpack).
"2. Bash is too primitive for Windows admins" would be closer to the truth.
I've spent almost all of my career on non-Windows systems (MacOS, embedded Unix, Linux, etc) but I had to do process automation stuff in Windows in one job, and after that, I can say that PowerShell is, without doubt, the best shell programming system I've ever used for actually getting shit done quickly (and being able to understand it again six months later).
At least 20% of any Bash script seems to be spent parsing out the results of other commands using a witches' brew of sed, awk and grep, then squirting that into other commands either as arguments or input. This is lot of effort with near zero value-add, and it's famously error-prone too (and there's also the security implications of using commands like 'eval' on what is basically free-form text*).
PowerShell does away with pretty much all of that: when you put a PowerShell command into a pipe, the output isn't text, but rather structured data (imagine that it's JSON, even though it's not). You can select or format or re-package the data any way you want, and pass it on along the pipe. If, like me, you've spent any amount of time writing shell scripts, PowerShell is like stepping into the sunlight.
( * no, I woudn't either. But I've had to take it out of a lot of scripts written by people who did... )
"At least 20% of any Bash script seems to be spent parsing out the results of other commands using a witches' brew of sed, awk and grep"
If the entire script were "that" and it worked reliably, I'd give the author a beer. AND, maybe a promotion.
The alternative is to write a C language utility that does some of the more complex stuff. Usually a 1-pager that does stdin/stdout with printf and scanf etc.. Not too hard even for a junior coder right out of "pre-school" (aka CS major that just graduated from college - the REAL schooling starts with your first paid programming assignment!).
You may be confusing bash with Perl in this regard. Perl is often filled with regex stuff. It also has objects if you like those. The fact is you don't have to do it "that way" (with the "witch's brew"). But often, it's faster to write if you DO do it "that way". In fact I kinda like the "witch's brew" analogy. I think I'll start using it.
/me likes to encapsulate the "witch's brew" as functions. that way, the real code is readable and maintainable, and you can debug the "witch's brew" separately, with test data, before putting it into production. Been there, done that, should've written the book. I also use comments so others can maintain it.
added note: pre-emptively I'm going to mention using "the more secure versions" of printf/scanf when unknown input sources are involved. Someone will criticize me and narrowly focus on one tiny nitty detail like that. this is to pre-empt it. Yes, captain obvious, you DO want to keep security in mind.
Not that anyone will do anything the easy way these days, but from perlfaq8:
How can I convert my shell script to perl?
Learn Perl and rewrite it. Seriously, there's no simple converter. Things that are awkward to do in the shell are easy to do in Perl, and this very awkwardness is what would make a shell->perl converter nigh-on impossible to write. By rewriting it, you'll think about what you're really trying to do, and hopefully will escape the shell's pipeline datastream paradigm, which while convenient for some matters, causes many inefficiencies.
Personally, I find perl easier than bash due to all those weird variable and quoting conventions.
(and having learned C and perl first)
Yes, you can write insane read-only code in perl but you needn't. I've been asked what language my perl source was as it's so readable, it's a matter of discipline, another quality in very short supply.
So I guess doing things right is right out, Bob.
"2. Bash is too complicated for Windows admins."
Well it's certainly more complicated to use than Powershell, which has consistent syntax throughout, whereas with Bash it varies by command. Also with Bash you have to constantly reformat text via Grep, Sed, etc. Powershell passes data as objects which completely removes the need to worry about field formats and text filtering.
Well that's pretty obvious.
BASH doesn't support consuming .net libraries directly like PowerShell does. I suspect PERL doesn't either though it has been a very long time since I used it.
PowerShell has some very powerful processing features built in that BASH is utterly missing.
I was going to make some comments about ancient scripting languages having arcane syntax's but then I realised that PowerShell's syntax is even more arcane in places!
Well that's pretty obvious....
Yeah, because there's all this stuff that couldn't be added into the existing command line interface and run from batch files. We definitely needed a new interface and it really needed to be completely object-oriented. What will they do next? Change the OS GUI? Replace MS Office menus with something completely different that requires everyone to relearn the product from scratch? Change the OS GUI again? The mind boggles!
I like bash for quick once-off one-liners but would recommend against it for production scripts. The quoting rules are hell, see all the bash scripts which break if a path contains a space.
Suggest Python instead, it has a great abstraction of common operations across Posix and windows.
"see all the bash scripts which break if a path contains a space."
spaces in file names are *EVIL*. don't allow them on your network. and you can backslash the spaces in case you absolutely MUST allow them, like this.
/the_share/Some\ Idiot\ Put\ Spaces\ In\ The\ Name.whatever
you can make that happen with this:
sed 's/ /\\ /g'
EXISTING tools. they exist. and they still do the job, very very well. Best to learn how to use what's there and not inject some Micro-shaft NIH-agenda bloatware onto a perfectly good Linux or BSD system...
Also keep in mind - Embrace Extend Extinguish.
"BASH doesn't support consuming .net libraries directly like PowerShell does"
you say that as if it were a BAD thing... I think the 'lack of .Not support' is a GOOD thing. It means it's not internally polluted with "that architecture" in mind.
"PowerShell has some very powerful processing features built in that BASH is utterly missing"
And it's missing in Perl as well? How about (instead) writing a quicky piping filter in C, in accordance with the 'UNIX principle' of "do one thing, well". Yeah, 'too hard' for Windows admins. I believe they don't have that much of an intelligence vacuum, to be honest. But I suppose I _could_ be wrong about THAT detail...
As for Python, it's too bass-ackwards for efficient coding (much like '.Not' and C-pound). I find Python to be extremely useful for quicky things but a poor choice for anything above prototype level.
if the only thing keeping you away from bash and perl is the alleged 'arcane syntax' I prefer 'arcane' over 'bloatware inefficient' (aka ANYTHING using '.Not' in ANY fashion) **ANY** day.
In the most recent versions of Windows 10 they have either hidden (that I can't find) removed a lot of configuration that you need when anything goes wrong. I couldn't do without "powercfg -requests" every week to figure out why the fuck the computer won't go into sleep this week when it did last week. Every week is a new education. Without powershell I would be screwed with this and many other task I need to do to get the damn thing to work.
Biting the hand that feeds IT © 1998–2019