Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How to effectively learn PowerShell?
196 points by mondoshawan on Jan 15, 2017 | hide | past | favorite | 99 comments
I've been looking around for a while now, but haven't really found what I'm looking for. Essentially, what I'd like to use to learn powershell effectively with is a "powershell by example" page somewhere, similar to gobyexample.com or rustbyexample.com where the tutorial encourages active tinkering.

What have you been using to effectively learn the ins and outs of powershell usage?

I also moved from bash (after nearly 2 decades!) to powershell. Here's my powershell profile, including instructions for setting up a new box and additional aliases for Unix commands:


Short answer for 'How do I learn powershell?' is:

* Learn 'select'

* Learn 'where'

Once you get those two, and get out of the scraping with sed/grep/awk mentality you now properly get powershell.

There seems to be a certificate request appended to line 46

I don't know if this information is sensitive, but you probably don't want it there either way.

Good spot - CSR is only a public key so not sensitive - but removed.

I don't remember where I found it but I use this for touch https://gist.github.com/golf1052/39603656500adcaef3e8fd3d210...

It acts like Linux touch where if the file already exists it just updates the last modified date

Why do you choose not to install OpenSSH over chocolatey?

I'm looking for a clean way to install OpenSSH on Windows.

Looking at the code (commented lines at the top), I thought parent was using Chocolatey as a OneGet provider? See https://github.com/chocolatey/chocolatey-oneget

Yep this is correct. I prefer less software, though apparently chocolatey oneget isn't as well maintained as regular chocolatey.

Not sure how much time you have, but if you do not have much I strongly recommend "Learn PowerShell In A Month Of Lunches" [1]

Basically means that if you can spend about one hour every day on the text and exercises in the book you will be able to grasp PowerShell scripting in about a month.

[1] https://www.manning.com/books/learn-windows-powershell-in-a-...

This book is book great and after you've read it I can recommend "The Powershell Scripting and Toolmaking Book"[1]. I just started reading it and teaches you how to write good tools with practical examples and business scenarios. My next step will be learning Pester and DSC.

Also "Powershell in Action" by Manning is great to lookup things in detail.

[1] https://leanpub.com/powershell-scripting-toolmaking

Definitely recommend the Manning book "PowerShell in Action" by Bruce Payette. The second edition is on Amazon but looks like a third edition is coming out in the Spring and you can pick up the EAP.


What's a practical way to learn it on a Macintosh? VM?

Windows VM, or if you are a daredevil you could try and install PowerShell 6 (which will be crossplatform) on macOS from here: https://github.com/PowerShell/PowerShell (do note its currently in alpha state)

I looked at the Microsoft Virtual academy videos [1], they cover a lot of basics but were usefeul, having the creator of powershell teach the course helped understand the philosophy behind it.

When searching for tutorials online, "the scripting guy" was useful, but more importantly I make sure to search for powershell v5, v4, or v3 tutorials. - There are lots of "old" tutorials, but I think there were major changes between Powershell v1, v2, and v3, so I try to avoid those, especially regarding modules

[1] https://mva.microsoft.com/en-us/training-courses/getting-sta...

I checked this thread out just to make sure someone posted this link. I have not found a better resource for learning PowerShell anywhere. It covers what makes PowerShell special, and then gives an excellent primer on the language. Start here.

Maybe it's just me but I find this series incredibly annoying to watch. I doubt I can tolerate 5 hours of these two. Each hour of video has 10 minutes of content.

Whilst you might get some value in trying to learn in a structured way, I'd say you'll get much more out of it if you try to scratch your own itch.

In other words, think of something you want to script, then try to learn how to do that in PowerShell.

What I think you'll find if you try learning something as vast as PowerShell with a general approach is that, whilst you may pick up some decent general habits, you'll also find yourself learning a whole bunch you never use.

Learning PowerShell is different from learning a conventional programming language as each use case you'll have will make use of different commands. It's like having a DSL for each use case. You'll use different commands for Active Directory management, for Azure management, for file processing, etc... As long as you know the basics you can pick up whatever is going to be most relevant for what you do.

Sorry to piggyback on this post:

I have to use Windows at work, and do not know Powershell. Several times I've debated learning it, but never put in the effort.

