And exactly where do you see this oh so unlikely scenario playing out. What IT support staff are running Linux while everyone else is running Windows, because that would just be dumb and I would expect the manager of that IT department to be canned post haste.
In my 20 years in IT I have never seen nor heard of this situation.
Perhaps you should get out more. I know of myself and others that run either linux or MacOS as their local machine, RDP into Windows VMs for management. We also tend to be the guys who get promoted, because we don't restrict ourselves to what's considered "fashionable" to get stuff done. We learn and adapt to new options when they suit our needs. We think outside of the box that you seem to be too busy judging people from within.
Perks of this 'dumb' arrangement include:
---knowing my management tools all exist on the VM, as most of them are incompatible with my workstation. That means replacing my workstation leads to minimal downtime, I just have to install an RDP client. This also means that VM is ready for troubleshooting from remote locations, and I don't have to deal with large desktops due to multi-monitor setups, as one would when remoting to a local workstation.
---knowing that Windows key combinations won't be intercepted by the local OS.
---can test against Mac, Windows, and linux with ease.
---can use tools from all aforementioned OSs with ease.
little more than just empty bragging by a contingent of cheerleaders who were, before Powershell came on the scene, were sneering at CLIs.
You're off base. Those GUI cheerleaders are still cheering the GUI while looking forward to retirement within the next decade. They're the ones who will never install server core or nano because they can't RDP into it. I've known quite a few of them over my career, and I'm glad I don't have to work with any of them at my current employer.
Those of us who use and promote Powershell are the guys who never stopped using a cmd shell, and still dealt with ugly batch and *shudder* vb scripts until powershell arrived and gave us something worth bragging about. We never sneered at CLIs, we simply wished for something better, and now we can start using that something on linux also.
At least that's my concern. I've been in meetings with Microsoft product reps who would be very condescending towards non-Microsoft solutions even if those solutions were older, more mature, and more robust, often because the worse GUI or lack of GUI meant that you actually had to know what you were doing. It makes it easier to pander to managers that aren't as technical as they should be. This is just another tool in that toolkit.
Salesmen putting down the competition in an effort to make a sale. In other news, the sky is still blue.
This is the biggest reason to have a network or community of trusted techs/engineers with a variety of disciplines. Instead of "bad because I prefer X" you get actual usable feedback. You ask "I need something that does X" and they respond with probing questions instead of "Y or nothing". Sometimes the obvious old familiar tool with lots of history isn't the right one. Sometimes it is. Never depend on the salesman to determine if it's the right time to rip off the old bandaid.
That sound you heard was the point whoosing right past.
The point isn't possibility of emitting text.
The point is:
"This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface."
This philosophy was first written down in 1978.
And if we all blindly stuck to something because it was written a long time ago, we'd still be offering up children to stone statues on a flaming pedestal. You're free to stick to the old ways to your heart's content. Now that there's a familiar more advanced option available, I'm free to use that. Options are a good thing, even when they don't match up with the philosophy you want to constrain them to. Don't use it. Or do. Either way, others will.
To get back to the topic of this discussion - how well do you expect that to run on a Powershell running on a Linux machine?
This is day 2 of the alpha release. Even the most zealous powershell proponent would be an imbecile to expect it to work today. Although if implicit remoting is functional, that might make such a thing possible, though it *is* a workaround. I haven't updated a suitable machine to be able to install it in a linux environment yet.
The point of a shell is not to be an all-powerful programming language.
The point is to allow to simply (with minimal changes to what you have done manually before) automate low-complexity tasks, with minimal extra complexity, in a hands-on way with high visibility into the steps.
Missing the difference between a shell and a programming language is essentially what Powershell embodies - even though there is no doubt that quite a few people on the Linux side have mistaken bash for a programming language.
And *WHY* must they continue to be different or separate? "Because history" isn't a good enough reason. Having one language that's capable of handling simple (shell) and complex (programming) automation tasks isn't a mistake, it's sanity.
And the focus on objects means there is still a lack of good tools to manipulate text.
Ignorance of the tools doesn't mean they don't exist, and 'good' is a subjective term. Based on your logic thus far, I doubt your definition of 'good' will pass with everyone outside of the "MS is evil" club.:P
Plus the Java-style verbosity, leading then to the need for aliases (usually with names that have no connection at all to the long name). Yay for having to learn every command twice, once in long and once in short form.
You don't need to use aliases, you just need to press tab. Autocomplete/intellisense in powershell works not only for the command names, but the parameters and frequently the inputs as well.
Also, complaining about verbosity is sad. It like you're trying to uphold the old greybeard mentality of job security by means of "no-one else knows how to do what I'm doing", or a poor-man's version of closed source by means of unreadable code. Verbosity makes code readable, not just the day you're writing it, but months or years later when you need to fix or update it. In powershell you have the best of both worlds with conciseness through tab-completion AND verbosity. If you compared actual keyboard strokes (instead of characters displayed) between powershell and bash, you might be surprised to find them very comparable.
No, it shows that you need to use the right tool for the job.
...
And yes, I'm aware that you can use debuggers with PS, but then I have to load a debugger - which means yet another tool has to be installed and run - more memory required to figure out what is going wrong.
You claim that loading different tools for different tasks is fine, but draw the line when that tool is a debugger? o.O
I can Get-Help -examples to skip directly to syntax examples, and I'm moved on to the next step before I've gotten half-way through a man [page]...
OK, let's try: "man awk" in man browser window (less) type "/examples" and there they are...
Yes, clearly inferior, slower and much more inelegant...
Thank you for making my point, YES, you can/examples IN a "man awk".
Now try that in "man ls" or "man grep" or a "man alias" or "man set". These are bare-bones core linux commands, and the help is inconsistent, and therefore inelegant and yes, frustrating. Yet try any of the core powershell cmdlets with "get-help -examples". CONSISTENCY. Heck, try typing "man for". Here I'll save you: "No manual entry for for". Now powershell: "Get-Help for" returns a list of possible matches. I can "get-help foreach", or get-help "about_for" which goes deeper on the for keyword.
You can pick at powershell for many things, but it's help implementation soundly thrashes "man". It's not even a contest.
But, as we are constantly informed by Powershell advocates, Windows is object oriented, so bash won't work on Windows. And yet, apparently, text-oriented *nix will be administered by Powershell? Methinks maybe Windows object nature has been somewhat oversold to justify why Powershell ended up so different than the most used shell scripting language family ever developed.
I think you're oversimplifying things. Making object oriented constructs output text is much easier then making text oriented constructs output objects. Also, comparing it as "the most used shell scripting language family ever developed" to an alpha product just released today is a bit much. After all, today IS the first time they can run in the same environment. Lets see where things are in 5-10 years. "Different" isn't always a bad thing, and perhaps after some time has passed, you'll be complaining about how Google's new terminal doesn't do things like powershell.
Yes I know that's quite a reach, but if it happens, I'll try to be awake to poke you over it:P
So really it is security theater, with a dose of security through obscurity.
At the end of the day, the only thing that actually protects any environment are the low-level permissions systems. Signing scripts is just a false sense of security at best, and a general pain in the ass otherwise.
That's because everyone here knows that grep stands for something like 'general regular expression parser' or some such.
WTF does 'sls' stand for, and is its primary purpose to do a regexp search through files and/or character streams?
This argument brought to you by that employee you know will be canned in 6 months because he believes learning something new is a waste of time. You all know him....or knew him:P
No, I'm asking how is cutting off a path of a file (as an example of the kind of shortened output Powershell commands can produce) informative? And yes, I know it's fairly easy to overcome, but it just strikes me that this is the kind of GUI-centric thinking (this kind of output is straight out of a Listview object) that infects Powershell.
Ah, I misunderstood the thrust of your response.
If I'm understanding you correctly now, resizing the window to be wider will cause the path length to be extended. It typically only cuts it off when the data is too long to be displayed on the screen and the default formatting is in a table view. I'm admittedly guessing that it's the fullname property alongside some other properties in a table format that is causing this, do you have an example that produces this output? Get-ChildItem is the first that comes to mind, but it doesn't output like that by default.
If Joe Newbie doesn't have some level of Administrator privileges (in particular the domain and enterprise level admin group membership) these vile organization-crushing powershell scripts couldn't do it at all. Citing the possibility of an inexperienced admin is an issue, but is it the policy in your organization not to allow the running of Powershell scripts until they've proven themselves, and if that is the case, then how is that any different than not giving elevated (i.e. sudo) privileges to *nix IT staff until they've demonstrated some ability with it.
That's my point, really. *nix security doesn't work because only really experienced people use it. That wouldn't be security at all. It works because unless you're able to gain elevated permissions, you're pretty much screwed (with the caveat about exploits, which Windows has as well). In that case, if you just enable shell usage for all your staff, and if Joe Newbie writes a Powershell script that deletes all users in an Active Directory Organizational Unit, unless he's got modify or admin privileges for that OU, he's shit out of luck. And if you're worried about Powershell being the problem, and leave Powershell disabled, or only allow signed scripts to be run, well, Mr. Newbie, presuming he does have some level of management permissions over that OU, can still go into Active Directorys Users and Computers and delete the users via the GUI.
In other words, the whole disabled or signed only Powershell script system is really just security theater. It really does very little to secure a system.
Perhaps you're thinking script signing is meant to protect the system from being exploited. That's not how I view it at all and if I did, I'd agree with you in it being "security theater". There are ways around the execution policy if you do your research, but this level of complexity is where the user typically loses interest and gets back to their assigned job.
I view code signing as a restraining wall to prevent the user from hurting *their self*. It take multi-line scripts which they are likely not capable of understanding, and prevents them from *easily* executing them, and potentially deleting or changing anything or everything they have access to.
As for the rookie admin, yes, he can delete a user or an OU, but with scripts he may be capable of affecting an organization-wide change that is difficult to detect until problems arise days later, which may then be difficult to revert without a large loss of work. As well, with the GUI, the rookie is more likely to *understand* the scope of the change he's making as he can more easily picture the structure. This is less likely the case with a script, until he has a clear understanding of what he's working with.
Responding to a complaint about a strawman agrument by constructing yet ANOTHER argument out of straw? "having an open mind and a balanced view is a crime"? WTF? Who said this? [citation needed]
You have zero self-awareness, don't you?
Hello pot, this is the kettle speaking. That quote you made was my statement, not a citation. It was addressing your aggression over what you believed to be a strawman argument. Whether you are ignorant of the past, or refuse to acknowledge it, it doesn't change the fact that he pointed out a long running complaint of the linux community. He's bringing it up now to point out the hypocrisy in those who simply state "M$ Evil" or "EEE". It's argument is relevant because it points out that the claimed reasons don't matter, Microsoft is evil in their minds.
Or perhaps you are confused what a strawman argument is. OP went directly to the root of the debate, and addressed it there. You call it "ridiculous", but it's a statement that was thundered by the linux faithful all the way back to when Microsoft was in it's heyday. Care to take another swing, or does trolling lose it's luster when it requires your brain?
But with bash you can just start typing text. No need to look up obscure command system and object names if they only thing you want to do is get a list of all files matching a pattern. There's no text wrangling, you just start typing commands. And the same syntax you use for giving commands is used if you want a complicated script.
The difference is that Unix is oriented around commands and programs that take input and give output; whereas Windows is oriented around DLLs and frameworks that build on top of DLLs.
So dealing with those DLLs from a scripting language is very powerful, but those are inherently complex operations. The learning curve is like a brick wall. Unix builds on combining very simple operations into more complex results. If you only use powershell twice a year you'll forever be stumped and lost, but if you use bash only twice a year you'll still be able to get stuff done.
As someone who uses bash twice a month (red hat and ubuntu), finding some of the commands, or the correct syntax/switches frequently tends to be a frustrating experience. The man pages are occasionally helpful, but they're just as often a novel on something that's inapplicable, and missing the data I really need. That means a trip to google, and ending up on a blog page.
When I compare that to the documentation in powershell, man seems like an empty water bottle, and powershell's Get-Help is a river. I can Get-Help -examples to skip directly to syntax examples, and I'm moved on to the next step before I've gotten half-way through a man document that *may* or may-not help me. Also, the naming of commands in powershell is *predictable* which is a *huge* help. Get-Command Get-* will return all the available commands for retrieving information, and Set- * for setting whichever. You can typically *guess* what a command does, just by looking at it. How frequently can you say the same for linux?
Learning *either* can be like a brick wall, depending on what that person has already learned, but I see powershell's documentation and the obviousness of it's command names lends itself to faster learning, including among a couple of linux admins I taught a little powershell to. They still prefer the bash terminal, but I see the fluency of their powershell scripts jumping when they use it every few months.
That is concise. However, no one knows about it. Part of the problem with PS is that the commands and syntax have changed radically through the versions. The difference between PS 1.0 and 4.0 is significant. I think a lot of us are waiting for it to stabilize before diving in (again).
The biggest differences are between versions 2 and 3. Version 3 added in a ton of quality of life fixes that help prevent hair-loss. With the release of Version 3, the syntax is functionally stable, and while there may be some QOL fixes since, the V3 ways still work the same.
The cmdlets themselves may have been extended (additional parameters) but they've been stable as well. The only major catch you might see is the lack of some newer generation cmdlets on older windows OS. Win7, Win8, and Win10, each OS adds additional cmdlets that the predecessor do not have, so if you have to support older generation OSs, you have to write your scripts down to that level.
Also, if you are using the built in PowerShell ISE to write your script, all of the available cmdlets are auto-completed.
Not to mention the parameter names. And frequently other things as well. Intellisense in the powershell ISE has been one of the most personally enjoyable parts about scripting in powershell for me. When in doubt, hit tab. Repeat until you find what you're looking for.
Security shouldn't be attached to the running of the scripts, but rather what it is that the scripts actually do.
Powershell has both. I like both. Why shouldn't it be both?
Since Windows has that level of protection out of the box, having to enable scripts just to run is little more than some rather silly security theater.
Having to enable unsigned scripts to run in an environment that a user or rookie admin has direct access to is a rather insightful move. Complaining about a Windows having security feature when the linux faithful typically like to bash on what they perceive as windows security is laughable. Besides, if you have admin on the box, and know access to that box is restricted to competent admins, disabling that feature is a one-liner.
Just because it makes sense to allow scripts out of the box on linux, doesn't mean it makes sense to do the same on Windows. It's not an issue of native support, it's a question of "do we trust the guy who has physical access to the machine?" Linux is frequently locked in a datacenter and/or used by a competent (I hope) admin , Windows is commonly sitting on a desk out in the open and used by Joe Newbie, the new hotshot sales guy who claims he knows everything about computers, but is quite capable of unwittingly formatting his own hard drive from the command line. This was a conscious design decision with an accessible off-switch and it makes a lot of sense in particular use cases, just apparently not *yours*.
agreed. Coming from Solaris to Windows, I find it horrid, just horrid. Some days, I would give my server for a workable "grep".
pipe to: where {$_.property -match "regex"}
Powershell has had a workable grep for a long time, but it's usually learning how objects work that typically obstruct new users.
Wow, that's elegant.
Fair enough, the sls 'regex' files mentioned by spongman is probably more your speed. I prefer the where statements because they're much more flexible and not restricted to regex, but that's simply a matter of preference.
I don't want the results filtered even on stdio to a command window. Yes I know they're not filtered if redirected to some other stream, but the fact that it filters it for the command prompt is absurd, and often renders the output useless unless you throw in the flag.
Sometimes what we need is just a quick glance at the status, and that's what that "absurd" filtered view provides, a glance. Often times that glance is good enough, and I'm glad I didn't get 15 pages of scroll for 10 items. It's one of the compromises of a shell that's also a scripting language. Also, doesn't "ps" on linux do the same thing? You have to throw on additional switches if you want to see ALL the processes or ALL the fields.
How is "c:\somedir\someotherdir\importantf..." useful?
If you don't get how all that data is useful, you've never needed it. Congrats, you've got it easy. For the rest of us, that amount of data in invaluable, because we can easily filter down to what we need.
And the fact that everything is an object is not very helpful unless there is consistent polymorphism and iterability.
As to easily extend the shell, you might have heard something like this:
"This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface."
This philosophy was first written down in 1978. Good of Microsoft to finally start catching up to it. Too bad they think it's better done with proprietary object interfaces than with plain text, but maybe the next iteration will get there.
The ConvertFrom- and ConvertTo- cmdlet sets allow you to deal with a variety of text level interfaces. I'll be the first to admit they DO need to work on their XML handling, but otherwise Powershell is quite capable of speaking text when needed.
Slashdot Mirror
And exactly where do you see this oh so unlikely scenario playing out. What IT support staff are running Linux while everyone else is running Windows, because that would just be dumb and I would expect the manager of that IT department to be canned post haste. In my 20 years in IT I have never seen nor heard of this situation.
Perhaps you should get out more. I know of myself and others that run either linux or MacOS as their local machine, RDP into Windows VMs for management. We also tend to be the guys who get promoted, because we don't restrict ourselves to what's considered "fashionable" to get stuff done. We learn and adapt to new options when they suit our needs. We think outside of the box that you seem to be too busy judging people from within.
Perks of this 'dumb' arrangement include:
---knowing my management tools all exist on the VM, as most of them are incompatible with my workstation. That means replacing my workstation leads to minimal downtime, I just have to install an RDP client. This also means that VM is ready for troubleshooting from remote locations, and I don't have to deal with large desktops due to multi-monitor setups, as one would when remoting to a local workstation.
---knowing that Windows key combinations won't be intercepted by the local OS.
---can test against Mac, Windows, and linux with ease.
---can use tools from all aforementioned OSs with ease.
little more than just empty bragging by a contingent of cheerleaders who were, before Powershell came on the scene, were sneering at CLIs.
You're off base. Those GUI cheerleaders are still cheering the GUI while looking forward to retirement within the next decade. They're the ones who will never install server core or nano because they can't RDP into it. I've known quite a few of them over my career, and I'm glad I don't have to work with any of them at my current employer.
Those of us who use and promote Powershell are the guys who never stopped using a cmd shell, and still dealt with ugly batch and *shudder* vb scripts until powershell arrived and gave us something worth bragging about. We never sneered at CLIs, we simply wished for something better, and now we can start using that something on linux also.
At least that's my concern. I've been in meetings with Microsoft product reps who would be very condescending towards non-Microsoft solutions even if those solutions were older, more mature, and more robust, often because the worse GUI or lack of GUI meant that you actually had to know what you were doing. It makes it easier to pander to managers that aren't as technical as they should be. This is just another tool in that toolkit.
Salesmen putting down the competition in an effort to make a sale. In other news, the sky is still blue.
This is the biggest reason to have a network or community of trusted techs/engineers with a variety of disciplines. Instead of "bad because I prefer X" you get actual usable feedback. You ask "I need something that does X" and they respond with probing questions instead of "Y or nothing". Sometimes the obvious old familiar tool with lots of history isn't the right one. Sometimes it is. Never depend on the salesman to determine if it's the right time to rip off the old bandaid.
That sound you heard was the point whoosing right past.
The point isn't possibility of emitting text.
The point is:
"This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface."
This philosophy was first written down in 1978.
And if we all blindly stuck to something because it was written a long time ago, we'd still be offering up children to stone statues on a flaming pedestal. You're free to stick to the old ways to your heart's content. Now that there's a familiar more advanced option available, I'm free to use that. Options are a good thing, even when they don't match up with the philosophy you want to constrain them to. Don't use it. Or do. Either way, others will.
To get back to the topic of this discussion - how well do you expect that to run on a Powershell running on a Linux machine?
This is day 2 of the alpha release. Even the most zealous powershell proponent would be an imbecile to expect it to work today. Although if implicit remoting is functional, that might make such a thing possible, though it *is* a workaround. I haven't updated a suitable machine to be able to install it in a linux environment yet.
$lastSetdate = [DateTime]::Now - [TimeSpan]::Parse("90")
Or my favorite: $lastSetDate = (Get-Date).addDays(-90)
Love that between Powershell and DotNet, we have multiple powerful options to accomplish tasks.
The point of a shell is not to be an all-powerful programming language. The point is to allow to simply (with minimal changes to what you have done manually before) automate low-complexity tasks, with minimal extra complexity, in a hands-on way with high visibility into the steps. Missing the difference between a shell and a programming language is essentially what Powershell embodies - even though there is no doubt that quite a few people on the Linux side have mistaken bash for a programming language.
And *WHY* must they continue to be different or separate? "Because history" isn't a good enough reason. Having one language that's capable of handling simple (shell) and complex (programming) automation tasks isn't a mistake, it's sanity.
And the focus on objects means there is still a lack of good tools to manipulate text.
Ignorance of the tools doesn't mean they don't exist, and 'good' is a subjective term. Based on your logic thus far, I doubt your definition of 'good' will pass with everyone outside of the "MS is evil" club. :P
Plus the Java-style verbosity, leading then to the need for aliases (usually with names that have no connection at all to the long name). Yay for having to learn every command twice, once in long and once in short form.
You don't need to use aliases, you just need to press tab. Autocomplete/intellisense in powershell works not only for the command names, but the parameters and frequently the inputs as well.
Also, complaining about verbosity is sad. It like you're trying to uphold the old greybeard mentality of job security by means of "no-one else knows how to do what I'm doing", or a poor-man's version of closed source by means of unreadable code. Verbosity makes code readable, not just the day you're writing it, but months or years later when you need to fix or update it. In powershell you have the best of both worlds with conciseness through tab-completion AND verbosity. If you compared actual keyboard strokes (instead of characters displayed) between powershell and bash, you might be surprised to find them very comparable.
No, it shows that you need to use the right tool for the job.
And yes, I'm aware that you can use debuggers with PS, but then I have to load a debugger - which means yet another tool has to be installed and run - more memory required to figure out what is going wrong.
You claim that loading different tools for different tasks is fine, but draw the line when that tool is a debugger? o.O
I can Get-Help -examples to skip directly to syntax examples, and I'm moved on to the next step before I've gotten half-way through a man [page]...
OK, let's try: "man awk" in man browser window (less) type "/examples" and there they are...
Yes, clearly inferior, slower and much more inelegant...
Thank you for making my point, YES, you can /examples IN a "man awk".
Now try that in "man ls" or "man grep" or a "man alias" or "man set". These are bare-bones core linux commands, and the help is inconsistent, and therefore inelegant and yes, frustrating. Yet try any of the core powershell cmdlets with "get-help -examples". CONSISTENCY. Heck, try typing "man for". Here I'll save you: "No manual entry for for". Now powershell: "Get-Help for" returns a list of possible matches. I can "get-help foreach", or get-help "about_for" which goes deeper on the for keyword.
You can pick at powershell for many things, but it's help implementation soundly thrashes "man". It's not even a contest.
But, as we are constantly informed by Powershell advocates, Windows is object oriented, so bash won't work on Windows. And yet, apparently, text-oriented *nix will be administered by Powershell? Methinks maybe Windows object nature has been somewhat oversold to justify why Powershell ended up so different than the most used shell scripting language family ever developed.
I think you're oversimplifying things. Making object oriented constructs output text is much easier then making text oriented constructs output objects. Also, comparing it as "the most used shell scripting language family ever developed" to an alpha product just released today is a bit much. After all, today IS the first time they can run in the same environment. Lets see where things are in 5-10 years. "Different" isn't always a bad thing, and perhaps after some time has passed, you'll be complaining about how Google's new terminal doesn't do things like powershell.
:P
Yes I know that's quite a reach, but if it happens, I'll try to be awake to poke you over it
So really it is security theater, with a dose of security through obscurity.
At the end of the day, the only thing that actually protects any environment are the low-level permissions systems. Signing scripts is just a false sense of security at best, and a general pain in the ass otherwise.
That's your view, and you're entitled to it.
That's because everyone here knows that grep stands for something like 'general regular expression parser' or some such.
WTF does 'sls' stand for, and is its primary purpose to do a regexp search through files and/or character streams?
This argument brought to you by that employee you know will be canned in 6 months because he believes learning something new is a waste of time. You all know him....or knew him :P
No, I'm asking how is cutting off a path of a file (as an example of the kind of shortened output Powershell commands can produce) informative? And yes, I know it's fairly easy to overcome, but it just strikes me that this is the kind of GUI-centric thinking (this kind of output is straight out of a Listview object) that infects Powershell.
Ah, I misunderstood the thrust of your response.
If I'm understanding you correctly now, resizing the window to be wider will cause the path length to be extended. It typically only cuts it off when the data is too long to be displayed on the screen and the default formatting is in a table view. I'm admittedly guessing that it's the fullname property alongside some other properties in a table format that is causing this, do you have an example that produces this output? Get-ChildItem is the first that comes to mind, but it doesn't output like that by default.
If Joe Newbie doesn't have some level of Administrator privileges (in particular the domain and enterprise level admin group membership) these vile organization-crushing powershell scripts couldn't do it at all. Citing the possibility of an inexperienced admin is an issue, but is it the policy in your organization not to allow the running of Powershell scripts until they've proven themselves, and if that is the case, then how is that any different than not giving elevated (i.e. sudo) privileges to *nix IT staff until they've demonstrated some ability with it.
That's my point, really. *nix security doesn't work because only really experienced people use it. That wouldn't be security at all. It works because unless you're able to gain elevated permissions, you're pretty much screwed (with the caveat about exploits, which Windows has as well). In that case, if you just enable shell usage for all your staff, and if Joe Newbie writes a Powershell script that deletes all users in an Active Directory Organizational Unit, unless he's got modify or admin privileges for that OU, he's shit out of luck. And if you're worried about Powershell being the problem, and leave Powershell disabled, or only allow signed scripts to be run, well, Mr. Newbie, presuming he does have some level of management permissions over that OU, can still go into Active Directorys Users and Computers and delete the users via the GUI.
In other words, the whole disabled or signed only Powershell script system is really just security theater. It really does very little to secure a system.
Perhaps you're thinking script signing is meant to protect the system from being exploited. That's not how I view it at all and if I did, I'd agree with you in it being "security theater". There are ways around the execution policy if you do your research, but this level of complexity is where the user typically loses interest and gets back to their assigned job.
I view code signing as a restraining wall to prevent the user from hurting *their self*. It take multi-line scripts which they are likely not capable of understanding, and prevents them from *easily* executing them, and potentially deleting or changing anything or everything they have access to.
As for the rookie admin, yes, he can delete a user or an OU, but with scripts he may be capable of affecting an organization-wide change that is difficult to detect until problems arise days later, which may then be difficult to revert without a large loss of work. As well, with the GUI, the rookie is more likely to *understand* the scope of the change he's making as he can more easily picture the structure. This is less likely the case with a script, until he has a clear understanding of what he's working with.
Yes, on Internet Explorer.
You actually made a comment that I can almost agree with. Color me shocked! :D
Responding to a complaint about a strawman agrument by constructing yet ANOTHER argument out of straw? "having an open mind and a balanced view is a crime"? WTF? Who said this? [citation needed]
You have zero self-awareness, don't you?
Hello pot, this is the kettle speaking. That quote you made was my statement, not a citation. It was addressing your aggression over what you believed to be a strawman argument. Whether you are ignorant of the past, or refuse to acknowledge it, it doesn't change the fact that he pointed out a long running complaint of the linux community. He's bringing it up now to point out the hypocrisy in those who simply state "M$ Evil" or "EEE". It's argument is relevant because it points out that the claimed reasons don't matter, Microsoft is evil in their minds.
Or perhaps you are confused what a strawman argument is. OP went directly to the root of the debate, and addressed it there. You call it "ridiculous", but it's a statement that was thundered by the linux faithful all the way back to when Microsoft was in it's heyday. Care to take another swing, or does trolling lose it's luster when it requires your brain?
But with bash you can just start typing text. No need to look up obscure command system and object names if they only thing you want to do is get a list of all files matching a pattern. There's no text wrangling, you just start typing commands. And the same syntax you use for giving commands is used if you want a complicated script.
The difference is that Unix is oriented around commands and programs that take input and give output; whereas Windows is oriented around DLLs and frameworks that build on top of DLLs.
So dealing with those DLLs from a scripting language is very powerful, but those are inherently complex operations. The learning curve is like a brick wall. Unix builds on combining very simple operations into more complex results. If you only use powershell twice a year you'll forever be stumped and lost, but if you use bash only twice a year you'll still be able to get stuff done.
As someone who uses bash twice a month (red hat and ubuntu), finding some of the commands, or the correct syntax/switches frequently tends to be a frustrating experience. The man pages are occasionally helpful, but they're just as often a novel on something that's inapplicable, and missing the data I really need. That means a trip to google, and ending up on a blog page.
When I compare that to the documentation in powershell, man seems like an empty water bottle, and powershell's Get-Help is a river. I can Get-Help -examples to skip directly to syntax examples, and I'm moved on to the next step before I've gotten half-way through a man document that *may* or may-not help me. Also, the naming of commands in powershell is *predictable* which is a *huge* help. Get-Command Get-* will return all the available commands for retrieving information, and Set- * for setting whichever.
You can typically *guess* what a command does, just by looking at it. How frequently can you say the same for linux?
Learning *either* can be like a brick wall, depending on what that person has already learned, but I see powershell's documentation and the obviousness of it's command names lends itself to faster learning, including among a couple of linux admins I taught a little powershell to. They still prefer the bash terminal, but I see the fluency of their powershell scripts jumping when they use it every few months.
No lolololololol posts stating how asinine the syntax is in PowerShell... oh... because it is actually a shorter command line than grep....
No lol+, sorry. But if that extra char in grep vs. sls is really that important for you, try adding
alias g=grep
to your .bashrc or equivalent, for maximal char savings.
I did...in powershell :P
That is concise. However, no one knows about it. Part of the problem with PS is that the commands and syntax have changed radically through the versions. The difference between PS 1.0 and 4.0 is significant. I think a lot of us are waiting for it to stabilize before diving in (again).
The biggest differences are between versions 2 and 3. Version 3 added in a ton of quality of life fixes that help prevent hair-loss. With the release of Version 3, the syntax is functionally stable, and while there may be some QOL fixes since, the V3 ways still work the same.
The cmdlets themselves may have been extended (additional parameters) but they've been stable as well. The only major catch you might see is the lack of some newer generation cmdlets on older windows OS. Win7, Win8, and Win10, each OS adds additional cmdlets that the predecessor do not have, so if you have to support older generation OSs, you have to write your scripts down to that level.
Really-long-command-options-because-I-enjoy-typing-a-lot.
Also, if you are using the built in PowerShell ISE to write your script, all of the available cmdlets are auto-completed.
Not to mention the parameter names. And frequently other things as well. Intellisense in the powershell ISE has been one of the most personally enjoyable parts about scripting in powershell for me. When in doubt, hit tab. Repeat until you find what you're looking for.
Security shouldn't be attached to the running of the scripts, but rather what it is that the scripts actually do.
Powershell has both. I like both. Why shouldn't it be both?
Since Windows has that level of protection out of the box, having to enable scripts just to run is little more than some rather silly security theater.
Having to enable unsigned scripts to run in an environment that a user or rookie admin has direct access to is a rather insightful move. Complaining about a Windows having security feature when the linux faithful typically like to bash on what they perceive as windows security is laughable. Besides, if you have admin on the box, and know access to that box is restricted to competent admins, disabling that feature is a one-liner.
Just because it makes sense to allow scripts out of the box on linux, doesn't mean it makes sense to do the same on Windows. It's not an issue of native support, it's a question of "do we trust the guy who has physical access to the machine?" Linux is frequently locked in a datacenter and/or used by a competent (I hope) admin , Windows is commonly sitting on a desk out in the open and used by Joe Newbie, the new hotshot sales guy who claims he knows everything about computers, but is quite capable of unwittingly formatting his own hard drive from the command line. This was a conscious design decision with an accessible off-switch and it makes a lot of sense in particular use cases, just apparently not *yours*.
LOLOLOLOL who did it first though? Who copied who? Ok then stfu. It's 1 char shorter.
In code/scripting golf, it's not who finishes first, it's who comes in with the lowest score.
agreed. Coming from Solaris to Windows, I find it horrid, just horrid. Some days, I would give my server for a workable "grep".
pipe to: where {$_.property -match "regex"}
Powershell has had a workable grep for a long time, but it's usually learning how objects work that typically obstruct new users.
Wow, that's elegant.
Fair enough, the sls 'regex' files mentioned by spongman is probably more your speed. I prefer the where statements because they're much more flexible and not restricted to regex, but that's simply a matter of preference.
I don't want the results filtered even on stdio to a command window. Yes I know they're not filtered if redirected to some other stream, but the fact that it filters it for the command prompt is absurd, and often renders the output useless unless you throw in the flag.
Sometimes what we need is just a quick glance at the status, and that's what that "absurd" filtered view provides, a glance. Often times that glance is good enough, and I'm glad I didn't get 15 pages of scroll for 10 items. It's one of the compromises of a shell that's also a scripting language. Also, doesn't "ps" on linux do the same thing? You have to throw on additional switches if you want to see ALL the processes or ALL the fields.
How is "c:\somedir\someotherdir\importantf..." useful?
If you don't get how all that data is useful, you've never needed it. Congrats, you've got it easy. For the rest of us, that amount of data in invaluable, because we can easily filter down to what we need.
"Parsing"? What other tools have you been using?
And the fact that everything is an object is not very helpful unless there is consistent polymorphism and iterability.
As to easily extend the shell, you might have heard something like this:
"This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface."
This philosophy was first written down in 1978. Good of Microsoft to finally start catching up to it. Too bad they think it's better done with proprietary object interfaces than with plain text, but maybe the next iteration will get there.
The ConvertFrom- and ConvertTo- cmdlet sets allow you to deal with a variety of text level interfaces. I'll be the first to admit they DO need to work on their XML handling, but otherwise Powershell is quite capable of speaking text when needed.