
Re: Powershell is nice, but creating GUIs on powershell scripts is really stupid
GUI over scripts?
You mean like SQL Server Management Studio?
Works well there. Not a PowerShell guy myself, but SSMS works brilliantly.
Microsoft's Windows Server 2012 is out. For many systems administrators, the question about this latest iteration of Microsoft's server family is not "What's new?" but "Why care?" Server 2008 R2 is a great operating system, while Server 2012 bears the stigma of Metro and the Windows 8 controversy. But the answer to "why care" …
Yes, and Exchange administration, and WSUS, and so on.... they are all slower and more cumbersome than the old non powershell based applications. It gives me the same sense of slowness Oracle has always given me when its tools starts to invoke SQL*Plus or some external utility to perform something, and then have to parse the output to find out what's happened... as a software developer I really think that's just wasted CPU cycles and gives a far less good "user experience". What worries me is that technical skills at MS are going down the sink, and if core parts looks good, the whole "shell" experience is getting worse and worse. Probably they too are outsourcing those applications to some part of the world where they don't understand anything about a good GUI app.
We are about to evaluate the benefits of moving from 2008R2 standard to 2012 standard on our DB machines, the one thing I can say I am looking forward too is the removed RAM cap of 32GB.that is imposed on standard 2008R2. I can't say I am particularly interested in any of the other advances except hyper-v improvements as I cant stand VmWares ESXi so perhaps I will look into that.
But seriously another advert for Microsoft?!
You should take a look at the storage improvements, this are excellent and should be very useful to a DBA.
Also: It's an IT news web site, Windows is the most installed server OS in the world, if they didn't publish articles like this they wouldn't be doing their job, it's not an advert to discuss the new and exciting stuff in a new product.
The article makes it clear the 2012 is pretty awesome and mentions catching up or sometimes surpassing the competition a few times... but the competition is (presumably) Linux which is free. Now I know that software/license costs can dwindle to insignificance compared to hardware and human costs but even so, you'd want to be cost-effective.
AS a non-server guy powershell sounds a killer feature but doesn't nix match that for example?
@JDX Linux can go toe-to-toe on many things...but I honestly think MS pipped Linux on the storage front this go-round. And Hyper-V is more or less a match for anything Linux can offer...but with far superior management tools available from both Microsoft and third parties.
Really, the question is: do you manage everything from the command line, read all reports encoded, as text or as HTML...or do you have your staff doing more than just one task? If your staff do more than just the one thing (virtualisation admin, storage admin, network admin, etc) then the reality of the world is that they won't have time to memorise all the commandline details that would be required to do their jobs efficiently using that interface.
Chances are then that a GUI for day-to-day monitoring, maintenance and minor changes are better suited for these individuals, with scripting automating the bulk of the regular work. (Scripting used solely for automation can be done with the textbook beside you, it doesn't require rote memorisation of all the commands.)
In the latter case, good management tools matter. It is here that Microsoft has consistently been ahead of Linux. Is the commandline – and specifically the Linux commandline – better than Microsoft's offerings? Hell fucking yes. If you live and breathe commandline for administration of your daily tasks, accept no substitutes!
But there are rather a lot of admins out there who don't be narrowly focused experts. For them, good management – and monitoring – tools matter. MS did a good job on that here. (RSAT, SCVMM, SCOM, etc.) Credit where it's due.
It would help if the loudest anti-windows ranters would actually admit to the last time they had hands-on (or even eyes-on) experience of Windows [insert marketing tag].
I mean, would you be impressed if I argued against Linux based on my execrable experience of Red Hat distro 4.2, widely regarded as the boil on the backside of IT?
"It would help if the loudest anti-windows ranters would actually admit to the last time they had hands-on (or even eyes-on) experience of Windows [insert marketing tag]."
Last Windows experience: WinXP, WinVista, Win7, Win8.
Last Windows Server experience: Win2003, Win2008, Win2008R2.
With Win8 and now Win2012, it seems MS is going backwards.
I have played around with it, in fact I plan to move to it in the coming months. It does do a lot to make life easier, however as a mixed environment, I not exactly rolling in praise. I give there server team credit, damn good job on the system, but the price to Hyper-V with Windows 2012, is not exactly peaking my interest.
I find the metro interface for the server better than the OS version (which sound weird), and I think its cause they provided functionality into the interface rather than its sole focus as a tablet-ish app whore.
Still, not finalized yet, though as I am contemplating running a primary CentOS server backed, with a few sporadic Windows Servers for Windows Only applications, or if I should Windows-ize the environment, and use the Linux boxes for other items.
It's really hard for me not to poke fun at Power Shell. I've really tried to give it a go, but coming from a very strong background in command line driven systems, it's really awful.
1. Takes an inordinate amount of time to actually start. 11 Seconds each time on speedy, modern hardware
2. Lacks many of the basic features of a unix-like shell
3. Has no concept of handling text in an elegant manner, every thing is an ``object``
4. It's WAY too wordy for even the simplest tasks
5. PATHs are still using the wrong slash
6. No persistent command history
Consider the following:
I need to see the last 10 lines of a log file (ran into this recently with being required to run Splunk on Widows..)
Linux: tail filename.log
Done.
Windows: get-content .\filename.log | select -last 10
Wait for 15 seconds while command is parsed and eventually get the last 10 lines of the file, only the data that I needed was scooted past the 10 line marker while the command was taking an eternity to run.
microsoft just doesn't get it. They continually fail to learn the KISS lesson and continually elect to do things differently just for the sake of being different.
>1. Takes an inordinate amount of time to actually start. 11 Seconds each time on speedy, modern hardware
On my machine it opens *instantly*. Only the first time you open PowerShell after a system reboot does it take a little longer. Maybe you should check to see what's going on the the profile scripts?
>2. Lacks many of the basic features of a unix-like shell
On the contrary, Unix shells lack many, *many* of the features of PowerShell.
>3. Has no concept of handling text in an elegant manner, every thing is an ``object``
Yes it does. Text is just a sequence of string objects. But you will hardly ever use the powerfull string functions of PowerShell, because they simply are not needed when you operate with objects.
>4. It's WAY too wordy for even the simplest tasks
There are short aliases for most common commands, all parameter names can be shortened as long as they are ambigous. Do not be fooled by the fact that it is considered good style to use the long forms when illustrating code. PowerShell can be every bit as terse as bash - sometimes more so.
>5. PATHs are still using the wrong slash
Ignorant. PowerShell has always accepted both the forward slash as well as the backward slash forms.
>6. No persistent command history
Just save it. Or set a function to save it on exit and reload it on initialization. Or better yet: Build a library of actual snippets. Oh, bash doesn't have snippets?
Where is the consistently implemented risk management in *sh shells? In PowerShell you can run any action command with -WhatIf. In that mode no changes will be made to the system. Instead the changes that *would* have been made are reported to the user. It even works with scripts: If you support -whatif as a script parameter it sets global preference to "whatif" and none of the commands of the script will actually execute.
Where is *sh shells integration with transactions? You can use PowerShell to connect to multiple database servers, message queue servers, etc. and perform tasks in a transaction context and ensure transactional consistency.
Where are *sh shells suspendable and resumeable scripts? PowerShell workflows can run scripts across system restarts, suspend a script/job on one machien and resume it on another machine.
How do you create parallel *sh scripts? PowerShell supports parallel execution within a workflow script.
Oh and:
Linux: tail filename.log
PowerShell: gc filename.log -La 10
done.
For starters: I am really glad MS finally saw the light and recognized the essential importance of having a decent CLI in their systems. However I am blinded by your arguments. Let's see:
1. PS is slow to start up or to do anything. Denying it is just stupid, anyone having used both a linux shell or PS knows it.
2. What features does a linux shell lack in your opinion? Truly interested in your answer.
What I still cannot do in powershell is use a MUA like pine or mutt; a browser, irc client, rss feed reader, mp3 player, ..., god, I can't do plenty of stuff I already can with my old fashioned linux prompt. Is this progress? Not for me.
3. text processing in PS is ... painful. It is not its strongest point. Try finding matches of a certain string on a 3GB text file (like an iis log file in a busy web server), you will soon grab naar findstr.exe or script something fast in Perl (yes, for Windows, works great) to get the job done without bringing the server to its knees.
Parsing the windows event log on the other hand is very convenient with PS. Slow, but convenient ;-)
4. yes, syntax can be terse. It's a shame that MS just *ignores* the rest of the industry and 40 years of knowledge and experience to invent another wheel instead of just adopting the posix standard every admin they want off Unix already knows. Weird.
5. You're right on paths, those work fine.
6. snippets? O, you mean like 'functions'?
Risk management? Like thinking what you're doing before hitting enter? Or writing scripts properly with proper error handling? With great power comes great responsibility.
Database shells? Never heard of cli tools for databases? Those tools ensure the consistency of the database, so please spare us your bullsh*t ITIL lingo.
And you should just google job control to learn about suspending and starting jobs.
Oh and:
PS D:\tmp> gc logfile.log -La 10
Get-Content : A parameter cannot be found that matches parameter name 'La'.
At line:1 char:19
+ gc logfile.log -La <<<< 10
How hard can it be?
>1. PS is slow to start up or to do anything. Denying it is just stupid, anyone having used both a linux shell or PS knows it.
PowerShell is based on .NET. The first time you load it after system restart it will JIT the assemblies. After the first time it starts instantly.
>2. What features does a linux shell lack in your opinion? Truly interested in your answer.
Ok:
1) Object oriented pipes so that I don't have to format and reparse and be concerned about language settings. Object oriented pipelines
2) Command metadata. PowerShell commands, functions and even *script files* expose metadata about the names, positions, types and validation rules for parameters, allowing the *shell* to perform type coercion, allowing the *shell* to explain the parameters/syntax, allowing the *shell* to support both tab completion and auto-suggestions with no need for external and cumbersome completion definitions.
3) Robust risk management. Look up common parameters -WhatIf, -Confirm, -Force and consider how they are supported by ambient values in scripts you author yourself.
4) Multiple location types and -providers. Even a SQL Server appears as a navigable file system. Want to work with a certain database? Just switch to the sqlserver: drive and navigate to the server/database and start selecting, creating tables etc.
5) Fan-out remoting. Execute the same script transparently and *robustly* on multiple servers and consolidate the results back on the controlling console. Try icm host1,host2,host3 {ps} and watch how you get consolidated, object-oriented process descriptions from multiple servers.
6) Workflow scripting. PowerShell scripts can (since v3) be defined as workflows which are suspendable, resumable and which can pick up and continue even across system restarts.
7) Parallel scripting. No, not just starting multiple processes, but having the actual *script* branch out and run massively parallel.
8) True remote sessions where you don't step into and out of remote sessions but actually controls any number of remote sessions from the outside.
9) PowerShell web access. You can now set up a IIS with PWA as a gateway. This gives you a firewall-friendly remote command line in any standards compliant browser.
10) Superior security features, e.g. script signing, memory encryption, proper multi-mode credentials allowing script to be agnostic about authentication schemes which may go way beyond stupid username+password and use smart cards, tokens, OTPs etc.
11) Transaction support right in the shell. Script actions can join any resource manager such as SQL server, registry, message queues in a single atomic transaction. Do that in bash?
12) Strongly typed stripting, extensive data types, e.g first class xml support and regex support right in the shell. Optional static/explicit typing. Real lambdas (script blocks) instead of stupidly relying on dangerous and error prone "eval" functions.
13) Real *structured* exception handling as an alternative to outdated traps (which PowerShell also has). try-catch-finally blocks.
14) Instrumentation, extensive tracing, transcript and *source level* debugging of scripts.
15) Consistent naming conventions covering verb-noun command names, common verbs, common parameter names.
>What I still cannot do in powershell is use a MUA like pine or mutt; a browser, irc client, rss feed reader, mp3 player,
PowerShell can start external processes like any other shell. If you have an rss feed reader then just start it. Sheesh!
>3. text processing in PS is ... painful. It is not its strongest point. Try finding matches of a certain string on a 3GB text file (like an iis log file in a busy web server), you will soon grab naar findstr.exe or script something fast in Perl
No, I will just use select-string (alias sls). Just type sls <message> logfile.log -all. It is that simple and super fast.
>Parsing the windows event log on the other hand is very convenient with PS. Slow, but convenient ;-)
Get-EventLog actually *searches* the event logs, as opposed to stupid bash tools which *read* the entire logs and passes them through a filter. Want to guess what is faster?
>4. yes, syntax can be terse. It's a shame that MS just *ignores* the rest of the industry and 40 years of knowledge and experience to invent another wheel instead of just adopting the posix standard every admin they want off Unix already knows. Weird.
posix is a *Unix* standard. And if you believe that command names like ls or awk is the epitome of consistency you are seriously deluded. Why does Unix need multiple commands (ls, find, du) to search the file system when PowerShell needs only one? Because PowerShell combines much better than *sh tools, that's why. Instead of including options and flags to control output format, sorting in every stupid command, PowerShell has a class of commands for that - which works with *every* other command regardless of whether they list file system objects, process information, rss items, certificates, user accounts or organizational units.
>5. You're right on paths, those work fine.
yes.
>6. snippets? O, you mean like 'functions'?
No, I mean *snippets*. Launch PowerShell ISE and hit Ctrl-J. Pick a snippet and *edit* it before issuing it. You can build your own snippet library or download one or simply use the built-in snippets.
>Risk management? Like thinking what you're doing before hitting enter? Or writing scripts properly with proper error handling?
No, risk management like asking a command or a script what it will do *before* actually executing it. It is a built-in feature. PowerShells errorhandling is superior to bash, btw. Like real structured exception handling, or the fact that cmdlets actually use delimited input and any errors reported during operation is uniquely referenced with the items of the input stream that were processed when the error hit. In *sh commands are simply streams and if you want the same level of error reporting you better pray that the author of the command replicates the input on stderr - otherwise you have no idea what part of the input stream wasn't processed.
> Database shells? Never heard of cli tools for databases? Those tools ensure the consistency of the database, so please spare us your bullsh*t ITIL lingo.
Ah, *another* cli? How about dreaming up a CLI which can handle database servers, mail servers, web servers or any other type of server using the very same tools? And how does a cli tool for databases coordinate transactions with the message queue server? Ah - it doesn't because it is a *database* tools.
>And you should just google job control to learn about suspending and starting jobs.
Yeah. You can suspend a *process*. But can the process/job automatically persist it's state so that it can resume from the same state after e.g. a system restart? No - because then the process is terminated all its state is lost. PowerShell does that.
>Oh and:
>Get-Content : A parameter cannot be found that matches parameter name 'La'.
>At line:1 char:19
>How hard can it be?
yeah - try PowerShell 3 - which this article was about. Then return. Ignoramus.
A shell is a an interface that glues programs together. What it does is providing both user and programs to interact with one another in a convenient, simple, seamless fashion.
Sure bash can do many things by itself without utils, its gonna be slower and several magnitudes weaker (perl 5 can do hundreds times more and faster what bash does). Instead, you primarily use bash to talk to those many little almost perfect utils.
Why does Unix need multiple commands (ls, find, du) to search the file system when PowerShell needs only one?
Okay,
ls - lists files in various, permissions formats
du - prints disk usage, and so on in various formats
find - is an extremely power and flexible utility, I'd be very surprised, PS can do as much as 10% as find does and be as efficient.
Moreover, find in combination with xargs, (e)(f)grep, wc, sed, awk and other utils can do virtually anything, thanks to bash/zsh/ksh or whatever shell you prefer.
Can you beat the interactive pager less?
Get-EventLog actually *searches* the event logs, as opposed to stupid bash tools which *read* the entire logs and passes them through a filter. Want to guess what is faster?
Do you know how (z)grep operates? It's actually extremely fast and efficient and doubt that PS can beat it. awk/sed are very fast as well, so with awk or sed you do
(g)awk '/eventLogRegexp/{do a lot stuff}'
sed '/eventLogRegexp/{do stuff}' # use options -r for extended regex and/or --posix for the posix regexp
So you don't read anything missing that regexp
Try icm host1,host2,host3 {ps} and watch how you get consolidated, object-oriented process descriptions from multiple servers.
No bash alone won't do it, you can perform a similar task through ssh and public keys shared by servers, something like:
for host in host1 host2 host3
do
echo " Host name :$host"
ssh $host top -b -n1 | head -15 # or use almighty ps
done
That will give you a consolidated report about the top processes per host
The power of a posix shell and posix utils is that it is an environment of independent, simple, very efficient utils and apps yet capable to talk to each other and shell very well, thus adhering to the KISS principle. The atoms of this ensemble tend to be small and simple. Similarly, emacs is a collection of independent bits incorporating shells and utils plus it's own power. That is why it is awesome in dired, grep, tramp, calc modes multiplied by the shell commands on a region...
While PS seems to have larger add-on chunks that is not easy to divide. Creating a complex cumbersome monster in my mind is not creating a shell.
> ls - lists files in various, permissions formats
> du - prints disk usage, and so on in various formats
> find - is an extremely power and flexible utility, I'd be very surprised, PS can do as much as 10% as find does and be as efficient.
ls finds files/dirs. And then it also has many(!) options for controlling output formatting. And it has options for controlling sorting. So ls doesn't do "one thing" - it does multiple things which other commands also do. Not very "unixy".
find also finds files/dirs. And then it has many(!) options for controlling output formatting as well. And then it has options to *execute other processes*. wtf? Why would a find utility execute other processes? That's not very "unixy" as in "do one thing and do it well".
ps finds processes. It has many, many options for controlling filtering, output formatting (again!) and sorting (again!). Why do multiple utilities include options for controlling output formatting and sorting beyond what their task is? That's not very "unixy", is it?
Enter PowerShell. ls is an alias for Get-ChildItem - which does one thing: It finds files/dirs. It has very few options compared to the *nix counterpart - simply because it doesn't do output formatting or sorting. It also doesn't need an enormous amount of filtering options because the objects it produces include all of the properties that you could possibly want to filter on.
PowerShell ps is an alias for Get-Process. It also doesn't have output formatting or sorting options. It also doesn't have a vast array of filtering options.
PowerShell ft is an alias for Format-Table. fl is an alias for Format-List. These commands do output formatting. Output from ls and from ps can be piped to the Format-* commands.
PowerShell ? command (an alias for Select-Object) does filtering. No need for ls or ps to do filtering when you can just pipe the objects through this command. No need to control output formatting and ensure that last access time is formatted in a certain way that you know you can reparse in the next command without loss of precision or being skewed by language settings.
PowerShell sort command (alias for Sort-Object) does all of the sorting for ls, for ps or for any other command. Other commands don't have options for controlling sorting, because unlike *nix shells, that's not *needed*
So which shell has a design which allows tools to do one thing and do it well? Look at the commands. PowerShell commands do one thing and not the kitchen sink like *nix commands. And yet you can combine PowerShell commands in straightforward ways to achieve functionality not even possible in *nix shells.
Interesting, that you forget that powershell with all of its commands is one thing, while find/grep/ls/awk/sed etc are independent utils.
find has quite a few different options, I'd agree, but it still does one thing, it "searches for files in a directory hierarchy".
You can't really remove options, like -name (-iname, -regex) or -atime and similar. Any respectable utility would be addressing very same features. Yes, -printf is just a formatting option and a classic C function. -exec is not recommended. Besides that, I am not aware of any bugs it ever had. Note, that find cannot be used as serial editor like sed or awk, all these work quite happily together in bash/ksh or zsh though.
If PowerShell has limited number of options/features, it's weak, if it has all the options of a *nix shell and many utilities, it is a One Monstrous Shell of All Trades notwithstanding your claims. And it could be both as well.
And yet you can combine PowerShell commands in straightforward ways to achieve functionality not even possible in *nix shells.
Would you mind providing an an example, please?
It's hard for me to say what PS cannot accomplish, you can't play with it without a Windows system (while you can with bash using CYGWIN on Windows). I heard that MS haven't devised a descent terminal or console similar to what we have with *nix systems.
> Interesting, that you forget that powershell with all of its commands is one thing, while find/grep/ls/awk/sed etc are independent utils.
PowerShell also uses utils. It is just that PowerShell has defined utils as cmdlets. Cmdlets pipes objects instead of text/bytestreams. Get-ChildItem is a util (with an alias ls). It finds child items of a location and sends filesystem objects through the pipeline. Because filesystem object are rich objects with property getters for a large number of properties (last access time, last write time, security information, reparse points, attributes, state, name, location/parent, version info ...) a *generic* filtering cmdlet can filter on all of this information and a *generic* sorting cmdlet can sort on any combination of these properties.
That is why PowerShell doesn't need find. It already does all of what find does by simply combining Get-ChildItem with Where-Object (which have aliases "ls" and "?", respectively). So to find all files which are larger than 1GB you'd write
ls . -r|? length -gt 1GB
Find in unix has it's own expression language which is not the same language used to filter processes or records from a csv file. PowerShell has ls and a filtering cmdlet. One does the finding, one does the filtering.
Want to limit the list to just the 10 last accessed files and format it in a table with the name, last write and length columns? Use the sort utility to sort, use the select utility to limit the list to 10 and use the format-table command to format as a table:
ls . -r | ? length -gt 1GB | sort -des lastaccesstime | select -first 10 | ft name,lastaccesstime,length
One utility to find file system objects, and just that. One utility to filter objects using a common expression syntax and just that. One utility to take a subset and just that. One utility to format in a table. I could write
ps | ? ws -gt 100mb | sort -des starttime | select -first 10 | ft starttime,name,id,cpu
And I would get a table of the last 10 processes started which consumes more than 100mb of memory. Notice the similarity? Notice how it doesnt format and reparse?
> find has quite a few different options, I'd agree, but it still does one thing, it "searches for files in a directory hierarchy".
No, it also executes processes, duplicating functionality from the shell. And it also implements a (non-standard) expression language, duplicating functionality from the shell itself and from other utilities.
> You can't really remove options, like -name (-iname, -regex) or -atime and similar.
Yes I can. Just make it return objects and ensure that name, time etc are properties.
> Yes, -printf is just a formatting option and a classic C function. -exec is not recommended. Besides that, I am not aware of any bugs it ever had.
It has serious security problems, so now -execdir is recommended. Still stupid. And -print0 illustrates the problem with text formatting+reparsing: the simple options handles uncommon file names *really* badly. None of that is a problem with object pipelines.
> If PowerShell has limited number of options/features, it's weak, if it has all the options of a *nix shell and many utilities, it is a One Monstrous Shell of All Trades notwithstanding your claims. And it could be both as well.
PowerShell utilities don't need as many options on the utilities to achieve more functionality than *sh shells, simply because they combine better. One utility to format in tables, regardless of object types.
> I heard that MS haven't devised a descent terminal or console similar to what we have with *nix systems.
PowerShell ISE blows any *nix console out of the water: Syntax highlighting, much better completion, auto suggestions (intellisense), context sensitive help, source level debugger and much more.
PowerShell ISE blows any *nix console out of the water . Syntax highlighting, much better completion, auto suggestions (intellisense), context sensitive help, source level debugger and much more..
Please be easy on thee claims. "Much better completion"?
"ISE provides and up to 8 PowerShell Unicode-enabled consoles (Runspaces) in a tabbed UI, as well as the ability to run only the selected parts in a script."
It looks more like an IDE, not a pure console to me, in this case, it won't blow GNU Emacs, or vi out of the water that's for sure.
Say, does it have something similar to a grep-mode, where you run a grep command to look for a keyword match and a buffer is created with highlighted hyperlinked matches?
Console runs interactive shell and can be used to launch scripts/apps. You can also use to compose simple scripts, usually oneliners.
# to find all files which are larger than 1GB... ls . -r|? length -gt 1GB. Find where?
find . -size +1G
looks more elegant to me.
#Want to limit the list to just the 10 last accessed files and format it in a table with the name, last write and length columns? Use the sort utility to sort, use the select utility to limit the list to 10 and use the format-table command to format as a table:
ls . -r | ? length -gt 1GB | sort -des lastaccesstime | select -first 10 | ft name,lastaccesstime,length
find . -size +1G -printf "%a\t%f\t%k\n" | sort| head
would do a similar thing.
PowerShell utilities don't need as many options on the utilities to achieve more functionality than *sh shells, simply because they combine better. One utility to format in tables, regardless of object types.
That's really cool (however, the syntax is not as appealing).
If everything must be an object to be able to talk to PS, than its capabilities are limited, unless you rewrite all utilities to talk objects. Say, bash doesn't really care what it glues together. Any app that either accepts text or outputs text can be used. Quite a few objects out there are plain text, despite MS efforts. Think html, xml, logs etc
Consider an an example: you got a text each line of which has fixed number of fields, say 4, separated by some weird char, e.g., ";;;" . You need to print all lines starting with the regex [0-9]{3}-[0-9]{2}, apply a certain formula to the 3 fields,say,f2*f3-f4^2 , print a result on each line and add all results together printing it out at the end. With awk you could try this
awk --posix -F";;;" '/^[0-9]{3}-[0-9]{3}/{
s=$2*$3-$4^2;sum+=s;print $0,s}
END{print "Here is your total -->",sum}
'
> Please be easy on thee claims. "Much better completion"?
Oh yes. PowerShell *automatically* completes command names, parameter names *and* parameter values. It doesn't need external completion definitions bolted on like bash. PowerShell has completion for *all* cmdlets, *all* functions, *all* aliases and *all* script files.
Yes, even your own scripts declare parameters in such a way that PowerShell can suggest completions for parameter names and parameter values. If you declare a parameter as an enumeration or with a validation set, PowerShell will both validate the parameters *and* use the information in completions.
The Get-Process cmdlet for instance support completion for process names. If you request completion for the -Name parameter, it will look up current process names and suggest completions from that list.
PowerShell has wildcard completions for all values. If you use * or ? wildcard characters it will suggest only the matching names/values.
In ISE it even supports intellisense (auto suggestions). As soon as you type certain characters like "-" or "." it will open a suggestion list in a popup window *without* interrupting your typing. The list is adjusted as you type.
So yes, PowerShell completion blows bash out of the water. Bash needs external definitions, doesn't cover all commands, doesn't automatically cover aliases, doesn't cover functions and certainly doesn't cover your own script files. Bash completion doesn't have dynamic completion and doesn't have auto suggestions.
"ISE provides and up to 8 PowerShell Unicode-enabled consoles (Runspaces) in a tabbed UI, as well as the ability to run only the selected parts in a script."
> It looks more like an IDE, not a pure console to me, in this case, it won't blow GNU Emacs, or vi out of the water that's for sure.
It is an Integrated *Scripting* Environment, and it is where most administrators live today. The main pane is the command console which is a normal console, only with syntax highlighting (as you type) and auto suggestions (as you type). There is *nothing* similar for bash. An no, emacs doesn't cut it. Laughable, really.
> Consider an an example: you got a text each line of which has fixed number of fields, say 4, separated by some weird char, e.g., ";;;" . You need to print all lines starting with the regex [0-9]{3}-[0-9]{2}, apply a certain formula to the 3 fields,say,f2*f3-f4^2 , print a result on each line and add all results together printing it out at the end. With awk you could try this
You totally miss the point. awk is not a feature of bash. awk is awk and can awk can be used from PowerShell as well. You come up with a deliberately convoluted format specifically tailored for awk and present it as a feature of *bash*? I could come up with a (less convoluted) XML or json format which would be almost totally impossible to process with bash and awk, but which you could probably find some external tool that could help you. To powershell traditional tools like awk are just commands which consume and produce sequences of strings (lines). Strings are just objects
The *shell* has to be measured on how well it allows the tools to be integrated, not on the set of tools available on the system. In that sense PowerShell trounces bash. How would you for instance read a rss feed and insert the records into a database?
You totally miss the point. awk is not a feature of bash. awk is awk and can awk can be used from PowerShell as well.
No, it seems that you are missing the point. bash is not omnipotent, it's pretty simple. It's best for gluing things together. Make it more complex, it won't be as attractive (like cmd.exe or PS). Powershell as you have demonstrated is a thing by itself. So it has to be super universal, and in noway it will be. It will not satisfy all possible needs, say it most probably has no curl,mail, imagemagick, video/audio decoders or player...
I gave an awk example. And text is indeed an important entity, despite MS views. awk works very well with bash, will PS do, since it needs objects? Will an average Win admin get it right after getting used to "PS manners"? (First teach them to not be afraid of *any shell*)
And we didn't even compare performances of these. I have strong doubts that cmdlets can outperform grep/find/wc/awk/curl etc
Interestingly, one of the most used command
(e)grep 'regex' file
PS analog looks weird (if it's right):
select-string f.txt -pattern xyz -CaseSensitive
only with syntax highlighting (as you type) and auto suggestions (as you type). There is *nothing* similar for bash. An no, emacs doesn't cut it. Laughable, really.
You don't need syntax highlighting for interactive stuff in a console input, it is pretty useful for the output though and it is always there. Auto-suggesting without not very useful when you're not asking for it, it would be a nuisance for me. I am more than happy with the tab key and bash autocompletion including options, aliases (and btw that's default config of my distros).
As far as laughs at Emacs are concerned, spare those for the ISE and Visual Studio that are both useless pieces of software before GNU Emacs.
Or maybe you can find just very few things present in emacs, just say:
* grep-mode
*interactive (regex) search
* run-shell command on region with optional outputs on it or into a special buffer
* tramp-mode to handle ssh/sudo/su or whatever windows has
* reverse polish calculator calc with many math, calendar functions etc many CAS mode (maxima,pari-gp, matlab etc)
* dired mode
*tons of other modes
.....
>>You totally miss the point. awk is not a feature of bash. awk is awk and can awk can be used from PowerShell as well.
>No, it seems that you are missing the point
I'm not missing anything. Here is how I'd do it in PowerShell:
gawk -F";;;" '/^[0-9]/{s=$2*$3-$4^2;sum+=s;print $0,s}END{print \"Here is your total -->\",sum}' weird.txt
Notice the difference? What? there is no difference?
Old-style utilities like (g)awk that produces text can be used as easy in PowerShell as in bash. No difference. It is only that PowerShell offers much more. Text is just one type of object, powershell can work with all kinds of objects. Bash can only work with text, so *everything* has to be text, which precludes a lot of data, like e.g. trees.
Now, get the weather forecast for Los Angeles and format it in a table:
([xml](iwr http://weather.yahooapis.com/forecastrss?w=2442047).content).rss.channel.item.forecast | ft
The table will have columns automatically derived from the forecast item, with the item names as table headers. Try to do that in bash.
> Interestingly, one of the most used command
> (e)grep 'regex' file
>PS analog looks weird (if it's right):
>select-string f.txt -pattern xyz -CaseSensitive
The sort form in PS is:
sls regex file
So it is even 1 character shorter than grep.
Don't be fooled by the fact that it is considered good style to use the long form in scripts and when explaining commands in articles. PowerShell has a consistent shortcut system where
* aliases can be used
* parameter names can be abbreviated as long as the abbreviated form is unambigous
* parameter names can be omitted for parameters which also has positions.
Unlike in bash, in PowerShell it is the *shell* that does the parameter binding. The shell looks at the command definition and figures out whar arguments to bind to which parameters and with which coercion, e.g. parsing text as date or number if the parameter expects date or integer. The canonical form of the above is:
Select-String -Pattern <regex> -Path <path>
But because Pattern is the first parameter and Path is the second parameter, the names can be omitted.
Simple and consistent.
Indeed, if you ask the shell to explain the syntax ("help sls") this is one of the forms it responds with:
Select-String [-Pattern] <String[]> [-Path] <String[]> [-AllMatches <SwitchParameter>] [-CaseSensitive <SwitchParameter>] [-Context <Int32[]>] [-Encoding <String>] [-Exclude <String[]>] [-Include <String[]>] [-List <SwitchParameter>] [-NotMatch <SwitchParameter>] [-Quiet <SwitchParameter>] [-SimpleMatch <SwitchParameter>] [<CommonParameters>]
I should correct my statement: Yes the window may open instantly, however it is still 11 seconds before the shell is actually usable. It doesn't matter if the system has been rebooted recently or not. Since we're likely using different hardware, I'm sure the speed will differ, so I can only comment on what I can see here. On the same hardware, the unix shells open immediately and powershell does not. So there's something similar to .profile?
>On the contrary, Unix shells lack many, *many* of the features of PowerShell.
Sorce? I've noticed tab completion works some of the times. The ls command is there which is nice and ps is there. Are there emacs bindings? No I have to use the home and end keys if I want to manipulate the line I'm working on. Can I delete a word backwards? Not that I've found. Can I kill the line I'm working on? Again, not that I can see. Aliases are nice, however the fact that there are unix like commands aliased over enforces the point that these should have just been adopted rather than abstracted out after the fact.
>Yes it does. Text is just a sequence of string objects. But you will hardly ever use the powerfull string functions of PowerShell, because they simply are not needed when you operate with objects.
Strings are the whole point of working on the command line to begin with. Examples? Sources?
>There are short aliases for most common commands, all parameter names can be shortened as long as they are ambigous.
Awesome! That shouldn't be too hard because all the parameters I've seen so far are ambiguous
>Do not be fooled by the fact that it is considered good style to use the long forms when illustrating code.
I'm so glad style is important here. Most sysadmins I know are concerned with getting something done correctly and in an expedient manner.
>PowerShell can be every bit as terse as bash - sometimes more so.
Again, examples?
>Ignorant. PowerShell has always accepted both the forward slash as well as the backward slash forms.
I'm so glad you're mature with the name calling and labeling. But I don't mind learning things and TIL that you can use a / slash in the command line. It just happens to get converted each time you tab to .\
>Just save it. Or set a function to save it on exit and reload it on initialization. Or better yet: Build a library of actual snippets. Oh, bash doesn't have snippets?
Or just use a shell that has all of this built in. Why should I need to build a library of information that should be included by default? I'm pretty sure bash doesn't need `snippets`, else it would already have them.
>Where is the consistently implemented risk management in *sh shells? In PowerShell you can run any action command with -WhatIf. In that mode no changes will be made to the system. Instead the changes that *would* have been made are reported to the user. It even works with scripts: If you support -whatif as a script parameter it sets global preference to "whatif" and none of the commands of the script will actually execute.
Risk Management? Now I am sure you're just astro-turfing for MS. In bash and other shells you can pass the -x flag and see exactly what your script is going to do when evaluated by the shell. We don't usually work on production data when writing scripts so there isn't a need for a -whatif flag. When we are working in production there are many checks to make sure you don't overwrite a file, make sure it exists, or test for multiple other conditions.
>Where is *sh shells integration with transactions? You can use PowerShell to connect to multiple database servers, message queue servers, etc. and perform tasks in a transaction context and ensure transactional consistency.
Paralell - http://www.gnu.org/software/parallel/
xargs is also viable when dealing multiple systems
>Where are *sh shells suspendable and resumeable scripts?
Bash and other shells have job control to both suspend and resume scripts.
>PowerShell workflows can run scripts across system restarts, suspend a script/job on one machien and resume it on another machine.
Crontab and paralell
>How do you create parallel *sh scripts? PowerShell supports parallel execution within a workflow script.
By using Paralell or xargs
>Oh and:
>Linux: tail filename.log
>PowerShell: gc filename.log -La 10
>done.
No, Not done. It does not work so I'm guessing you're using a custom library of sorts, not built in functions:
PS C:\> gc filename.log -La 10
Get-Content | A parameter cannot be found that matches parameter name 'La'.
At line:1 char:19
+ gc filename.log -La <<<< 10
+ CategoryInfo : InvalidArgument: (:) [Get-Content], ParameterBindingException
+ FullyQualifiedErrorId : NameParameterNotFound,Microsoft.PowerShell.Commands.GetContentCommand
Tomorrow night I'm completing a server replacement with a new Dell PowerEdge T620 w/dual Intel Xeon E5-2630 6C processors, 16GB ram, 2x 1TB SATA HD's in RAID1 config - replaces another Dell PowerEdge from 2004 w/Windows 2003 SBS 8GB ram and three 79GB SCSI HD's in RAID4 that I installed back then. Going to retire said server, actually make it a DC just i->BREAK: seen the movie "Christmas Story"? The dad's Major Award and what happened to it? Just heard a tremendous crash, run to bedroom, see wife holding her arm standing over my wallshelf/cabinet thing smashed on the floor... she's ok, but she always hated it<-
Meanwhile, I told you all that to say this: I installed Windows Server 2008 R2 w/SQL 2008R2 in this machine, which flies by the way, because the client runs a multimillion dollar business and doesn't need to be beta testing for Microsoft. Ain't nobody got time for dat, you know?
;)
Jesus H Christ, with a comment board like this is it any surprise that people think we're troglodytes?
Windows Server used to be crap. It isn't any more. It's not perfect either.
Linux used to be crap. It isn't any more. It's not perfect either.
For whatever task you have in mind, you may find Windows slightly less crap at doing it than Linux. Or you might find Linux slightly less crap. The end.
There - fixed it for you.
Yeah, but the Windows only and Linux only people have been making these arguments for about fifteen years, rather than bother to learn the system that they don't know. Why would they learn something new, when they can loudly slag off the other system.
There is the matter of bettering yourself by learning new things, but that's difficult, loud slagging off is easy.
Is the argument seriously that IIS now works and windows supports FTP? Because if it is, no sale. All my servers don't support FTP because it's fail protocol fail. Chrooted sftp over ssh or get out? No really FTP is the most useless protocol ever.
"Server 2012 sees Hyper-V catch up with VMware's mainstream"
But VMware are technologically behind KVM and XEN so.. what?
"Hyper-V Replica is a storage technology designed to continuously replicate your virtual machines across to a backup cluster"
Distributed block device?