Now I use Xonsh (http://xon.sh/). It is a Python shell - cross platform and similar semantics to bash, etc. I was never a power bash/zsh user (scripting in them is Hell). The nice thing with xonsh is that it is Python. If you want to customize your environment, have complex aliases - well, you just write Python code in your config file.

Learning PowerShell for Windows is the ideal. But xonsh is a good intermediate solution for people who don't want to invest in going all the way.

(To be honest, I'm seriously considering switching to xonsh for my Linux machine - currently I use zsh).

I was totally entusiastic when you mentioned this so I went to read the docs. While it does seem way "shellier" then pure python I don't think its comparable to Powershell.

One of the main benefits of posh is that it provides standards on arguments so that discoverability is easy. Along with that you get automatic tab completition for everything, module autoloading and nice stuff such as proxy commands, JEA and other great stuff not avaialble in alternatives. The other one is that nowdays many tools expose automation via powershell modules - sql server, visual svn, chocoalatey, vmware, etc. just to name few - so all that power seems wasted with xonsh on Windows. Not to mention wmi, COM and other nastier stuff becomes way more problematic then it needs to be. Good luck driving Excel for example.

There was similar attempt with Ruby (https://github.com/adamwiggins/rush) - but it failed because you do really need a special language for shell. Its pitty Xiki (http://xiki.org/) didn't become mainstream talking about Ruby.

Whitespace semantics also look like troublesome in the shell context and I guess in some more serious usage ambigious stuff like ls -l may become problematic and hard to detect source of bugs.

On the other hand, it rewards with better Python knowledge which is always good.

>While it does seem way "shellier" then pure python I don't think its comparable to Powershell.

Well, none of the UNIX shells are comparable to Powershell. That's why this is a nice in-between solution. A way to have a UNIX like shell on Windows, without the need to learn a new language if you already know Python.

>Whitespace semantics also look like troublesome in the shell context and I guess in some more serious usage ambigious stuff like ls -l may become problematic and hard to detect source of bugs.

Been using it for a few months. So far, not a problem. The biggest headache is that "dir" is a reserved keyword in Python. Not a problem: I just made 'ls' an alias for it.

The only real problem is that Windows has case-insensitive environment variables, but xonsh makes them case-sensitive. This is fixable, and they'll probably fix it some time soon.

> Well, none of the UNIX shells are comparable to Powershell.

Yes there is one, Powershell :)

Thx for detailed report by the way. I hope the project will get mature and adopted.

xonsh looks interesting. My first question would be along the lines of "do you get command completion and nice syntax highlighting in the shell?" but I see in your link that it does have those, so that's a great start.

My other worry is that there's going to be some things it's hard to do _on windows_ for any shell that isn't created by microsoft. Which is not the fault of xonsh, or any other alternative shell, obviously- but which might make psh a better deal in some cases.

Can't think of an example though, to be honest :)

xonsh might be fine for interactive use, but I'd hesitate to use it for serious scripting. The nice thing about PowerShell is that it's a .Net CLR language. So, this means that anything that's accessible to .Net (including COM bindings) is also accessible to PowerShell. This means that for example, you can script IIS configuration and setup with PowerShell. You can script things like importing certificates. You can stop and restart Windows services. I'd be surprised if xonsh exposed the same amount of the Windows API as PowerShell.

Oh, for sure. xonsh is nowhere near as powerful as PowerShell.

I was pointing out that xonsh is a good shell for people who do not want to learn Powershell: people who do not need all the power.

I work on Windows, but I'm not a Windows developer. I do embedded programming, and so am not familiar with most of .Net/COM. I just need to do my work on Windows, and for people coming from the UNIX world, xonsh is a shell that makes life tolerable with minimal learning necessary. Obviously, Powershell is better, but requires a lot more investment.

With a bit of pinvoke goodness you can load unmanaged dlls also.

I've started reading this one and found it pretty good. As a beginner at least.


Powershell is frankly fairly amazing. Recently I found myself needing to open the Windows datastore.edb file, and before I discovered some interops I learned that in fact you can grab a C# member definition, then use it as a signature and load that type as a Powershell object [1]

Hell, I even found a C# code snippet and was able to add into a Powershell string, then add this as a C# type definition, and Powershell compiled it to an assembly and then loaded it as an instance of a Powershell object.[2]

1. http://www.leeholmes.com/blog/2009/01/19/powershell-pinvoke-...

2. I found how to do this here: https://blogs.technet.microsoft.com/stefan_gossner/2010/05/0...

To add further - I found out PInvoke over Powershell works just as well on OS X.

This may or may not work for you but it's now I forced myself to learn PowerShell.

First you need to understand that PowerShell (because of WMI and .net snapins) can do literally anything that can be done on a windows environment either via click, keystroke, or code.

Second you need to understand that PowerShell is an object-oriented scripting language. You can certainly use it in a procedural fashion, if you're so inclined, but you will be severely hobbling yourself in the process.

Third you need to decide to write (or locate, test, and study) scripts to do a fair percentage of the things you might normally seek small single-purpose third party software to do. Want to scan your network for devices, use PowerShell. Want to bulk, edit AD users, do it in PowerShell. Need to clone a directory structure? You get the idea...

Take this approach and look for legitimate reasons to use PowerShell every day.

Seconded. In my last job i automated all tedious tasks via powershell. Need to verify connectivity and documentation accuracy (credentials, snmp strings, vendors, versions...)? Powershell is solution for me.

Even tcl scripts was parsed, compared and exported to xls with Powershell. Verify and implement configuratiom template was another case where powershell was solution.

For me this is my strongest weapon on windows automation and system management.

And i like it beacuse you can edit in notepad++, sublime, atom, whatever...save... a run ps1 file. No insane and complex IDE needed, no compilers. If you need you can do exe files. It's dirty solution, but it works.

My last project (app for coffe shopps and restaurants) is written in powershell.

"The biggest issue" for me is support of my scripts on windows with lower version of powershell or .NET

In regards to original question. "Powershell in action" is my favorite resource about powershell.

Protip: You'll find two app on Windows called Powershell. One is just called Powershell and the other is called Powershell ISE. I mistakenly picked the regular one, to later find out that Powershell ISE is epic. It's like a combination of a terminal and some kind of IDE.

Use PSReadLine instead of ISE.https://github.com/lzybkr/PSReadLine

ISE has bugs that the CLI doesn't (ex: splats for hashtable arguments used to not work in ISE - I don't know if that is still true, because I gave up using ISE and have only used the CLI for the last 2-3 years).

And if you use PS 5.0 (not the default for Win 7/8/8.1 but downloadable as WMF 5.0) it has PSReadLine by default.

As an emacs user this is quite a pleasing news.

    Import-Module PSReadLine
    Set-PSReadlineOption -EditMode Emacs
    ### profit

Mnyeah, dunno. I tried the Vi mode, but right off the bat I missed the ability to hit ESC to clear the current input. So much easier than doing ^d$

I don't know about Emacs bindings, but I've tried vim bindings in all sorts of things outside vim, browsers, IDEs, other editors... somehow they never made sense outside of vim.

Awesome nugget of info! Does this work in v5?

I believe so, the PSReadLine module has been included in PS since v3 IIRC

Many thanks, a colleague sent me Clink for CMD, but I noticed it didn't apply to PoSh. Ths is what I needed.

ISE is the best for learning but doesn't have good readline support (it's not quite a normal windows console). Once you're up to speed, grab ConEmu. It's the iTerm2 of the Windows world.

