Live data from Hacker News

Looking Forward: Support for Secure Shell

blogs.msdn.com

311–320 of 404 posts

Re: Looking Forward: Support for Secure Shell

#311
post #60

For all Balmer's thing of dancing on a stage and chanting "developers", there was no point under Gates or he at which Microsoft felt like a pro-developer company. That has completely changed in the last eighteen months. Each time I think "wouldn't it be cool if" I'm finding a few weeks later that someone at Microsoft is well ahead of me. How much easier it will be to ship my sucky roguelikes to Windows users in this…

Yesterday only I was talking with my friend about "Would Microsoft will ever support ssh?" and voila its done.

I am a linux guy who did his intern in Microsoft. That was the first time I appreciated Powershell and from then I am in love with it. Its object oriented nature makes thing easy, fluid, understandable. I can never run linux command line with Google but with Powershell, its possible with the way it manages help pages.

Re: Looking Forward: Support for Secure Shell

#312

Earlier quoted context omitted.

that's a pretty terrible practice no matter what OS you're using.

Why? I assume that "private VLAN" means it isn't exposed to potential external attack.

Being 'private' only means you don't get hit by drive-by scans from the Internet. There are (depending on configuration) plenty of opportunities for internal attacks, for example the workstation being used to access the boxes. Not to mention removable media (usb, cd-rom) or files copied onto those otherwise isolated hosts could be infected.

Patching servers is just good practice. As is designing a system that can handle rebooting individual servers without user-facing downtime.

Re: Looking Forward: Support for Secure Shell

#313

Earlier quoted context omitted.

TBH I couldn't find a decent book or resource and sort of hacked my way around for a year or so. It had a good build in manual (get-help). This is a good poke at the fundamentals of my example: 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 Hit a…

This is really cool (and unfortunately I know nothing about powershell, I'm young and dumb) but I'm pretty sure this is replicable line for line with bash (and curl, maybe awk too idk). Am I wrong?

The main difference between bash/gnuutils stuff and Powershell is that every command returns an object (or an enumeration of objects), and commands can take an object (or an enumeration of objects) as input.

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.

Re: Looking Forward: Support for Secure Shell

#314
post #163

Earlier quoted context omitted.

Couldn't agree more. 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 end…

I'm not even a Powershell fan, I'm just not especially fond of Unix-likes, which feel like a local maximum that has turned into an unchangable standard. I think Unix-like environments feel dated, clunky and there's a tendancy for it to result in permanent bloat, stagnation and a web of interdependencies. I understand that lots of people are familiar with Unix-like tools and their many idiosyncrasies and like to be ab…

I disagree. 1. Unix-like environments are (or rather were before systemd) kinda similar and once you drop a shell - good to go. Even with powershell Microsoft have gone down the route of version/feature pinning. If you plan to maintain at least Windows 7/Server 2003 in your scripts - well, powershell 2 is the highest you can aim, bye bye new features, welcome bloat. Red Hat while shipping old versions still backports features. 2. The only thing in Unix-likes being standard are core utils and OpenSSH. Everything else can be anything (SysV/upstart/Systemd, Gnome/KDE/tiny_tiling_wm, bash/zsh) and we are actually deprecating older technologies for new ones (quite often changing the name). Due to ELTS (extremely long term support, often called legacy cruft) core subsystems are mostly the same (on the outside) in Windows. And if it is a server you can bet it is running IIS and MSSQL. 3. Try using `wmic` shell or `net` util. Unbearable clunkiness of such tools and bearable GUI tools mean that we have very little general scripts/tools to transfer

Re: Looking Forward: Support for Secure Shell

#315
post #266
post #216

Earlier quoted context omitted.

I'd guess that almost all corporations would be on your 'hate' list. This is a popular position, yes. But Microsoft in particular have tried to make Linux impossible on a number of occasions over a period of decades, so it'll take a while for the guerillas to come out of the jungle and stop fighting them. But now they're in competition with the platform that want to annex all your personal data and the platform that…

Linux survived because commercial vendors poured in over a billion dollars into making it a viable UNIX alternative. Microsoft's feeble attempts to sabotage it are pretty much irrelevant in that regard.

I think it is intent that counts here, not overall success of efforts. May they be feeble - they are still attempts of sabotage.

Re: Looking Forward: Support for Secure Shell

#316
post #213

Earlier quoted context omitted.

It's like people don't even try to learn how it works It's much harder to know how it works, for some reason. Information like this doesn't make its way into the community and circulate. On a UNIX system you can poke around /etc and get an idea of the scope of what is configurable. The same is very much not true of the registry and only slightly true of WMI.

You are right. The guy that wrote PowerShell says that UNIX is document oriented configuration while windows is API oriented configuration. To get into it in any depth you have to approach windows programmatically. The most power is through C\C++...to be a good windows admin you need to read the docs about how you interact with different subsystems, even if you aren't going to code against them.

> You are right. The guy that wrote PowerShell says that UNIX is document oriented configuration while windows is API oriented configuration.

That's an interesting way of putting it. I strongly prefer the Unix way then,(just avoid turing complete config languages).

Re: Looking Forward: Support for Secure Shell

#317

Earlier quoted context omitted.

> 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. 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?

TBH I couldn't find a decent book or resource and sort of hacked my way around for a year or so. It had a good build in manual (get-help). This is a good poke at the fundamentals of my example: 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 Hit a…

Ha, now when you Google "flight status for LH3396" the fourth result is your StackOverflow link.

Re: Looking Forward: Support for Secure Shell

#318
post #295

Earlier quoted context omitted.

Powershell will need some kind of text editor though, even if it's just something as simple as nano.

Edlin. The Standard Microsoft Text Editor.

> Edlin. The Standard Microsoft Text Editor.

One line is enough for everyone.

Re: Looking Forward: Support for Secure Shell

#319

Wonderful. I am a big supporter of Powershell, and while Powershell has supported remoting since almost day one, it will never enjoy quite as much support as SSH already receives (e.g. third party tools, firewall support, etc). It is also nice that they're looking into using something fairly "proven" secure, OpenSSH is exposed to the internet a lot (even if, yes, that is not best practice) so we can reasonably expect…

Why is SFTP > FTPS? Any place I could look for some info on this?

Are you talking about firewall easy-to-setup?

Re: Looking Forward: Support for Secure Shell

#320

Earlier quoted context omitted.

TBH I couldn't find a decent book or resource and sort of hacked my way around for a year or so. It had a good build in manual (get-help). This is a good poke at the fundamentals of my example: 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 Hit a…

This is really cool (and unfortunately I know nothing about powershell, I'm young and dumb) but I'm pretty sure this is replicable line for line with bash (and curl, maybe awk too idk). Am I wrong?

Probably not. In my experience it's not so much about things being impossible elsewhere, just that PowerShell can often be better at fiddling in a REPL until you got the results you wanted, in a way. The point where you need (or want) to upgrade to a more powerful language is IMHO earlier in bash than 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.)

Post reply on HN