No thankyou. I can certainly understand including SSH support, but I don't want what is pretty much the only remaining viable non-Unix platform to start bundling horribly dated and clunky Unix-like commands and bloated GNU tools.
As a die hard Unix guy and ex Slashdot-esque zealot (colloquially a bit of a twat). Yet I'm knocking out PowerShell all the time now and dread having to log into the pile of CentOS kit I have lying around. It is arcane. Even after 15 years I spend most of my time in the manpages or working out another damn config format.
Literally did a two liner to scrape a web page, parse it and call a REST endpoint with the parsed data as JSON in PowerShell. I cant even use python now. I've been broken.
It makes me cringe saying all this as well kind of like a racist making amends with his past.
The only thing I still hate is windows update.
I understand that lots of people are familiar with Unix-like tools and their many idiosyncrasies and like to be able to transfer that knowledge across platforms. But that doesn't mean there isn't merit to a platform not conforming to that and trying to improve on it.
Or I guess another way to say it is that "bloated" is only a measurement of the speaker's disdain for the software under question. It has little relationship with any actual quality measurement, generally. Bizarre on its face, to me.
Bloat seems like dirt that accumulates overtime. A little bit of cleanup and optimization can sometimes do magic.
Microsoft chose one answer to that, Apple another.
I think Windows Phone is a clear example that Microsoft has technical chops when starting clean, it just lacks business willpower to make decisions that favor performance over support.
all those "2 liners" don't mean much if you have to reboot your box every 2 days to apply more emergency 0-day security patches.
Only ones that affect the network surface footprint, so none here as it's on a private VLAN.
I assume that "private VLAN" means it isn't exposed to potential external attack.
Patching servers is just good practice. As is designing a system that can handle rebooting individual servers without user-facing downtime.
b) They won't download anything wrong. There's no route to the internet for this machine.
c) They won't visit any web sites. There's no browser on the machine. This is a core profile windows server installation.
Don't assume that we don't know what we're doing. We have 500ish Windows Server machines floating around.
It's good that you've managed to perfect the hiring process to the point you have zero risk of internal fraud or malice.
Nowhere!
What does that have to do with security updates and reboots?
Nothing!
This is a Hyper-V hypervisor host on a private VLAN three layers behind the internet and two layers behind the users locked in a room with no console access other than via an ILO card on yet another VLAN.
There has only been one KB which infers a security problem and that has had alternative mitigation put in place.
Not rebooting your server doesn't imply incompetence or disregard to security.
This sounds cool. Can you recommend terse resources for getting to know PowerShell? Is MSDN the best place to look for docs or are there better places to go?
http://social.technet.microsoft.com/wiki/contents/articles/1...
Scrape a page:
$flight = " LH3396"
$url = "http://bing.com?q=flight status for $flight"
$result = Invoke-WebRequest $url
$elements = $result.AllElements | Where Class -eq "ans" | Select -First 1 -ExpandProperty innerText
$body = @{
Name = "So long and thanks for all the fish"
}
Invoke-RestMethod -Method Post -Uri "$resource\new" -Body (ConvertTo-Json $body) -Header @{"X-ApiKey"=$apiKey}
[1] http://stackoverflow.com/questions/9053573/powershell-html-p...
[2] http://www.lavinski.me/calling-a-rest-json-api-with-powershe...
This lets everything implicitly understand how to access named properties without everyone having to do string parsing.
Sure, you can solve the same problems with bash/grep/awk/sed/etc - but sometimes it's a bunch simpler to solve in Powershell.
PowerShell handles objects like Unix utilities handle text. You get a lot more orthogonality in commands, e.g. there's just a few commands dealing with JSON, CSV, XML, etc.¹ – they mostly do just the conversion of a specific text-based format to an object list or tree representation and back. Everything else after that can be done with just the same set of core commands which deal with objects. Filtering, projecting, and iterating over object sequences is probably the most common part of PowerShell scripts and one-liners and it's a part that's useful everywhere you need the language. Note that we have a bit of that in the samples here, too. ConvertTo-JSON is used to convert a hashmap to a JSON string to use in a request, and Invoke-WebRequest already handles parsing HTML for us so the following line can just filter elements by certain attributes.
Where the ideal format for the core Unix tools you use most frequently, is free-form text, you often have special commands that work on other formats by replicating a few core tools' features on that format, e.g. a grep for JSON, a grep for XML, etc. There are others, of course, that do the conversion in a way that's friendly to text-based tools, but the representation still lacks fidelity. Finding XML elements with certain attributes quickly becomes an exercise in how to write robust regexes. Cutting up CSV by column numbers is a frequent occurrence – and since the tools do not understand the format it makes for not a pretty read in the script's code. Personal opinion here, based on lots of PowerShell written, some shell scripts written, lots of horrible things read in either (sure, awful PowerShell scripts do exist, but I'd argue that discovering a nice way is much easier where you can cut most of the ad-hoc parsers written in regex or string manipulation in pipelines).
(One last point about orthogonality of commands: ls has a few options on how to sort or output the results, for example. Sorting a list of things? That's Sort-Object's domain. Formatting a list of things? Format-Table, Format-Wide, Format-List. That's quite a bit less each individual command has to do and it's all just for nicety to the user. For working with the output programmatically you don't (well, and can't) need them at all.)
I have a few posts on SO where I tried to steer people into actually learning how the language works and that you should use the pipeline as much as possible, e.g. http://stackoverflow.com/a/7394766/73070 or http://stackoverflow.com/a/3104721/73070. That's not to say you can't write un-understandable things: http://stackoverflow.com/q/1018873/73070.
And finally, let's not forget that PowerShell exists on Windows where text-based tools are mostly useless. Want to query the event log? The registry? WMI? Good luck. Windows has a long history of having non-text formats everywhere in the system and for administration it's a bit hard to pretend they don't exist. Jeffrey Snover elaborates a bit on that here: http://stackoverflow.com/a/573861/73070.
There may be a lot of developers getting by with Unix tools on Windows, but they're not the target audience for PowerShell³. And the previous approach to scripting things on Windows servers and domains was either batch files or VBScript/JScript.
This ... uhm, got longer than anticipated and probably a lot less coherent than planned. Apologies for anything that makes no sense. I didn't have caffeine yet.
______
¹ ConvertFrom-JSON and ConvertTo-JSON for JSON for example. For CSV there are also convenience commands that directly work on files as well, so there's four of them. XML processing is built-in since .NET can do that easily already.
² I probably don't get to live the rest of the day now, I guess.
³ I am a developer, though, who uses PowerShell daily for scripting, as a shell, and a .NET playground. The PowerShell team at MS was a bit surprised once when I told them that my background was not server administration (the Scripting Games were quite focused on that part and often involved doing things with WMI or AD – stuff I rarely, if ever, do.)
Just incited me to have a little look at powershell (read through [0], useful intro). It looks nice, I can definitely see the utility in have a simple object model for transferring information between processes. In nix land you get pretty good at extracting data from simple text forms, though sometimes it's harder than it should be.
One thing that jumped out at me there is the overhead of the commands.
430ms: ls | where {$_.Name -like "*.exe"}
140ms: ls *.exe
27ms : ls -Filter "*.exe".
What happens when you add another command to the pipeline? Do they buffer the streams like in linux?
I guess the situation will improve over time but how complete is the eco-system at the moment? One area nixes will always shine is the total ubiquity. Everything can be done over commands and everything works with text.
[0] https://developer.rackspace.com/blog/powershell-101-from-a-l...
It's not uncommon for the most flexible option to be the slowest, though. In my own tests my results were 18 ms, 115 ms and 140 ms for doing those commands in $Env:Windir\system32, so the difference wasn't as big as in your case. For a quick command on the command line I feel performance is adequate in either case, unless you're doing things with very large directories. If you handle a large volume of data, regardless of whether it's files, lines, or other objects, you probably want to filter as much as you can as close to the source as you can – generally speaking.
As for buffering ... I'm not aware of, unless the cmdlet needs to have complete output of the previous one to do its work. Every result from a pipeline is passed individually from one cmdlet to the next by default. Some cmdlets do* buffer, though, e.g. Get-Content has a -ReadCount parameter that controls buffering in the cmdlet (man gc -param readcount). Sort-Object and Group-Object are the most common (for me at least) that always need complete output of the stage before to return anything, for quite obvious reasons.
However, even though I did some work on Pash, the open-source reimplementation of PowerShell, I'm not terribly well-versed in its internal workings, so take the buffering part with a grain of salt.
As for completeness, well, the Unix ecosystem has an enormous edge here, simply by having been there for decades and amassing tools and utilities. Since PowerShell was intended for system administrators you can expect nearly everything needed there to have PowerShell-native support. This includes files, processes, services, event logs, active directory, and various other things I know little to nothing about. Get-Command -Verb Get gives you a list of things that are supported directly that way. It seems like even configuration things like network, disks and other such things are supported by now. At Microsoft there's a rule, I think, that every new configuration GUI in Windows Server has to be built on PowerShell. Which means, everything you can do in the GUI, you can do in PowerShell, and I think you can in some cases even access the script to do the changes you just made in the GUI – e.g. for doing the same change on a few hundred machines at once, or whatever.
Of course, you can just work with any collection of .NET objects by virtue of the common cmdlets working with objects (gcm -noun object). For me, whenever there is no native support, .NET is often a good escape hatch, that in many cases isn't terribly inconvenient to use. You also have more control over what exactly happens at that level, because you're one abstraction level lower. As a last resort, it's still a shell. It can run any program and get its output. Output from native programs is returned as string[], line by line, and in many cases that's not worse than with cmd or any Unix shell.
_____
¹ Keep in mind, the file system is just one provider and there are others, e.g. registry, cert store, functions, variables, aliases, environment variables that work with exactly the same commands. That's why ls is an alias for Get-ChildItem and there is no Get-File, because those commands are agnostic of the underlying provider.
² So much for do one thing – but understandable, because ls' output is not rich enough to filter for certain things further down in the pipeline.
Was just a bit surprised at the overhead of adding a command to the pipeline. A similar setup on linux would be like the following I guess (on a folder with 4600 files, 170 matching files).
20ms time ls *.pdf
35ms time find -maxdepth 1 -iname '*.pdf'
60ms time ls | egrep '.pdf$'
$ sudo apt-get install html-xml-utils jq
$ curl 'https://duckduckgo.com/html/?q=cake' | hxclean \
| hxselect .web-result:first-child .snippet
$ curl apy.projectjj.com/listPairs | jq .responseData[0]
Don't know if it's any good --- never tried it; it says it's about half complete, but I don't know if it's a useful half.
After looking at the docs, you could do a lot of what Powershell does with Unix shells; you'd need a different set of conventions, where instead of using unformatted text as an intermediate format you used a streamable table format with support for metadata. Then you could have commands like 'where', which would be awesome.
$ xps | xwhere user -eq dg | xsort -desc rss | xtop 10 | xecho "rss=@.rss cmdline=@.command"
...or something. sh syntax is a bit lacking; PowerShell's got lots of useful builtins, including having native support for the format so it knows how to present it to the user. An sh version would conversion routines back and forth from text.
The tricky part would be bootstrapping; getting enough functionality quickly enough that enough people would start using it to make it sustainable.
I'd still rather use this than faff around with awk, though. I've done way too much of that. And if I never have to parse the output of ls -l using cut again, I will be a happy person.
The whole point of the GNU system was working around the usual "I can see it here, need this bit, and want to put it there". If you need to do something really specific a lot, you write a tool which does that.
When we want a text oriented API we use shell scripts. When we want an object oriented API we pick our favourite scripting language - which may very well for many of us be different for different problem domains.
The point of the exercise is that the traditional Unix pipelinable commands have standardised on unstructured textual data. Powershell has standardised on structured tabular data, which is what lets you do the cool things.
find "$@" -printf "%TY %Tm %Td %TT %1y %4m %3n %4U:%-3G %8s %p\t%l\n"
But I've never tried it; just came across it recently as a homebrew update.
There are at least two parties working on it who have interest in certain features to be working: It's the NuGet shell within MonoDevelop, so custom PowerShell hosts need to work as well as a bunch of things needed by NuGet. Then one of the more prolific developers actually gets paid to work on Pash to support features related to PowerShell add-ins and a few others. (My own efforts so far were mostly bits and pieces, missing cmdlets (there are still a lot of those), test cases, and weird parser behaviour, mostly due to my history of golfing in PowerShell – golfed code makes for some fun tests of edge cases.)
Try stat instead, e.g.
$ stat -c 'NAME: %n; OWNER: %U, SIZE: %s' *
Can you post this 2 liner? Sounds interesting.
This isn't stocks, shares, futures etc for ref either.
I don't want to say any more nor post any code as it's unique and a good earner at the moment.
Now that's teasing ;)
Let me guess: arbitrage applied to sports gambling. Wink my way if I'm on the right track.
Update-Help
Then you can type "Get-Help About_" and hit tab to see the master topic lists.
Ah also POSIX compliance could simplify the life of those who develop on Windows. I tryed to develop on Windows for many years, I tryed hard but you are always missing some feature that on Unix is basic.
I tend to use PowerShell ISE that is built into windows rather than cmd, which you're right, sucks.
If you were coming from the Unix/BSD world, I could understand this, but how is using a GUI for everything considered elegant, while GNU tools are considered "bloated?" Doesn't the GUI necessarily "bloat" the program more than a few extra command-line options would?
Embedded Windows, on the other hand, is forever the poor relation.
Windows could do a lot better than curses by providing easy means to pop MFC dialogs from the shell to prompt the user.
Zip and unzip are already available, in https://pscx.codeplex.com/
> Who uses vi-mode in the shell?
> Windows could do a lot better than curses by
> providing easy means to pop MFC dialogs from
> the shell to prompt the user.
With deliberate effort, you can build automation to Windows platforms. But in unix, one guy with a clue can create vast value working with the defaults. Even on an ancient Solaris box with no compiler or extra tools installed. If you're desperate you'll be able to find a shell that can open a socket server or staple some awk together to get a result.
Windows powershell is a vision of what a shell can be that has grown up separate to the unix world. In a fair world it would be considered heavy-lifting-equipment, like bash or emacs lisp. It would be thriving. But it has lived in a straight-jacket because until now Microsoft has forced operators to to interact with it via the windows GUI.
MFC popups would undermine the benefits of SSH. If you're worried about your shell hanging at a background window event, you'll avoid using it in anger.
Same issue with editors. Existing editors require the GUI layer. A strength of ssh is how well it suits you when you want to dive on to a host and make a fast change.
This was common on the Amiga. E.g. tab completion in the shell can bring up a pre-filtered file requester.
Why do you think that is? As in, why is everyone else on unix (like toolchains)? Why do you think pretty much the entire tech-stack of mobile and web companies has moved to Linux or BSD as the default choice.
The reason is clear. The unix "small tools connected by text based pipes" philosophy has won. Whether disaffected powershell users find it clunky or not is not the point. Unix tools are the lingua-franca of developers everywhere.
There are many reasons for this but the most important is that the commandline toolset for managing a machine from a remote terminal has always been the most important UI for unix over the last forty years. You can call it "dated". The industry calls it "the standard".
The irony here is that Microsoft itself has come to the realization that they have to follow where the developer ecosystem is inexorably marching en mass. There will of course be a certain percent of holdouts clinging to their powershells. But now they'll be fighting against not only the linux'er and BSD'rs. But Microsoft management itself.
One line is enough for everyone.