ConEmu is pretty great (and WAY better than a standard console), but CMDer builds upon the ConEmu base and improves it, in my opinion: http://cmder.net/

>> ISE is the best for learning but doesn't have good readline support

But it has very nice tab completion with a graphical drop-down :0

It either has the full powershell console in a pane depending on your view settings or you can hit f8 to run highlighted text or the line your cursor is on.

At least you have proper copy/paste in ISE :P

ConEmu has Unix style, highlight & right click paste. :P~

Not if you run RealVNC, it kills cut...

Thanks for pointing this out. I thought I was going crazy when it happened to me just yesterday.

If you want to take ISE to the next level, check out ISESteroids. After being spoiled by Visual Studio, it's nice to have powerful debugging capabilities.

ISESteroids simply sux. The worst money thrown yet. Its slower to start then Visual Studio Ultimate, then continues to be slow during usage, it has bunch of useless features, it does some Write-Hosts on its own (?!) and unimportant icons and is buggy. It also greets you over full screen each time which is very annoying. The only good feature is powershell compatibility check which actually stopped working for me after some time. Plus its commerical, you have to take care of licensing stuff. Its on my ignore list.

I just registered powershellbyexample.com - I'll start updating it soon!

I may be an outlier in this regard. I learned PowerShell by starting to golf in it. However, while I know the language quiet well, I'm completely useless at using it for administrative tasks, simply because I've never done that with it. I use PowerShell as my go-to scripting language, calculator, interactive .NET playground and a bunch of other things, but rarely for managing Windows servers.

I can recommend the PowerShell cookbook too, though. I've been a technical reviewer of the 2nd edition and at least back then it was good :-)

dkarapetyan linked a good Cookbook. That's essentially what you're asking for. In addition to that, when I had to learn Powershell I found "Learn Powershell in a Month of Lunches" quite useful. At the time it was considered the go to book for PoSh, but that may have changed.

For me it was this - https://stacktoheap.com/blog/2012/10/17/learning-by-answerin...

I started using Powershell and also started answering questions on SO. The latter helped a lot in quickly improving my skills.

There is an excellent series of videos on PluralSight. I can't remember for sure who the instructor was, but I always recommend them to anyone learning PowerShell.

I think it's this guy: https://www.pluralsight.com/courses/powershell-intro

Even though this is titled as PowerShell for Mac and Linux, one of the presenters is Jeffrey Snover who invented PowerShell. He provides some great information about how the pipeline works and compares it to the pipe system in Unix. I found it very informative.


If you can get hold of either Bruce Payett or Lee Holm's PowerShell scripting books, those are pretty canonical guides, as both of those guys were devs on the PowerShell team for years. On day one you should get familiar with the discoverability features built in: get-member, get-help, get-command, get-member, tab completion, get-alias, etc.

There is a well designed tutorial on Youtube, helped me a lot to get started.


I still think Bruce Payette'a book on PowerShell is referential in explaining how PowerShell works inside-out.

As far as learning it goes, there's no better practice than porting your old work!

I'd recommend: - "Learn PowerShell in A Month Of Lunches" - reddit.com/r/powershell - the powershell podcast at powershell.org

