Is PowerShell ready to replace my Cygwin shell on Windows? [closed]
I'm debating whether I should learn PowerShell, or just stick with Cygwin/Perl scripts/Unix shell scripts, etc.
The benefit of PowerShell would be that the scripts could be more easily used by teammates that don't have Cygwin; however, I don't know if I'd really be writing that many general purpose scripts, or if people would even use them.
Unix scripting is so powerful, does PowerShell come close enough to warrant switching over?
Here are some of the specific things (or equivalents) I would be looking for in PowerShell:
- grep
- sort
- uniq
- Perl (how close does PowerShell come to Perl's capabilities?)
- AWK
- sed
- file (the command that gives file information)
- etc.
unix shell powershell
closed as primarily opinion-based by TylerH, Jean-François Fabre, Paul Roub, Makyen, Samuel Liew♦ Mar 1 at 3:14
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
|
show 5 more comments
I'm debating whether I should learn PowerShell, or just stick with Cygwin/Perl scripts/Unix shell scripts, etc.
The benefit of PowerShell would be that the scripts could be more easily used by teammates that don't have Cygwin; however, I don't know if I'd really be writing that many general purpose scripts, or if people would even use them.
Unix scripting is so powerful, does PowerShell come close enough to warrant switching over?
Here are some of the specific things (or equivalents) I would be looking for in PowerShell:
- grep
- sort
- uniq
- Perl (how close does PowerShell come to Perl's capabilities?)
- AWK
- sed
- file (the command that gives file information)
- etc.
unix shell powershell
closed as primarily opinion-based by TylerH, Jean-François Fabre, Paul Roub, Makyen, Samuel Liew♦ Mar 1 at 3:14
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
6
I wouldn't say that, I was interested in picking up Powershell, found this page, and now I know the general differences between PS and the shell scripting I'm used to.
– Bender the Greatest
Jul 16 '11 at 16:58
4
This post suddenly rose from ashes in a HN link submission. Great work. And bad for @Bobby for closing this as not constructive.
– Sid
Jul 13 '12 at 14:27
24
If someone cannot ask how well one tool replicates the functions of another then S.O. cannot answer tool comparison questions. This is carefully worded to avoid controversy but was careless presumed "controversial" simply for looking like a Unix vs Windows question. And it got a factual, objective answer, with additional factual insight into how helpful Unix scripting might be on Windows.
– chernevik
Jul 13 '12 at 15:16
14
Why is this closed, again? Someone please edit the title to say "PowerShell vs Unix Shells on the Windows Platform" to steer the trolls away from treating it as "Windows vs Unix," which it is not. This is a perfectly constructive question - voted to reopen.
– x0n
Jul 16 '12 at 6:14
2
The op is mixing shell with tools. PowerShell has its use. But GNU is a project to bring UNIX goodies freely to other OS, including Windows. Every thing in the list op gives have a gnu implementation in Windows. Accessible from GnuWin32 or individual sites. Windows BAT isn't useless, it has redirection and pipe and conditions.
– MeaCulpa
Oct 24 '12 at 4:41
|
show 5 more comments
I'm debating whether I should learn PowerShell, or just stick with Cygwin/Perl scripts/Unix shell scripts, etc.
The benefit of PowerShell would be that the scripts could be more easily used by teammates that don't have Cygwin; however, I don't know if I'd really be writing that many general purpose scripts, or if people would even use them.
Unix scripting is so powerful, does PowerShell come close enough to warrant switching over?
Here are some of the specific things (or equivalents) I would be looking for in PowerShell:
- grep
- sort
- uniq
- Perl (how close does PowerShell come to Perl's capabilities?)
- AWK
- sed
- file (the command that gives file information)
- etc.
unix shell powershell
I'm debating whether I should learn PowerShell, or just stick with Cygwin/Perl scripts/Unix shell scripts, etc.
The benefit of PowerShell would be that the scripts could be more easily used by teammates that don't have Cygwin; however, I don't know if I'd really be writing that many general purpose scripts, or if people would even use them.
Unix scripting is so powerful, does PowerShell come close enough to warrant switching over?
Here are some of the specific things (or equivalents) I would be looking for in PowerShell:
- grep
- sort
- uniq
- Perl (how close does PowerShell come to Perl's capabilities?)
- AWK
- sed
- file (the command that gives file information)
- etc.
unix shell powershell
unix shell powershell
edited Dec 11 '14 at 22:05
Peter Mortensen
13.7k1986113
13.7k1986113
asked Feb 21 '09 at 19:42
Andy WhiteAndy White
58.5k46160200
58.5k46160200
closed as primarily opinion-based by TylerH, Jean-François Fabre, Paul Roub, Makyen, Samuel Liew♦ Mar 1 at 3:14
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
closed as primarily opinion-based by TylerH, Jean-François Fabre, Paul Roub, Makyen, Samuel Liew♦ Mar 1 at 3:14
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
6
I wouldn't say that, I was interested in picking up Powershell, found this page, and now I know the general differences between PS and the shell scripting I'm used to.
– Bender the Greatest
Jul 16 '11 at 16:58
4
This post suddenly rose from ashes in a HN link submission. Great work. And bad for @Bobby for closing this as not constructive.
– Sid
Jul 13 '12 at 14:27
24
If someone cannot ask how well one tool replicates the functions of another then S.O. cannot answer tool comparison questions. This is carefully worded to avoid controversy but was careless presumed "controversial" simply for looking like a Unix vs Windows question. And it got a factual, objective answer, with additional factual insight into how helpful Unix scripting might be on Windows.
– chernevik
Jul 13 '12 at 15:16
14
Why is this closed, again? Someone please edit the title to say "PowerShell vs Unix Shells on the Windows Platform" to steer the trolls away from treating it as "Windows vs Unix," which it is not. This is a perfectly constructive question - voted to reopen.
– x0n
Jul 16 '12 at 6:14
2
The op is mixing shell with tools. PowerShell has its use. But GNU is a project to bring UNIX goodies freely to other OS, including Windows. Every thing in the list op gives have a gnu implementation in Windows. Accessible from GnuWin32 or individual sites. Windows BAT isn't useless, it has redirection and pipe and conditions.
– MeaCulpa
Oct 24 '12 at 4:41
|
show 5 more comments
6
I wouldn't say that, I was interested in picking up Powershell, found this page, and now I know the general differences between PS and the shell scripting I'm used to.
– Bender the Greatest
Jul 16 '11 at 16:58
4
This post suddenly rose from ashes in a HN link submission. Great work. And bad for @Bobby for closing this as not constructive.
– Sid
Jul 13 '12 at 14:27
24
If someone cannot ask how well one tool replicates the functions of another then S.O. cannot answer tool comparison questions. This is carefully worded to avoid controversy but was careless presumed "controversial" simply for looking like a Unix vs Windows question. And it got a factual, objective answer, with additional factual insight into how helpful Unix scripting might be on Windows.
– chernevik
Jul 13 '12 at 15:16
14
Why is this closed, again? Someone please edit the title to say "PowerShell vs Unix Shells on the Windows Platform" to steer the trolls away from treating it as "Windows vs Unix," which it is not. This is a perfectly constructive question - voted to reopen.
– x0n
Jul 16 '12 at 6:14
2
The op is mixing shell with tools. PowerShell has its use. But GNU is a project to bring UNIX goodies freely to other OS, including Windows. Every thing in the list op gives have a gnu implementation in Windows. Accessible from GnuWin32 or individual sites. Windows BAT isn't useless, it has redirection and pipe and conditions.
– MeaCulpa
Oct 24 '12 at 4:41
6
6
I wouldn't say that, I was interested in picking up Powershell, found this page, and now I know the general differences between PS and the shell scripting I'm used to.
– Bender the Greatest
Jul 16 '11 at 16:58
I wouldn't say that, I was interested in picking up Powershell, found this page, and now I know the general differences between PS and the shell scripting I'm used to.
– Bender the Greatest
Jul 16 '11 at 16:58
4
4
This post suddenly rose from ashes in a HN link submission. Great work. And bad for @Bobby for closing this as not constructive.
– Sid
Jul 13 '12 at 14:27
This post suddenly rose from ashes in a HN link submission. Great work. And bad for @Bobby for closing this as not constructive.
– Sid
Jul 13 '12 at 14:27
24
24
If someone cannot ask how well one tool replicates the functions of another then S.O. cannot answer tool comparison questions. This is carefully worded to avoid controversy but was careless presumed "controversial" simply for looking like a Unix vs Windows question. And it got a factual, objective answer, with additional factual insight into how helpful Unix scripting might be on Windows.
– chernevik
Jul 13 '12 at 15:16
If someone cannot ask how well one tool replicates the functions of another then S.O. cannot answer tool comparison questions. This is carefully worded to avoid controversy but was careless presumed "controversial" simply for looking like a Unix vs Windows question. And it got a factual, objective answer, with additional factual insight into how helpful Unix scripting might be on Windows.
– chernevik
Jul 13 '12 at 15:16
14
14
Why is this closed, again? Someone please edit the title to say "PowerShell vs Unix Shells on the Windows Platform" to steer the trolls away from treating it as "Windows vs Unix," which it is not. This is a perfectly constructive question - voted to reopen.
– x0n
Jul 16 '12 at 6:14
Why is this closed, again? Someone please edit the title to say "PowerShell vs Unix Shells on the Windows Platform" to steer the trolls away from treating it as "Windows vs Unix," which it is not. This is a perfectly constructive question - voted to reopen.
– x0n
Jul 16 '12 at 6:14
2
2
The op is mixing shell with tools. PowerShell has its use. But GNU is a project to bring UNIX goodies freely to other OS, including Windows. Every thing in the list op gives have a gnu implementation in Windows. Accessible from GnuWin32 or individual sites. Windows BAT isn't useless, it has redirection and pipe and conditions.
– MeaCulpa
Oct 24 '12 at 4:41
The op is mixing shell with tools. PowerShell has its use. But GNU is a project to bring UNIX goodies freely to other OS, including Windows. Every thing in the list op gives have a gnu implementation in Windows. Accessible from GnuWin32 or individual sites. Windows BAT isn't useless, it has redirection and pipe and conditions.
– MeaCulpa
Oct 24 '12 at 4:41
|
show 5 more comments
18 Answers
18
active
oldest
votes
Tools are just tools.
They help or they don't.
You need help or you don't.
If you know Unix and those tools do what you need them to do on Windows - then you are a happy guy and there is no need to learn PowerShell (unless you want to explore).
My original intent was to include a set of Unix tools in Windows and be done with it (a number of us on the team have deep Unix backgrounds and a healthy dose of respect for that community.) What I found was that this didn't really help much. The reason for that is that awk/grep/sed don't work against COM, WMI, ADSI, the Registry, the cert store, etc, etc. In other words, UNIX is an entire ecosystem self-tuned around text files. As such, text processing tools are effectively management tools. Windows is a completely different ecosystem self-tuned around APIs and Objects. That's why we invented PowerShell.
What I think you'll find is that there will be lots of occasions when text-processing won't get you what you want on Windows. At that point, you'll want to pick up PowerShell. NOTE - it is not an all or nothing deal. Within PowerShell, you can call out to your Unix tools (and use their text process or PowerShell's text processing). Also you can call PowerShell from your Unix tools and get text.
Again - there is no religion here - our focus is on giving you the tools you need to succeed. That is why we are so passionate about feedback. Let us know where we are falling down on the job or where you don't have a tool you need and we'll put it on the list and get to it. In all honesty, we are digging ourselves out of a 30 year hole so it is going to take a while. That said, if you pick up the beta of Windows Server 2008 /R2 and/or the betas of our server products, I think you'll be shocked at how quickly that hole is getting filled.
With regard to usage - we've had > 3.5 million downloads to date. That does not include the people using it in Windows Server 2008 because it is included as an optional component and does not need a download. V2 will ship in all versions of Windows. It will be on-by-default for all editions except Server core where it is an optional component. Shortly after Windows 7/Windows Server 2008 R2 ships, we'll make V2 available on all platforms XP and above. In other words - your investment in learning will be applicable to a very large number of machines/environments.
One last comment. If/when you start to learn PowerShell, I think you'll be pretty happy. Much of the design is heavily influenced by our Unix backgrounds so while we are quite different, you'll pick it up very quickly (after you get over cussing that it isn't Unix :-) ). We know that people have a very limited budget for learning - that is why we are super hard-core about consistency. You are going to learn something and then you'll use it over and over and over again.
Experiment! Enjoy! Engage!
10
Thanks for your answer. I think I'm going to go ahead and learn PowerShell. It looks powerful from what I've seen so far, and I'll be able to write more useful scripts with it at work.
– Andy White
Feb 23 '09 at 0:20
55
@Jeffrey: is there a chance for a better terminal for Windows? Powershell is a powerful scripting language, but the fact it runs in cmd.exe makes it much more convenient in the interactive mode
– sumek
Jul 7 '10 at 10:23
42
This "not constructive" question generated the best insight I've seen into the whole "on Unix everything is a file" mantra, and why Windows is different. Maybe StackOverflow would be better served closing not constructive discussions?
– chernevik
Jul 13 '12 at 14:51
12
@sumek - Give ConEmu a try; I've been using it for a few weeks and it's pretty sweet: hanselman.com/blog/…
– E.Z. Hart
Jul 13 '12 at 17:43
4
Heads up: powershell doesn't like piping binary data. So beware when you're calling your trusty Unix tools, just don't do stuff liketar -c . | gzip > package.tar.gz
directly in PowerShell, or you'll suffer. See brianreiter.org/2010/01/29/…
– Interarticle
Oct 28 '13 at 4:24
|
show 10 more comments
grep
Select-String
cmdlet and -match
operator work with regexes. Also you can directly make use of .NET's regex support for more advanced functionality.
sort
Sort-Object
is more powerful (than I remember *nix's sort
). Allowing multi-level sorting on arbitrary expressions. Here PowerShell's maintenance of underlying type helps; e.g. a DateTime
property will be sorted as a DateTime
without having to ensure formatting into a sortable format.
uniq
Select-Object -Unique
Perl (how close does PowerShell come to Perl capabilities?)
In terms of Perl's breadth of domain specific support libraries: nowhere close (yet).
For general programming, PowerShell is certainly more cohesive and consistent, and easier to extend. The one gap for text munging is something equivalent to Perl's ..
operator.
AWK
It has been long enough since using AWK (must be >18 years, since later I just used Perl), so can't really comment.
sed
[See above]
file (the command that gives file information)
PowerShell's strength here isn't so much of what it can do with filesystem objects (and it gets full information here, dir
returns FileInfo
or FolderInfo
objects as appropriate) is that is the whole provider model.
You can treat the registry, certificate store, SQL Server, Internet Explorer's RSS cache, etc. as an object space navigable by the same cmdlets as the filesystem.
PowerShell is definitely the way forward on Windows. Microsoft has made it part of their requirements for future non-home products. Hence rich support in Exchange, support in SQL Server. This is only going to expand.
A recent example of this is the TFS PowerToys. Many TFS client operations are done without having to startup tf.exe each time (which requires a new TFS server connection, etc.) and is notably easier to then further process the data. As well as allowing wide access to the whole TFS client API to a greater detail than exposed in either Team Explorer of TF.exe.
2
The thing is that the provider model is interesting only because the OS doesn't use text as its universal config medium, so you NEED these providers. With UNIX most languages have APIs to touch PAM, hosts, and packages, but ultimately text will always be there.
– Daishiman
Feb 21 '09 at 23:44
11
Text is not always the best format for everything (start with databases and raster images). But I think we can agree to disagree rather than open format wars.
– Richard
Feb 22 '09 at 0:06
5
Powershell can use any object in the .NET framework, doesn't this match Perl's domain capabilities? Plus you can write cmdlets in C# etc. if you want re-usability
– Chris S
May 30 '13 at 15:01
Point by point comparison. Nice one. This should be the accepted answer. PowerShell's strength lies in its .NET foundations and how easily you can extend the system by writing new Cmdlets or even calling class libraries
– Sau001
Mar 2 at 8:27
add a comment |
As someone whose career focused on Windows enterprise development from 1997 - 2010, the obvious answer would be PowerShell for all the good reasons given previously (e.g., it is part of Microsoft's enterprise strategy; it integrates well with Windows/COM/.NET; and using objects instead of files provides for a "richer" coding model). For that reason I'd been using and promoting PowerShell for the last two years or so, with the express belief I was following the "Word of Bill."
However, as a pragmatist I'm no longer sure PowerShell is such a great answer. While it's an excellent Windows tool and provides a much needed step towards filling the historic hole that is the Window command line, as we all watch Microsoft's grip on consumer computing slip it seems increasingly likely that Microsoft has a massive battle ahead to keep its OS as important to the enterprise of the future.
Indeed, given I find my work is increasingly in heterogeneous environments, I'm finding it much more useful to use Bash scripts at the moment, as they not only work on Linux, Solaris and Mac OS X, but they also work—with the help of Cygwin—on Windows.
So if you buy into the belief that the future of the OS is commoditized rather than a monopolized, then it seems to make sense to opt for an agile development tool strategy that keeps away from proprietary tools where feasible. If however you see your future being dominated by all-that-is-Redmond then go for PowerShell.
1
Does unix scripts work perfectly on Cygwin-Windows without errors?
– Pacerier
Jan 3 '15 at 12:27
@Pacerier I've been using Cygwin and MinGW for 12 years, and had problems surprisingly rarely. The important thing is that if something doesn't work, it's always possible to fall back on Windows tools, or anything — processes can be started in the same way as any other shell starts them.
– Evgeni Sergeev
May 24 '16 at 15:56
3
Okay, your answer is from 2011. Today powershell runs on linux too. And -- my personal opinion -- bash is too antique. The syntax is horrible and I would rather use a different scripting language. Nowadays with python being standard on most linux distros I don't see any reason to use bash for scripts. I'd advise you to check out powershell again as there has happened a lot since 2011.
– itmuckel
Sep 19 '16 at 6:31
Link for those curious about PowerShell on Linux
– Chris
Oct 15 '18 at 19:37
add a comment |
I have used a bit of PowerShell for script automation. While it is very nice that the environment seems to have been thought out much more than Unix shells, in practice the use of objects instead of text streams is much more clunky, and a lot of the Unix facilities that have been developed in the last 30 years are still missing.
Cygwin is still my scripting environment of choice for Windows hosts. It certainly beats the alternatives in terms of getting things done.
27
Using objects is a paradigm shift and takes some getting used to. But avoids the whole re-parsing at each step where structured data is involved (e.g. no need to ensure fields are delimited).
– Richard
Feb 21 '09 at 21:22
16
@Andy White @Daishiman, I can understand where there is a learning curve with PowerShell, but piping objects can be much more flexible than piping text. @Richard is correct. :)
– Steven Murawski
Feb 21 '09 at 22:28
18
Auto makers had a hard time arguing with 1000+ years of horses too. I'm not trying to be flippant. Just pointing out that past success does not remove the potential benefit of innovation.
– EBGreen
Feb 21 '09 at 23:04
11
@daishiman - The benefit of Objects is that when you want a property, you ask for it - you don't have to parse,guess,cast. I did not understand your point about "what happens when objects don't have compatible methods" - Could you say that another way or give an example of the problem? Thanks.
– Jeffrey Snover - MSFT
Feb 22 '09 at 0:33
12
@Daishiman - I understand. In practice people have found this not to be a problem but rather a huge advantage. That said, I can see that if you were an expert text parser, this would be a new skill to learn and it might feel unneeded and awkward at first. Again - whatever helps is the right tool.
– Jeffrey Snover - MSFT
Feb 22 '09 at 1:21
|
show 10 more comments
There are lots of great great answers here, and here is my take. PowerShell is ready if you are... Examples:
grep = "Select-String -Pattern"
sort = "Sort-Object"
uniq = "Get-Unique"
file = "Get-Item"
cat = "Get-Content"
Perl/AWK/Sed are not commands, but utilities hence hard to compare, but you can do almost everything in PowerShell.
2
Can you believe the cryptic four-letter commands our ancestors were forced to use?
– Evgeni Sergeev
May 24 '16 at 16:10
3
@EvgeniSergeev All the above are available by default assls
,sort
,gu
,gi
,gc
, respectively. Long readable names which tab-complete, and short type-able names in one system. That's user-friendly progress for you.
– TessellatingHeckler
Sep 16 '17 at 4:13
add a comment |
I have only recently started dabbling in PowerShell with any degree of seriousness. Although for the past seven years I've worked in an almost exclusively Windows-based environment, I come from a Unix background and find myself constantly trying to "Unix-fy" my interaction experience on Windows. It's frustrating to say the least.
It's only fair to compare PowerShell to something like Bash, tcsh, or zsh since utilities like grep, sed, awk, find, etc. are not, strictly speaking, part of the shell; they will always, however, be part of any Unix environment. That said, a PowerShell command like Select-String has a very similar function to grep and is bundled as a core module in PowerShell ... so the lines can be a little blurred.
I think the key thing is culture, and the fact that the respective tool-sets will embody their respective cultures:
- Unix is a file-based, (in general, non Unicode) text-based culture. Configuration files are almost exclusively text files. Windows, on the other hand has always been far more structured in respect of configuration formats--configurations are generally kept in proprietary databases (e.g., the Windows registry) which require specialised tools for their management.
The Unix administrative (and, for many years, development) interface has traditionally been the command line and the virtual terminal. Windows started off as a GUI and administrative functions have only recently started moving away from being exclusively GUI-based. We can expect the Unix experience on the command line to be a richer, more mature one given the significant lead it has on PowerShell, and my experience matches this. On this, in my experience:
The Unix administrative experience is geared towards making things easy to do in a minimal amount of key strokes; this is probably as a result of the historical situation of having to administer a server over a slow 9600 baud dial-up connection. Now PowerShell does have aliases which go a long way to getting around the rather verbose Verb-Noun standard, but getting to know those aliases is a bit of a pain (anyone know of something better than:
alias | where {$_.ResolvedCommandName -eq "<command>"}
?).
An example of the rich way in which history can be manipulated:
iptables
commands are often long-winded and repeating them with slight differences would be a pain if it weren't for just one of many neat features of history manipulation built into Bash, so inserting an iptables rule like the following:
iptables -I camera-1-internet -s 192.168.0.50 -m state --state NEW -j ACCEPT
a second time for another camera ("
camera-2
"), is just a case of issuing:
!!:s/-1-/-2-/:s/50/51
which means "perform the previous command, but substitute
-1-
with-2-
and50
with51
.
The Unix experience is optimised for touch-typists; one can pretty much do everything without leaving the "home" position. For example, in Bash, using the Emacs key bindings (yes, Bash also supports vi bindings), cycling through the history is done using Ctrl-P and Ctrl-N whilst moving to the start and end of a line is done using Ctrl-A and Ctrl-E respectively ... and it definitely doesn't end there. Try even the simplest of navigation in the PowerShell console without moving from the home position and you're in trouble.
- Simple things like versatile paging (a la less) on Unix don't seem to be available out-of-the-box in PowerShell which is a little frustrating, and a rich editor experience doesn't exist either. Of course, one can always download third-party tools that will fill those gaps, but it sure would be nice if these things were just "there" like they are on pretty much any flavour of Unix.
The Windows culture, at least in terms of system API's is largely driven by the supporting frameworks, viz., COM and .NET, both of-which are highly structured and object-based. On the other hand, access to Unix APIs has traditionally been through a file interface (
/dev
and/proc
) or (non-object-oriented) C-style library calls. It's no surprise then that the scripting experiences match their respective OS paradigms. PowerShell is by nature structured (everything is an object) and Bash-and-friends file-based. The structured API which is at the disposal of a PowerShell programmer is vast (essentially matching the vastness of the existing set of standard COM and .NET interfaces).
In short, although the scripting capabilities of PowerShell are arguably more powerful than Bash (especially when you consider the availability of the .NET BCL), the interactive experience is significantly weaker, particularly if you're coming at it from an entirely keyboard-driven, console-based perspective (as many Unix-heads are).
You ask "anyone know of something better than: alias | where {$_.ResolvedCommandName -eq "<command>"}?". How about justalias -Definition *property
(or any other pattern)? I think the problem with your answer is that you are conflating the shell and the console: remember you have a choice of consoles with different editing options. They deliberately left the DOS console editing broken to encourage people to use other consoles such as ISE.
– Duncan
Feb 12 '14 at 9:17
BTW, your!!
example can be written in Powershell as(h -c 1) -replace '-1-','-2-' -replace '50','51' | iex
but it's easier to up arrow and edit for a single command. If you want to do it across a lot of commands I think Powershell would win. To repeat 10 commands ending at command #255 with your edits:(h -c 10 -id 255) -replace '-1-','-2-' -replace '50','51' | iex
Also Powershell's history lets you do things unheard of in Linux shells; if you wonder retrospectively just how long a command took to run:h -id 20 | select { $_.EndExecutionTime - $_.StartExecutionTime }
– Duncan
Feb 12 '14 at 9:32
@Duncan In respect of your comment re the shell and the console--I think that that's just a fundamental difference between Bash and PS; that is: Bash expects to deliver a certain interactive experience whereas PS "leaves" that to something else. I don't have a lot of experience with the ISE console, but from I can remember, it doesn't have a tremendously rich interactive experience either.
– Eric Smith
Feb 14 '14 at 13:21
@Duncan, yes - good point about the ability of PS to deliver in respect of clever history tricks.
– Eric Smith
Feb 14 '14 at 13:24
@Duncan ... but despite your assertion that some things are unheard of in Linux shells:fc -e "sed -i -e 's/-1-/-2-/g' -e 's/50/51/g'" 10 255
– Eric Smith
Feb 14 '14 at 13:56
|
show 1 more comment
I am not a very experienced PowerShell user by any means, but the little bit of it that I was exposed to impressed me a great deal. You can chain the built-in cmdlets together to do just about anything that you could do at a Unix prompt, and there's some additional goodness for doing things like exporting to CSV, HTML tables, and for more in-depth sys-admin types of jobs. And if you really needed something like sed, there's always UnixUtils or GnuWin32, which you could integrate with Powershell fairly easily.
As a longtime Unix user, I did however have a bit of trouble getting used to the command naming scheme, and I certainly would have benefitted more from it if I knew more .NET.
So essentially, I say it's well worth learning it if the Windows-only-ness of it doesn't pose a problem.
1
There is an open source project "Pash" that lets you run PowerShell on other platforms via Mono. tinyurl.com/6dyoso
– John D. Cook
Feb 21 '09 at 20:46
Whoa! Thanks for the tip; I can't wait to give it a try
– yalestar
Feb 21 '09 at 22:29
add a comment |
When you compare PowerShell to the combination Cygwin/Perl/Shell, be aware that PowerShell only represents the "Shell" part of that combination.
You can however invoke any command from PowerShell just as you do from cmd.exe or Cygwin. It does not re-implement the specified functions, and it is certainly not comparable to Perl.
It's "just" a shell, but it makes programming easier providing a comfortable interface to the .Net universe.
Also keep in mind that PowerShell requires WinXP, Srv2003 or higher, which may pose a problem depending on your IT infrastructure.
Update:
I had no idea what kind of philosophical debate my answer would spark.
I posted my answer in the context of the question: Compare PowerShell to Cygwin and Perl and bash.
PowerShell is a shell, as it makes no syntactic difference between built-in commands, commandlets, user functions, and external commands (.exe, .bat, .cmd). Only invoking .Net methods differ by adding a namespace or an object in the call.
Its programmability derives from .Net framework, not from anything specific to the PowerShell "language".
I'd say I believe PowerShell is a "scripting language" as soon as Bugzilla or MediaWiki are implemented as PowerShell scripts running on a web server ;)
Until then, enjoy the comparisons.
Yeah, I guess when I'm talking about Unix "shell" I'm also referring to all the normal utilities that come with Unix, such as grep, awk, etc. I'm just wondering if PowerShell offers similar utilities out-of-the-box.
– Andy White
Feb 21 '09 at 20:06
3
Powershell is not "just a shell". It is a scripting language. I wonder in what way it is not comparable to perl? I admit that it isn't as mature, but beyond that I don't see the disparity.
– EBGreen
Feb 21 '09 at 23:11
@EBGreen, What exactly do you mean with this comment? I agree that any shell or scripting language is inherently similar, but I was wondering more about the specific capabilities of PowerShell vs. bash/perl/other unix shells/scripting languages.
– Andy White
Feb 21 '09 at 23:33
2
Powershell has an incredibly wide range of functions. It is - A interactive, composable shell - A rich interactive scripting language - A programming language It has a rich set of OO & tesxt utility functions (i.e. equivalents to grep/awk/etc) as well.
– Jeffrey Snover - MSFT
Feb 22 '09 at 0:28
1
@Andy - I understood Devio to say that powershell is not as powerful as Perl. I don't believe that is true and I just wondered why he thought that was the case.
– EBGreen
Feb 22 '09 at 4:15
|
show 2 more comments
If you like shell scripting you will love PowerShell!
Start at A guided tour of the Microsoft Command Shell (Ars Technica).
8
I love shell scripting and I tolerate PowerShell. It's commands and syntax are atrocious. Horribly long commands and options without any useful command completion. Or if there is I haven't found it. Too many features crammed into single commands that should be separated out. Weird variable and escape syntax only a DOS batch programmer could love.
– Zan Lynx
Jun 24 '10 at 5:32
8
@Zan Lynx - You are right about not having found stuff. All commands have aliases, and many of them match both DOS and UNIX commands ( ps, dir, rm, ls, kill, history, man, cat, clear etc.) The names are long so that they have a meaningful name. Great for scripts -it helps when a new person has to use and maintain it. There is tab expansion for cmdlets, functions, variable, path, parameters etc. Much of the syntax is from Unix shells and what escape syntax are you talking about? `` is not used for escape since it is the path separator in Windows.
– manojlds
Aug 24 '11 at 4:49
3
@Zan Lynx - Your arguments are not valid. To stop interpreting variables, use'
(single quotes). To the double double quotes thing - same, usewrite-output 'this is a "test"'
. The question you are pointing to is for Regex and the escaping for regex is valid everywhere. Powershell has Here-Strings / verbatim strings as well. Even Java doesn't have these! Try escaping regex in Java. And you don't sometimes use literalpath. You use when you need to. LiteralPath treats wildcard characters verbatim and doesn't expand them. You use it when your files have it. It gives you more options.
– manojlds
Aug 24 '11 at 5:41
3
@manojlds: Compared to the bash shell, Powershell is full of inconsistencies that make no sense and are just confusing. In bash you use the same escape character everywhere and file paths are escaped just as strings are. You don't need a special parameter for it. If you expand a variable that has special characters in it, you put it in double quotes and the contents are safe, no need to call a function to re-escape it.
– Zan Lynx
Aug 24 '11 at 5:46
5
@Zan Lynx - There are no inconsistencies. Evenwrite-output "this is a `"test`""
works. Just use`
instead of ``. regex::escape exists to help you so that you don't miss escaping stuff. It is not necessary to use it. You are thinking that additional options that are there to help you and prevent mistakes are inconsistencies.
– manojlds
Aug 24 '11 at 5:51
|
show 4 more comments
As my recent experiments led me into depths of PowerShell and .NET calls, I must say that PowerShell can replace Cygwin and Unix shell.
I'm not sure about Perl, but since both PowerShell and Perl are Turing complete as programming languages, I give this as a yes to replacing Perl too.
One thing that PowerShell has above Cygwin and ordinary Bash under *nix, is its ability to perform sandboxed DLL calls, manipulating the operating system via direct API calls, WMI methods and even COM objects. How about launching Internet Explorer via code, then doing whatever you want with its displayed document, effectively emulating a back-end for a Web server?
How about gathering data from SQL servers and other data providers, parse them and export as CSV, mail messages, text and actually any kind of existing and non-existing file formats? (With proper skills of creating a valid file out of data received, of course, but CSV are readily available).
And there is an extra security available via signed cmdlets and scripts,
group policies, and execution policies that help prevent malicious code from running on your system even if you run them as administrator.
About what commands are implemented - the answer by Richard lists them and PowerShell's capability of emulating their functionality already.
About whether PowerShell is strong to warrant switching over - this is more a matter of personal preference, although as more and more Windows services are providing PowerShell cmdlets to control them, not using PowerShell with these services present is considered a hindrance. (Hyper-V server is the primary such service, and it also provides the ability to do more with PowerShell cmdlets than with GUI!)
Probably this answer is five years late, but still, if someone performs administrative tasks or general scripting of various stuff on Windows, they should definitely try harnessing PowerShell for their purposes.
add a comment |
TL;DR -- I don't hate Windows or PowerShell I just can't do anything in windows or on PowerShell.
I personally still find PowerShell underwhelming at best.
- tab completion of directory paths do not compound, requiring the user to enter a path separator after every name completion.
- I still feel like windows doesn't even the concept of path or of what a path is, with no accessible user home indicator
~/
short of some@environment://somejibberish/%user_home%
NTFS is still a mess and seemingly always will be, good luck navigating.
cmd-esque interface, The dinosaur cmd.exe is still visible in PowerShell,
edit->mark
still being the only way to copy information, and copying only in the form of rectangular blocks of visible terminal space. andedit->paste
still being the only way to paste strings into the terminal.Painting it blue doesn't make it any more attractive. I don't mind MS developers having a taste in color though.
Windows always opens at top left corner of screen, For somebody who uses vertical task bars this is incredibly annoying, especially considering that the windows task bar will cover the only corner of the window that gives access to copy/paste functionality.
I can't speak much on the grounds of the tools windows includes. Being that there is a whole set of open-source, freely licensed CLI tools, and PowerShell ships with, to my knowledge, none of them is an utter disappointment.
- PowerShell
wget
takes seemingly incomparable arguments to GNU wget, thanks glimmer of hope portably-useless. - PowerShell POSIX is not Bash-compatible, particularly the
&&
operator is not handled, making the simplest of conditional command following not a thing.
I don't know man; I gave it a shot, I really did; I still try to give it a shot in the hopes that the next time I open it it will be any less useless. I cannot do anything in PowerShell, and I can barely do things with a real project to bring GNU tools to Windows.
MySysGit gives me the dinosaur cmd.exe prompt with a couple of GNU tools, and it is still very underwhelming, but at last path completion works. And the Git command will run in Git Bash.
Mintty for MySysGit gives the Cygwin interface over mysysgit's environment, making copy and paste a thing (select to copy (mouse), shift+ins to paste, how modern...). However, things like git push
are broken in Mintty.
I don't mean to rant, but I still see huge problems with command-line usability on Windows even given tools like Cygwin.
P.S.: Just because something can be done in PowerShell, doesn't make it usable. Usability is deeper than ability and is what I tend to focus on when trying to use a product as a consumer.
Turn on QuickEdit mode? Select and press enter to copy, ctrl-v to paste, no more Edit->Mark or Edit->Paste. While in the preferences, set the Window position and untick "let system position window". Tab completion is not just completing filesystem paths, it's also completing variable names, command names, object properties, you might be about to type.
or[
to access a property or index, so it can't just add a path separator on the end. Which PowerShell wget, exactly? Which PowerShell POSIX? It's not trying to bring gnu tools to Windows, or be bash-compatible btw.
– TessellatingHeckler
Mar 27 '14 at 0:22
Yeah i know it's not trying to be bash. I refrained from saying so in the original post. I would say which w get binary but there is no "which" command in power shell :( i don't recall where buy i read power Shell was supposed to be POSIX compatible
– ThorSummoner
Mar 27 '14 at 0:31
5
re: "no which" ->(get-command wg*.exe).Path
. Re: bash completion and readline -> leeholmes.com/blog/2012/09/13/… leading to github.com/lzybkr/PSReadLine
– TessellatingHeckler
Mar 27 '14 at 5:14
add a comment |
The cmdlets in PowerShell are very nice and work reliably. Their object-orientedness appeals to me a lot since I'm a Java/C# developer, but it's not at all a complete set. Since it's object oriented, it's missed out on a lot of the text stream maturity of the POSIX tool set (awk
and sed
to name a few).
The best answer I've found to the dilemma of loving OO techniques and loving the maturity in the POSIX tools is to use both! One great aspect of PowerShell is that it does an excellent job piping objects to standard streams. PowerShell by default uses an object pipeline to transport its objects around. These aren't the standard streams (standard out, standard error, and standard in). When PowerShell needs to pass output to a standard process that doesn't have an object pipeline, it first converts the objects to a text stream. Since it does this so well, PowerShell makes an excellent place to host POSIX tools!
The best POSIX tool set is GnuWin32. It does take more than 5 seconds to install, but it's worth the trouble, and as far as I can tell, it doesn't modify your system (registry, c:windows*
folders, etc.) except copying files to the directories you specify. This is extra nice because if you put the tools in a shared directory, many people can access them concurrently.
GnuWin32 Installation Instructions
Download and execute the exe (it's from the SourceForge site) pointing it to a suitable directory (I'll be using C:bin
). It will create a GetGnuWin32
directory there in which you will run download.bat
, then install.bat
(without parameters), after which, there will be a C:binGetGnuWin32gnuwin32bin
directory that is the most useful folder that has ever existed on a Windows machine. Add that directory to your path, and you're ready to go.
add a comment |
I haven't seen that the PowerShell has really taken off, at least not yet. So it might not be worth the effort of learning it unless those others on your team already know it.
For your predicament you might be better off with a scripting language that others could get behind, Perl like you mentioned, or others like Ruby or Python.
I think a lot of it depends on what you need to do. Personally I've been using Python for my own personal scripts, but I know when I start writing something that I'll never be able to pass it on - so I try not to do anything too revolutionary.
add a comment |
Why not use both? Call PowerShell scripts in Cygwin just like any other interpreted scripts like Perl, etc.
I do this enough that I wrote https://bitbucket.org/jbianchi/powershell for a Bash wrapper to call powershell.exe in Cygwin. It can be used as a shebang as the first line of a powershell.exe .ps1 script (since PowerShell also uses "#" as a comment). See https://bitbucket.org/jbianchi/powershell/wiki/Home for examples
add a comment |
In a couple of lines, Cygwin and PowerShell are different tools however if you have Cygwin installed you can run the Cygwin executables within a PowerShell session. I've gotten so used to PowerShell that now I no longer use grep, sort, awk, etc. There are pretty much built-in alternatives in PowerShell, and if not you can find a cmdlet out there.
The main tool I find myself using is ssh.exe, but within a PowerShell session.
It works great.
add a comment |
PowerShell is very powerful, more powerful than the standard built-ins of the Unix shells (but only because it includes much of the functionality usually shelled out to subprograms). Also, consider that you can write applets in any .NET language, including IronPython, IronRuby, PerlNet, etc.. or you can simply call your cygwin commands from PowerShell, ignoring all the extra functionality and it will work similarly to bash, korn, or whatever...
I think you may be missing the design goals of Unix shells. Not knocking PowerShell (would like to learn more myself) but you need to understand Unix tooling to make a statement like that.
– Jé Queue
Jan 7 '11 at 17:24
2
@Xepoch - No, I think you're missing the design goals of PowerShell. PowerShell can do everything the Unix shells can do in the same way that they do it. However, the real power comes when you utilize PS's object piping system rather than just parsing text output. So, PowerShell can do exactly what bash or korn can do, but they can't do what PowerShell can do.
– Erik Funkenbusch
Jan 7 '11 at 17:31
3
I simply don't know PowerShell enough to give you a critique thereon, but as you clearly know the goals of the Unix shells are not necessarily a fully comprehensive replacement of external tooling, rather the control structures around it. Again I cannot at this time compare nor contrast but elevating PowerShell because it has more built-ins is not necessarily the boon of the Unix shells.
– Jé Queue
Jan 7 '11 at 18:07
@Xepoch - The point is, you can choose which way you want to do it. You can use all the goodness of the built-in shell, or you can ignore and do it the way Unix does it. It's your choice. And choice is good, right?
– Erik Funkenbusch
Jan 7 '11 at 18:08
add a comment |
I found PowerShell programming to be not worth the effort.
I have several years of experience with shell scripting under Unix, but I found it enormously difficult to do much of anything with PowerShell.
It seems like many functions require you to interrogate the Windows Management Interface and issue SQL-like commands to get the information you need.
For example, I wanted to write a script to remove all files with a specific suffix from a directory tree. Under Unix, this would be a simple ...
find . -name *.xyz -exec rm {} ;
After a couple of hours dicking around with Scripting.FileSystemObject
and WScript.Shell
and issuing "SELECT * FROM Win32_ShortcutFile WHERE Drive = '" & drive & "' AND Path = '" & searchFolder & "'", I finally gave up and settled for Windows Explorer's Search command and just do it manually. There's probably some way to do what I wanted, but I didn't see anything obvious and all the examples on the MSDN site were so trivial as to be worthless.
EDIT Heh, of course as soon as I wrote this I poked around some more and found what I had been missing: the -recurse
option to the remove-item command is faulty (revealed if you use get-help remove-item -detailed
).
I had been trying "remove-item -filter '* .xyz' -recurse" and it wasn't working, so I gave up on it.
Turns out you need to use get-childitem -filter '*.xyz' -recurse | remove-item
16
I think you're confusing Windows Scripting Host (WSH) with PowerShell. They're totally different.
– Erik Funkenbusch
Feb 22 '09 at 3:05
3
As an example, if you want to delete all the files that end in .TMN you can issue this command get-childitem c: -include *.TMN -recurse | foreach ($_) {remove-item $_.fullname}
– Erik Funkenbusch
Feb 22 '09 at 3:10
@Mystere: I tried this, and it didn't seem to work. After some futzing about, it seems that *.tmn is what you need (instead of just .tmn)
– redtuna
Jun 23 '10 at 20:47
5
I couldn't respectfully disagree more, and I'm by no means a Windows guy. I find PS much easier to script than bash. PS is more consistent. With Bash, any console utility you invoke has its own syntax, and unique behavior, and the bash syntax itself is rather cryptic. PS is much more robust with language features like anonymous functions, (scriptblocks), parameter validation, advanced functions etc. Plus concepts of modules for portability and many other features. Mainly though, the biggest reason is the thing you always hear about PS, objects trump text. Bash is still faster though.
– user2233949
Apr 28 '15 at 22:27
add a comment |
You can also try running Bash scripts on Windows using BashWin at
https://github.com/skanga/BashWin.
add a comment |
18 Answers
18
active
oldest
votes
18 Answers
18
active
oldest
votes
active
oldest
votes
active
oldest
votes
Tools are just tools.
They help or they don't.
You need help or you don't.
If you know Unix and those tools do what you need them to do on Windows - then you are a happy guy and there is no need to learn PowerShell (unless you want to explore).
My original intent was to include a set of Unix tools in Windows and be done with it (a number of us on the team have deep Unix backgrounds and a healthy dose of respect for that community.) What I found was that this didn't really help much. The reason for that is that awk/grep/sed don't work against COM, WMI, ADSI, the Registry, the cert store, etc, etc. In other words, UNIX is an entire ecosystem self-tuned around text files. As such, text processing tools are effectively management tools. Windows is a completely different ecosystem self-tuned around APIs and Objects. That's why we invented PowerShell.
What I think you'll find is that there will be lots of occasions when text-processing won't get you what you want on Windows. At that point, you'll want to pick up PowerShell. NOTE - it is not an all or nothing deal. Within PowerShell, you can call out to your Unix tools (and use their text process or PowerShell's text processing). Also you can call PowerShell from your Unix tools and get text.
Again - there is no religion here - our focus is on giving you the tools you need to succeed. That is why we are so passionate about feedback. Let us know where we are falling down on the job or where you don't have a tool you need and we'll put it on the list and get to it. In all honesty, we are digging ourselves out of a 30 year hole so it is going to take a while. That said, if you pick up the beta of Windows Server 2008 /R2 and/or the betas of our server products, I think you'll be shocked at how quickly that hole is getting filled.
With regard to usage - we've had > 3.5 million downloads to date. That does not include the people using it in Windows Server 2008 because it is included as an optional component and does not need a download. V2 will ship in all versions of Windows. It will be on-by-default for all editions except Server core where it is an optional component. Shortly after Windows 7/Windows Server 2008 R2 ships, we'll make V2 available on all platforms XP and above. In other words - your investment in learning will be applicable to a very large number of machines/environments.
One last comment. If/when you start to learn PowerShell, I think you'll be pretty happy. Much of the design is heavily influenced by our Unix backgrounds so while we are quite different, you'll pick it up very quickly (after you get over cussing that it isn't Unix :-) ). We know that people have a very limited budget for learning - that is why we are super hard-core about consistency. You are going to learn something and then you'll use it over and over and over again.
Experiment! Enjoy! Engage!
10
Thanks for your answer. I think I'm going to go ahead and learn PowerShell. It looks powerful from what I've seen so far, and I'll be able to write more useful scripts with it at work.
– Andy White
Feb 23 '09 at 0:20
55
@Jeffrey: is there a chance for a better terminal for Windows? Powershell is a powerful scripting language, but the fact it runs in cmd.exe makes it much more convenient in the interactive mode
– sumek
Jul 7 '10 at 10:23
42
This "not constructive" question generated the best insight I've seen into the whole "on Unix everything is a file" mantra, and why Windows is different. Maybe StackOverflow would be better served closing not constructive discussions?
– chernevik
Jul 13 '12 at 14:51
12
@sumek - Give ConEmu a try; I've been using it for a few weeks and it's pretty sweet: hanselman.com/blog/…
– E.Z. Hart
Jul 13 '12 at 17:43
4
Heads up: powershell doesn't like piping binary data. So beware when you're calling your trusty Unix tools, just don't do stuff liketar -c . | gzip > package.tar.gz
directly in PowerShell, or you'll suffer. See brianreiter.org/2010/01/29/…
– Interarticle
Oct 28 '13 at 4:24
|
show 10 more comments
Tools are just tools.
They help or they don't.
You need help or you don't.
If you know Unix and those tools do what you need them to do on Windows - then you are a happy guy and there is no need to learn PowerShell (unless you want to explore).
My original intent was to include a set of Unix tools in Windows and be done with it (a number of us on the team have deep Unix backgrounds and a healthy dose of respect for that community.) What I found was that this didn't really help much. The reason for that is that awk/grep/sed don't work against COM, WMI, ADSI, the Registry, the cert store, etc, etc. In other words, UNIX is an entire ecosystem self-tuned around text files. As such, text processing tools are effectively management tools. Windows is a completely different ecosystem self-tuned around APIs and Objects. That's why we invented PowerShell.
What I think you'll find is that there will be lots of occasions when text-processing won't get you what you want on Windows. At that point, you'll want to pick up PowerShell. NOTE - it is not an all or nothing deal. Within PowerShell, you can call out to your Unix tools (and use their text process or PowerShell's text processing). Also you can call PowerShell from your Unix tools and get text.
Again - there is no religion here - our focus is on giving you the tools you need to succeed. That is why we are so passionate about feedback. Let us know where we are falling down on the job or where you don't have a tool you need and we'll put it on the list and get to it. In all honesty, we are digging ourselves out of a 30 year hole so it is going to take a while. That said, if you pick up the beta of Windows Server 2008 /R2 and/or the betas of our server products, I think you'll be shocked at how quickly that hole is getting filled.
With regard to usage - we've had > 3.5 million downloads to date. That does not include the people using it in Windows Server 2008 because it is included as an optional component and does not need a download. V2 will ship in all versions of Windows. It will be on-by-default for all editions except Server core where it is an optional component. Shortly after Windows 7/Windows Server 2008 R2 ships, we'll make V2 available on all platforms XP and above. In other words - your investment in learning will be applicable to a very large number of machines/environments.
One last comment. If/when you start to learn PowerShell, I think you'll be pretty happy. Much of the design is heavily influenced by our Unix backgrounds so while we are quite different, you'll pick it up very quickly (after you get over cussing that it isn't Unix :-) ). We know that people have a very limited budget for learning - that is why we are super hard-core about consistency. You are going to learn something and then you'll use it over and over and over again.
Experiment! Enjoy! Engage!
10
Thanks for your answer. I think I'm going to go ahead and learn PowerShell. It looks powerful from what I've seen so far, and I'll be able to write more useful scripts with it at work.
– Andy White
Feb 23 '09 at 0:20
55
@Jeffrey: is there a chance for a better terminal for Windows? Powershell is a powerful scripting language, but the fact it runs in cmd.exe makes it much more convenient in the interactive mode
– sumek
Jul 7 '10 at 10:23
42
This "not constructive" question generated the best insight I've seen into the whole "on Unix everything is a file" mantra, and why Windows is different. Maybe StackOverflow would be better served closing not constructive discussions?
– chernevik
Jul 13 '12 at 14:51
12
@sumek - Give ConEmu a try; I've been using it for a few weeks and it's pretty sweet: hanselman.com/blog/…
– E.Z. Hart
Jul 13 '12 at 17:43
4
Heads up: powershell doesn't like piping binary data. So beware when you're calling your trusty Unix tools, just don't do stuff liketar -c . | gzip > package.tar.gz
directly in PowerShell, or you'll suffer. See brianreiter.org/2010/01/29/…
– Interarticle
Oct 28 '13 at 4:24
|
show 10 more comments
Tools are just tools.
They help or they don't.
You need help or you don't.
If you know Unix and those tools do what you need them to do on Windows - then you are a happy guy and there is no need to learn PowerShell (unless you want to explore).
My original intent was to include a set of Unix tools in Windows and be done with it (a number of us on the team have deep Unix backgrounds and a healthy dose of respect for that community.) What I found was that this didn't really help much. The reason for that is that awk/grep/sed don't work against COM, WMI, ADSI, the Registry, the cert store, etc, etc. In other words, UNIX is an entire ecosystem self-tuned around text files. As such, text processing tools are effectively management tools. Windows is a completely different ecosystem self-tuned around APIs and Objects. That's why we invented PowerShell.
What I think you'll find is that there will be lots of occasions when text-processing won't get you what you want on Windows. At that point, you'll want to pick up PowerShell. NOTE - it is not an all or nothing deal. Within PowerShell, you can call out to your Unix tools (and use their text process or PowerShell's text processing). Also you can call PowerShell from your Unix tools and get text.
Again - there is no religion here - our focus is on giving you the tools you need to succeed. That is why we are so passionate about feedback. Let us know where we are falling down on the job or where you don't have a tool you need and we'll put it on the list and get to it. In all honesty, we are digging ourselves out of a 30 year hole so it is going to take a while. That said, if you pick up the beta of Windows Server 2008 /R2 and/or the betas of our server products, I think you'll be shocked at how quickly that hole is getting filled.
With regard to usage - we've had > 3.5 million downloads to date. That does not include the people using it in Windows Server 2008 because it is included as an optional component and does not need a download. V2 will ship in all versions of Windows. It will be on-by-default for all editions except Server core where it is an optional component. Shortly after Windows 7/Windows Server 2008 R2 ships, we'll make V2 available on all platforms XP and above. In other words - your investment in learning will be applicable to a very large number of machines/environments.
One last comment. If/when you start to learn PowerShell, I think you'll be pretty happy. Much of the design is heavily influenced by our Unix backgrounds so while we are quite different, you'll pick it up very quickly (after you get over cussing that it isn't Unix :-) ). We know that people have a very limited budget for learning - that is why we are super hard-core about consistency. You are going to learn something and then you'll use it over and over and over again.
Experiment! Enjoy! Engage!
Tools are just tools.
They help or they don't.
You need help or you don't.
If you know Unix and those tools do what you need them to do on Windows - then you are a happy guy and there is no need to learn PowerShell (unless you want to explore).
My original intent was to include a set of Unix tools in Windows and be done with it (a number of us on the team have deep Unix backgrounds and a healthy dose of respect for that community.) What I found was that this didn't really help much. The reason for that is that awk/grep/sed don't work against COM, WMI, ADSI, the Registry, the cert store, etc, etc. In other words, UNIX is an entire ecosystem self-tuned around text files. As such, text processing tools are effectively management tools. Windows is a completely different ecosystem self-tuned around APIs and Objects. That's why we invented PowerShell.
What I think you'll find is that there will be lots of occasions when text-processing won't get you what you want on Windows. At that point, you'll want to pick up PowerShell. NOTE - it is not an all or nothing deal. Within PowerShell, you can call out to your Unix tools (and use their text process or PowerShell's text processing). Also you can call PowerShell from your Unix tools and get text.
Again - there is no religion here - our focus is on giving you the tools you need to succeed. That is why we are so passionate about feedback. Let us know where we are falling down on the job or where you don't have a tool you need and we'll put it on the list and get to it. In all honesty, we are digging ourselves out of a 30 year hole so it is going to take a while. That said, if you pick up the beta of Windows Server 2008 /R2 and/or the betas of our server products, I think you'll be shocked at how quickly that hole is getting filled.
With regard to usage - we've had > 3.5 million downloads to date. That does not include the people using it in Windows Server 2008 because it is included as an optional component and does not need a download. V2 will ship in all versions of Windows. It will be on-by-default for all editions except Server core where it is an optional component. Shortly after Windows 7/Windows Server 2008 R2 ships, we'll make V2 available on all platforms XP and above. In other words - your investment in learning will be applicable to a very large number of machines/environments.
One last comment. If/when you start to learn PowerShell, I think you'll be pretty happy. Much of the design is heavily influenced by our Unix backgrounds so while we are quite different, you'll pick it up very quickly (after you get over cussing that it isn't Unix :-) ). We know that people have a very limited budget for learning - that is why we are super hard-core about consistency. You are going to learn something and then you'll use it over and over and over again.
Experiment! Enjoy! Engage!
edited May 30 '15 at 16:18
Kev
98k45263356
98k45263356
answered Feb 21 '09 at 22:53
Jeffrey Snover - MSFTJeffrey Snover - MSFT
9,25541712
9,25541712
10
Thanks for your answer. I think I'm going to go ahead and learn PowerShell. It looks powerful from what I've seen so far, and I'll be able to write more useful scripts with it at work.
– Andy White
Feb 23 '09 at 0:20
55
@Jeffrey: is there a chance for a better terminal for Windows? Powershell is a powerful scripting language, but the fact it runs in cmd.exe makes it much more convenient in the interactive mode
– sumek
Jul 7 '10 at 10:23
42
This "not constructive" question generated the best insight I've seen into the whole "on Unix everything is a file" mantra, and why Windows is different. Maybe StackOverflow would be better served closing not constructive discussions?
– chernevik
Jul 13 '12 at 14:51
12
@sumek - Give ConEmu a try; I've been using it for a few weeks and it's pretty sweet: hanselman.com/blog/…
– E.Z. Hart
Jul 13 '12 at 17:43
4
Heads up: powershell doesn't like piping binary data. So beware when you're calling your trusty Unix tools, just don't do stuff liketar -c . | gzip > package.tar.gz
directly in PowerShell, or you'll suffer. See brianreiter.org/2010/01/29/…
– Interarticle
Oct 28 '13 at 4:24
|
show 10 more comments
10
Thanks for your answer. I think I'm going to go ahead and learn PowerShell. It looks powerful from what I've seen so far, and I'll be able to write more useful scripts with it at work.
– Andy White
Feb 23 '09 at 0:20
55
@Jeffrey: is there a chance for a better terminal for Windows? Powershell is a powerful scripting language, but the fact it runs in cmd.exe makes it much more convenient in the interactive mode
– sumek
Jul 7 '10 at 10:23
42
This "not constructive" question generated the best insight I've seen into the whole "on Unix everything is a file" mantra, and why Windows is different. Maybe StackOverflow would be better served closing not constructive discussions?
– chernevik
Jul 13 '12 at 14:51
12
@sumek - Give ConEmu a try; I've been using it for a few weeks and it's pretty sweet: hanselman.com/blog/…
– E.Z. Hart
Jul 13 '12 at 17:43
4
Heads up: powershell doesn't like piping binary data. So beware when you're calling your trusty Unix tools, just don't do stuff liketar -c . | gzip > package.tar.gz
directly in PowerShell, or you'll suffer. See brianreiter.org/2010/01/29/…
– Interarticle
Oct 28 '13 at 4:24
10
10
Thanks for your answer. I think I'm going to go ahead and learn PowerShell. It looks powerful from what I've seen so far, and I'll be able to write more useful scripts with it at work.
– Andy White
Feb 23 '09 at 0:20
Thanks for your answer. I think I'm going to go ahead and learn PowerShell. It looks powerful from what I've seen so far, and I'll be able to write more useful scripts with it at work.
– Andy White
Feb 23 '09 at 0:20
55
55
@Jeffrey: is there a chance for a better terminal for Windows? Powershell is a powerful scripting language, but the fact it runs in cmd.exe makes it much more convenient in the interactive mode
– sumek
Jul 7 '10 at 10:23
@Jeffrey: is there a chance for a better terminal for Windows? Powershell is a powerful scripting language, but the fact it runs in cmd.exe makes it much more convenient in the interactive mode
– sumek
Jul 7 '10 at 10:23
42
42
This "not constructive" question generated the best insight I've seen into the whole "on Unix everything is a file" mantra, and why Windows is different. Maybe StackOverflow would be better served closing not constructive discussions?
– chernevik
Jul 13 '12 at 14:51
This "not constructive" question generated the best insight I've seen into the whole "on Unix everything is a file" mantra, and why Windows is different. Maybe StackOverflow would be better served closing not constructive discussions?
– chernevik
Jul 13 '12 at 14:51
12
12
@sumek - Give ConEmu a try; I've been using it for a few weeks and it's pretty sweet: hanselman.com/blog/…
– E.Z. Hart
Jul 13 '12 at 17:43
@sumek - Give ConEmu a try; I've been using it for a few weeks and it's pretty sweet: hanselman.com/blog/…
– E.Z. Hart
Jul 13 '12 at 17:43
4
4
Heads up: powershell doesn't like piping binary data. So beware when you're calling your trusty Unix tools, just don't do stuff like
tar -c . | gzip > package.tar.gz
directly in PowerShell, or you'll suffer. See brianreiter.org/2010/01/29/…– Interarticle
Oct 28 '13 at 4:24
Heads up: powershell doesn't like piping binary data. So beware when you're calling your trusty Unix tools, just don't do stuff like
tar -c . | gzip > package.tar.gz
directly in PowerShell, or you'll suffer. See brianreiter.org/2010/01/29/…– Interarticle
Oct 28 '13 at 4:24
|
show 10 more comments
grep
Select-String
cmdlet and -match
operator work with regexes. Also you can directly make use of .NET's regex support for more advanced functionality.
sort
Sort-Object
is more powerful (than I remember *nix's sort
). Allowing multi-level sorting on arbitrary expressions. Here PowerShell's maintenance of underlying type helps; e.g. a DateTime
property will be sorted as a DateTime
without having to ensure formatting into a sortable format.
uniq
Select-Object -Unique
Perl (how close does PowerShell come to Perl capabilities?)
In terms of Perl's breadth of domain specific support libraries: nowhere close (yet).
For general programming, PowerShell is certainly more cohesive and consistent, and easier to extend. The one gap for text munging is something equivalent to Perl's ..
operator.
AWK
It has been long enough since using AWK (must be >18 years, since later I just used Perl), so can't really comment.
sed
[See above]
file (the command that gives file information)
PowerShell's strength here isn't so much of what it can do with filesystem objects (and it gets full information here, dir
returns FileInfo
or FolderInfo
objects as appropriate) is that is the whole provider model.
You can treat the registry, certificate store, SQL Server, Internet Explorer's RSS cache, etc. as an object space navigable by the same cmdlets as the filesystem.
PowerShell is definitely the way forward on Windows. Microsoft has made it part of their requirements for future non-home products. Hence rich support in Exchange, support in SQL Server. This is only going to expand.
A recent example of this is the TFS PowerToys. Many TFS client operations are done without having to startup tf.exe each time (which requires a new TFS server connection, etc.) and is notably easier to then further process the data. As well as allowing wide access to the whole TFS client API to a greater detail than exposed in either Team Explorer of TF.exe.
2
The thing is that the provider model is interesting only because the OS doesn't use text as its universal config medium, so you NEED these providers. With UNIX most languages have APIs to touch PAM, hosts, and packages, but ultimately text will always be there.
– Daishiman
Feb 21 '09 at 23:44
11
Text is not always the best format for everything (start with databases and raster images). But I think we can agree to disagree rather than open format wars.
– Richard
Feb 22 '09 at 0:06
5
Powershell can use any object in the .NET framework, doesn't this match Perl's domain capabilities? Plus you can write cmdlets in C# etc. if you want re-usability
– Chris S
May 30 '13 at 15:01
Point by point comparison. Nice one. This should be the accepted answer. PowerShell's strength lies in its .NET foundations and how easily you can extend the system by writing new Cmdlets or even calling class libraries
– Sau001
Mar 2 at 8:27
add a comment |
grep
Select-String
cmdlet and -match
operator work with regexes. Also you can directly make use of .NET's regex support for more advanced functionality.
sort
Sort-Object
is more powerful (than I remember *nix's sort
). Allowing multi-level sorting on arbitrary expressions. Here PowerShell's maintenance of underlying type helps; e.g. a DateTime
property will be sorted as a DateTime
without having to ensure formatting into a sortable format.
uniq
Select-Object -Unique
Perl (how close does PowerShell come to Perl capabilities?)
In terms of Perl's breadth of domain specific support libraries: nowhere close (yet).
For general programming, PowerShell is certainly more cohesive and consistent, and easier to extend. The one gap for text munging is something equivalent to Perl's ..
operator.
AWK
It has been long enough since using AWK (must be >18 years, since later I just used Perl), so can't really comment.
sed
[See above]
file (the command that gives file information)
PowerShell's strength here isn't so much of what it can do with filesystem objects (and it gets full information here, dir
returns FileInfo
or FolderInfo
objects as appropriate) is that is the whole provider model.
You can treat the registry, certificate store, SQL Server, Internet Explorer's RSS cache, etc. as an object space navigable by the same cmdlets as the filesystem.
PowerShell is definitely the way forward on Windows. Microsoft has made it part of their requirements for future non-home products. Hence rich support in Exchange, support in SQL Server. This is only going to expand.
A recent example of this is the TFS PowerToys. Many TFS client operations are done without having to startup tf.exe each time (which requires a new TFS server connection, etc.) and is notably easier to then further process the data. As well as allowing wide access to the whole TFS client API to a greater detail than exposed in either Team Explorer of TF.exe.
2
The thing is that the provider model is interesting only because the OS doesn't use text as its universal config medium, so you NEED these providers. With UNIX most languages have APIs to touch PAM, hosts, and packages, but ultimately text will always be there.
– Daishiman
Feb 21 '09 at 23:44
11
Text is not always the best format for everything (start with databases and raster images). But I think we can agree to disagree rather than open format wars.
– Richard
Feb 22 '09 at 0:06
5
Powershell can use any object in the .NET framework, doesn't this match Perl's domain capabilities? Plus you can write cmdlets in C# etc. if you want re-usability
– Chris S
May 30 '13 at 15:01
Point by point comparison. Nice one. This should be the accepted answer. PowerShell's strength lies in its .NET foundations and how easily you can extend the system by writing new Cmdlets or even calling class libraries
– Sau001
Mar 2 at 8:27
add a comment |
grep
Select-String
cmdlet and -match
operator work with regexes. Also you can directly make use of .NET's regex support for more advanced functionality.
sort
Sort-Object
is more powerful (than I remember *nix's sort
). Allowing multi-level sorting on arbitrary expressions. Here PowerShell's maintenance of underlying type helps; e.g. a DateTime
property will be sorted as a DateTime
without having to ensure formatting into a sortable format.
uniq
Select-Object -Unique
Perl (how close does PowerShell come to Perl capabilities?)
In terms of Perl's breadth of domain specific support libraries: nowhere close (yet).
For general programming, PowerShell is certainly more cohesive and consistent, and easier to extend. The one gap for text munging is something equivalent to Perl's ..
operator.
AWK
It has been long enough since using AWK (must be >18 years, since later I just used Perl), so can't really comment.
sed
[See above]
file (the command that gives file information)
PowerShell's strength here isn't so much of what it can do with filesystem objects (and it gets full information here, dir
returns FileInfo
or FolderInfo
objects as appropriate) is that is the whole provider model.
You can treat the registry, certificate store, SQL Server, Internet Explorer's RSS cache, etc. as an object space navigable by the same cmdlets as the filesystem.
PowerShell is definitely the way forward on Windows. Microsoft has made it part of their requirements for future non-home products. Hence rich support in Exchange, support in SQL Server. This is only going to expand.
A recent example of this is the TFS PowerToys. Many TFS client operations are done without having to startup tf.exe each time (which requires a new TFS server connection, etc.) and is notably easier to then further process the data. As well as allowing wide access to the whole TFS client API to a greater detail than exposed in either Team Explorer of TF.exe.
grep
Select-String
cmdlet and -match
operator work with regexes. Also you can directly make use of .NET's regex support for more advanced functionality.
sort
Sort-Object
is more powerful (than I remember *nix's sort
). Allowing multi-level sorting on arbitrary expressions. Here PowerShell's maintenance of underlying type helps; e.g. a DateTime
property will be sorted as a DateTime
without having to ensure formatting into a sortable format.
uniq
Select-Object -Unique
Perl (how close does PowerShell come to Perl capabilities?)
In terms of Perl's breadth of domain specific support libraries: nowhere close (yet).
For general programming, PowerShell is certainly more cohesive and consistent, and easier to extend. The one gap for text munging is something equivalent to Perl's ..
operator.
AWK
It has been long enough since using AWK (must be >18 years, since later I just used Perl), so can't really comment.
sed
[See above]
file (the command that gives file information)
PowerShell's strength here isn't so much of what it can do with filesystem objects (and it gets full information here, dir
returns FileInfo
or FolderInfo
objects as appropriate) is that is the whole provider model.
You can treat the registry, certificate store, SQL Server, Internet Explorer's RSS cache, etc. as an object space navigable by the same cmdlets as the filesystem.
PowerShell is definitely the way forward on Windows. Microsoft has made it part of their requirements for future non-home products. Hence rich support in Exchange, support in SQL Server. This is only going to expand.
A recent example of this is the TFS PowerToys. Many TFS client operations are done without having to startup tf.exe each time (which requires a new TFS server connection, etc.) and is notably easier to then further process the data. As well as allowing wide access to the whole TFS client API to a greater detail than exposed in either Team Explorer of TF.exe.
edited Nov 19 '18 at 7:10
Peter Mortensen
13.7k1986113
13.7k1986113
answered Feb 21 '09 at 21:37
RichardRichard
89.8k17155222
89.8k17155222
2
The thing is that the provider model is interesting only because the OS doesn't use text as its universal config medium, so you NEED these providers. With UNIX most languages have APIs to touch PAM, hosts, and packages, but ultimately text will always be there.
– Daishiman
Feb 21 '09 at 23:44
11
Text is not always the best format for everything (start with databases and raster images). But I think we can agree to disagree rather than open format wars.
– Richard
Feb 22 '09 at 0:06
5
Powershell can use any object in the .NET framework, doesn't this match Perl's domain capabilities? Plus you can write cmdlets in C# etc. if you want re-usability
– Chris S
May 30 '13 at 15:01
Point by point comparison. Nice one. This should be the accepted answer. PowerShell's strength lies in its .NET foundations and how easily you can extend the system by writing new Cmdlets or even calling class libraries
– Sau001
Mar 2 at 8:27
add a comment |
2
The thing is that the provider model is interesting only because the OS doesn't use text as its universal config medium, so you NEED these providers. With UNIX most languages have APIs to touch PAM, hosts, and packages, but ultimately text will always be there.
– Daishiman
Feb 21 '09 at 23:44
11
Text is not always the best format for everything (start with databases and raster images). But I think we can agree to disagree rather than open format wars.
– Richard
Feb 22 '09 at 0:06
5
Powershell can use any object in the .NET framework, doesn't this match Perl's domain capabilities? Plus you can write cmdlets in C# etc. if you want re-usability
– Chris S
May 30 '13 at 15:01
Point by point comparison. Nice one. This should be the accepted answer. PowerShell's strength lies in its .NET foundations and how easily you can extend the system by writing new Cmdlets or even calling class libraries
– Sau001
Mar 2 at 8:27
2
2
The thing is that the provider model is interesting only because the OS doesn't use text as its universal config medium, so you NEED these providers. With UNIX most languages have APIs to touch PAM, hosts, and packages, but ultimately text will always be there.
– Daishiman
Feb 21 '09 at 23:44
The thing is that the provider model is interesting only because the OS doesn't use text as its universal config medium, so you NEED these providers. With UNIX most languages have APIs to touch PAM, hosts, and packages, but ultimately text will always be there.
– Daishiman
Feb 21 '09 at 23:44
11
11
Text is not always the best format for everything (start with databases and raster images). But I think we can agree to disagree rather than open format wars.
– Richard
Feb 22 '09 at 0:06
Text is not always the best format for everything (start with databases and raster images). But I think we can agree to disagree rather than open format wars.
– Richard
Feb 22 '09 at 0:06
5
5
Powershell can use any object in the .NET framework, doesn't this match Perl's domain capabilities? Plus you can write cmdlets in C# etc. if you want re-usability
– Chris S
May 30 '13 at 15:01
Powershell can use any object in the .NET framework, doesn't this match Perl's domain capabilities? Plus you can write cmdlets in C# etc. if you want re-usability
– Chris S
May 30 '13 at 15:01
Point by point comparison. Nice one. This should be the accepted answer. PowerShell's strength lies in its .NET foundations and how easily you can extend the system by writing new Cmdlets or even calling class libraries
– Sau001
Mar 2 at 8:27
Point by point comparison. Nice one. This should be the accepted answer. PowerShell's strength lies in its .NET foundations and how easily you can extend the system by writing new Cmdlets or even calling class libraries
– Sau001
Mar 2 at 8:27
add a comment |
As someone whose career focused on Windows enterprise development from 1997 - 2010, the obvious answer would be PowerShell for all the good reasons given previously (e.g., it is part of Microsoft's enterprise strategy; it integrates well with Windows/COM/.NET; and using objects instead of files provides for a "richer" coding model). For that reason I'd been using and promoting PowerShell for the last two years or so, with the express belief I was following the "Word of Bill."
However, as a pragmatist I'm no longer sure PowerShell is such a great answer. While it's an excellent Windows tool and provides a much needed step towards filling the historic hole that is the Window command line, as we all watch Microsoft's grip on consumer computing slip it seems increasingly likely that Microsoft has a massive battle ahead to keep its OS as important to the enterprise of the future.
Indeed, given I find my work is increasingly in heterogeneous environments, I'm finding it much more useful to use Bash scripts at the moment, as they not only work on Linux, Solaris and Mac OS X, but they also work—with the help of Cygwin—on Windows.
So if you buy into the belief that the future of the OS is commoditized rather than a monopolized, then it seems to make sense to opt for an agile development tool strategy that keeps away from proprietary tools where feasible. If however you see your future being dominated by all-that-is-Redmond then go for PowerShell.
1
Does unix scripts work perfectly on Cygwin-Windows without errors?
– Pacerier
Jan 3 '15 at 12:27
@Pacerier I've been using Cygwin and MinGW for 12 years, and had problems surprisingly rarely. The important thing is that if something doesn't work, it's always possible to fall back on Windows tools, or anything — processes can be started in the same way as any other shell starts them.
– Evgeni Sergeev
May 24 '16 at 15:56
3
Okay, your answer is from 2011. Today powershell runs on linux too. And -- my personal opinion -- bash is too antique. The syntax is horrible and I would rather use a different scripting language. Nowadays with python being standard on most linux distros I don't see any reason to use bash for scripts. I'd advise you to check out powershell again as there has happened a lot since 2011.
– itmuckel
Sep 19 '16 at 6:31
Link for those curious about PowerShell on Linux
– Chris
Oct 15 '18 at 19:37
add a comment |
As someone whose career focused on Windows enterprise development from 1997 - 2010, the obvious answer would be PowerShell for all the good reasons given previously (e.g., it is part of Microsoft's enterprise strategy; it integrates well with Windows/COM/.NET; and using objects instead of files provides for a "richer" coding model). For that reason I'd been using and promoting PowerShell for the last two years or so, with the express belief I was following the "Word of Bill."
However, as a pragmatist I'm no longer sure PowerShell is such a great answer. While it's an excellent Windows tool and provides a much needed step towards filling the historic hole that is the Window command line, as we all watch Microsoft's grip on consumer computing slip it seems increasingly likely that Microsoft has a massive battle ahead to keep its OS as important to the enterprise of the future.
Indeed, given I find my work is increasingly in heterogeneous environments, I'm finding it much more useful to use Bash scripts at the moment, as they not only work on Linux, Solaris and Mac OS X, but they also work—with the help of Cygwin—on Windows.
So if you buy into the belief that the future of the OS is commoditized rather than a monopolized, then it seems to make sense to opt for an agile development tool strategy that keeps away from proprietary tools where feasible. If however you see your future being dominated by all-that-is-Redmond then go for PowerShell.
1
Does unix scripts work perfectly on Cygwin-Windows without errors?
– Pacerier
Jan 3 '15 at 12:27
@Pacerier I've been using Cygwin and MinGW for 12 years, and had problems surprisingly rarely. The important thing is that if something doesn't work, it's always possible to fall back on Windows tools, or anything — processes can be started in the same way as any other shell starts them.
– Evgeni Sergeev
May 24 '16 at 15:56
3
Okay, your answer is from 2011. Today powershell runs on linux too. And -- my personal opinion -- bash is too antique. The syntax is horrible and I would rather use a different scripting language. Nowadays with python being standard on most linux distros I don't see any reason to use bash for scripts. I'd advise you to check out powershell again as there has happened a lot since 2011.
– itmuckel
Sep 19 '16 at 6:31
Link for those curious about PowerShell on Linux
– Chris
Oct 15 '18 at 19:37
add a comment |
As someone whose career focused on Windows enterprise development from 1997 - 2010, the obvious answer would be PowerShell for all the good reasons given previously (e.g., it is part of Microsoft's enterprise strategy; it integrates well with Windows/COM/.NET; and using objects instead of files provides for a "richer" coding model). For that reason I'd been using and promoting PowerShell for the last two years or so, with the express belief I was following the "Word of Bill."
However, as a pragmatist I'm no longer sure PowerShell is such a great answer. While it's an excellent Windows tool and provides a much needed step towards filling the historic hole that is the Window command line, as we all watch Microsoft's grip on consumer computing slip it seems increasingly likely that Microsoft has a massive battle ahead to keep its OS as important to the enterprise of the future.
Indeed, given I find my work is increasingly in heterogeneous environments, I'm finding it much more useful to use Bash scripts at the moment, as they not only work on Linux, Solaris and Mac OS X, but they also work—with the help of Cygwin—on Windows.
So if you buy into the belief that the future of the OS is commoditized rather than a monopolized, then it seems to make sense to opt for an agile development tool strategy that keeps away from proprietary tools where feasible. If however you see your future being dominated by all-that-is-Redmond then go for PowerShell.
As someone whose career focused on Windows enterprise development from 1997 - 2010, the obvious answer would be PowerShell for all the good reasons given previously (e.g., it is part of Microsoft's enterprise strategy; it integrates well with Windows/COM/.NET; and using objects instead of files provides for a "richer" coding model). For that reason I'd been using and promoting PowerShell for the last two years or so, with the express belief I was following the "Word of Bill."
However, as a pragmatist I'm no longer sure PowerShell is such a great answer. While it's an excellent Windows tool and provides a much needed step towards filling the historic hole that is the Window command line, as we all watch Microsoft's grip on consumer computing slip it seems increasingly likely that Microsoft has a massive battle ahead to keep its OS as important to the enterprise of the future.
Indeed, given I find my work is increasingly in heterogeneous environments, I'm finding it much more useful to use Bash scripts at the moment, as they not only work on Linux, Solaris and Mac OS X, but they also work—with the help of Cygwin—on Windows.
So if you buy into the belief that the future of the OS is commoditized rather than a monopolized, then it seems to make sense to opt for an agile development tool strategy that keeps away from proprietary tools where feasible. If however you see your future being dominated by all-that-is-Redmond then go for PowerShell.
edited Nov 21 '18 at 20:37
Peter Mortensen
13.7k1986113
13.7k1986113
answered Jan 7 '11 at 17:12
UbiguchiUbiguchi
2,56211922
2,56211922
1
Does unix scripts work perfectly on Cygwin-Windows without errors?
– Pacerier
Jan 3 '15 at 12:27
@Pacerier I've been using Cygwin and MinGW for 12 years, and had problems surprisingly rarely. The important thing is that if something doesn't work, it's always possible to fall back on Windows tools, or anything — processes can be started in the same way as any other shell starts them.
– Evgeni Sergeev
May 24 '16 at 15:56
3
Okay, your answer is from 2011. Today powershell runs on linux too. And -- my personal opinion -- bash is too antique. The syntax is horrible and I would rather use a different scripting language. Nowadays with python being standard on most linux distros I don't see any reason to use bash for scripts. I'd advise you to check out powershell again as there has happened a lot since 2011.
– itmuckel
Sep 19 '16 at 6:31
Link for those curious about PowerShell on Linux
– Chris
Oct 15 '18 at 19:37
add a comment |
1
Does unix scripts work perfectly on Cygwin-Windows without errors?
– Pacerier
Jan 3 '15 at 12:27
@Pacerier I've been using Cygwin and MinGW for 12 years, and had problems surprisingly rarely. The important thing is that if something doesn't work, it's always possible to fall back on Windows tools, or anything — processes can be started in the same way as any other shell starts them.
– Evgeni Sergeev
May 24 '16 at 15:56
3
Okay, your answer is from 2011. Today powershell runs on linux too. And -- my personal opinion -- bash is too antique. The syntax is horrible and I would rather use a different scripting language. Nowadays with python being standard on most linux distros I don't see any reason to use bash for scripts. I'd advise you to check out powershell again as there has happened a lot since 2011.
– itmuckel
Sep 19 '16 at 6:31
Link for those curious about PowerShell on Linux
– Chris
Oct 15 '18 at 19:37
1
1
Does unix scripts work perfectly on Cygwin-Windows without errors?
– Pacerier
Jan 3 '15 at 12:27
Does unix scripts work perfectly on Cygwin-Windows without errors?
– Pacerier
Jan 3 '15 at 12:27
@Pacerier I've been using Cygwin and MinGW for 12 years, and had problems surprisingly rarely. The important thing is that if something doesn't work, it's always possible to fall back on Windows tools, or anything — processes can be started in the same way as any other shell starts them.
– Evgeni Sergeev
May 24 '16 at 15:56
@Pacerier I've been using Cygwin and MinGW for 12 years, and had problems surprisingly rarely. The important thing is that if something doesn't work, it's always possible to fall back on Windows tools, or anything — processes can be started in the same way as any other shell starts them.
– Evgeni Sergeev
May 24 '16 at 15:56
3
3
Okay, your answer is from 2011. Today powershell runs on linux too. And -- my personal opinion -- bash is too antique. The syntax is horrible and I would rather use a different scripting language. Nowadays with python being standard on most linux distros I don't see any reason to use bash for scripts. I'd advise you to check out powershell again as there has happened a lot since 2011.
– itmuckel
Sep 19 '16 at 6:31
Okay, your answer is from 2011. Today powershell runs on linux too. And -- my personal opinion -- bash is too antique. The syntax is horrible and I would rather use a different scripting language. Nowadays with python being standard on most linux distros I don't see any reason to use bash for scripts. I'd advise you to check out powershell again as there has happened a lot since 2011.
– itmuckel
Sep 19 '16 at 6:31
Link for those curious about PowerShell on Linux
– Chris
Oct 15 '18 at 19:37
Link for those curious about PowerShell on Linux
– Chris
Oct 15 '18 at 19:37
add a comment |
I have used a bit of PowerShell for script automation. While it is very nice that the environment seems to have been thought out much more than Unix shells, in practice the use of objects instead of text streams is much more clunky, and a lot of the Unix facilities that have been developed in the last 30 years are still missing.
Cygwin is still my scripting environment of choice for Windows hosts. It certainly beats the alternatives in terms of getting things done.
27
Using objects is a paradigm shift and takes some getting used to. But avoids the whole re-parsing at each step where structured data is involved (e.g. no need to ensure fields are delimited).
– Richard
Feb 21 '09 at 21:22
16
@Andy White @Daishiman, I can understand where there is a learning curve with PowerShell, but piping objects can be much more flexible than piping text. @Richard is correct. :)
– Steven Murawski
Feb 21 '09 at 22:28
18
Auto makers had a hard time arguing with 1000+ years of horses too. I'm not trying to be flippant. Just pointing out that past success does not remove the potential benefit of innovation.
– EBGreen
Feb 21 '09 at 23:04
11
@daishiman - The benefit of Objects is that when you want a property, you ask for it - you don't have to parse,guess,cast. I did not understand your point about "what happens when objects don't have compatible methods" - Could you say that another way or give an example of the problem? Thanks.
– Jeffrey Snover - MSFT
Feb 22 '09 at 0:33
12
@Daishiman - I understand. In practice people have found this not to be a problem but rather a huge advantage. That said, I can see that if you were an expert text parser, this would be a new skill to learn and it might feel unneeded and awkward at first. Again - whatever helps is the right tool.
– Jeffrey Snover - MSFT
Feb 22 '09 at 1:21
|
show 10 more comments
I have used a bit of PowerShell for script automation. While it is very nice that the environment seems to have been thought out much more than Unix shells, in practice the use of objects instead of text streams is much more clunky, and a lot of the Unix facilities that have been developed in the last 30 years are still missing.
Cygwin is still my scripting environment of choice for Windows hosts. It certainly beats the alternatives in terms of getting things done.
27
Using objects is a paradigm shift and takes some getting used to. But avoids the whole re-parsing at each step where structured data is involved (e.g. no need to ensure fields are delimited).
– Richard
Feb 21 '09 at 21:22
16
@Andy White @Daishiman, I can understand where there is a learning curve with PowerShell, but piping objects can be much more flexible than piping text. @Richard is correct. :)
– Steven Murawski
Feb 21 '09 at 22:28
18
Auto makers had a hard time arguing with 1000+ years of horses too. I'm not trying to be flippant. Just pointing out that past success does not remove the potential benefit of innovation.
– EBGreen
Feb 21 '09 at 23:04
11
@daishiman - The benefit of Objects is that when you want a property, you ask for it - you don't have to parse,guess,cast. I did not understand your point about "what happens when objects don't have compatible methods" - Could you say that another way or give an example of the problem? Thanks.
– Jeffrey Snover - MSFT
Feb 22 '09 at 0:33
12
@Daishiman - I understand. In practice people have found this not to be a problem but rather a huge advantage. That said, I can see that if you were an expert text parser, this would be a new skill to learn and it might feel unneeded and awkward at first. Again - whatever helps is the right tool.
– Jeffrey Snover - MSFT
Feb 22 '09 at 1:21
|
show 10 more comments
I have used a bit of PowerShell for script automation. While it is very nice that the environment seems to have been thought out much more than Unix shells, in practice the use of objects instead of text streams is much more clunky, and a lot of the Unix facilities that have been developed in the last 30 years are still missing.
Cygwin is still my scripting environment of choice for Windows hosts. It certainly beats the alternatives in terms of getting things done.
I have used a bit of PowerShell for script automation. While it is very nice that the environment seems to have been thought out much more than Unix shells, in practice the use of objects instead of text streams is much more clunky, and a lot of the Unix facilities that have been developed in the last 30 years are still missing.
Cygwin is still my scripting environment of choice for Windows hosts. It certainly beats the alternatives in terms of getting things done.
edited Dec 11 '14 at 22:07
Peter Mortensen
13.7k1986113
13.7k1986113
answered Feb 21 '09 at 19:59
DaishimanDaishiman
7481714
7481714
27
Using objects is a paradigm shift and takes some getting used to. But avoids the whole re-parsing at each step where structured data is involved (e.g. no need to ensure fields are delimited).
– Richard
Feb 21 '09 at 21:22
16
@Andy White @Daishiman, I can understand where there is a learning curve with PowerShell, but piping objects can be much more flexible than piping text. @Richard is correct. :)
– Steven Murawski
Feb 21 '09 at 22:28
18
Auto makers had a hard time arguing with 1000+ years of horses too. I'm not trying to be flippant. Just pointing out that past success does not remove the potential benefit of innovation.
– EBGreen
Feb 21 '09 at 23:04
11
@daishiman - The benefit of Objects is that when you want a property, you ask for it - you don't have to parse,guess,cast. I did not understand your point about "what happens when objects don't have compatible methods" - Could you say that another way or give an example of the problem? Thanks.
– Jeffrey Snover - MSFT
Feb 22 '09 at 0:33
12
@Daishiman - I understand. In practice people have found this not to be a problem but rather a huge advantage. That said, I can see that if you were an expert text parser, this would be a new skill to learn and it might feel unneeded and awkward at first. Again - whatever helps is the right tool.
– Jeffrey Snover - MSFT
Feb 22 '09 at 1:21
|
show 10 more comments
27
Using objects is a paradigm shift and takes some getting used to. But avoids the whole re-parsing at each step where structured data is involved (e.g. no need to ensure fields are delimited).
– Richard
Feb 21 '09 at 21:22
16
@Andy White @Daishiman, I can understand where there is a learning curve with PowerShell, but piping objects can be much more flexible than piping text. @Richard is correct. :)
– Steven Murawski
Feb 21 '09 at 22:28
18
Auto makers had a hard time arguing with 1000+ years of horses too. I'm not trying to be flippant. Just pointing out that past success does not remove the potential benefit of innovation.
– EBGreen
Feb 21 '09 at 23:04
11
@daishiman - The benefit of Objects is that when you want a property, you ask for it - you don't have to parse,guess,cast. I did not understand your point about "what happens when objects don't have compatible methods" - Could you say that another way or give an example of the problem? Thanks.
– Jeffrey Snover - MSFT
Feb 22 '09 at 0:33
12
@Daishiman - I understand. In practice people have found this not to be a problem but rather a huge advantage. That said, I can see that if you were an expert text parser, this would be a new skill to learn and it might feel unneeded and awkward at first. Again - whatever helps is the right tool.
– Jeffrey Snover - MSFT
Feb 22 '09 at 1:21
27
27
Using objects is a paradigm shift and takes some getting used to. But avoids the whole re-parsing at each step where structured data is involved (e.g. no need to ensure fields are delimited).
– Richard
Feb 21 '09 at 21:22
Using objects is a paradigm shift and takes some getting used to. But avoids the whole re-parsing at each step where structured data is involved (e.g. no need to ensure fields are delimited).
– Richard
Feb 21 '09 at 21:22
16
16
@Andy White @Daishiman, I can understand where there is a learning curve with PowerShell, but piping objects can be much more flexible than piping text. @Richard is correct. :)
– Steven Murawski
Feb 21 '09 at 22:28
@Andy White @Daishiman, I can understand where there is a learning curve with PowerShell, but piping objects can be much more flexible than piping text. @Richard is correct. :)
– Steven Murawski
Feb 21 '09 at 22:28
18
18
Auto makers had a hard time arguing with 1000+ years of horses too. I'm not trying to be flippant. Just pointing out that past success does not remove the potential benefit of innovation.
– EBGreen
Feb 21 '09 at 23:04
Auto makers had a hard time arguing with 1000+ years of horses too. I'm not trying to be flippant. Just pointing out that past success does not remove the potential benefit of innovation.
– EBGreen
Feb 21 '09 at 23:04
11
11
@daishiman - The benefit of Objects is that when you want a property, you ask for it - you don't have to parse,guess,cast. I did not understand your point about "what happens when objects don't have compatible methods" - Could you say that another way or give an example of the problem? Thanks.
– Jeffrey Snover - MSFT
Feb 22 '09 at 0:33
@daishiman - The benefit of Objects is that when you want a property, you ask for it - you don't have to parse,guess,cast. I did not understand your point about "what happens when objects don't have compatible methods" - Could you say that another way or give an example of the problem? Thanks.
– Jeffrey Snover - MSFT
Feb 22 '09 at 0:33
12
12
@Daishiman - I understand. In practice people have found this not to be a problem but rather a huge advantage. That said, I can see that if you were an expert text parser, this would be a new skill to learn and it might feel unneeded and awkward at first. Again - whatever helps is the right tool.
– Jeffrey Snover - MSFT
Feb 22 '09 at 1:21
@Daishiman - I understand. In practice people have found this not to be a problem but rather a huge advantage. That said, I can see that if you were an expert text parser, this would be a new skill to learn and it might feel unneeded and awkward at first. Again - whatever helps is the right tool.
– Jeffrey Snover - MSFT
Feb 22 '09 at 1:21
|
show 10 more comments
There are lots of great great answers here, and here is my take. PowerShell is ready if you are... Examples:
grep = "Select-String -Pattern"
sort = "Sort-Object"
uniq = "Get-Unique"
file = "Get-Item"
cat = "Get-Content"
Perl/AWK/Sed are not commands, but utilities hence hard to compare, but you can do almost everything in PowerShell.
2
Can you believe the cryptic four-letter commands our ancestors were forced to use?
– Evgeni Sergeev
May 24 '16 at 16:10
3
@EvgeniSergeev All the above are available by default assls
,sort
,gu
,gi
,gc
, respectively. Long readable names which tab-complete, and short type-able names in one system. That's user-friendly progress for you.
– TessellatingHeckler
Sep 16 '17 at 4:13
add a comment |
There are lots of great great answers here, and here is my take. PowerShell is ready if you are... Examples:
grep = "Select-String -Pattern"
sort = "Sort-Object"
uniq = "Get-Unique"
file = "Get-Item"
cat = "Get-Content"
Perl/AWK/Sed are not commands, but utilities hence hard to compare, but you can do almost everything in PowerShell.
2
Can you believe the cryptic four-letter commands our ancestors were forced to use?
– Evgeni Sergeev
May 24 '16 at 16:10
3
@EvgeniSergeev All the above are available by default assls
,sort
,gu
,gi
,gc
, respectively. Long readable names which tab-complete, and short type-able names in one system. That's user-friendly progress for you.
– TessellatingHeckler
Sep 16 '17 at 4:13
add a comment |
There are lots of great great answers here, and here is my take. PowerShell is ready if you are... Examples:
grep = "Select-String -Pattern"
sort = "Sort-Object"
uniq = "Get-Unique"
file = "Get-Item"
cat = "Get-Content"
Perl/AWK/Sed are not commands, but utilities hence hard to compare, but you can do almost everything in PowerShell.
There are lots of great great answers here, and here is my take. PowerShell is ready if you are... Examples:
grep = "Select-String -Pattern"
sort = "Sort-Object"
uniq = "Get-Unique"
file = "Get-Item"
cat = "Get-Content"
Perl/AWK/Sed are not commands, but utilities hence hard to compare, but you can do almost everything in PowerShell.
edited Nov 21 '18 at 20:03
Peter Mortensen
13.7k1986113
13.7k1986113
answered Sep 17 '15 at 8:22
VicVic
1,4801122
1,4801122
2
Can you believe the cryptic four-letter commands our ancestors were forced to use?
– Evgeni Sergeev
May 24 '16 at 16:10
3
@EvgeniSergeev All the above are available by default assls
,sort
,gu
,gi
,gc
, respectively. Long readable names which tab-complete, and short type-able names in one system. That's user-friendly progress for you.
– TessellatingHeckler
Sep 16 '17 at 4:13
add a comment |
2
Can you believe the cryptic four-letter commands our ancestors were forced to use?
– Evgeni Sergeev
May 24 '16 at 16:10
3
@EvgeniSergeev All the above are available by default assls
,sort
,gu
,gi
,gc
, respectively. Long readable names which tab-complete, and short type-able names in one system. That's user-friendly progress for you.
– TessellatingHeckler
Sep 16 '17 at 4:13
2
2
Can you believe the cryptic four-letter commands our ancestors were forced to use?
– Evgeni Sergeev
May 24 '16 at 16:10
Can you believe the cryptic four-letter commands our ancestors were forced to use?
– Evgeni Sergeev
May 24 '16 at 16:10
3
3
@EvgeniSergeev All the above are available by default as
sls
, sort
, gu
, gi
, gc
, respectively. Long readable names which tab-complete, and short type-able names in one system. That's user-friendly progress for you.– TessellatingHeckler
Sep 16 '17 at 4:13
@EvgeniSergeev All the above are available by default as
sls
, sort
, gu
, gi
, gc
, respectively. Long readable names which tab-complete, and short type-able names in one system. That's user-friendly progress for you.– TessellatingHeckler
Sep 16 '17 at 4:13
add a comment |
I have only recently started dabbling in PowerShell with any degree of seriousness. Although for the past seven years I've worked in an almost exclusively Windows-based environment, I come from a Unix background and find myself constantly trying to "Unix-fy" my interaction experience on Windows. It's frustrating to say the least.
It's only fair to compare PowerShell to something like Bash, tcsh, or zsh since utilities like grep, sed, awk, find, etc. are not, strictly speaking, part of the shell; they will always, however, be part of any Unix environment. That said, a PowerShell command like Select-String has a very similar function to grep and is bundled as a core module in PowerShell ... so the lines can be a little blurred.
I think the key thing is culture, and the fact that the respective tool-sets will embody their respective cultures:
- Unix is a file-based, (in general, non Unicode) text-based culture. Configuration files are almost exclusively text files. Windows, on the other hand has always been far more structured in respect of configuration formats--configurations are generally kept in proprietary databases (e.g., the Windows registry) which require specialised tools for their management.
The Unix administrative (and, for many years, development) interface has traditionally been the command line and the virtual terminal. Windows started off as a GUI and administrative functions have only recently started moving away from being exclusively GUI-based. We can expect the Unix experience on the command line to be a richer, more mature one given the significant lead it has on PowerShell, and my experience matches this. On this, in my experience:
The Unix administrative experience is geared towards making things easy to do in a minimal amount of key strokes; this is probably as a result of the historical situation of having to administer a server over a slow 9600 baud dial-up connection. Now PowerShell does have aliases which go a long way to getting around the rather verbose Verb-Noun standard, but getting to know those aliases is a bit of a pain (anyone know of something better than:
alias | where {$_.ResolvedCommandName -eq "<command>"}
?).
An example of the rich way in which history can be manipulated:
iptables
commands are often long-winded and repeating them with slight differences would be a pain if it weren't for just one of many neat features of history manipulation built into Bash, so inserting an iptables rule like the following:
iptables -I camera-1-internet -s 192.168.0.50 -m state --state NEW -j ACCEPT
a second time for another camera ("
camera-2
"), is just a case of issuing:
!!:s/-1-/-2-/:s/50/51
which means "perform the previous command, but substitute
-1-
with-2-
and50
with51
.
The Unix experience is optimised for touch-typists; one can pretty much do everything without leaving the "home" position. For example, in Bash, using the Emacs key bindings (yes, Bash also supports vi bindings), cycling through the history is done using Ctrl-P and Ctrl-N whilst moving to the start and end of a line is done using Ctrl-A and Ctrl-E respectively ... and it definitely doesn't end there. Try even the simplest of navigation in the PowerShell console without moving from the home position and you're in trouble.
- Simple things like versatile paging (a la less) on Unix don't seem to be available out-of-the-box in PowerShell which is a little frustrating, and a rich editor experience doesn't exist either. Of course, one can always download third-party tools that will fill those gaps, but it sure would be nice if these things were just "there" like they are on pretty much any flavour of Unix.
The Windows culture, at least in terms of system API's is largely driven by the supporting frameworks, viz., COM and .NET, both of-which are highly structured and object-based. On the other hand, access to Unix APIs has traditionally been through a file interface (
/dev
and/proc
) or (non-object-oriented) C-style library calls. It's no surprise then that the scripting experiences match their respective OS paradigms. PowerShell is by nature structured (everything is an object) and Bash-and-friends file-based. The structured API which is at the disposal of a PowerShell programmer is vast (essentially matching the vastness of the existing set of standard COM and .NET interfaces).
In short, although the scripting capabilities of PowerShell are arguably more powerful than Bash (especially when you consider the availability of the .NET BCL), the interactive experience is significantly weaker, particularly if you're coming at it from an entirely keyboard-driven, console-based perspective (as many Unix-heads are).
You ask "anyone know of something better than: alias | where {$_.ResolvedCommandName -eq "<command>"}?". How about justalias -Definition *property
(or any other pattern)? I think the problem with your answer is that you are conflating the shell and the console: remember you have a choice of consoles with different editing options. They deliberately left the DOS console editing broken to encourage people to use other consoles such as ISE.
– Duncan
Feb 12 '14 at 9:17
BTW, your!!
example can be written in Powershell as(h -c 1) -replace '-1-','-2-' -replace '50','51' | iex
but it's easier to up arrow and edit for a single command. If you want to do it across a lot of commands I think Powershell would win. To repeat 10 commands ending at command #255 with your edits:(h -c 10 -id 255) -replace '-1-','-2-' -replace '50','51' | iex
Also Powershell's history lets you do things unheard of in Linux shells; if you wonder retrospectively just how long a command took to run:h -id 20 | select { $_.EndExecutionTime - $_.StartExecutionTime }
– Duncan
Feb 12 '14 at 9:32
@Duncan In respect of your comment re the shell and the console--I think that that's just a fundamental difference between Bash and PS; that is: Bash expects to deliver a certain interactive experience whereas PS "leaves" that to something else. I don't have a lot of experience with the ISE console, but from I can remember, it doesn't have a tremendously rich interactive experience either.
– Eric Smith
Feb 14 '14 at 13:21
@Duncan, yes - good point about the ability of PS to deliver in respect of clever history tricks.
– Eric Smith
Feb 14 '14 at 13:24
@Duncan ... but despite your assertion that some things are unheard of in Linux shells:fc -e "sed -i -e 's/-1-/-2-/g' -e 's/50/51/g'" 10 255
– Eric Smith
Feb 14 '14 at 13:56
|
show 1 more comment
I have only recently started dabbling in PowerShell with any degree of seriousness. Although for the past seven years I've worked in an almost exclusively Windows-based environment, I come from a Unix background and find myself constantly trying to "Unix-fy" my interaction experience on Windows. It's frustrating to say the least.
It's only fair to compare PowerShell to something like Bash, tcsh, or zsh since utilities like grep, sed, awk, find, etc. are not, strictly speaking, part of the shell; they will always, however, be part of any Unix environment. That said, a PowerShell command like Select-String has a very similar function to grep and is bundled as a core module in PowerShell ... so the lines can be a little blurred.
I think the key thing is culture, and the fact that the respective tool-sets will embody their respective cultures:
- Unix is a file-based, (in general, non Unicode) text-based culture. Configuration files are almost exclusively text files. Windows, on the other hand has always been far more structured in respect of configuration formats--configurations are generally kept in proprietary databases (e.g., the Windows registry) which require specialised tools for their management.
The Unix administrative (and, for many years, development) interface has traditionally been the command line and the virtual terminal. Windows started off as a GUI and administrative functions have only recently started moving away from being exclusively GUI-based. We can expect the Unix experience on the command line to be a richer, more mature one given the significant lead it has on PowerShell, and my experience matches this. On this, in my experience:
The Unix administrative experience is geared towards making things easy to do in a minimal amount of key strokes; this is probably as a result of the historical situation of having to administer a server over a slow 9600 baud dial-up connection. Now PowerShell does have aliases which go a long way to getting around the rather verbose Verb-Noun standard, but getting to know those aliases is a bit of a pain (anyone know of something better than:
alias | where {$_.ResolvedCommandName -eq "<command>"}
?).
An example of the rich way in which history can be manipulated:
iptables
commands are often long-winded and repeating them with slight differences would be a pain if it weren't for just one of many neat features of history manipulation built into Bash, so inserting an iptables rule like the following:
iptables -I camera-1-internet -s 192.168.0.50 -m state --state NEW -j ACCEPT
a second time for another camera ("
camera-2
"), is just a case of issuing:
!!:s/-1-/-2-/:s/50/51
which means "perform the previous command, but substitute
-1-
with-2-
and50
with51
.
The Unix experience is optimised for touch-typists; one can pretty much do everything without leaving the "home" position. For example, in Bash, using the Emacs key bindings (yes, Bash also supports vi bindings), cycling through the history is done using Ctrl-P and Ctrl-N whilst moving to the start and end of a line is done using Ctrl-A and Ctrl-E respectively ... and it definitely doesn't end there. Try even the simplest of navigation in the PowerShell console without moving from the home position and you're in trouble.
- Simple things like versatile paging (a la less) on Unix don't seem to be available out-of-the-box in PowerShell which is a little frustrating, and a rich editor experience doesn't exist either. Of course, one can always download third-party tools that will fill those gaps, but it sure would be nice if these things were just "there" like they are on pretty much any flavour of Unix.
The Windows culture, at least in terms of system API's is largely driven by the supporting frameworks, viz., COM and .NET, both of-which are highly structured and object-based. On the other hand, access to Unix APIs has traditionally been through a file interface (
/dev
and/proc
) or (non-object-oriented) C-style library calls. It's no surprise then that the scripting experiences match their respective OS paradigms. PowerShell is by nature structured (everything is an object) and Bash-and-friends file-based. The structured API which is at the disposal of a PowerShell programmer is vast (essentially matching the vastness of the existing set of standard COM and .NET interfaces).
In short, although the scripting capabilities of PowerShell are arguably more powerful than Bash (especially when you consider the availability of the .NET BCL), the interactive experience is significantly weaker, particularly if you're coming at it from an entirely keyboard-driven, console-based perspective (as many Unix-heads are).
You ask "anyone know of something better than: alias | where {$_.ResolvedCommandName -eq "<command>"}?". How about justalias -Definition *property
(or any other pattern)? I think the problem with your answer is that you are conflating the shell and the console: remember you have a choice of consoles with different editing options. They deliberately left the DOS console editing broken to encourage people to use other consoles such as ISE.
– Duncan
Feb 12 '14 at 9:17
BTW, your!!
example can be written in Powershell as(h -c 1) -replace '-1-','-2-' -replace '50','51' | iex
but it's easier to up arrow and edit for a single command. If you want to do it across a lot of commands I think Powershell would win. To repeat 10 commands ending at command #255 with your edits:(h -c 10 -id 255) -replace '-1-','-2-' -replace '50','51' | iex
Also Powershell's history lets you do things unheard of in Linux shells; if you wonder retrospectively just how long a command took to run:h -id 20 | select { $_.EndExecutionTime - $_.StartExecutionTime }
– Duncan
Feb 12 '14 at 9:32
@Duncan In respect of your comment re the shell and the console--I think that that's just a fundamental difference between Bash and PS; that is: Bash expects to deliver a certain interactive experience whereas PS "leaves" that to something else. I don't have a lot of experience with the ISE console, but from I can remember, it doesn't have a tremendously rich interactive experience either.
– Eric Smith
Feb 14 '14 at 13:21
@Duncan, yes - good point about the ability of PS to deliver in respect of clever history tricks.
– Eric Smith
Feb 14 '14 at 13:24
@Duncan ... but despite your assertion that some things are unheard of in Linux shells:fc -e "sed -i -e 's/-1-/-2-/g' -e 's/50/51/g'" 10 255
– Eric Smith
Feb 14 '14 at 13:56
|
show 1 more comment
I have only recently started dabbling in PowerShell with any degree of seriousness. Although for the past seven years I've worked in an almost exclusively Windows-based environment, I come from a Unix background and find myself constantly trying to "Unix-fy" my interaction experience on Windows. It's frustrating to say the least.
It's only fair to compare PowerShell to something like Bash, tcsh, or zsh since utilities like grep, sed, awk, find, etc. are not, strictly speaking, part of the shell; they will always, however, be part of any Unix environment. That said, a PowerShell command like Select-String has a very similar function to grep and is bundled as a core module in PowerShell ... so the lines can be a little blurred.
I think the key thing is culture, and the fact that the respective tool-sets will embody their respective cultures:
- Unix is a file-based, (in general, non Unicode) text-based culture. Configuration files are almost exclusively text files. Windows, on the other hand has always been far more structured in respect of configuration formats--configurations are generally kept in proprietary databases (e.g., the Windows registry) which require specialised tools for their management.
The Unix administrative (and, for many years, development) interface has traditionally been the command line and the virtual terminal. Windows started off as a GUI and administrative functions have only recently started moving away from being exclusively GUI-based. We can expect the Unix experience on the command line to be a richer, more mature one given the significant lead it has on PowerShell, and my experience matches this. On this, in my experience:
The Unix administrative experience is geared towards making things easy to do in a minimal amount of key strokes; this is probably as a result of the historical situation of having to administer a server over a slow 9600 baud dial-up connection. Now PowerShell does have aliases which go a long way to getting around the rather verbose Verb-Noun standard, but getting to know those aliases is a bit of a pain (anyone know of something better than:
alias | where {$_.ResolvedCommandName -eq "<command>"}
?).
An example of the rich way in which history can be manipulated:
iptables
commands are often long-winded and repeating them with slight differences would be a pain if it weren't for just one of many neat features of history manipulation built into Bash, so inserting an iptables rule like the following:
iptables -I camera-1-internet -s 192.168.0.50 -m state --state NEW -j ACCEPT
a second time for another camera ("
camera-2
"), is just a case of issuing:
!!:s/-1-/-2-/:s/50/51
which means "perform the previous command, but substitute
-1-
with-2-
and50
with51
.
The Unix experience is optimised for touch-typists; one can pretty much do everything without leaving the "home" position. For example, in Bash, using the Emacs key bindings (yes, Bash also supports vi bindings), cycling through the history is done using Ctrl-P and Ctrl-N whilst moving to the start and end of a line is done using Ctrl-A and Ctrl-E respectively ... and it definitely doesn't end there. Try even the simplest of navigation in the PowerShell console without moving from the home position and you're in trouble.
- Simple things like versatile paging (a la less) on Unix don't seem to be available out-of-the-box in PowerShell which is a little frustrating, and a rich editor experience doesn't exist either. Of course, one can always download third-party tools that will fill those gaps, but it sure would be nice if these things were just "there" like they are on pretty much any flavour of Unix.
The Windows culture, at least in terms of system API's is largely driven by the supporting frameworks, viz., COM and .NET, both of-which are highly structured and object-based. On the other hand, access to Unix APIs has traditionally been through a file interface (
/dev
and/proc
) or (non-object-oriented) C-style library calls. It's no surprise then that the scripting experiences match their respective OS paradigms. PowerShell is by nature structured (everything is an object) and Bash-and-friends file-based. The structured API which is at the disposal of a PowerShell programmer is vast (essentially matching the vastness of the existing set of standard COM and .NET interfaces).
In short, although the scripting capabilities of PowerShell are arguably more powerful than Bash (especially when you consider the availability of the .NET BCL), the interactive experience is significantly weaker, particularly if you're coming at it from an entirely keyboard-driven, console-based perspective (as many Unix-heads are).
I have only recently started dabbling in PowerShell with any degree of seriousness. Although for the past seven years I've worked in an almost exclusively Windows-based environment, I come from a Unix background and find myself constantly trying to "Unix-fy" my interaction experience on Windows. It's frustrating to say the least.
It's only fair to compare PowerShell to something like Bash, tcsh, or zsh since utilities like grep, sed, awk, find, etc. are not, strictly speaking, part of the shell; they will always, however, be part of any Unix environment. That said, a PowerShell command like Select-String has a very similar function to grep and is bundled as a core module in PowerShell ... so the lines can be a little blurred.
I think the key thing is culture, and the fact that the respective tool-sets will embody their respective cultures:
- Unix is a file-based, (in general, non Unicode) text-based culture. Configuration files are almost exclusively text files. Windows, on the other hand has always been far more structured in respect of configuration formats--configurations are generally kept in proprietary databases (e.g., the Windows registry) which require specialised tools for their management.
The Unix administrative (and, for many years, development) interface has traditionally been the command line and the virtual terminal. Windows started off as a GUI and administrative functions have only recently started moving away from being exclusively GUI-based. We can expect the Unix experience on the command line to be a richer, more mature one given the significant lead it has on PowerShell, and my experience matches this. On this, in my experience:
The Unix administrative experience is geared towards making things easy to do in a minimal amount of key strokes; this is probably as a result of the historical situation of having to administer a server over a slow 9600 baud dial-up connection. Now PowerShell does have aliases which go a long way to getting around the rather verbose Verb-Noun standard, but getting to know those aliases is a bit of a pain (anyone know of something better than:
alias | where {$_.ResolvedCommandName -eq "<command>"}
?).
An example of the rich way in which history can be manipulated:
iptables
commands are often long-winded and repeating them with slight differences would be a pain if it weren't for just one of many neat features of history manipulation built into Bash, so inserting an iptables rule like the following:
iptables -I camera-1-internet -s 192.168.0.50 -m state --state NEW -j ACCEPT
a second time for another camera ("
camera-2
"), is just a case of issuing:
!!:s/-1-/-2-/:s/50/51
which means "perform the previous command, but substitute
-1-
with-2-
and50
with51
.
The Unix experience is optimised for touch-typists; one can pretty much do everything without leaving the "home" position. For example, in Bash, using the Emacs key bindings (yes, Bash also supports vi bindings), cycling through the history is done using Ctrl-P and Ctrl-N whilst moving to the start and end of a line is done using Ctrl-A and Ctrl-E respectively ... and it definitely doesn't end there. Try even the simplest of navigation in the PowerShell console without moving from the home position and you're in trouble.
- Simple things like versatile paging (a la less) on Unix don't seem to be available out-of-the-box in PowerShell which is a little frustrating, and a rich editor experience doesn't exist either. Of course, one can always download third-party tools that will fill those gaps, but it sure would be nice if these things were just "there" like they are on pretty much any flavour of Unix.
The Windows culture, at least in terms of system API's is largely driven by the supporting frameworks, viz., COM and .NET, both of-which are highly structured and object-based. On the other hand, access to Unix APIs has traditionally been through a file interface (
/dev
and/proc
) or (non-object-oriented) C-style library calls. It's no surprise then that the scripting experiences match their respective OS paradigms. PowerShell is by nature structured (everything is an object) and Bash-and-friends file-based. The structured API which is at the disposal of a PowerShell programmer is vast (essentially matching the vastness of the existing set of standard COM and .NET interfaces).
In short, although the scripting capabilities of PowerShell are arguably more powerful than Bash (especially when you consider the availability of the .NET BCL), the interactive experience is significantly weaker, particularly if you're coming at it from an entirely keyboard-driven, console-based perspective (as many Unix-heads are).
edited Nov 21 '18 at 20:25
Peter Mortensen
13.7k1986113
13.7k1986113
answered Nov 1 '13 at 6:12
Eric SmithEric Smith
3,63712541
3,63712541
You ask "anyone know of something better than: alias | where {$_.ResolvedCommandName -eq "<command>"}?". How about justalias -Definition *property
(or any other pattern)? I think the problem with your answer is that you are conflating the shell and the console: remember you have a choice of consoles with different editing options. They deliberately left the DOS console editing broken to encourage people to use other consoles such as ISE.
– Duncan
Feb 12 '14 at 9:17
BTW, your!!
example can be written in Powershell as(h -c 1) -replace '-1-','-2-' -replace '50','51' | iex
but it's easier to up arrow and edit for a single command. If you want to do it across a lot of commands I think Powershell would win. To repeat 10 commands ending at command #255 with your edits:(h -c 10 -id 255) -replace '-1-','-2-' -replace '50','51' | iex
Also Powershell's history lets you do things unheard of in Linux shells; if you wonder retrospectively just how long a command took to run:h -id 20 | select { $_.EndExecutionTime - $_.StartExecutionTime }
– Duncan
Feb 12 '14 at 9:32
@Duncan In respect of your comment re the shell and the console--I think that that's just a fundamental difference between Bash and PS; that is: Bash expects to deliver a certain interactive experience whereas PS "leaves" that to something else. I don't have a lot of experience with the ISE console, but from I can remember, it doesn't have a tremendously rich interactive experience either.
– Eric Smith
Feb 14 '14 at 13:21
@Duncan, yes - good point about the ability of PS to deliver in respect of clever history tricks.
– Eric Smith
Feb 14 '14 at 13:24
@Duncan ... but despite your assertion that some things are unheard of in Linux shells:fc -e "sed -i -e 's/-1-/-2-/g' -e 's/50/51/g'" 10 255
– Eric Smith
Feb 14 '14 at 13:56
|
show 1 more comment
You ask "anyone know of something better than: alias | where {$_.ResolvedCommandName -eq "<command>"}?". How about justalias -Definition *property
(or any other pattern)? I think the problem with your answer is that you are conflating the shell and the console: remember you have a choice of consoles with different editing options. They deliberately left the DOS console editing broken to encourage people to use other consoles such as ISE.
– Duncan
Feb 12 '14 at 9:17
BTW, your!!
example can be written in Powershell as(h -c 1) -replace '-1-','-2-' -replace '50','51' | iex
but it's easier to up arrow and edit for a single command. If you want to do it across a lot of commands I think Powershell would win. To repeat 10 commands ending at command #255 with your edits:(h -c 10 -id 255) -replace '-1-','-2-' -replace '50','51' | iex
Also Powershell's history lets you do things unheard of in Linux shells; if you wonder retrospectively just how long a command took to run:h -id 20 | select { $_.EndExecutionTime - $_.StartExecutionTime }
– Duncan
Feb 12 '14 at 9:32
@Duncan In respect of your comment re the shell and the console--I think that that's just a fundamental difference between Bash and PS; that is: Bash expects to deliver a certain interactive experience whereas PS "leaves" that to something else. I don't have a lot of experience with the ISE console, but from I can remember, it doesn't have a tremendously rich interactive experience either.
– Eric Smith
Feb 14 '14 at 13:21
@Duncan, yes - good point about the ability of PS to deliver in respect of clever history tricks.
– Eric Smith
Feb 14 '14 at 13:24
@Duncan ... but despite your assertion that some things are unheard of in Linux shells:fc -e "sed -i -e 's/-1-/-2-/g' -e 's/50/51/g'" 10 255
– Eric Smith
Feb 14 '14 at 13:56
You ask "anyone know of something better than: alias | where {$_.ResolvedCommandName -eq "<command>"}?". How about just
alias -Definition *property
(or any other pattern)? I think the problem with your answer is that you are conflating the shell and the console: remember you have a choice of consoles with different editing options. They deliberately left the DOS console editing broken to encourage people to use other consoles such as ISE.– Duncan
Feb 12 '14 at 9:17
You ask "anyone know of something better than: alias | where {$_.ResolvedCommandName -eq "<command>"}?". How about just
alias -Definition *property
(or any other pattern)? I think the problem with your answer is that you are conflating the shell and the console: remember you have a choice of consoles with different editing options. They deliberately left the DOS console editing broken to encourage people to use other consoles such as ISE.– Duncan
Feb 12 '14 at 9:17
BTW, your
!!
example can be written in Powershell as (h -c 1) -replace '-1-','-2-' -replace '50','51' | iex
but it's easier to up arrow and edit for a single command. If you want to do it across a lot of commands I think Powershell would win. To repeat 10 commands ending at command #255 with your edits: (h -c 10 -id 255) -replace '-1-','-2-' -replace '50','51' | iex
Also Powershell's history lets you do things unheard of in Linux shells; if you wonder retrospectively just how long a command took to run: h -id 20 | select { $_.EndExecutionTime - $_.StartExecutionTime }
– Duncan
Feb 12 '14 at 9:32
BTW, your
!!
example can be written in Powershell as (h -c 1) -replace '-1-','-2-' -replace '50','51' | iex
but it's easier to up arrow and edit for a single command. If you want to do it across a lot of commands I think Powershell would win. To repeat 10 commands ending at command #255 with your edits: (h -c 10 -id 255) -replace '-1-','-2-' -replace '50','51' | iex
Also Powershell's history lets you do things unheard of in Linux shells; if you wonder retrospectively just how long a command took to run: h -id 20 | select { $_.EndExecutionTime - $_.StartExecutionTime }
– Duncan
Feb 12 '14 at 9:32
@Duncan In respect of your comment re the shell and the console--I think that that's just a fundamental difference between Bash and PS; that is: Bash expects to deliver a certain interactive experience whereas PS "leaves" that to something else. I don't have a lot of experience with the ISE console, but from I can remember, it doesn't have a tremendously rich interactive experience either.
– Eric Smith
Feb 14 '14 at 13:21
@Duncan In respect of your comment re the shell and the console--I think that that's just a fundamental difference between Bash and PS; that is: Bash expects to deliver a certain interactive experience whereas PS "leaves" that to something else. I don't have a lot of experience with the ISE console, but from I can remember, it doesn't have a tremendously rich interactive experience either.
– Eric Smith
Feb 14 '14 at 13:21
@Duncan, yes - good point about the ability of PS to deliver in respect of clever history tricks.
– Eric Smith
Feb 14 '14 at 13:24
@Duncan, yes - good point about the ability of PS to deliver in respect of clever history tricks.
– Eric Smith
Feb 14 '14 at 13:24
@Duncan ... but despite your assertion that some things are unheard of in Linux shells:
fc -e "sed -i -e 's/-1-/-2-/g' -e 's/50/51/g'" 10 255
– Eric Smith
Feb 14 '14 at 13:56
@Duncan ... but despite your assertion that some things are unheard of in Linux shells:
fc -e "sed -i -e 's/-1-/-2-/g' -e 's/50/51/g'" 10 255
– Eric Smith
Feb 14 '14 at 13:56
|
show 1 more comment
I am not a very experienced PowerShell user by any means, but the little bit of it that I was exposed to impressed me a great deal. You can chain the built-in cmdlets together to do just about anything that you could do at a Unix prompt, and there's some additional goodness for doing things like exporting to CSV, HTML tables, and for more in-depth sys-admin types of jobs. And if you really needed something like sed, there's always UnixUtils or GnuWin32, which you could integrate with Powershell fairly easily.
As a longtime Unix user, I did however have a bit of trouble getting used to the command naming scheme, and I certainly would have benefitted more from it if I knew more .NET.
So essentially, I say it's well worth learning it if the Windows-only-ness of it doesn't pose a problem.
1
There is an open source project "Pash" that lets you run PowerShell on other platforms via Mono. tinyurl.com/6dyoso
– John D. Cook
Feb 21 '09 at 20:46
Whoa! Thanks for the tip; I can't wait to give it a try
– yalestar
Feb 21 '09 at 22:29
add a comment |
I am not a very experienced PowerShell user by any means, but the little bit of it that I was exposed to impressed me a great deal. You can chain the built-in cmdlets together to do just about anything that you could do at a Unix prompt, and there's some additional goodness for doing things like exporting to CSV, HTML tables, and for more in-depth sys-admin types of jobs. And if you really needed something like sed, there's always UnixUtils or GnuWin32, which you could integrate with Powershell fairly easily.
As a longtime Unix user, I did however have a bit of trouble getting used to the command naming scheme, and I certainly would have benefitted more from it if I knew more .NET.
So essentially, I say it's well worth learning it if the Windows-only-ness of it doesn't pose a problem.
1
There is an open source project "Pash" that lets you run PowerShell on other platforms via Mono. tinyurl.com/6dyoso
– John D. Cook
Feb 21 '09 at 20:46
Whoa! Thanks for the tip; I can't wait to give it a try
– yalestar
Feb 21 '09 at 22:29
add a comment |
I am not a very experienced PowerShell user by any means, but the little bit of it that I was exposed to impressed me a great deal. You can chain the built-in cmdlets together to do just about anything that you could do at a Unix prompt, and there's some additional goodness for doing things like exporting to CSV, HTML tables, and for more in-depth sys-admin types of jobs. And if you really needed something like sed, there's always UnixUtils or GnuWin32, which you could integrate with Powershell fairly easily.
As a longtime Unix user, I did however have a bit of trouble getting used to the command naming scheme, and I certainly would have benefitted more from it if I knew more .NET.
So essentially, I say it's well worth learning it if the Windows-only-ness of it doesn't pose a problem.
I am not a very experienced PowerShell user by any means, but the little bit of it that I was exposed to impressed me a great deal. You can chain the built-in cmdlets together to do just about anything that you could do at a Unix prompt, and there's some additional goodness for doing things like exporting to CSV, HTML tables, and for more in-depth sys-admin types of jobs. And if you really needed something like sed, there's always UnixUtils or GnuWin32, which you could integrate with Powershell fairly easily.
As a longtime Unix user, I did however have a bit of trouble getting used to the command naming scheme, and I certainly would have benefitted more from it if I knew more .NET.
So essentially, I say it's well worth learning it if the Windows-only-ness of it doesn't pose a problem.
answered Feb 21 '09 at 20:05
yalestaryalestar
6,68153349
6,68153349
1
There is an open source project "Pash" that lets you run PowerShell on other platforms via Mono. tinyurl.com/6dyoso
– John D. Cook
Feb 21 '09 at 20:46
Whoa! Thanks for the tip; I can't wait to give it a try
– yalestar
Feb 21 '09 at 22:29
add a comment |
1
There is an open source project "Pash" that lets you run PowerShell on other platforms via Mono. tinyurl.com/6dyoso
– John D. Cook
Feb 21 '09 at 20:46
Whoa! Thanks for the tip; I can't wait to give it a try
– yalestar
Feb 21 '09 at 22:29
1
1
There is an open source project "Pash" that lets you run PowerShell on other platforms via Mono. tinyurl.com/6dyoso
– John D. Cook
Feb 21 '09 at 20:46
There is an open source project "Pash" that lets you run PowerShell on other platforms via Mono. tinyurl.com/6dyoso
– John D. Cook
Feb 21 '09 at 20:46
Whoa! Thanks for the tip; I can't wait to give it a try
– yalestar
Feb 21 '09 at 22:29
Whoa! Thanks for the tip; I can't wait to give it a try
– yalestar
Feb 21 '09 at 22:29
add a comment |
When you compare PowerShell to the combination Cygwin/Perl/Shell, be aware that PowerShell only represents the "Shell" part of that combination.
You can however invoke any command from PowerShell just as you do from cmd.exe or Cygwin. It does not re-implement the specified functions, and it is certainly not comparable to Perl.
It's "just" a shell, but it makes programming easier providing a comfortable interface to the .Net universe.
Also keep in mind that PowerShell requires WinXP, Srv2003 or higher, which may pose a problem depending on your IT infrastructure.
Update:
I had no idea what kind of philosophical debate my answer would spark.
I posted my answer in the context of the question: Compare PowerShell to Cygwin and Perl and bash.
PowerShell is a shell, as it makes no syntactic difference between built-in commands, commandlets, user functions, and external commands (.exe, .bat, .cmd). Only invoking .Net methods differ by adding a namespace or an object in the call.
Its programmability derives from .Net framework, not from anything specific to the PowerShell "language".
I'd say I believe PowerShell is a "scripting language" as soon as Bugzilla or MediaWiki are implemented as PowerShell scripts running on a web server ;)
Until then, enjoy the comparisons.
Yeah, I guess when I'm talking about Unix "shell" I'm also referring to all the normal utilities that come with Unix, such as grep, awk, etc. I'm just wondering if PowerShell offers similar utilities out-of-the-box.
– Andy White
Feb 21 '09 at 20:06
3
Powershell is not "just a shell". It is a scripting language. I wonder in what way it is not comparable to perl? I admit that it isn't as mature, but beyond that I don't see the disparity.
– EBGreen
Feb 21 '09 at 23:11
@EBGreen, What exactly do you mean with this comment? I agree that any shell or scripting language is inherently similar, but I was wondering more about the specific capabilities of PowerShell vs. bash/perl/other unix shells/scripting languages.
– Andy White
Feb 21 '09 at 23:33
2
Powershell has an incredibly wide range of functions. It is - A interactive, composable shell - A rich interactive scripting language - A programming language It has a rich set of OO & tesxt utility functions (i.e. equivalents to grep/awk/etc) as well.
– Jeffrey Snover - MSFT
Feb 22 '09 at 0:28
1
@Andy - I understood Devio to say that powershell is not as powerful as Perl. I don't believe that is true and I just wondered why he thought that was the case.
– EBGreen
Feb 22 '09 at 4:15
|
show 2 more comments
When you compare PowerShell to the combination Cygwin/Perl/Shell, be aware that PowerShell only represents the "Shell" part of that combination.
You can however invoke any command from PowerShell just as you do from cmd.exe or Cygwin. It does not re-implement the specified functions, and it is certainly not comparable to Perl.
It's "just" a shell, but it makes programming easier providing a comfortable interface to the .Net universe.
Also keep in mind that PowerShell requires WinXP, Srv2003 or higher, which may pose a problem depending on your IT infrastructure.
Update:
I had no idea what kind of philosophical debate my answer would spark.
I posted my answer in the context of the question: Compare PowerShell to Cygwin and Perl and bash.
PowerShell is a shell, as it makes no syntactic difference between built-in commands, commandlets, user functions, and external commands (.exe, .bat, .cmd). Only invoking .Net methods differ by adding a namespace or an object in the call.
Its programmability derives from .Net framework, not from anything specific to the PowerShell "language".
I'd say I believe PowerShell is a "scripting language" as soon as Bugzilla or MediaWiki are implemented as PowerShell scripts running on a web server ;)
Until then, enjoy the comparisons.
Yeah, I guess when I'm talking about Unix "shell" I'm also referring to all the normal utilities that come with Unix, such as grep, awk, etc. I'm just wondering if PowerShell offers similar utilities out-of-the-box.
– Andy White
Feb 21 '09 at 20:06
3
Powershell is not "just a shell". It is a scripting language. I wonder in what way it is not comparable to perl? I admit that it isn't as mature, but beyond that I don't see the disparity.
– EBGreen
Feb 21 '09 at 23:11
@EBGreen, What exactly do you mean with this comment? I agree that any shell or scripting language is inherently similar, but I was wondering more about the specific capabilities of PowerShell vs. bash/perl/other unix shells/scripting languages.
– Andy White
Feb 21 '09 at 23:33
2
Powershell has an incredibly wide range of functions. It is - A interactive, composable shell - A rich interactive scripting language - A programming language It has a rich set of OO & tesxt utility functions (i.e. equivalents to grep/awk/etc) as well.
– Jeffrey Snover - MSFT
Feb 22 '09 at 0:28
1
@Andy - I understood Devio to say that powershell is not as powerful as Perl. I don't believe that is true and I just wondered why he thought that was the case.
– EBGreen
Feb 22 '09 at 4:15
|
show 2 more comments
When you compare PowerShell to the combination Cygwin/Perl/Shell, be aware that PowerShell only represents the "Shell" part of that combination.
You can however invoke any command from PowerShell just as you do from cmd.exe or Cygwin. It does not re-implement the specified functions, and it is certainly not comparable to Perl.
It's "just" a shell, but it makes programming easier providing a comfortable interface to the .Net universe.
Also keep in mind that PowerShell requires WinXP, Srv2003 or higher, which may pose a problem depending on your IT infrastructure.
Update:
I had no idea what kind of philosophical debate my answer would spark.
I posted my answer in the context of the question: Compare PowerShell to Cygwin and Perl and bash.
PowerShell is a shell, as it makes no syntactic difference between built-in commands, commandlets, user functions, and external commands (.exe, .bat, .cmd). Only invoking .Net methods differ by adding a namespace or an object in the call.
Its programmability derives from .Net framework, not from anything specific to the PowerShell "language".
I'd say I believe PowerShell is a "scripting language" as soon as Bugzilla or MediaWiki are implemented as PowerShell scripts running on a web server ;)
Until then, enjoy the comparisons.
When you compare PowerShell to the combination Cygwin/Perl/Shell, be aware that PowerShell only represents the "Shell" part of that combination.
You can however invoke any command from PowerShell just as you do from cmd.exe or Cygwin. It does not re-implement the specified functions, and it is certainly not comparable to Perl.
It's "just" a shell, but it makes programming easier providing a comfortable interface to the .Net universe.
Also keep in mind that PowerShell requires WinXP, Srv2003 or higher, which may pose a problem depending on your IT infrastructure.
Update:
I had no idea what kind of philosophical debate my answer would spark.
I posted my answer in the context of the question: Compare PowerShell to Cygwin and Perl and bash.
PowerShell is a shell, as it makes no syntactic difference between built-in commands, commandlets, user functions, and external commands (.exe, .bat, .cmd). Only invoking .Net methods differ by adding a namespace or an object in the call.
Its programmability derives from .Net framework, not from anything specific to the PowerShell "language".
I'd say I believe PowerShell is a "scripting language" as soon as Bugzilla or MediaWiki are implemented as PowerShell scripts running on a web server ;)
Until then, enjoy the comparisons.
edited Feb 22 '09 at 11:44
answered Feb 21 '09 at 20:02
deviodevio
32.6k565129
32.6k565129
Yeah, I guess when I'm talking about Unix "shell" I'm also referring to all the normal utilities that come with Unix, such as grep, awk, etc. I'm just wondering if PowerShell offers similar utilities out-of-the-box.
– Andy White
Feb 21 '09 at 20:06
3
Powershell is not "just a shell". It is a scripting language. I wonder in what way it is not comparable to perl? I admit that it isn't as mature, but beyond that I don't see the disparity.
– EBGreen
Feb 21 '09 at 23:11
@EBGreen, What exactly do you mean with this comment? I agree that any shell or scripting language is inherently similar, but I was wondering more about the specific capabilities of PowerShell vs. bash/perl/other unix shells/scripting languages.
– Andy White
Feb 21 '09 at 23:33
2
Powershell has an incredibly wide range of functions. It is - A interactive, composable shell - A rich interactive scripting language - A programming language It has a rich set of OO & tesxt utility functions (i.e. equivalents to grep/awk/etc) as well.
– Jeffrey Snover - MSFT
Feb 22 '09 at 0:28
1
@Andy - I understood Devio to say that powershell is not as powerful as Perl. I don't believe that is true and I just wondered why he thought that was the case.
– EBGreen
Feb 22 '09 at 4:15
|
show 2 more comments
Yeah, I guess when I'm talking about Unix "shell" I'm also referring to all the normal utilities that come with Unix, such as grep, awk, etc. I'm just wondering if PowerShell offers similar utilities out-of-the-box.
– Andy White
Feb 21 '09 at 20:06
3
Powershell is not "just a shell". It is a scripting language. I wonder in what way it is not comparable to perl? I admit that it isn't as mature, but beyond that I don't see the disparity.
– EBGreen
Feb 21 '09 at 23:11
@EBGreen, What exactly do you mean with this comment? I agree that any shell or scripting language is inherently similar, but I was wondering more about the specific capabilities of PowerShell vs. bash/perl/other unix shells/scripting languages.
– Andy White
Feb 21 '09 at 23:33
2
Powershell has an incredibly wide range of functions. It is - A interactive, composable shell - A rich interactive scripting language - A programming language It has a rich set of OO & tesxt utility functions (i.e. equivalents to grep/awk/etc) as well.
– Jeffrey Snover - MSFT
Feb 22 '09 at 0:28
1
@Andy - I understood Devio to say that powershell is not as powerful as Perl. I don't believe that is true and I just wondered why he thought that was the case.
– EBGreen
Feb 22 '09 at 4:15
Yeah, I guess when I'm talking about Unix "shell" I'm also referring to all the normal utilities that come with Unix, such as grep, awk, etc. I'm just wondering if PowerShell offers similar utilities out-of-the-box.
– Andy White
Feb 21 '09 at 20:06
Yeah, I guess when I'm talking about Unix "shell" I'm also referring to all the normal utilities that come with Unix, such as grep, awk, etc. I'm just wondering if PowerShell offers similar utilities out-of-the-box.
– Andy White
Feb 21 '09 at 20:06
3
3
Powershell is not "just a shell". It is a scripting language. I wonder in what way it is not comparable to perl? I admit that it isn't as mature, but beyond that I don't see the disparity.
– EBGreen
Feb 21 '09 at 23:11
Powershell is not "just a shell". It is a scripting language. I wonder in what way it is not comparable to perl? I admit that it isn't as mature, but beyond that I don't see the disparity.
– EBGreen
Feb 21 '09 at 23:11
@EBGreen, What exactly do you mean with this comment? I agree that any shell or scripting language is inherently similar, but I was wondering more about the specific capabilities of PowerShell vs. bash/perl/other unix shells/scripting languages.
– Andy White
Feb 21 '09 at 23:33
@EBGreen, What exactly do you mean with this comment? I agree that any shell or scripting language is inherently similar, but I was wondering more about the specific capabilities of PowerShell vs. bash/perl/other unix shells/scripting languages.
– Andy White
Feb 21 '09 at 23:33
2
2
Powershell has an incredibly wide range of functions. It is - A interactive, composable shell - A rich interactive scripting language - A programming language It has a rich set of OO & tesxt utility functions (i.e. equivalents to grep/awk/etc) as well.
– Jeffrey Snover - MSFT
Feb 22 '09 at 0:28
Powershell has an incredibly wide range of functions. It is - A interactive, composable shell - A rich interactive scripting language - A programming language It has a rich set of OO & tesxt utility functions (i.e. equivalents to grep/awk/etc) as well.
– Jeffrey Snover - MSFT
Feb 22 '09 at 0:28
1
1
@Andy - I understood Devio to say that powershell is not as powerful as Perl. I don't believe that is true and I just wondered why he thought that was the case.
– EBGreen
Feb 22 '09 at 4:15
@Andy - I understood Devio to say that powershell is not as powerful as Perl. I don't believe that is true and I just wondered why he thought that was the case.
– EBGreen
Feb 22 '09 at 4:15
|
show 2 more comments
If you like shell scripting you will love PowerShell!
Start at A guided tour of the Microsoft Command Shell (Ars Technica).
8
I love shell scripting and I tolerate PowerShell. It's commands and syntax are atrocious. Horribly long commands and options without any useful command completion. Or if there is I haven't found it. Too many features crammed into single commands that should be separated out. Weird variable and escape syntax only a DOS batch programmer could love.
– Zan Lynx
Jun 24 '10 at 5:32
8
@Zan Lynx - You are right about not having found stuff. All commands have aliases, and many of them match both DOS and UNIX commands ( ps, dir, rm, ls, kill, history, man, cat, clear etc.) The names are long so that they have a meaningful name. Great for scripts -it helps when a new person has to use and maintain it. There is tab expansion for cmdlets, functions, variable, path, parameters etc. Much of the syntax is from Unix shells and what escape syntax are you talking about? `` is not used for escape since it is the path separator in Windows.
– manojlds
Aug 24 '11 at 4:49
3
@Zan Lynx - Your arguments are not valid. To stop interpreting variables, use'
(single quotes). To the double double quotes thing - same, usewrite-output 'this is a "test"'
. The question you are pointing to is for Regex and the escaping for regex is valid everywhere. Powershell has Here-Strings / verbatim strings as well. Even Java doesn't have these! Try escaping regex in Java. And you don't sometimes use literalpath. You use when you need to. LiteralPath treats wildcard characters verbatim and doesn't expand them. You use it when your files have it. It gives you more options.
– manojlds
Aug 24 '11 at 5:41
3
@manojlds: Compared to the bash shell, Powershell is full of inconsistencies that make no sense and are just confusing. In bash you use the same escape character everywhere and file paths are escaped just as strings are. You don't need a special parameter for it. If you expand a variable that has special characters in it, you put it in double quotes and the contents are safe, no need to call a function to re-escape it.
– Zan Lynx
Aug 24 '11 at 5:46
5
@Zan Lynx - There are no inconsistencies. Evenwrite-output "this is a `"test`""
works. Just use`
instead of ``. regex::escape exists to help you so that you don't miss escaping stuff. It is not necessary to use it. You are thinking that additional options that are there to help you and prevent mistakes are inconsistencies.
– manojlds
Aug 24 '11 at 5:51
|
show 4 more comments
If you like shell scripting you will love PowerShell!
Start at A guided tour of the Microsoft Command Shell (Ars Technica).
8
I love shell scripting and I tolerate PowerShell. It's commands and syntax are atrocious. Horribly long commands and options without any useful command completion. Or if there is I haven't found it. Too many features crammed into single commands that should be separated out. Weird variable and escape syntax only a DOS batch programmer could love.
– Zan Lynx
Jun 24 '10 at 5:32
8
@Zan Lynx - You are right about not having found stuff. All commands have aliases, and many of them match both DOS and UNIX commands ( ps, dir, rm, ls, kill, history, man, cat, clear etc.) The names are long so that they have a meaningful name. Great for scripts -it helps when a new person has to use and maintain it. There is tab expansion for cmdlets, functions, variable, path, parameters etc. Much of the syntax is from Unix shells and what escape syntax are you talking about? `` is not used for escape since it is the path separator in Windows.
– manojlds
Aug 24 '11 at 4:49
3
@Zan Lynx - Your arguments are not valid. To stop interpreting variables, use'
(single quotes). To the double double quotes thing - same, usewrite-output 'this is a "test"'
. The question you are pointing to is for Regex and the escaping for regex is valid everywhere. Powershell has Here-Strings / verbatim strings as well. Even Java doesn't have these! Try escaping regex in Java. And you don't sometimes use literalpath. You use when you need to. LiteralPath treats wildcard characters verbatim and doesn't expand them. You use it when your files have it. It gives you more options.
– manojlds
Aug 24 '11 at 5:41
3
@manojlds: Compared to the bash shell, Powershell is full of inconsistencies that make no sense and are just confusing. In bash you use the same escape character everywhere and file paths are escaped just as strings are. You don't need a special parameter for it. If you expand a variable that has special characters in it, you put it in double quotes and the contents are safe, no need to call a function to re-escape it.
– Zan Lynx
Aug 24 '11 at 5:46
5
@Zan Lynx - There are no inconsistencies. Evenwrite-output "this is a `"test`""
works. Just use`
instead of ``. regex::escape exists to help you so that you don't miss escaping stuff. It is not necessary to use it. You are thinking that additional options that are there to help you and prevent mistakes are inconsistencies.
– manojlds
Aug 24 '11 at 5:51
|
show 4 more comments
If you like shell scripting you will love PowerShell!
Start at A guided tour of the Microsoft Command Shell (Ars Technica).
If you like shell scripting you will love PowerShell!
Start at A guided tour of the Microsoft Command Shell (Ars Technica).
edited Dec 11 '14 at 22:08
Peter Mortensen
13.7k1986113
13.7k1986113
answered Feb 21 '09 at 20:01
NickNick
2,31211718
2,31211718
8
I love shell scripting and I tolerate PowerShell. It's commands and syntax are atrocious. Horribly long commands and options without any useful command completion. Or if there is I haven't found it. Too many features crammed into single commands that should be separated out. Weird variable and escape syntax only a DOS batch programmer could love.
– Zan Lynx
Jun 24 '10 at 5:32
8
@Zan Lynx - You are right about not having found stuff. All commands have aliases, and many of them match both DOS and UNIX commands ( ps, dir, rm, ls, kill, history, man, cat, clear etc.) The names are long so that they have a meaningful name. Great for scripts -it helps when a new person has to use and maintain it. There is tab expansion for cmdlets, functions, variable, path, parameters etc. Much of the syntax is from Unix shells and what escape syntax are you talking about? `` is not used for escape since it is the path separator in Windows.
– manojlds
Aug 24 '11 at 4:49
3
@Zan Lynx - Your arguments are not valid. To stop interpreting variables, use'
(single quotes). To the double double quotes thing - same, usewrite-output 'this is a "test"'
. The question you are pointing to is for Regex and the escaping for regex is valid everywhere. Powershell has Here-Strings / verbatim strings as well. Even Java doesn't have these! Try escaping regex in Java. And you don't sometimes use literalpath. You use when you need to. LiteralPath treats wildcard characters verbatim and doesn't expand them. You use it when your files have it. It gives you more options.
– manojlds
Aug 24 '11 at 5:41
3
@manojlds: Compared to the bash shell, Powershell is full of inconsistencies that make no sense and are just confusing. In bash you use the same escape character everywhere and file paths are escaped just as strings are. You don't need a special parameter for it. If you expand a variable that has special characters in it, you put it in double quotes and the contents are safe, no need to call a function to re-escape it.
– Zan Lynx
Aug 24 '11 at 5:46
5
@Zan Lynx - There are no inconsistencies. Evenwrite-output "this is a `"test`""
works. Just use`
instead of ``. regex::escape exists to help you so that you don't miss escaping stuff. It is not necessary to use it. You are thinking that additional options that are there to help you and prevent mistakes are inconsistencies.
– manojlds
Aug 24 '11 at 5:51
|
show 4 more comments
8
I love shell scripting and I tolerate PowerShell. It's commands and syntax are atrocious. Horribly long commands and options without any useful command completion. Or if there is I haven't found it. Too many features crammed into single commands that should be separated out. Weird variable and escape syntax only a DOS batch programmer could love.
– Zan Lynx
Jun 24 '10 at 5:32
8
@Zan Lynx - You are right about not having found stuff. All commands have aliases, and many of them match both DOS and UNIX commands ( ps, dir, rm, ls, kill, history, man, cat, clear etc.) The names are long so that they have a meaningful name. Great for scripts -it helps when a new person has to use and maintain it. There is tab expansion for cmdlets, functions, variable, path, parameters etc. Much of the syntax is from Unix shells and what escape syntax are you talking about? `` is not used for escape since it is the path separator in Windows.
– manojlds
Aug 24 '11 at 4:49
3
@Zan Lynx - Your arguments are not valid. To stop interpreting variables, use'
(single quotes). To the double double quotes thing - same, usewrite-output 'this is a "test"'
. The question you are pointing to is for Regex and the escaping for regex is valid everywhere. Powershell has Here-Strings / verbatim strings as well. Even Java doesn't have these! Try escaping regex in Java. And you don't sometimes use literalpath. You use when you need to. LiteralPath treats wildcard characters verbatim and doesn't expand them. You use it when your files have it. It gives you more options.
– manojlds
Aug 24 '11 at 5:41
3
@manojlds: Compared to the bash shell, Powershell is full of inconsistencies that make no sense and are just confusing. In bash you use the same escape character everywhere and file paths are escaped just as strings are. You don't need a special parameter for it. If you expand a variable that has special characters in it, you put it in double quotes and the contents are safe, no need to call a function to re-escape it.
– Zan Lynx
Aug 24 '11 at 5:46
5
@Zan Lynx - There are no inconsistencies. Evenwrite-output "this is a `"test`""
works. Just use`
instead of ``. regex::escape exists to help you so that you don't miss escaping stuff. It is not necessary to use it. You are thinking that additional options that are there to help you and prevent mistakes are inconsistencies.
– manojlds
Aug 24 '11 at 5:51
8
8
I love shell scripting and I tolerate PowerShell. It's commands and syntax are atrocious. Horribly long commands and options without any useful command completion. Or if there is I haven't found it. Too many features crammed into single commands that should be separated out. Weird variable and escape syntax only a DOS batch programmer could love.
– Zan Lynx
Jun 24 '10 at 5:32
I love shell scripting and I tolerate PowerShell. It's commands and syntax are atrocious. Horribly long commands and options without any useful command completion. Or if there is I haven't found it. Too many features crammed into single commands that should be separated out. Weird variable and escape syntax only a DOS batch programmer could love.
– Zan Lynx
Jun 24 '10 at 5:32
8
8
@Zan Lynx - You are right about not having found stuff. All commands have aliases, and many of them match both DOS and UNIX commands ( ps, dir, rm, ls, kill, history, man, cat, clear etc.) The names are long so that they have a meaningful name. Great for scripts -it helps when a new person has to use and maintain it. There is tab expansion for cmdlets, functions, variable, path, parameters etc. Much of the syntax is from Unix shells and what escape syntax are you talking about? `` is not used for escape since it is the path separator in Windows.
– manojlds
Aug 24 '11 at 4:49
@Zan Lynx - You are right about not having found stuff. All commands have aliases, and many of them match both DOS and UNIX commands ( ps, dir, rm, ls, kill, history, man, cat, clear etc.) The names are long so that they have a meaningful name. Great for scripts -it helps when a new person has to use and maintain it. There is tab expansion for cmdlets, functions, variable, path, parameters etc. Much of the syntax is from Unix shells and what escape syntax are you talking about? `` is not used for escape since it is the path separator in Windows.
– manojlds
Aug 24 '11 at 4:49
3
3
@Zan Lynx - Your arguments are not valid. To stop interpreting variables, use
'
(single quotes). To the double double quotes thing - same, use write-output 'this is a "test"'
. The question you are pointing to is for Regex and the escaping for regex is valid everywhere. Powershell has Here-Strings / verbatim strings as well. Even Java doesn't have these! Try escaping regex in Java. And you don't sometimes use literalpath. You use when you need to. LiteralPath treats wildcard characters verbatim and doesn't expand them. You use it when your files have it. It gives you more options.– manojlds
Aug 24 '11 at 5:41
@Zan Lynx - Your arguments are not valid. To stop interpreting variables, use
'
(single quotes). To the double double quotes thing - same, use write-output 'this is a "test"'
. The question you are pointing to is for Regex and the escaping for regex is valid everywhere. Powershell has Here-Strings / verbatim strings as well. Even Java doesn't have these! Try escaping regex in Java. And you don't sometimes use literalpath. You use when you need to. LiteralPath treats wildcard characters verbatim and doesn't expand them. You use it when your files have it. It gives you more options.– manojlds
Aug 24 '11 at 5:41
3
3
@manojlds: Compared to the bash shell, Powershell is full of inconsistencies that make no sense and are just confusing. In bash you use the same escape character everywhere and file paths are escaped just as strings are. You don't need a special parameter for it. If you expand a variable that has special characters in it, you put it in double quotes and the contents are safe, no need to call a function to re-escape it.
– Zan Lynx
Aug 24 '11 at 5:46
@manojlds: Compared to the bash shell, Powershell is full of inconsistencies that make no sense and are just confusing. In bash you use the same escape character everywhere and file paths are escaped just as strings are. You don't need a special parameter for it. If you expand a variable that has special characters in it, you put it in double quotes and the contents are safe, no need to call a function to re-escape it.
– Zan Lynx
Aug 24 '11 at 5:46
5
5
@Zan Lynx - There are no inconsistencies. Even
write-output "this is a `"test`""
works. Just use `
instead of ``. regex::escape exists to help you so that you don't miss escaping stuff. It is not necessary to use it. You are thinking that additional options that are there to help you and prevent mistakes are inconsistencies.– manojlds
Aug 24 '11 at 5:51
@Zan Lynx - There are no inconsistencies. Even
write-output "this is a `"test`""
works. Just use `
instead of ``. regex::escape exists to help you so that you don't miss escaping stuff. It is not necessary to use it. You are thinking that additional options that are there to help you and prevent mistakes are inconsistencies.– manojlds
Aug 24 '11 at 5:51
|
show 4 more comments
As my recent experiments led me into depths of PowerShell and .NET calls, I must say that PowerShell can replace Cygwin and Unix shell.
I'm not sure about Perl, but since both PowerShell and Perl are Turing complete as programming languages, I give this as a yes to replacing Perl too.
One thing that PowerShell has above Cygwin and ordinary Bash under *nix, is its ability to perform sandboxed DLL calls, manipulating the operating system via direct API calls, WMI methods and even COM objects. How about launching Internet Explorer via code, then doing whatever you want with its displayed document, effectively emulating a back-end for a Web server?
How about gathering data from SQL servers and other data providers, parse them and export as CSV, mail messages, text and actually any kind of existing and non-existing file formats? (With proper skills of creating a valid file out of data received, of course, but CSV are readily available).
And there is an extra security available via signed cmdlets and scripts,
group policies, and execution policies that help prevent malicious code from running on your system even if you run them as administrator.
About what commands are implemented - the answer by Richard lists them and PowerShell's capability of emulating their functionality already.
About whether PowerShell is strong to warrant switching over - this is more a matter of personal preference, although as more and more Windows services are providing PowerShell cmdlets to control them, not using PowerShell with these services present is considered a hindrance. (Hyper-V server is the primary such service, and it also provides the ability to do more with PowerShell cmdlets than with GUI!)
Probably this answer is five years late, but still, if someone performs administrative tasks or general scripting of various stuff on Windows, they should definitely try harnessing PowerShell for their purposes.
add a comment |
As my recent experiments led me into depths of PowerShell and .NET calls, I must say that PowerShell can replace Cygwin and Unix shell.
I'm not sure about Perl, but since both PowerShell and Perl are Turing complete as programming languages, I give this as a yes to replacing Perl too.
One thing that PowerShell has above Cygwin and ordinary Bash under *nix, is its ability to perform sandboxed DLL calls, manipulating the operating system via direct API calls, WMI methods and even COM objects. How about launching Internet Explorer via code, then doing whatever you want with its displayed document, effectively emulating a back-end for a Web server?
How about gathering data from SQL servers and other data providers, parse them and export as CSV, mail messages, text and actually any kind of existing and non-existing file formats? (With proper skills of creating a valid file out of data received, of course, but CSV are readily available).
And there is an extra security available via signed cmdlets and scripts,
group policies, and execution policies that help prevent malicious code from running on your system even if you run them as administrator.
About what commands are implemented - the answer by Richard lists them and PowerShell's capability of emulating their functionality already.
About whether PowerShell is strong to warrant switching over - this is more a matter of personal preference, although as more and more Windows services are providing PowerShell cmdlets to control them, not using PowerShell with these services present is considered a hindrance. (Hyper-V server is the primary such service, and it also provides the ability to do more with PowerShell cmdlets than with GUI!)
Probably this answer is five years late, but still, if someone performs administrative tasks or general scripting of various stuff on Windows, they should definitely try harnessing PowerShell for their purposes.
add a comment |
As my recent experiments led me into depths of PowerShell and .NET calls, I must say that PowerShell can replace Cygwin and Unix shell.
I'm not sure about Perl, but since both PowerShell and Perl are Turing complete as programming languages, I give this as a yes to replacing Perl too.
One thing that PowerShell has above Cygwin and ordinary Bash under *nix, is its ability to perform sandboxed DLL calls, manipulating the operating system via direct API calls, WMI methods and even COM objects. How about launching Internet Explorer via code, then doing whatever you want with its displayed document, effectively emulating a back-end for a Web server?
How about gathering data from SQL servers and other data providers, parse them and export as CSV, mail messages, text and actually any kind of existing and non-existing file formats? (With proper skills of creating a valid file out of data received, of course, but CSV are readily available).
And there is an extra security available via signed cmdlets and scripts,
group policies, and execution policies that help prevent malicious code from running on your system even if you run them as administrator.
About what commands are implemented - the answer by Richard lists them and PowerShell's capability of emulating their functionality already.
About whether PowerShell is strong to warrant switching over - this is more a matter of personal preference, although as more and more Windows services are providing PowerShell cmdlets to control them, not using PowerShell with these services present is considered a hindrance. (Hyper-V server is the primary such service, and it also provides the ability to do more with PowerShell cmdlets than with GUI!)
Probably this answer is five years late, but still, if someone performs administrative tasks or general scripting of various stuff on Windows, they should definitely try harnessing PowerShell for their purposes.
As my recent experiments led me into depths of PowerShell and .NET calls, I must say that PowerShell can replace Cygwin and Unix shell.
I'm not sure about Perl, but since both PowerShell and Perl are Turing complete as programming languages, I give this as a yes to replacing Perl too.
One thing that PowerShell has above Cygwin and ordinary Bash under *nix, is its ability to perform sandboxed DLL calls, manipulating the operating system via direct API calls, WMI methods and even COM objects. How about launching Internet Explorer via code, then doing whatever you want with its displayed document, effectively emulating a back-end for a Web server?
How about gathering data from SQL servers and other data providers, parse them and export as CSV, mail messages, text and actually any kind of existing and non-existing file formats? (With proper skills of creating a valid file out of data received, of course, but CSV are readily available).
And there is an extra security available via signed cmdlets and scripts,
group policies, and execution policies that help prevent malicious code from running on your system even if you run them as administrator.
About what commands are implemented - the answer by Richard lists them and PowerShell's capability of emulating their functionality already.
About whether PowerShell is strong to warrant switching over - this is more a matter of personal preference, although as more and more Windows services are providing PowerShell cmdlets to control them, not using PowerShell with these services present is considered a hindrance. (Hyper-V server is the primary such service, and it also provides the ability to do more with PowerShell cmdlets than with GUI!)
Probably this answer is five years late, but still, if someone performs administrative tasks or general scripting of various stuff on Windows, they should definitely try harnessing PowerShell for their purposes.
edited Nov 21 '18 at 20:07
Peter Mortensen
13.7k1986113
13.7k1986113
answered Jun 17 '15 at 20:25
VesperVesper
16.8k42849
16.8k42849
add a comment |
add a comment |
TL;DR -- I don't hate Windows or PowerShell I just can't do anything in windows or on PowerShell.
I personally still find PowerShell underwhelming at best.
- tab completion of directory paths do not compound, requiring the user to enter a path separator after every name completion.
- I still feel like windows doesn't even the concept of path or of what a path is, with no accessible user home indicator
~/
short of some@environment://somejibberish/%user_home%
NTFS is still a mess and seemingly always will be, good luck navigating.
cmd-esque interface, The dinosaur cmd.exe is still visible in PowerShell,
edit->mark
still being the only way to copy information, and copying only in the form of rectangular blocks of visible terminal space. andedit->paste
still being the only way to paste strings into the terminal.Painting it blue doesn't make it any more attractive. I don't mind MS developers having a taste in color though.
Windows always opens at top left corner of screen, For somebody who uses vertical task bars this is incredibly annoying, especially considering that the windows task bar will cover the only corner of the window that gives access to copy/paste functionality.
I can't speak much on the grounds of the tools windows includes. Being that there is a whole set of open-source, freely licensed CLI tools, and PowerShell ships with, to my knowledge, none of them is an utter disappointment.
- PowerShell
wget
takes seemingly incomparable arguments to GNU wget, thanks glimmer of hope portably-useless. - PowerShell POSIX is not Bash-compatible, particularly the
&&
operator is not handled, making the simplest of conditional command following not a thing.
I don't know man; I gave it a shot, I really did; I still try to give it a shot in the hopes that the next time I open it it will be any less useless. I cannot do anything in PowerShell, and I can barely do things with a real project to bring GNU tools to Windows.
MySysGit gives me the dinosaur cmd.exe prompt with a couple of GNU tools, and it is still very underwhelming, but at last path completion works. And the Git command will run in Git Bash.
Mintty for MySysGit gives the Cygwin interface over mysysgit's environment, making copy and paste a thing (select to copy (mouse), shift+ins to paste, how modern...). However, things like git push
are broken in Mintty.
I don't mean to rant, but I still see huge problems with command-line usability on Windows even given tools like Cygwin.
P.S.: Just because something can be done in PowerShell, doesn't make it usable. Usability is deeper than ability and is what I tend to focus on when trying to use a product as a consumer.
Turn on QuickEdit mode? Select and press enter to copy, ctrl-v to paste, no more Edit->Mark or Edit->Paste. While in the preferences, set the Window position and untick "let system position window". Tab completion is not just completing filesystem paths, it's also completing variable names, command names, object properties, you might be about to type.
or[
to access a property or index, so it can't just add a path separator on the end. Which PowerShell wget, exactly? Which PowerShell POSIX? It's not trying to bring gnu tools to Windows, or be bash-compatible btw.
– TessellatingHeckler
Mar 27 '14 at 0:22
Yeah i know it's not trying to be bash. I refrained from saying so in the original post. I would say which w get binary but there is no "which" command in power shell :( i don't recall where buy i read power Shell was supposed to be POSIX compatible
– ThorSummoner
Mar 27 '14 at 0:31
5
re: "no which" ->(get-command wg*.exe).Path
. Re: bash completion and readline -> leeholmes.com/blog/2012/09/13/… leading to github.com/lzybkr/PSReadLine
– TessellatingHeckler
Mar 27 '14 at 5:14
add a comment |
TL;DR -- I don't hate Windows or PowerShell I just can't do anything in windows or on PowerShell.
I personally still find PowerShell underwhelming at best.
- tab completion of directory paths do not compound, requiring the user to enter a path separator after every name completion.
- I still feel like windows doesn't even the concept of path or of what a path is, with no accessible user home indicator
~/
short of some@environment://somejibberish/%user_home%
NTFS is still a mess and seemingly always will be, good luck navigating.
cmd-esque interface, The dinosaur cmd.exe is still visible in PowerShell,
edit->mark
still being the only way to copy information, and copying only in the form of rectangular blocks of visible terminal space. andedit->paste
still being the only way to paste strings into the terminal.Painting it blue doesn't make it any more attractive. I don't mind MS developers having a taste in color though.
Windows always opens at top left corner of screen, For somebody who uses vertical task bars this is incredibly annoying, especially considering that the windows task bar will cover the only corner of the window that gives access to copy/paste functionality.
I can't speak much on the grounds of the tools windows includes. Being that there is a whole set of open-source, freely licensed CLI tools, and PowerShell ships with, to my knowledge, none of them is an utter disappointment.
- PowerShell
wget
takes seemingly incomparable arguments to GNU wget, thanks glimmer of hope portably-useless. - PowerShell POSIX is not Bash-compatible, particularly the
&&
operator is not handled, making the simplest of conditional command following not a thing.
I don't know man; I gave it a shot, I really did; I still try to give it a shot in the hopes that the next time I open it it will be any less useless. I cannot do anything in PowerShell, and I can barely do things with a real project to bring GNU tools to Windows.
MySysGit gives me the dinosaur cmd.exe prompt with a couple of GNU tools, and it is still very underwhelming, but at last path completion works. And the Git command will run in Git Bash.
Mintty for MySysGit gives the Cygwin interface over mysysgit's environment, making copy and paste a thing (select to copy (mouse), shift+ins to paste, how modern...). However, things like git push
are broken in Mintty.
I don't mean to rant, but I still see huge problems with command-line usability on Windows even given tools like Cygwin.
P.S.: Just because something can be done in PowerShell, doesn't make it usable. Usability is deeper than ability and is what I tend to focus on when trying to use a product as a consumer.
Turn on QuickEdit mode? Select and press enter to copy, ctrl-v to paste, no more Edit->Mark or Edit->Paste. While in the preferences, set the Window position and untick "let system position window". Tab completion is not just completing filesystem paths, it's also completing variable names, command names, object properties, you might be about to type.
or[
to access a property or index, so it can't just add a path separator on the end. Which PowerShell wget, exactly? Which PowerShell POSIX? It's not trying to bring gnu tools to Windows, or be bash-compatible btw.
– TessellatingHeckler
Mar 27 '14 at 0:22
Yeah i know it's not trying to be bash. I refrained from saying so in the original post. I would say which w get binary but there is no "which" command in power shell :( i don't recall where buy i read power Shell was supposed to be POSIX compatible
– ThorSummoner
Mar 27 '14 at 0:31
5
re: "no which" ->(get-command wg*.exe).Path
. Re: bash completion and readline -> leeholmes.com/blog/2012/09/13/… leading to github.com/lzybkr/PSReadLine
– TessellatingHeckler
Mar 27 '14 at 5:14
add a comment |
TL;DR -- I don't hate Windows or PowerShell I just can't do anything in windows or on PowerShell.
I personally still find PowerShell underwhelming at best.
- tab completion of directory paths do not compound, requiring the user to enter a path separator after every name completion.
- I still feel like windows doesn't even the concept of path or of what a path is, with no accessible user home indicator
~/
short of some@environment://somejibberish/%user_home%
NTFS is still a mess and seemingly always will be, good luck navigating.
cmd-esque interface, The dinosaur cmd.exe is still visible in PowerShell,
edit->mark
still being the only way to copy information, and copying only in the form of rectangular blocks of visible terminal space. andedit->paste
still being the only way to paste strings into the terminal.Painting it blue doesn't make it any more attractive. I don't mind MS developers having a taste in color though.
Windows always opens at top left corner of screen, For somebody who uses vertical task bars this is incredibly annoying, especially considering that the windows task bar will cover the only corner of the window that gives access to copy/paste functionality.
I can't speak much on the grounds of the tools windows includes. Being that there is a whole set of open-source, freely licensed CLI tools, and PowerShell ships with, to my knowledge, none of them is an utter disappointment.
- PowerShell
wget
takes seemingly incomparable arguments to GNU wget, thanks glimmer of hope portably-useless. - PowerShell POSIX is not Bash-compatible, particularly the
&&
operator is not handled, making the simplest of conditional command following not a thing.
I don't know man; I gave it a shot, I really did; I still try to give it a shot in the hopes that the next time I open it it will be any less useless. I cannot do anything in PowerShell, and I can barely do things with a real project to bring GNU tools to Windows.
MySysGit gives me the dinosaur cmd.exe prompt with a couple of GNU tools, and it is still very underwhelming, but at last path completion works. And the Git command will run in Git Bash.
Mintty for MySysGit gives the Cygwin interface over mysysgit's environment, making copy and paste a thing (select to copy (mouse), shift+ins to paste, how modern...). However, things like git push
are broken in Mintty.
I don't mean to rant, but I still see huge problems with command-line usability on Windows even given tools like Cygwin.
P.S.: Just because something can be done in PowerShell, doesn't make it usable. Usability is deeper than ability and is what I tend to focus on when trying to use a product as a consumer.
TL;DR -- I don't hate Windows or PowerShell I just can't do anything in windows or on PowerShell.
I personally still find PowerShell underwhelming at best.
- tab completion of directory paths do not compound, requiring the user to enter a path separator after every name completion.
- I still feel like windows doesn't even the concept of path or of what a path is, with no accessible user home indicator
~/
short of some@environment://somejibberish/%user_home%
NTFS is still a mess and seemingly always will be, good luck navigating.
cmd-esque interface, The dinosaur cmd.exe is still visible in PowerShell,
edit->mark
still being the only way to copy information, and copying only in the form of rectangular blocks of visible terminal space. andedit->paste
still being the only way to paste strings into the terminal.Painting it blue doesn't make it any more attractive. I don't mind MS developers having a taste in color though.
Windows always opens at top left corner of screen, For somebody who uses vertical task bars this is incredibly annoying, especially considering that the windows task bar will cover the only corner of the window that gives access to copy/paste functionality.
I can't speak much on the grounds of the tools windows includes. Being that there is a whole set of open-source, freely licensed CLI tools, and PowerShell ships with, to my knowledge, none of them is an utter disappointment.
- PowerShell
wget
takes seemingly incomparable arguments to GNU wget, thanks glimmer of hope portably-useless. - PowerShell POSIX is not Bash-compatible, particularly the
&&
operator is not handled, making the simplest of conditional command following not a thing.
I don't know man; I gave it a shot, I really did; I still try to give it a shot in the hopes that the next time I open it it will be any less useless. I cannot do anything in PowerShell, and I can barely do things with a real project to bring GNU tools to Windows.
MySysGit gives me the dinosaur cmd.exe prompt with a couple of GNU tools, and it is still very underwhelming, but at last path completion works. And the Git command will run in Git Bash.
Mintty for MySysGit gives the Cygwin interface over mysysgit's environment, making copy and paste a thing (select to copy (mouse), shift+ins to paste, how modern...). However, things like git push
are broken in Mintty.
I don't mean to rant, but I still see huge problems with command-line usability on Windows even given tools like Cygwin.
P.S.: Just because something can be done in PowerShell, doesn't make it usable. Usability is deeper than ability and is what I tend to focus on when trying to use a product as a consumer.
edited Nov 21 '18 at 20:19
community wiki
2 revs, 2 users 84%
ThorSummoner
Turn on QuickEdit mode? Select and press enter to copy, ctrl-v to paste, no more Edit->Mark or Edit->Paste. While in the preferences, set the Window position and untick "let system position window". Tab completion is not just completing filesystem paths, it's also completing variable names, command names, object properties, you might be about to type.
or[
to access a property or index, so it can't just add a path separator on the end. Which PowerShell wget, exactly? Which PowerShell POSIX? It's not trying to bring gnu tools to Windows, or be bash-compatible btw.
– TessellatingHeckler
Mar 27 '14 at 0:22
Yeah i know it's not trying to be bash. I refrained from saying so in the original post. I would say which w get binary but there is no "which" command in power shell :( i don't recall where buy i read power Shell was supposed to be POSIX compatible
– ThorSummoner
Mar 27 '14 at 0:31
5
re: "no which" ->(get-command wg*.exe).Path
. Re: bash completion and readline -> leeholmes.com/blog/2012/09/13/… leading to github.com/lzybkr/PSReadLine
– TessellatingHeckler
Mar 27 '14 at 5:14
add a comment |
Turn on QuickEdit mode? Select and press enter to copy, ctrl-v to paste, no more Edit->Mark or Edit->Paste. While in the preferences, set the Window position and untick "let system position window". Tab completion is not just completing filesystem paths, it's also completing variable names, command names, object properties, you might be about to type.
or[
to access a property or index, so it can't just add a path separator on the end. Which PowerShell wget, exactly? Which PowerShell POSIX? It's not trying to bring gnu tools to Windows, or be bash-compatible btw.
– TessellatingHeckler
Mar 27 '14 at 0:22
Yeah i know it's not trying to be bash. I refrained from saying so in the original post. I would say which w get binary but there is no "which" command in power shell :( i don't recall where buy i read power Shell was supposed to be POSIX compatible
– ThorSummoner
Mar 27 '14 at 0:31
5
re: "no which" ->(get-command wg*.exe).Path
. Re: bash completion and readline -> leeholmes.com/blog/2012/09/13/… leading to github.com/lzybkr/PSReadLine
– TessellatingHeckler
Mar 27 '14 at 5:14
Turn on QuickEdit mode? Select and press enter to copy, ctrl-v to paste, no more Edit->Mark or Edit->Paste. While in the preferences, set the Window position and untick "let system position window". Tab completion is not just completing filesystem paths, it's also completing variable names, command names, object properties, you might be about to type
.
or [
to access a property or index, so it can't just add a path separator on the end. Which PowerShell wget, exactly? Which PowerShell POSIX? It's not trying to bring gnu tools to Windows, or be bash-compatible btw.– TessellatingHeckler
Mar 27 '14 at 0:22
Turn on QuickEdit mode? Select and press enter to copy, ctrl-v to paste, no more Edit->Mark or Edit->Paste. While in the preferences, set the Window position and untick "let system position window". Tab completion is not just completing filesystem paths, it's also completing variable names, command names, object properties, you might be about to type
.
or [
to access a property or index, so it can't just add a path separator on the end. Which PowerShell wget, exactly? Which PowerShell POSIX? It's not trying to bring gnu tools to Windows, or be bash-compatible btw.– TessellatingHeckler
Mar 27 '14 at 0:22
Yeah i know it's not trying to be bash. I refrained from saying so in the original post. I would say which w get binary but there is no "which" command in power shell :( i don't recall where buy i read power Shell was supposed to be POSIX compatible
– ThorSummoner
Mar 27 '14 at 0:31
Yeah i know it's not trying to be bash. I refrained from saying so in the original post. I would say which w get binary but there is no "which" command in power shell :( i don't recall where buy i read power Shell was supposed to be POSIX compatible
– ThorSummoner
Mar 27 '14 at 0:31
5
5
re: "no which" ->
(get-command wg*.exe).Path
. Re: bash completion and readline -> leeholmes.com/blog/2012/09/13/… leading to github.com/lzybkr/PSReadLine– TessellatingHeckler
Mar 27 '14 at 5:14
re: "no which" ->
(get-command wg*.exe).Path
. Re: bash completion and readline -> leeholmes.com/blog/2012/09/13/… leading to github.com/lzybkr/PSReadLine– TessellatingHeckler
Mar 27 '14 at 5:14
add a comment |
The cmdlets in PowerShell are very nice and work reliably. Their object-orientedness appeals to me a lot since I'm a Java/C# developer, but it's not at all a complete set. Since it's object oriented, it's missed out on a lot of the text stream maturity of the POSIX tool set (awk
and sed
to name a few).
The best answer I've found to the dilemma of loving OO techniques and loving the maturity in the POSIX tools is to use both! One great aspect of PowerShell is that it does an excellent job piping objects to standard streams. PowerShell by default uses an object pipeline to transport its objects around. These aren't the standard streams (standard out, standard error, and standard in). When PowerShell needs to pass output to a standard process that doesn't have an object pipeline, it first converts the objects to a text stream. Since it does this so well, PowerShell makes an excellent place to host POSIX tools!
The best POSIX tool set is GnuWin32. It does take more than 5 seconds to install, but it's worth the trouble, and as far as I can tell, it doesn't modify your system (registry, c:windows*
folders, etc.) except copying files to the directories you specify. This is extra nice because if you put the tools in a shared directory, many people can access them concurrently.
GnuWin32 Installation Instructions
Download and execute the exe (it's from the SourceForge site) pointing it to a suitable directory (I'll be using C:bin
). It will create a GetGnuWin32
directory there in which you will run download.bat
, then install.bat
(without parameters), after which, there will be a C:binGetGnuWin32gnuwin32bin
directory that is the most useful folder that has ever existed on a Windows machine. Add that directory to your path, and you're ready to go.
add a comment |
The cmdlets in PowerShell are very nice and work reliably. Their object-orientedness appeals to me a lot since I'm a Java/C# developer, but it's not at all a complete set. Since it's object oriented, it's missed out on a lot of the text stream maturity of the POSIX tool set (awk
and sed
to name a few).
The best answer I've found to the dilemma of loving OO techniques and loving the maturity in the POSIX tools is to use both! One great aspect of PowerShell is that it does an excellent job piping objects to standard streams. PowerShell by default uses an object pipeline to transport its objects around. These aren't the standard streams (standard out, standard error, and standard in). When PowerShell needs to pass output to a standard process that doesn't have an object pipeline, it first converts the objects to a text stream. Since it does this so well, PowerShell makes an excellent place to host POSIX tools!
The best POSIX tool set is GnuWin32. It does take more than 5 seconds to install, but it's worth the trouble, and as far as I can tell, it doesn't modify your system (registry, c:windows*
folders, etc.) except copying files to the directories you specify. This is extra nice because if you put the tools in a shared directory, many people can access them concurrently.
GnuWin32 Installation Instructions
Download and execute the exe (it's from the SourceForge site) pointing it to a suitable directory (I'll be using C:bin
). It will create a GetGnuWin32
directory there in which you will run download.bat
, then install.bat
(without parameters), after which, there will be a C:binGetGnuWin32gnuwin32bin
directory that is the most useful folder that has ever existed on a Windows machine. Add that directory to your path, and you're ready to go.
add a comment |
The cmdlets in PowerShell are very nice and work reliably. Their object-orientedness appeals to me a lot since I'm a Java/C# developer, but it's not at all a complete set. Since it's object oriented, it's missed out on a lot of the text stream maturity of the POSIX tool set (awk
and sed
to name a few).
The best answer I've found to the dilemma of loving OO techniques and loving the maturity in the POSIX tools is to use both! One great aspect of PowerShell is that it does an excellent job piping objects to standard streams. PowerShell by default uses an object pipeline to transport its objects around. These aren't the standard streams (standard out, standard error, and standard in). When PowerShell needs to pass output to a standard process that doesn't have an object pipeline, it first converts the objects to a text stream. Since it does this so well, PowerShell makes an excellent place to host POSIX tools!
The best POSIX tool set is GnuWin32. It does take more than 5 seconds to install, but it's worth the trouble, and as far as I can tell, it doesn't modify your system (registry, c:windows*
folders, etc.) except copying files to the directories you specify. This is extra nice because if you put the tools in a shared directory, many people can access them concurrently.
GnuWin32 Installation Instructions
Download and execute the exe (it's from the SourceForge site) pointing it to a suitable directory (I'll be using C:bin
). It will create a GetGnuWin32
directory there in which you will run download.bat
, then install.bat
(without parameters), after which, there will be a C:binGetGnuWin32gnuwin32bin
directory that is the most useful folder that has ever existed on a Windows machine. Add that directory to your path, and you're ready to go.
The cmdlets in PowerShell are very nice and work reliably. Their object-orientedness appeals to me a lot since I'm a Java/C# developer, but it's not at all a complete set. Since it's object oriented, it's missed out on a lot of the text stream maturity of the POSIX tool set (awk
and sed
to name a few).
The best answer I've found to the dilemma of loving OO techniques and loving the maturity in the POSIX tools is to use both! One great aspect of PowerShell is that it does an excellent job piping objects to standard streams. PowerShell by default uses an object pipeline to transport its objects around. These aren't the standard streams (standard out, standard error, and standard in). When PowerShell needs to pass output to a standard process that doesn't have an object pipeline, it first converts the objects to a text stream. Since it does this so well, PowerShell makes an excellent place to host POSIX tools!
The best POSIX tool set is GnuWin32. It does take more than 5 seconds to install, but it's worth the trouble, and as far as I can tell, it doesn't modify your system (registry, c:windows*
folders, etc.) except copying files to the directories you specify. This is extra nice because if you put the tools in a shared directory, many people can access them concurrently.
GnuWin32 Installation Instructions
Download and execute the exe (it's from the SourceForge site) pointing it to a suitable directory (I'll be using C:bin
). It will create a GetGnuWin32
directory there in which you will run download.bat
, then install.bat
(without parameters), after which, there will be a C:binGetGnuWin32gnuwin32bin
directory that is the most useful folder that has ever existed on a Windows machine. Add that directory to your path, and you're ready to go.
edited Nov 21 '18 at 20:32
Peter Mortensen
13.7k1986113
13.7k1986113
answered Oct 26 '12 at 14:52
Limited AtonementLimited Atonement
4,35923750
4,35923750
add a comment |
add a comment |
I haven't seen that the PowerShell has really taken off, at least not yet. So it might not be worth the effort of learning it unless those others on your team already know it.
For your predicament you might be better off with a scripting language that others could get behind, Perl like you mentioned, or others like Ruby or Python.
I think a lot of it depends on what you need to do. Personally I've been using Python for my own personal scripts, but I know when I start writing something that I'll never be able to pass it on - so I try not to do anything too revolutionary.
add a comment |
I haven't seen that the PowerShell has really taken off, at least not yet. So it might not be worth the effort of learning it unless those others on your team already know it.
For your predicament you might be better off with a scripting language that others could get behind, Perl like you mentioned, or others like Ruby or Python.
I think a lot of it depends on what you need to do. Personally I've been using Python for my own personal scripts, but I know when I start writing something that I'll never be able to pass it on - so I try not to do anything too revolutionary.
add a comment |
I haven't seen that the PowerShell has really taken off, at least not yet. So it might not be worth the effort of learning it unless those others on your team already know it.
For your predicament you might be better off with a scripting language that others could get behind, Perl like you mentioned, or others like Ruby or Python.
I think a lot of it depends on what you need to do. Personally I've been using Python for my own personal scripts, but I know when I start writing something that I'll never be able to pass it on - so I try not to do anything too revolutionary.
I haven't seen that the PowerShell has really taken off, at least not yet. So it might not be worth the effort of learning it unless those others on your team already know it.
For your predicament you might be better off with a scripting language that others could get behind, Perl like you mentioned, or others like Ruby or Python.
I think a lot of it depends on what you need to do. Personally I've been using Python for my own personal scripts, but I know when I start writing something that I'll never be able to pass it on - so I try not to do anything too revolutionary.
edited Nov 19 '18 at 7:06
Peter Mortensen
13.7k1986113
13.7k1986113
answered Feb 21 '09 at 20:12
greggreg
25911
25911
add a comment |
add a comment |
Why not use both? Call PowerShell scripts in Cygwin just like any other interpreted scripts like Perl, etc.
I do this enough that I wrote https://bitbucket.org/jbianchi/powershell for a Bash wrapper to call powershell.exe in Cygwin. It can be used as a shebang as the first line of a powershell.exe .ps1 script (since PowerShell also uses "#" as a comment). See https://bitbucket.org/jbianchi/powershell/wiki/Home for examples
add a comment |
Why not use both? Call PowerShell scripts in Cygwin just like any other interpreted scripts like Perl, etc.
I do this enough that I wrote https://bitbucket.org/jbianchi/powershell for a Bash wrapper to call powershell.exe in Cygwin. It can be used as a shebang as the first line of a powershell.exe .ps1 script (since PowerShell also uses "#" as a comment). See https://bitbucket.org/jbianchi/powershell/wiki/Home for examples
add a comment |
Why not use both? Call PowerShell scripts in Cygwin just like any other interpreted scripts like Perl, etc.
I do this enough that I wrote https://bitbucket.org/jbianchi/powershell for a Bash wrapper to call powershell.exe in Cygwin. It can be used as a shebang as the first line of a powershell.exe .ps1 script (since PowerShell also uses "#" as a comment). See https://bitbucket.org/jbianchi/powershell/wiki/Home for examples
Why not use both? Call PowerShell scripts in Cygwin just like any other interpreted scripts like Perl, etc.
I do this enough that I wrote https://bitbucket.org/jbianchi/powershell for a Bash wrapper to call powershell.exe in Cygwin. It can be used as a shebang as the first line of a powershell.exe .ps1 script (since PowerShell also uses "#" as a comment). See https://bitbucket.org/jbianchi/powershell/wiki/Home for examples
edited Nov 21 '18 at 20:28
Peter Mortensen
13.7k1986113
13.7k1986113
answered Oct 25 '13 at 17:01
johnnyBjohnnyB
543512
543512
add a comment |
add a comment |
In a couple of lines, Cygwin and PowerShell are different tools however if you have Cygwin installed you can run the Cygwin executables within a PowerShell session. I've gotten so used to PowerShell that now I no longer use grep, sort, awk, etc. There are pretty much built-in alternatives in PowerShell, and if not you can find a cmdlet out there.
The main tool I find myself using is ssh.exe, but within a PowerShell session.
It works great.
add a comment |
In a couple of lines, Cygwin and PowerShell are different tools however if you have Cygwin installed you can run the Cygwin executables within a PowerShell session. I've gotten so used to PowerShell that now I no longer use grep, sort, awk, etc. There are pretty much built-in alternatives in PowerShell, and if not you can find a cmdlet out there.
The main tool I find myself using is ssh.exe, but within a PowerShell session.
It works great.
add a comment |
In a couple of lines, Cygwin and PowerShell are different tools however if you have Cygwin installed you can run the Cygwin executables within a PowerShell session. I've gotten so used to PowerShell that now I no longer use grep, sort, awk, etc. There are pretty much built-in alternatives in PowerShell, and if not you can find a cmdlet out there.
The main tool I find myself using is ssh.exe, but within a PowerShell session.
It works great.
In a couple of lines, Cygwin and PowerShell are different tools however if you have Cygwin installed you can run the Cygwin executables within a PowerShell session. I've gotten so used to PowerShell that now I no longer use grep, sort, awk, etc. There are pretty much built-in alternatives in PowerShell, and if not you can find a cmdlet out there.
The main tool I find myself using is ssh.exe, but within a PowerShell session.
It works great.
edited Nov 21 '18 at 20:29
Peter Mortensen
13.7k1986113
13.7k1986113
answered Aug 29 '13 at 7:13
yaxzoneyaxzone
1693
1693
add a comment |
add a comment |
PowerShell is very powerful, more powerful than the standard built-ins of the Unix shells (but only because it includes much of the functionality usually shelled out to subprograms). Also, consider that you can write applets in any .NET language, including IronPython, IronRuby, PerlNet, etc.. or you can simply call your cygwin commands from PowerShell, ignoring all the extra functionality and it will work similarly to bash, korn, or whatever...
I think you may be missing the design goals of Unix shells. Not knocking PowerShell (would like to learn more myself) but you need to understand Unix tooling to make a statement like that.
– Jé Queue
Jan 7 '11 at 17:24
2
@Xepoch - No, I think you're missing the design goals of PowerShell. PowerShell can do everything the Unix shells can do in the same way that they do it. However, the real power comes when you utilize PS's object piping system rather than just parsing text output. So, PowerShell can do exactly what bash or korn can do, but they can't do what PowerShell can do.
– Erik Funkenbusch
Jan 7 '11 at 17:31
3
I simply don't know PowerShell enough to give you a critique thereon, but as you clearly know the goals of the Unix shells are not necessarily a fully comprehensive replacement of external tooling, rather the control structures around it. Again I cannot at this time compare nor contrast but elevating PowerShell because it has more built-ins is not necessarily the boon of the Unix shells.
– Jé Queue
Jan 7 '11 at 18:07
@Xepoch - The point is, you can choose which way you want to do it. You can use all the goodness of the built-in shell, or you can ignore and do it the way Unix does it. It's your choice. And choice is good, right?
– Erik Funkenbusch
Jan 7 '11 at 18:08
add a comment |
PowerShell is very powerful, more powerful than the standard built-ins of the Unix shells (but only because it includes much of the functionality usually shelled out to subprograms). Also, consider that you can write applets in any .NET language, including IronPython, IronRuby, PerlNet, etc.. or you can simply call your cygwin commands from PowerShell, ignoring all the extra functionality and it will work similarly to bash, korn, or whatever...
I think you may be missing the design goals of Unix shells. Not knocking PowerShell (would like to learn more myself) but you need to understand Unix tooling to make a statement like that.
– Jé Queue
Jan 7 '11 at 17:24
2
@Xepoch - No, I think you're missing the design goals of PowerShell. PowerShell can do everything the Unix shells can do in the same way that they do it. However, the real power comes when you utilize PS's object piping system rather than just parsing text output. So, PowerShell can do exactly what bash or korn can do, but they can't do what PowerShell can do.
– Erik Funkenbusch
Jan 7 '11 at 17:31
3
I simply don't know PowerShell enough to give you a critique thereon, but as you clearly know the goals of the Unix shells are not necessarily a fully comprehensive replacement of external tooling, rather the control structures around it. Again I cannot at this time compare nor contrast but elevating PowerShell because it has more built-ins is not necessarily the boon of the Unix shells.
– Jé Queue
Jan 7 '11 at 18:07
@Xepoch - The point is, you can choose which way you want to do it. You can use all the goodness of the built-in shell, or you can ignore and do it the way Unix does it. It's your choice. And choice is good, right?
– Erik Funkenbusch
Jan 7 '11 at 18:08
add a comment |
PowerShell is very powerful, more powerful than the standard built-ins of the Unix shells (but only because it includes much of the functionality usually shelled out to subprograms). Also, consider that you can write applets in any .NET language, including IronPython, IronRuby, PerlNet, etc.. or you can simply call your cygwin commands from PowerShell, ignoring all the extra functionality and it will work similarly to bash, korn, or whatever...
PowerShell is very powerful, more powerful than the standard built-ins of the Unix shells (but only because it includes much of the functionality usually shelled out to subprograms). Also, consider that you can write applets in any .NET language, including IronPython, IronRuby, PerlNet, etc.. or you can simply call your cygwin commands from PowerShell, ignoring all the extra functionality and it will work similarly to bash, korn, or whatever...
answered Feb 22 '09 at 3:22
Erik FunkenbuschErik Funkenbusch
80.1k24159256
80.1k24159256
I think you may be missing the design goals of Unix shells. Not knocking PowerShell (would like to learn more myself) but you need to understand Unix tooling to make a statement like that.
– Jé Queue
Jan 7 '11 at 17:24
2
@Xepoch - No, I think you're missing the design goals of PowerShell. PowerShell can do everything the Unix shells can do in the same way that they do it. However, the real power comes when you utilize PS's object piping system rather than just parsing text output. So, PowerShell can do exactly what bash or korn can do, but they can't do what PowerShell can do.
– Erik Funkenbusch
Jan 7 '11 at 17:31
3
I simply don't know PowerShell enough to give you a critique thereon, but as you clearly know the goals of the Unix shells are not necessarily a fully comprehensive replacement of external tooling, rather the control structures around it. Again I cannot at this time compare nor contrast but elevating PowerShell because it has more built-ins is not necessarily the boon of the Unix shells.
– Jé Queue
Jan 7 '11 at 18:07
@Xepoch - The point is, you can choose which way you want to do it. You can use all the goodness of the built-in shell, or you can ignore and do it the way Unix does it. It's your choice. And choice is good, right?
– Erik Funkenbusch
Jan 7 '11 at 18:08
add a comment |
I think you may be missing the design goals of Unix shells. Not knocking PowerShell (would like to learn more myself) but you need to understand Unix tooling to make a statement like that.
– Jé Queue
Jan 7 '11 at 17:24
2
@Xepoch - No, I think you're missing the design goals of PowerShell. PowerShell can do everything the Unix shells can do in the same way that they do it. However, the real power comes when you utilize PS's object piping system rather than just parsing text output. So, PowerShell can do exactly what bash or korn can do, but they can't do what PowerShell can do.
– Erik Funkenbusch
Jan 7 '11 at 17:31
3
I simply don't know PowerShell enough to give you a critique thereon, but as you clearly know the goals of the Unix shells are not necessarily a fully comprehensive replacement of external tooling, rather the control structures around it. Again I cannot at this time compare nor contrast but elevating PowerShell because it has more built-ins is not necessarily the boon of the Unix shells.
– Jé Queue
Jan 7 '11 at 18:07
@Xepoch - The point is, you can choose which way you want to do it. You can use all the goodness of the built-in shell, or you can ignore and do it the way Unix does it. It's your choice. And choice is good, right?
– Erik Funkenbusch
Jan 7 '11 at 18:08
I think you may be missing the design goals of Unix shells. Not knocking PowerShell (would like to learn more myself) but you need to understand Unix tooling to make a statement like that.
– Jé Queue
Jan 7 '11 at 17:24
I think you may be missing the design goals of Unix shells. Not knocking PowerShell (would like to learn more myself) but you need to understand Unix tooling to make a statement like that.
– Jé Queue
Jan 7 '11 at 17:24
2
2
@Xepoch - No, I think you're missing the design goals of PowerShell. PowerShell can do everything the Unix shells can do in the same way that they do it. However, the real power comes when you utilize PS's object piping system rather than just parsing text output. So, PowerShell can do exactly what bash or korn can do, but they can't do what PowerShell can do.
– Erik Funkenbusch
Jan 7 '11 at 17:31
@Xepoch - No, I think you're missing the design goals of PowerShell. PowerShell can do everything the Unix shells can do in the same way that they do it. However, the real power comes when you utilize PS's object piping system rather than just parsing text output. So, PowerShell can do exactly what bash or korn can do, but they can't do what PowerShell can do.
– Erik Funkenbusch
Jan 7 '11 at 17:31
3
3
I simply don't know PowerShell enough to give you a critique thereon, but as you clearly know the goals of the Unix shells are not necessarily a fully comprehensive replacement of external tooling, rather the control structures around it. Again I cannot at this time compare nor contrast but elevating PowerShell because it has more built-ins is not necessarily the boon of the Unix shells.
– Jé Queue
Jan 7 '11 at 18:07
I simply don't know PowerShell enough to give you a critique thereon, but as you clearly know the goals of the Unix shells are not necessarily a fully comprehensive replacement of external tooling, rather the control structures around it. Again I cannot at this time compare nor contrast but elevating PowerShell because it has more built-ins is not necessarily the boon of the Unix shells.
– Jé Queue
Jan 7 '11 at 18:07
@Xepoch - The point is, you can choose which way you want to do it. You can use all the goodness of the built-in shell, or you can ignore and do it the way Unix does it. It's your choice. And choice is good, right?
– Erik Funkenbusch
Jan 7 '11 at 18:08
@Xepoch - The point is, you can choose which way you want to do it. You can use all the goodness of the built-in shell, or you can ignore and do it the way Unix does it. It's your choice. And choice is good, right?
– Erik Funkenbusch
Jan 7 '11 at 18:08
add a comment |
I found PowerShell programming to be not worth the effort.
I have several years of experience with shell scripting under Unix, but I found it enormously difficult to do much of anything with PowerShell.
It seems like many functions require you to interrogate the Windows Management Interface and issue SQL-like commands to get the information you need.
For example, I wanted to write a script to remove all files with a specific suffix from a directory tree. Under Unix, this would be a simple ...
find . -name *.xyz -exec rm {} ;
After a couple of hours dicking around with Scripting.FileSystemObject
and WScript.Shell
and issuing "SELECT * FROM Win32_ShortcutFile WHERE Drive = '" & drive & "' AND Path = '" & searchFolder & "'", I finally gave up and settled for Windows Explorer's Search command and just do it manually. There's probably some way to do what I wanted, but I didn't see anything obvious and all the examples on the MSDN site were so trivial as to be worthless.
EDIT Heh, of course as soon as I wrote this I poked around some more and found what I had been missing: the -recurse
option to the remove-item command is faulty (revealed if you use get-help remove-item -detailed
).
I had been trying "remove-item -filter '* .xyz' -recurse" and it wasn't working, so I gave up on it.
Turns out you need to use get-childitem -filter '*.xyz' -recurse | remove-item
16
I think you're confusing Windows Scripting Host (WSH) with PowerShell. They're totally different.
– Erik Funkenbusch
Feb 22 '09 at 3:05
3
As an example, if you want to delete all the files that end in .TMN you can issue this command get-childitem c: -include *.TMN -recurse | foreach ($_) {remove-item $_.fullname}
– Erik Funkenbusch
Feb 22 '09 at 3:10
@Mystere: I tried this, and it didn't seem to work. After some futzing about, it seems that *.tmn is what you need (instead of just .tmn)
– redtuna
Jun 23 '10 at 20:47
5
I couldn't respectfully disagree more, and I'm by no means a Windows guy. I find PS much easier to script than bash. PS is more consistent. With Bash, any console utility you invoke has its own syntax, and unique behavior, and the bash syntax itself is rather cryptic. PS is much more robust with language features like anonymous functions, (scriptblocks), parameter validation, advanced functions etc. Plus concepts of modules for portability and many other features. Mainly though, the biggest reason is the thing you always hear about PS, objects trump text. Bash is still faster though.
– user2233949
Apr 28 '15 at 22:27
add a comment |
I found PowerShell programming to be not worth the effort.
I have several years of experience with shell scripting under Unix, but I found it enormously difficult to do much of anything with PowerShell.
It seems like many functions require you to interrogate the Windows Management Interface and issue SQL-like commands to get the information you need.
For example, I wanted to write a script to remove all files with a specific suffix from a directory tree. Under Unix, this would be a simple ...
find . -name *.xyz -exec rm {} ;
After a couple of hours dicking around with Scripting.FileSystemObject
and WScript.Shell
and issuing "SELECT * FROM Win32_ShortcutFile WHERE Drive = '" & drive & "' AND Path = '" & searchFolder & "'", I finally gave up and settled for Windows Explorer's Search command and just do it manually. There's probably some way to do what I wanted, but I didn't see anything obvious and all the examples on the MSDN site were so trivial as to be worthless.
EDIT Heh, of course as soon as I wrote this I poked around some more and found what I had been missing: the -recurse
option to the remove-item command is faulty (revealed if you use get-help remove-item -detailed
).
I had been trying "remove-item -filter '* .xyz' -recurse" and it wasn't working, so I gave up on it.
Turns out you need to use get-childitem -filter '*.xyz' -recurse | remove-item
16
I think you're confusing Windows Scripting Host (WSH) with PowerShell. They're totally different.
– Erik Funkenbusch
Feb 22 '09 at 3:05
3
As an example, if you want to delete all the files that end in .TMN you can issue this command get-childitem c: -include *.TMN -recurse | foreach ($_) {remove-item $_.fullname}
– Erik Funkenbusch
Feb 22 '09 at 3:10
@Mystere: I tried this, and it didn't seem to work. After some futzing about, it seems that *.tmn is what you need (instead of just .tmn)
– redtuna
Jun 23 '10 at 20:47
5
I couldn't respectfully disagree more, and I'm by no means a Windows guy. I find PS much easier to script than bash. PS is more consistent. With Bash, any console utility you invoke has its own syntax, and unique behavior, and the bash syntax itself is rather cryptic. PS is much more robust with language features like anonymous functions, (scriptblocks), parameter validation, advanced functions etc. Plus concepts of modules for portability and many other features. Mainly though, the biggest reason is the thing you always hear about PS, objects trump text. Bash is still faster though.
– user2233949
Apr 28 '15 at 22:27
add a comment |
I found PowerShell programming to be not worth the effort.
I have several years of experience with shell scripting under Unix, but I found it enormously difficult to do much of anything with PowerShell.
It seems like many functions require you to interrogate the Windows Management Interface and issue SQL-like commands to get the information you need.
For example, I wanted to write a script to remove all files with a specific suffix from a directory tree. Under Unix, this would be a simple ...
find . -name *.xyz -exec rm {} ;
After a couple of hours dicking around with Scripting.FileSystemObject
and WScript.Shell
and issuing "SELECT * FROM Win32_ShortcutFile WHERE Drive = '" & drive & "' AND Path = '" & searchFolder & "'", I finally gave up and settled for Windows Explorer's Search command and just do it manually. There's probably some way to do what I wanted, but I didn't see anything obvious and all the examples on the MSDN site were so trivial as to be worthless.
EDIT Heh, of course as soon as I wrote this I poked around some more and found what I had been missing: the -recurse
option to the remove-item command is faulty (revealed if you use get-help remove-item -detailed
).
I had been trying "remove-item -filter '* .xyz' -recurse" and it wasn't working, so I gave up on it.
Turns out you need to use get-childitem -filter '*.xyz' -recurse | remove-item
I found PowerShell programming to be not worth the effort.
I have several years of experience with shell scripting under Unix, but I found it enormously difficult to do much of anything with PowerShell.
It seems like many functions require you to interrogate the Windows Management Interface and issue SQL-like commands to get the information you need.
For example, I wanted to write a script to remove all files with a specific suffix from a directory tree. Under Unix, this would be a simple ...
find . -name *.xyz -exec rm {} ;
After a couple of hours dicking around with Scripting.FileSystemObject
and WScript.Shell
and issuing "SELECT * FROM Win32_ShortcutFile WHERE Drive = '" & drive & "' AND Path = '" & searchFolder & "'", I finally gave up and settled for Windows Explorer's Search command and just do it manually. There's probably some way to do what I wanted, but I didn't see anything obvious and all the examples on the MSDN site were so trivial as to be worthless.
EDIT Heh, of course as soon as I wrote this I poked around some more and found what I had been missing: the -recurse
option to the remove-item command is faulty (revealed if you use get-help remove-item -detailed
).
I had been trying "remove-item -filter '* .xyz' -recurse" and it wasn't working, so I gave up on it.
Turns out you need to use get-childitem -filter '*.xyz' -recurse | remove-item
edited Apr 11 '13 at 21:46
Rob Kielty
6,29653047
6,29653047
answered Feb 22 '09 at 2:34
TMNTMN
2,8931621
2,8931621
16
I think you're confusing Windows Scripting Host (WSH) with PowerShell. They're totally different.
– Erik Funkenbusch
Feb 22 '09 at 3:05
3
As an example, if you want to delete all the files that end in .TMN you can issue this command get-childitem c: -include *.TMN -recurse | foreach ($_) {remove-item $_.fullname}
– Erik Funkenbusch
Feb 22 '09 at 3:10
@Mystere: I tried this, and it didn't seem to work. After some futzing about, it seems that *.tmn is what you need (instead of just .tmn)
– redtuna
Jun 23 '10 at 20:47
5
I couldn't respectfully disagree more, and I'm by no means a Windows guy. I find PS much easier to script than bash. PS is more consistent. With Bash, any console utility you invoke has its own syntax, and unique behavior, and the bash syntax itself is rather cryptic. PS is much more robust with language features like anonymous functions, (scriptblocks), parameter validation, advanced functions etc. Plus concepts of modules for portability and many other features. Mainly though, the biggest reason is the thing you always hear about PS, objects trump text. Bash is still faster though.
– user2233949
Apr 28 '15 at 22:27
add a comment |
16
I think you're confusing Windows Scripting Host (WSH) with PowerShell. They're totally different.
– Erik Funkenbusch
Feb 22 '09 at 3:05
3
As an example, if you want to delete all the files that end in .TMN you can issue this command get-childitem c: -include *.TMN -recurse | foreach ($_) {remove-item $_.fullname}
– Erik Funkenbusch
Feb 22 '09 at 3:10
@Mystere: I tried this, and it didn't seem to work. After some futzing about, it seems that *.tmn is what you need (instead of just .tmn)
– redtuna
Jun 23 '10 at 20:47
5
I couldn't respectfully disagree more, and I'm by no means a Windows guy. I find PS much easier to script than bash. PS is more consistent. With Bash, any console utility you invoke has its own syntax, and unique behavior, and the bash syntax itself is rather cryptic. PS is much more robust with language features like anonymous functions, (scriptblocks), parameter validation, advanced functions etc. Plus concepts of modules for portability and many other features. Mainly though, the biggest reason is the thing you always hear about PS, objects trump text. Bash is still faster though.
– user2233949
Apr 28 '15 at 22:27
16
16
I think you're confusing Windows Scripting Host (WSH) with PowerShell. They're totally different.
– Erik Funkenbusch
Feb 22 '09 at 3:05
I think you're confusing Windows Scripting Host (WSH) with PowerShell. They're totally different.
– Erik Funkenbusch
Feb 22 '09 at 3:05
3
3
As an example, if you want to delete all the files that end in .TMN you can issue this command get-childitem c: -include *.TMN -recurse | foreach ($_) {remove-item $_.fullname}
– Erik Funkenbusch
Feb 22 '09 at 3:10
As an example, if you want to delete all the files that end in .TMN you can issue this command get-childitem c: -include *.TMN -recurse | foreach ($_) {remove-item $_.fullname}
– Erik Funkenbusch
Feb 22 '09 at 3:10
@Mystere: I tried this, and it didn't seem to work. After some futzing about, it seems that *.tmn is what you need (instead of just .tmn)
– redtuna
Jun 23 '10 at 20:47
@Mystere: I tried this, and it didn't seem to work. After some futzing about, it seems that *.tmn is what you need (instead of just .tmn)
– redtuna
Jun 23 '10 at 20:47
5
5
I couldn't respectfully disagree more, and I'm by no means a Windows guy. I find PS much easier to script than bash. PS is more consistent. With Bash, any console utility you invoke has its own syntax, and unique behavior, and the bash syntax itself is rather cryptic. PS is much more robust with language features like anonymous functions, (scriptblocks), parameter validation, advanced functions etc. Plus concepts of modules for portability and many other features. Mainly though, the biggest reason is the thing you always hear about PS, objects trump text. Bash is still faster though.
– user2233949
Apr 28 '15 at 22:27
I couldn't respectfully disagree more, and I'm by no means a Windows guy. I find PS much easier to script than bash. PS is more consistent. With Bash, any console utility you invoke has its own syntax, and unique behavior, and the bash syntax itself is rather cryptic. PS is much more robust with language features like anonymous functions, (scriptblocks), parameter validation, advanced functions etc. Plus concepts of modules for portability and many other features. Mainly though, the biggest reason is the thing you always hear about PS, objects trump text. Bash is still faster though.
– user2233949
Apr 28 '15 at 22:27
add a comment |
You can also try running Bash scripts on Windows using BashWin at
https://github.com/skanga/BashWin.
add a comment |
You can also try running Bash scripts on Windows using BashWin at
https://github.com/skanga/BashWin.
add a comment |
You can also try running Bash scripts on Windows using BashWin at
https://github.com/skanga/BashWin.
You can also try running Bash scripts on Windows using BashWin at
https://github.com/skanga/BashWin.
edited Nov 21 '18 at 20:32
Peter Mortensen
13.7k1986113
13.7k1986113
answered Jul 13 '12 at 17:06
skangaskanga
8028
8028
add a comment |
add a comment |
6
I wouldn't say that, I was interested in picking up Powershell, found this page, and now I know the general differences between PS and the shell scripting I'm used to.
– Bender the Greatest
Jul 16 '11 at 16:58
4
This post suddenly rose from ashes in a HN link submission. Great work. And bad for @Bobby for closing this as not constructive.
– Sid
Jul 13 '12 at 14:27
24
If someone cannot ask how well one tool replicates the functions of another then S.O. cannot answer tool comparison questions. This is carefully worded to avoid controversy but was careless presumed "controversial" simply for looking like a Unix vs Windows question. And it got a factual, objective answer, with additional factual insight into how helpful Unix scripting might be on Windows.
– chernevik
Jul 13 '12 at 15:16
14
Why is this closed, again? Someone please edit the title to say "PowerShell vs Unix Shells on the Windows Platform" to steer the trolls away from treating it as "Windows vs Unix," which it is not. This is a perfectly constructive question - voted to reopen.
– x0n
Jul 16 '12 at 6:14
2
The op is mixing shell with tools. PowerShell has its use. But GNU is a project to bring UNIX goodies freely to other OS, including Windows. Every thing in the list op gives have a gnu implementation in Windows. Accessible from GnuWin32 or individual sites. Windows BAT isn't useless, it has redirection and pipe and conditions.
– MeaCulpa
Oct 24 '12 at 4:41