9 ms·
Powershell and its long winded cmdlets are really hard for me to like. I always fall back to cygwin on windows. I once wrote a PS script to set some power mana
by CraigJPerry 11y ago
Powershell and its long winded cmdlets are really hard for me to like. I always fall back to cygwin on windows.
I once wrote a PS script to set some power management options on a corporate laptop. The script was 11 lines long (vs 3 lines in Python), it was harder to read and understand. Even with ISE available it was much harder to write.
I followed along with some exchange server tutorial where the prescribed easy way to achieve the task was a completely unintuitive PS script. I kept thinking about how much easier that particular config change was to make on a Linux host running postfix.
I can't see what benefit PS has over cygwin bash but I'd love to hear ideas because PS comes installed out of the box where I have to install cygwin myself.
- sz4kerto 11y ago> The script was 11 lines long (vs 3 lines in Python), it was harder to read and understand. Note that this might be true for one script, and the opposite might be true for another script. Something is saner in bash, something is better in PS. They have fundamental differences (text- vs. object-based), and neither of them is better than the other in all scenarios. (At least that's my experience.)
- Touche 11y agoI think it's worth noting that powershell is .NET object-based. This means you can interact with powershell objects from a .NET language but not, for example, python. To me this is the fundamental flaw of PS. It's a neat idea as long as you stay within their box, within their ecosystem. With Bash you get a wealth of tools because everything can handle text.
- wolfgke 11y ago> With Bash you get a wealth of tools because everything can handle text. I think technically it should be no problem to write some package for most programming languages for interopting with .net objects. In this sense about everything could also handle .net objects.
- Aleman360 11y ago> With Bash you get a wealth of tools because everything can handle text. And no autocomplete.
- adrusi 11y agoUnix command line autocomplete is fairly good, but it's not useful for discovery of new features or for helping you figure out a CLI without reading anything. It is quite effective at helping a user who knows what they're avoid keystrokes, though.
- kuma4 11y agoBash completion is inferior. It doesn't understand types.
- pritambaral 11y agoI didn't get this, could you elaborate? Does powershell autocomplete objects it is about to ingest, and before you run the command?
- noinsight 11y agoPowerShell v3+ can autocomplete command names, command switches and switch values (if they're a strict set). It can also autocomplete object properties yes. $dir = gci $dir.<tab> -> $dir.Count
- pritambaral 11y ago> command names, command switches and switch values (if they're a strict set). So can bash. How is this different from bash's autocompletion? > also ... object properties Well, there aren't objects in bash, so I can't translate this.
- emodendroket 11y agoYes, but the downside of that is you have to munge the text to do things with it, while with .NET objects you often don't have to do that. And PowerShell certainly does provide facilities for dealing with text, so you can use other languages' tools within PowerShell (and I think with some use of Out-String and similar you could go the other way well enough).
- 13of40 11y agoPowerShell objects are actually a superset of . Net objects. They can also represent COM objects, WMI objects, XML nodes, etc. You can also export them to CSV, XML, JSON, and yes, even text. If you have cygwin installed you can pipe to and from the cygwin commands from PowerShell and pipe to and from powershell.exe from your cygwin shell.
- Touche 11y agoLanguages are not the same, you'll never have interoperability; try exporting a .NET object with a 64-bit integer to be consumed by JavaScript, for example. Text wins.
- UK-AL 11y agoYou would serialise it? $obj = [PSCustomObject]@{ Number = [long]2 } $obj | ConvertTo-Json
- orf 11y agoYou can have interoperability, COM does it well on Windows. JavaScript, .net, Python, ruby, C, C++ can all access COM methods and attributes.
- 13of40 11y agoPS C:\> 0x1234567812345678 1311768465173141112 PS C:\> 0x1234567812345678 >.\foo.txt ; cat .\foo.txt 1311768465173141112 PS C:\> "WScript.Echo('$(0x1234567812345678)')" >.\foo.js ; cat .\foo.js ; cscript //nologo .\foo.js WScript.Echo(1311768465173141112) 1.31176846517314E+18 ... I'm not seeing your point.
- dr_zoidberg 11y agoGoogled "powershell ironpython" and got this[0] as first result. Before that, I was going to point out that IronPython, despite it's performance issues and nitpicky differences (there's no 'struct' module, but there's '_struct', which is... struct and they somehow forgot to rename) is still considered a .NET language. If there's anything wrong with the article (for one thing, it's 4 yo), please point it out. I just brought this up because the IronPython part of .NET is usually forgotten, though still there and has some interesting uses. [0] http://www.pythondiary.com/blog/Jun.26,2012/ironpython-and-microsofts-powershell.html http://www.pythondiary.com/blog/Jun.26,2012/ironpython-and-m...
- Touche 11y agoYou're missing my point.
- dr_zoidberg 11y agoCould you please be more explicit about it then? The part about the .NET objects has already been addressed by others, and I actually like that -- right now at work we're wrestling with a few command line applications that output text (in full UNIX-style) and it's a mess to parse the thing, because it's so badly documented. If we had objects as a result it'd be glorious (not that PS would help, this isn't a bash script we're working with/against).
- Touche 11y ago> Could you please be more explicit about it then? Sure, it doesn't work with CPython. I shouldn't need to be that explicit though, bring up IronPython is one hell of a nit.
- latkin 11y ago> With Bash you get a wealth of tools because everything can handle text. ... and all those tools work seamlessly in Powershell, too. .NET objects are passed around within Powershell, but traditional dumb text is used for out-of-proc stuff. Where is the "fatal flaw?" I don't understand where the perceived downside is - you wish Powershell was implemented in Python, not .NET?
- Touche 11y ago> Where is the "fatal flaw?" The fatal flaw is that I have to distinguish between "within Powershell" and "out-of-proc". I simply don't have this issue with plain text; I don't know or care what language/runtime the programs I use are written in/for because they all use the same interface.
- kelvin0 11y agoI made a big push at some point to start using Powershell instead of the horrible .bat files I had written at some point (and their arcane unreadable commands). But Powershell's syntax, convoluted names and the unreadable code we had to write to do simple things really made me reconsider seriously. I simply use Python for these things (99% time it has all I need).
- ZenoArrow 11y agoI don't really understand this. If you don't like the verbose names of PowerShell commands, you still have the option to set up command aliases. Out of the box, PowerShell includes a number of common Unix terminal commands as aliases: https://technet.microsoft.com/en-us/library/dd347739.aspx https://technet.microsoft.com/en-us/library/dd347739.aspx
- kelvin0 11y agoWell right there, that's an extra step that I don't need to do when using Python. But I'll have a look at the link, thanks!
- cableshaft 11y agoHa, that explains why the other day I typed 'ls' out of habit in Powershell and it still printed out the folder contents. Now that I know it's not just that one command, it should make some things easier.
- UK-AL 11y agoWithout seeing the script, it's hard to make judgement. Powershell has a ton of alias(Use Get-Alias to find them) and shortcuts, but most people don't use them.
- emodendroket 11y agoI think most people discourage their use in scripts, which is understandable if you want to maintain the script easily.
- gnoway 11y agoOne thing is that Powershell has some built-in "cmdlets" which would be buried in the filesystem (and not in the PATH) otherwise. I'm thinking specifically about the PS equivalent of signtool.exe, which is normally in an SDK path under program files (x86) depending on which SDK(s) you have installed. Do I remember the name of the signing cmdlet(s)? Nope! Is this really better than just using alias, or changing the PATH? Probably not. Another reason is vendor support. For example, VMware publishes a set of PS cmdlets as 'PowerCLI' for doing stuff in vSphere, but if you want to do something outside PS you're going to have to script/code against an SDK. I suspect there are other vendors doing the same thing. That may be a PS benefit. I usually end up writing a script instead although I found e.g. bulk movement of VMs from one set of datastores to another easier in PS. The final thing I can think of is that there are a few situations where maybe you want things to stay in-process, and you get that w/ PS whereas you wouldn't with bash. An example I have is a script that facilitates remote deployment of an MSI with impersonation of a user on the remote machine. This is pretty straightforward with a WMIObject in PS, but not in cygwin bash since Windows doesn't really have sudo or su -c (runas only works interactively) and wmic doesn't offer any impersonation capability. None of the above are really compelling for me, I end up spending 99+% of my time in bash/tmux/mintty.
- simula67 11y agoI guess the difference between bash scripting and powershell scripting is that you have to learn a lot of things upfront to be productive with Powershell. Bash, on the other hand, with its simpler syntax and collection of text based utilities you can get productive pretty quickly. If you want more power or if you want cleaner code you can always switch to Python et al. Thus, the learning curve is much more gentle. The latter embodies tinkering spirit and self-learning and the former shows its enterprise nature.
- 13of40 11y agoThe first thing you should learn with PowerShell are the discoverability features: Tab completion, Get-help, get-command, show-command, get-member, get-alias. Last time I checked (and admittedly it's been a few years) bash has man pages and that's it.
- dr_zoidberg 11y agoI agree with you (was about to post something similar), and wanted to add that some unix commands (which become part of the soul of bash scripts), are sometimes named in weird, unintuitive ways. For one thing, one potentially dangerous command is simply called "dd", and its man page[0] says next to nothing at all about its true power, uses and danger. [0] http://linux.die.net/man/1/dd http://linux.die.net/man/1/dd
- Karunamon 11y agoI don't think it's dd itself that's dangerous, rather the fact that it's usage is often paired with root access to raw device nodes on the filesystem. Even innocuous things like tee, cat, and bash output redirection can mess up your system if you blast something into /dev/sda.
- dr_zoidberg 11y agoIndeed, without root access you don't get to screw a disk with dd. But let's also admit that saying dd is a tool for copying files is a bit like saying that with a katana sword you can slice pizza... Technically true, but you're likely to get hurt in the process.
- krylon 11y ago> I can't see what benefit PS has over cygwin bash but I'd love to hear ideas For Exchange server administration, it is very useful. Enter-PSSession give you a remote shell. There was news a while back that Microsoft was going to port OpenSSH to Windows, so things will improve. I still prefer a Unix environment; tools like find are just a must-have. But compared to cmd.exe, which is the baseline many Windows people look at, it is a huge improvement. For serious scripting, I prefer Perl, though.
- bitwize 11y agoPowerShell obeys the first iron law of I/O: ALL data has a type. Bash (and Unix in general) -- does not. Now of course the implementation of typed pipelines in PowerShell is clunky and forced, because typed I/O primitives do not (yet) actually exist in Windows, so all the piping is done within one process with streams of object pointers, else it doesn't work. There are other problems, too: I recall one advocate linking me to the PowerShit solution to some admin task like changing the ACLs of a directory tree recursively. It involved including a C# program as a herestring, passing it to the C# compiler, and loading the resulting bytecode. The advocate said "Isn't this beautiful and elegant?" But in principle the model embraced by PowerShell is strictly more robust than bash's fragile "dumb byte pipes" model. "Get a byte, get a byte, get a byte, byte, byte!" --NT architect Dave Cutler, on Unix I/O
- Someone1234 11y agoAnd the UNIX style has a cost: It is insecure e.g. [0][1]. Luckily modern UNIX-based systems are rarely used as multi-user terminals these days or we would see many more privilege escalations via exploiting bugs in scripts which iterate over user owned files. Even in web scenarios, most web frameworks carefully manage what is allowed in a filename or set the filename themselves. Ultimately because on UNIX there is no type, you have to make assumptions. These assumptions are sometimes dangerously wrong. You can definitely write scripts and execute commands in a more secure way, but you can go google Linux tutorials right now and find tons of examples where newbies are taught to do it wrong out of the gate. Data types make this "secure by default." String for everything requires the script-writer or command line-writer to be perfect every time they hit return. [0] http://www.defensecode.com/public/DefenseCode_Unix_WildCards_Gone_Wild.txt http://www.defensecode.com/public/DefenseCode_Unix_WildCards... [1] https://www.helpnetsecurity.com/2014/06/27/exploiting-wildcards-on-linux/ https://www.helpnetsecurity.com/2014/06/27/exploiting-wildca...
- striking 11y agoBash scripts aren't usually intended to be secure. They're quickly written one-offs that do some tiny task and do it well, not usually exposed to an insecure environment or externally controlled input. If you want to write a good program, use a programming language that cares about good programming. Bash et al. don't care about how good the program is, they care about getting something done quick.
- UK-AL 11y agoThis will help with longwinded'ness gal * | more A whole list of short alias's