I tried scripting the clipboard through vbscript but got stuck, tried powershell, it's a one liner.

Seems like a pleasant platform. Thanks for this thread.

Can someone link a site that was posted on HN a month ago that shows side by side comparisons between BASH commands and Powershell?

Have you tried the Search API below? You can search stories or comments.

Here's a list of likely Powershell submissions:


powershell does have its own command for normal scripting stuff...For e.g. Test-Path, etc...but if at all you are stuck with something you can always revert to the .net framework...but I still like curl hence I stuck to git bash

Effectively, forget about desktop and cmd and only live in powershell. That is what I do - Posh is my operating system, it autostarts with Windows. In a several months you will be effective user, but to master it will still take years.

In this regard, few tips:

- Install apps via Chocolatey. If app is not there create a package and maintain it. AU framework makes it one time development event. See this report: https://gist.github.com/majkinetor/a700c70b8847b29ebb1c918d4...

- Your profile is very important. I use profile.d which can be reused easily on all your machines: https://github.com/majkinetor/powershell_profile.d

- Use Powershell Gallery and modules in general. Make module or reusable component for everything. See my work here:


- Make sure you use mandatory cli tools:

cinst conemu less peco sysinternals everything copyq

- Do not use junk GUI editors such as ISE. Visual Studio Code is way better if you have to. Sometimes is OK when debugging. I would suggest vim because speed is of great importance in shell world.

- Follow reddit community and ask questions there rather then on SO which is full of achievement biatches. Redditors will help you for free for the joy of sharing the knowledge.

- Use Github to store all your stuff. Also, in coorporation you can use NAS share to let anybody import stuff from there.

- DO NOT LISTEN naysayers about aliases - use default alises all the time. They are cross-platform and well known and I can go into neurolinguistics of why is it better and easier for the brain but I don't want to do it here. People will certainly whine now but ignore them. DEFAULT (READ ONLY) ALIASES ARE THE BEST. Particularly, if you see somebody does foreach-object or where-object just kill him ASAP.

- Do ALL windows config from Posh. If you don't know ask around. If you are devops dude, you can thank me later, especially when you learn DSC and apply all that knowledge there or with boxstarter.

- If you happen to be locked in older posh use PSReadLine. Keep in mind that $host.Version -lt '3.0' is full of surprises and use latest version if possible.

- Do not compromise with others in coorporation. Ask for script for everything. If sysadmin tells you that server is low on disk you ask for proof in the form of the command you can execute. Ask for invoke-sql when using databases. If you give admin a job to create a IIS site for your web app ask for a script. If you are a project manager, do not close tickets without a script.

- If you monitor vendor excursions in your company infrastructure, ask for transcripipt of ALL operations they do. You will thank me later. Do not sign their work without it.

I can recommend "Windows Powershell In Depth" https://www.manning.com/books/powershell-in-depth-second-edi...

And if you don't enjoy PS almost every single moment you are doing something wrong.

PS: I do not work for Microsoft :) I just think bash and friends are ridiculous in 2017 and honestly a little embarrassing. Do not do that - install Powershell on Linux and Mac if you have to and keep your sanity.

PS2: Somebody will certainly say that ruby/python/whatever is great on linux side. Ignore them. Those are not shell languages (while great otherwise and valuable in your skillset - cinst ruby python etc. is among my mandatory stuff but lets keep perspective here).

Good luck.

> Do not compromise with others in coorporation. Ask for script for everything. If sysamin tells you that your server is low on disk you ask for proof in the form of the command you can execute. If you give it a job to create a IIS site for you ask for a script. If you are a project manager like me, do not close tickets without a script.

That may be the worst advice I've ever seen on how to work with others. It's the PowerShell equivalent of not just preaching veganism but requiring that anyone interacting with you start an organic garden.

You must be that click next person. I prefer to think about Posh as low carb, rather then veganism :)

But more seriously, anything repeatable easily will do. The problem is, Posh is there on all Windows machines while everything else must be installed (except cmd.exe which should be forbiden IMO). I heave interactions with 100+ engineers of different domains and the only thing that links them is that they all use Windows, even 95% of Solaris/Unix/Linux admins. So Posh is the most practical thing.

If you think reproducibility is bad thing or form of veganism, you should probably find another job.

Reproducability is great.

No, my concern is that if I submit a ticket that says "when I send 65 characters in the Username field I get random spew back, I think you need to be checking inputs better" and get a response of "show this to me with a PowerShell script" then I kick things upstairs with appropriate commentary.

And if the attitude you related in these comments is accurate, I suspect those engineers all have something else in common: working to bypass you as much as possible.

I think that

start my-fancy-app.exe; Sleep; [System.Windows.Forms.SendKeys]::Send("A"*65)

makes it way more reproducible and you even quickly get test from there (would do that in AutoHotkey tho for better effect, right tool for the job).

> And if the attitude you related in these comments is accurate, I suspect those engineers all have something else in common: working to bypass you as much as possible.

Actually, its quite the opposite. With that attitude tho, I suspect you get bypasses all the time.

And if something else has (or grabs) focus and the scripted input doesn't go where you're hoping it will, does the bug report get marked "can't reproduce" and closed?

I'll freely confess I'm not up on the current automated testing tools for Windows apps, but I'm hoping they're more sophisticated that "point and pray" keyboard spamming.

My concern with the approach you describe is that there are many categories of application problems that are not reasonably reproducible with a PowerShell script, some that are reproducible only with a sophisticated script, and some that are trivially reproduced.

For the trivial ones that are easily reproduced my feeling is that a quick description going to the developers will probably let them reproduce it more easily in a development environment with appropriate code stops that would be adversely affected by automated keyboard injection directly to Windows. For Windows app development if I put in a code stop to inspect state after each keypress, blowing 64 extra "A"s into my dev environment after the stop is unlikely to be helpful.

For problems that require more sophisticated scripting to reproduce, I'm unconvinced that I want to be requiring that all testers be able to write sophisticated test scripts. Maybe you have a ton of VC money and feel that burn rate isn't relevant, but that doesn't describe everyone. Sure, I want some good automated test scripts and the ability to say "When we run script XYZ with input set ABC it blows up" but scripting reproduction of every scenario? (expletive) no.

Basically you're putting up a sign that says "I don't care what problems you have found, if they can't be reproduced with an automated script I will reject them." That doesn't keep those problems from existing or being found, it just ensures that you don't try to fix them and eventually (if you're still around) it means that you don't hear about them either. That may never cause real problems, or someday you may get an email from Tavis Ormandy or someone you have even less desire to hear from.

Edit: it just occurred to me - basically this is a "captcha" system for bug reporting, but one with the potential for arbitrary puzzle difficulty potentially unrelated to problem severity or reproducability.

Didn't I tell AHK is the tool for that job ? It handles stuff like focus stealing, theming etc without any problems. Seriously, if there is no test, it might just be your high sugar levels. I don't know in what kind of stuff you are, but we develop software and services that entire country uses. If you do not make a test you can regress and it will probably happen in the worst possible time.

Also, I don't have testers, only developers. Testing is the part of the job which is mandatory. Along with some other stuff. :)

> - Do not compromise with others in coorporation. Ask for script for everything. If sysadmin tells you that server is low on disk you ask for proof in the form of the command you can execute. Ask for invoke-sql when using databases. If you give admin a job to create a IIS site for your web app ask for a script. If you are a project manager, do not close tickets without a script.

If you take that "do not compromise, demand a script that proves" attitude this this sysadmin, then this sysadmin will "not compromise" in return, and your code will never be deployed - clearly you're not going to be working on bugfixes, so why should it be deployed?

I'm generally very helpful and my devs generally like me. I take the time to teach when I can and try to learn and understand when I can't. But when someone demands that I write scripts to prove all bugs I find, they can fuck off. I don't have unlimited time - and my duties extend beyond babysitting code. I don't have the close knowledge of the codebase that the developer has. I'm not in the architectural meetings where decisions are made on the internals. I take the code I'm given, and make it live and breathe in the world. I work with the devs in doing this - and if a dev decides that they're too important to be bothered doing legwork in the code that they're the most familiar with, well, fuck 'em. They can sit with their ticket left open.

We're all in this shit together; don't make me do your job with less domain knowledge than you.

> Clearly you're not going to be working on bugfixes, so why should it be deployed?

What makes you say that ?

> And my devs generally like me.

And half of the world likes Kim Kardashian so what ?

> But when someone demands that I write scripts to prove all bugs I find, they can fuck off

You are not being proffesional then. You demand time of others to do your work, because, hej, you do your best, right ? Your managers decided to leave you out on arch decisions so you think all managers are like that. You extrapolate your slow and unworthy experience to everybody else.

The point is, there are almost no single time events in enterprise. Everything you do, somebody will have to do again, tomorrow, a few days from now, or a year later. So, if you do the things your way, others will have to repeat what you did (or you, or worse, somebody new who knows nothing about it but could get your script with simple Redmine search along with some 'historical records' - read the TMMM and see how communication/tutoring is important - feel free to watch Galaxy Quest later) and that is not a nice thing to do in a company - you are wasting our time, resources, customers etc., on the long run: https://xkcd.com/974/

You can do whatever the fuck you want in the company of your grandpa, but its about time you sysadmins understand that good sysadmining means understanding the code concepts and development tools, and ability to script in the middle of the night. Nobody will ever ask you to write Gherkin tests, Performanse test, unit tests, integration tests, to know OO patterns etc... But in my team I will demand you know how to write 50-100 line scripts. If you can't do that, then you are emberresment for your proffession.

Good time to quote Jeffrey Snover: "GUI-only, Click-Next, no-value-add Admins will be replaced with a new type of Admin - the kind that greet you the lobby".

When you start to experience this paradigm shift, you will soon find yourself thinking about how did you live before that, and maybe even buy me a beer for letting you know that you can improve.

>> Clearly you're not going to be working on bugfixes, so why should it be deployed? > What makes you say that ?

"Do not compromise". That's what "do not compromise" means. If you do your work without getting those things you have demanded, then you have compromised.

> And half of the world likes Kim Kardashian so what ?

My point was that I don't pride myself on being a BOFH. Apparently it's not okay to say "I get along with colleagues", but it's totally okay to say "I make the standards that people in other companies follow like groupies!". Sure you do, mate. Sure you do.

> You are not being proffesional then. You demand time of others to do your work, because, hej, you do your best, right ?

When I say "Hey, devs, this error is appearing in the logs on production - the logs you wrote for the application you wrote - please look at it", the one who is not being professional is the one who says "I'm not going to look at it until you troubleshoot the issue to the degree that you can write a script that replicates the error".

> and ability to script in the middle of the night

You mean the time that devs are never around? It's a bit rich you complaining of sysadmins 'not working after hours'.

> But in my team I will demand you know how to write 50-100 line scripts. If you can't do that, then you are emberresment for your proffession.

a) Even if English is not your first language, if you're accusing someone of being unprofessional, learn to spell the word. It undermines your jibe when you can't spell an insult about professionalism.

b) I can write the scripts. Clearly your troubleshooting is so atrophied that you can't see that I'm talking about the process and incumbent knowledge, not the ability to code. Yes, I write scripts, but no, I don't know what internal code doo-dad you devs thought to change in your last stand-up and pushed through. Why the fuck should the guy who is not intimately familiar with the codebase be the fucker that has to waste their time hunting the snark, then coding up a test for what is, to them, a (somewhat) black box?

> GUI-only, Click-Next, no-value-add Admins will be replaced with a new type of Admin

Again, fuck you too. I live in terminals. You're the lazy guy that wants everyone else to do the work. I'm saying that the person who knows the application should write the replicator script - you're saying the person who reports the issue should write it. God knows how you take a bug report from a non-technical person. I guess it just gets auto-marked WONTFIX.

Certainly you've learned more about the politics than the technical aspects of the industry. "I write stuff the whole country uses!" carries much less cachet when it's a small Balkan state known more for nepotism than for a strong technical sector. Especially when you also say "you can't force anything on someone working in gov", given that government software projects are rarely known for their excellence. But keep on bragging, eventually you'll find someone who listens to the brag rather than the technical merits.

>> - Do not compromise with others in coorporation. Ask for script for everything. If sysadmin tells you that server is low on disk you ask for proof in the form of the command you can execute. Ask for invoke-sql when using databases. If you give admin a job to create a IIS site for your web app ask for a script. If you are a project manager, do not close tickets without a script.

Yeah, I don't know. In another comment here I describe how I used to work in a workplace where nobody wanted to learn to use powershell. I was a junior dev at the time and it really wasn't easy for me to convince people of the need to use specific tools. I had enough problems as it was (some folks kicked up a fuss because I didn't smile when I spoke to them; I got a BRF, what can I do?) (and screw that anyway).

So I learned to use psh and used it to make my work easier, and it did miracles for my self-esteem and my self-confidence (which had taken a very bad turn after I first joined that company).

I've also had to bypass thick-headedness in colleagues in other organisations, and even jump through some hoops like connecting to the internet through proxies and restricting what can be installed on a machine etc.

Sometimes, you just have to be flexible, and trying to convince everyone that your way is better is not flexible. If your way really is better- go ahead and do your thing, and ask for forgiveness later, rather than permission now.

But, to be fair- all the stuff you say about using psh to make your job easier, it's all true. invoke-sql in particular, it's gold.

I am head of development in my company. I make standards and learn others WHY. They soon all become groopies as they replace usual borring repetitive stuff that no engineer is worthy doing with something far more interesting and rewarding.

Since I work wiht N other vendors and their engineers on which I don't have much jurisdiction, I just do my stuff explaning why all the time and if they are any good, they will adopt it. If they don't, its typical that they suffer ineficiencies and I show them by doing their work that it can be done better and faster. Top managers notice eventually how efficent things can be. For example, when I want quick metrics on bunch of servers I just invoke flea rather then having to mess with nagios, zabix or friends. Look how readable that is: https://github.com/majkinetor/flea

On my latest project I use powershell to do everything - configure Solaris, install and oracle database, configure and install and manage weblogic servers etc. Powershell is wrapping bash/python/awk/whatever scripts and provides consistent interface for all service operations. Vendor engineers didn't initially want to do it and it turned out that what my company does in 10 minutes they do in an hour. Now they all want it.

The best you can hope in your situation is that the 'truth' will come out from your actions, but you will have to push it also, people are usually enjoying the comforts of technologies that they are experienced with especially with harsh dead lines.

Give it time, and try to get more influental positions. If nothing works, find suitable alternative, posh is not the only stuff in the world. If that is not possible, you don't need job that bad IMO.

I've long since moved on from that position, and that company, so no worries there.

I'd be worried about this however:

>> I am head of development in my company. I make standards and learn others WHY. They soon all become groopies

It's easy to get people to agree to everything you say if you're their boss. It's good to keep that in mind, always. For myself, I've had the best experiences and learned the most when I had senior devs who listened and were willing to mentor, rather than impose their will.

Of course, up to a certain extent, if you set up processes in a certain way and then hire people to execute them, and they agree to come onboard, there's no issue of forcing them to do as you say. If they don't like it, they can go somewhere else.

Still, I think the best lesson I got from that job where people didn't want to listen to the junior dev (me) is that you should always be open to advice from all levels in the company hierarchy.

I work for government. You can't really impose anything on people in gov, three are no reprecussions for not listening to the boss.

> You should always be open to advice from all levels in the company hierarchy.

I agree 120%. I don't really care what's your position in the company. I am practical person - if you can prove me that I suck I will be happy to change. But I do need proof that new concept works in real world - so many things look good on the paper and you need to digest stuff fully. Currently, my best brainstorm partner can't be lower in the company, but he is driven by pure passion.

If you head development, then you have the power to demand evidence. But I'm afraid for a variety of reasons I work for a company that has outsourced their work to several good offshore folks, but mostly the most bone-headed, incompetent, inexperienced, dishonest bunch of people o have ever come across (and that's truly saying something). I'm also currently low down the food chain and so like most people I have to rather wary about making specific demands.

I might also mention that I discovered this outsourcer was doing all commands from a root shell, so I now refuse to give specific commands but ask fir the info but I am very deliberate in not giving them the specific commands to get the data.

That said, what I would give to do what you seem to get away with :-)

That is so typical for majority of vendors and the company you work for is irrelevant - I have seen that behavior from all major IT vendors and it is not culture or location specific.

I get away with it frequently but not always. You can't imagine how many times I got response 'nobody ever asked that'.

What I usually do when that happens is to do one case of their work entirely myself to show a complete working example in real life scenario. That requires certain knowledge about domain in question. I have experience in bunch of tools, platforms and paradigms so I know how to do it about 70% of the time. When I don't, or don't have time for it, I just let it go.

But no matter your position, its very probable that your voice will be listened over that of a vendor consultant so if you can educate your boss with WHY (if not, you could go higher or try to influence someone else who can influence the person you want) there is a chance that your words will be taken before that of the external consultant.

You sound like a person I really would not want to work with. I wonder why such attitude always comes from serbs and bulgarians but if anything the way you present your opinions is toxic.

Oh, cmon, you hurt my feelings now...

How have i learnt powershell: 1. Replace cmd to powershell everywhere 2. Make you routine tasks automated by ps 3. Connect to remote machines by powershell only .... PROFIT

So how well does number 3 really work? Is the experience similar to Linux and Bash in the way that you can do everything in the console.

Yes, ps is very advanced tool. Difficult to find information how to do certain things but when you found them you have jedi power

I believe the best way to learn powershell is by using it as your shell, everyday, for real-world tasks, particularly in your job.

Start small, with ls, cp and cat, and don't force the pace. psh is a shell first and foremost- a shell with a very nice language, but a shell all the same. So get comfortable using it as a shell.

First thing is to create your $PROFILE. Google for an example and see if you can edit it to suit you. Then get chocolatey, PSCX (psh community extensions), posh-git and vim, and get used to doing most of your work on the command line (like you'd do with bash, on Linux). See what tasks you can automate by writing a few short scripts- very simple things at first, like copying and renaming files, setting up directory structures and so on, then progress to processing xml and setting up scheduled tasks, and sending email, setting up credentials etc. After a few months you'll find that you can wean yourself of windows GUIs for most of your everyday tasks and probably all of your not-so-everyday ones.

psh being a command-line tool, it's far easier to learn it like that, than trying to learn the language first. You can learn the basics of the syntax allright, but there's a bazillion commandlets that you will never be able to remember, unless you use them in your everyday work, and incorporate in your scripts, and those commandlets are often integral to the use of psh. Basically, you can't separate the language from the use of the shell, so you shouldn't try. Learn them both at the same time.

  %        %        %
Here's my personal example: I learned psh to avoid the long rdp queues in a past workplace.

I guess that company didn't want to shell out for more windows server licenses and so there was a limit to the number of people who could rdp to a server at the same time- just two or three people per server. So there was always a bit of a queue and I often had to wait between a half hour and a couple of hours before I could get a slot. Or someone would go for lunch and forget to log out, and you had to kick them out and it was generally a big drag.

At some point I started using psh as my windows shell, and then I found out about windows remoting [1], which sounded a lot like ssh on Linux- basically, it lets you open a shell on a remote computer. Next time I had a slot on a remote machine, I enabled remoting and suddendly I could do all the work I needed on the command line, while everyone else still had to wait in line for an RDP slot [2]. Needless to say, this made my life and my job a hell of a lot easier, not to say pleasant (I might have had a few smug smiles on my face, at times).

I'll note there was only one thing I couldn't do remotely: running a proprietery installer for the company's platform, that only had a gui and no command-line options. Everything else, including a whole bunch of SQL stuff, I could do it remotely, on psh [3].

All this naturally pushed me to do more psh scripting, as it was easier to run a script than key in a dozen commends on the command-line. So I left that job feeling very comfortable with powershell, and although I didn't quite have to use it that much in any other job since, I still use it as my primary shell at home.


[1] I think it started with this article, whose title immediately caught my attention:


[2] Noone else cared to learn powershell. I did ask. They said they didn't want to have to learn a new programming language. To be fair, I never explained my remoting setup to anyone, because they would probably tell me to stop using it (I was just a junior dev at the time). Note also that I never enabled remoting on any of our public-facing servers, just in case there was some vulnerability that could be exploited.

[3] I also used vim and netrw to edit my scripts on the remote server directly, over a UNC path, so I didn't have to re-upload them every time I needed to change them. This was a very Linux-y way to do stuff and really unusual where I worked.

Unrelated to PowerShell, that sounds like information wasn't making it to the right people if the limit - 2 administrative connections were being used like that for regular terminal services access, or like it would have made sense to split services across more systems if you had multiple people routinely doing simultaneous system changes on single servers.

RDS CALs aren't cheap, but they're a one time cost and insignificant compared to the cost of staff sitting around waiting for RDP sessions to free up.

Aye right, there was no reason for all that. But, this was far from the only case where the company could have optimised its processes. For instance, as a junior dev, my work primarily consisted of copying some stuff off a spreadsheet (as in, with Ctrl+C), pasting it into a text file and creating some xml structure around it by hand. That was an extremely time-consuming and error-prone process and it caused all sorts of delays and frustrations, to myself as well as everyone that depended on my work.

I spoke up about those inefficiencies very early on, but I was very inexperienced at the time and, to be honest, I had no idea how to properly communicate this sort of thing, so I never got anywhere. I only managed to come across as snotty and get a reputation as a trouble maker.

After that I just kept to myself and focused on getting some experience with C# and learning psh and so on, generally learning as much as possible until I felt confident enough to look for a better job- which I took as soon as I found it.

Generally, I was really unhappy in that company, but at the same time, exactly because I had to jump through hoops and learn how to automate my work, I taught myself a whole bunch of stuff that were very useful in my next job (where, btw, I had a great mentoring relation with my boss). So it all turned out alright.

I dunno if this is the kind of advice you're looking for, but what I've found is forcing myself to do everything with an unfamiliar tool helps a great deal.

I strongly recommend against learning Powershell, it has horrid syntax and is not crossplatform.

It wants to be a pseudo C# but without being C#. And anyway you can use scriptcs nowadays to write scripts in C# (or even better: .fsx scripts, with F#, which is more succint, less verbose than C#).

I strongly recommend against believing people who say PS is not cross platform when it is available for macOS and Linux and is open source too.

Interesting. Does it actually work though, or does it tend to depend on Windows-specific assemblies to do any useful work?

The main use-case I have for Powershell is remotely administering Exchange. If I could do that from OSX or Linux, then that would be useful enough for me to spend the time learning it.

> The main use-case I have for Powershell is remotely administering Exchange. If I could do that from OSX or Linux, then that would be useful enough for me to spend the time learning it.

I guess you can always do powershell remoting? Apparently it also works from Windows to Linux! https://github.com/PowerShell/PowerShell/blob/866b558771a20c... (got pointed there from this Reddit post: https://www.reddit.com/r/PowerShell/comments/4ziw85/anyone_m... )

It's based on .Net Core, so anything not in core PS has to be available there.

I agree. If you like C# better (who wouldn't), then you should at least play around a bit with C# Scripting. A good starter article: https://msdn.microsoft.com/en-us/magazine/mt614271.aspx

>> It wants to be a pseudo C# but without being C#.

Where did that come from? You can instantiate .Net classes from the command line in powershell, but otherwise it's got nothing to do with C#.

Pretty much the only relation between psh and C# that I can think of is that they are two of the three least un-microsofty pieces of software from Microsoft, and they're both really nice to use (the third one being Visual Studio). Other than that, they don't really have anything in common.

> Horrid syntax

True enough, but I'd rather make use of all of the tools I have available on as many platforms as I have available to me so that I don't have to fight to do things with limited tools. GUI is nice, but knowing how the underlying system integrates together through a shell is infinitely better.

> Not crossplatform

Didn't they port to Linux and Mac?

I only suggest that the people who named certain commands must type 500 wpm. Shit can be really really long.

That's what tab completion and aliases are for. The long command names are mainly there so that everything is consistent and there's not much guessing involved what a command does (or when you need to find something).

You should really really inform yourself better.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact