Re: vim, modularity
>>"So you might not be such a big connoisseur of vi(m) as it turns out"
No idea what in my post prompted that. I've been using it for over a decade. All I said was gvim felt a bit weird which it did. I'm used to plain vim on a terminal. Looks and feels odd using it with icons.
>>>>This is wrong
>No, you're wrong.
Well, this is good debate!. :/ You cut off and ignored a full paragraph immediately after where I supported my statement. You claimed command line was an "afterthought" and "in its infancy" on Windows. I showed it had several advanced features, was integrated into the OS at a very deep level and showed that it was widely used by Windows professionals. Enough to refute what you said.
Now you say you have "proof" which is that there is "no usable terminal". As it turns out from this thread there are quite a few. I (still learning, remember) just didn't know about them. I'm now using ISE which is built into Windows. Try that and see what you think.
>>"it can't be more capable than bash as a glue between utilities and apps, "
Why can't it? This is getting dangerously close to a faith-based argument. Bash works by passing text. Powershell can pass objects (which can be text). Ergo, Powershell has a greater capability of joining "utilities and apps". It has try...catch, strong typing. Each of these things adds capabilities that Bash does not have. Now if you can't find the converse - things that Bash can do that Powershell can't, then by definition Powershell is more capable.
>>"it can't be more efficient than find, sed awk, grep and others"
As before, why can't it? Also, these are programs, not part of Bash and there's zero reason an implementation on Windows can't perform the same tasks in the same way. I'm not going to be lulled into attacking sed or grep because I have no reason to - I like them - and I'm not going to be put on the side of MS vs. Linux when I like and use both. I will pick up on awk however, not because I detest it or anything, but because it will provide an illustrative example of how you're ill-informed on this.
Awk is used to join up disaparate programs in Bash by hacking around with textual output that Bash uses. Say, I don't know - I want to find the owners of a list of files. I might do something like this:
ls -l | awk '{print $3}'
Fair? Prints out the third block of text in the ls -l output which happens to be the owner of a file. If the owner happend to be the fourth block of text in the output, I'd use print $4. (I know you know this, but this is a public forum so I'm trying to include everyone in the debate and some wont be familiar with awk). Why are we using awk? Because the output of ls is just lines of text. So if I want to do something where I take part of the output of one program and feed it to another program, I need to write parsing code in between the programs with awk to get them to play together.
That's not necessary in Powershell.
When I run ls in Powershell (or "dir", they're aliases and it has both), the output is an array of file objects. They will be text when they need to be. I.e. they have built in conversion that the user never needs to think about. Output to the screen, you get the same list of files as in Bash because it treats it as text. HOWEVER, I can pipe the file objects to something that wants more than just text.
DIR | Get-Acl | Select-Object Owner
The point is not that this is simpler than the Bash example (they are both trivially simple), but that awk is completely unnecessary in Powershell. It would serve no purpose. Saying that Bash has awk is not an advantage over Powershell. If you were familiar with Powershell you wouldn't make a comment such as "it can't be more efficient than awk", because awk is redundant there. It's purpose is to fudge joining programs together and Powershell is inherently more streamlined and efficient in how this is done by design.
Say I extend that example abouve and want to get all the unique owners in a directory hierarchy:
DIR -Recurse | Get-Acl | Select-Object Owner | Select -Unique
(the first component above gets a recursive directory listing, the second takes the array of file objects and gets their Access Controls, the third selects the owner object from the access control objects and the final part prunes the result set so it only contains uniques)
Simple, and no fudging around with string parsing. I'm going to take a quick stab at an equivalent in Bash. By all means, please produce a simpler version if one occurs - I do not mind.
find ./ -exec ls -l {} \; | awk '{print $3}' | sort | uniq
Except that's not working. The ls -l command prints out a summary at the foot of each directory which doesn't have a third block of text so I get blank lines in the output. Maybe I can put in a special case to deal with it:
find ./ -exec ls -l {} \; | awk '{print $3}' | grep . | sort | uniq
There, now the grep will only return lines with content. (I haven't tested this, but I'm pretty sure it'll work. If I've made a mistake, it's not a deliberate attack on Bash!).
See - this is a really simple task and I've already had to put in two components (the awk and the grep) that are only there to finangle joining up disparate programs
Yes, the Powershell example might contain unfamiliar commands to people not used to it (just the same as find or uniq are unfamiliar to those not used to them), but each is actually a logical command with a purpose by itself, not a command there solely to fiddle around turn the outputted string from one into the correct input for the next. Really it's actually three bits added just for text mangling as the sort is only there to get similar lines consequtive so that uniq can work. The Powershell version of uniq (Select -Unique) takes an array of anything in and works on it, so no ordering is necessary.
>>"If tries to do everything by itself, like math, regex, text manipulation it is no good."
I'm not sure you're really getting how this works. Windows has cmdlets which are compiled programs in and of themselves. You use these in Powershell just as you can use programs like sed in Bash. So it doesn't have to do "everything by itself". Also, why would you suppose the code built into Powershell to handle regular expressions is inherently less efficient than the same code put into a discrete program and piping the strings to it.
>>"I thought that OOP nature makes it more complex, but I might be wrong"
The point of object orientation has always been to make code simpler and more maintainable. It wasn't developed for the sake of performance, you know? Go back to any of the old back-in-the-day arguments from old C programmers railnig against C++ if in any doubt on that. ;)
Also, how do you think this OO makes it more complex? I am genuinely mystified by that so would genuinely appreciate a specific example showing a case of Powershell being more complex than Bash because of OO.
>>"What actually makes it harder is its syntax which doesn't look as clear, elegant as GNU Bash uses."
Again, please provide a specific example. In many ways Powershell and Bash are very similar. Powershell actually has a number of things that make it more readable. If I want a particular part of an expression to evaluate first, I wrap it in parentheses. E.g.
$a = ( Get-Content .\*.sql | Select-String "INSERT" )
$a now contains all the lines from the files ending .sql that have the text INSERT in them. The parentheses make it simple to see that the pipe of get-content to select-string are all handled as one thing before being assigned to a variable. Very easy to read. Why is a Bash equivalent clearer or more elegant? In fact, by all means come up with your own examples - only they must be performing the same task else it's a nonsense.
>>Sorry, I forgot about your allergies for Microsoft's criticism and sorry for your sneezes and coughs this have caused :)
I am fine with criticism of MS. What I dislike is criticism that is not true. I also disllike how a simple request for help with finding a better terminal becomes an assault on Powershell by someone confidently stating it is inferior whilst they clearly have very little to no experience using it. You will, I hope, admit you have little to no experience with it? Given the questions you've asked here and the things you've been pulled up on, you're going to be very hard-pressed to claim otherwise.
EDIT: And you have once again turned someone who genuinely likes both GNU/Linux and Windows into someone who has to argue the case of one over the other, simply because you relentlessly push your favourite, forcing others into the role of defending that which you attack. Seriously - Bash has been going a very long time. Is it that inconceivable that MS could not have made some refinements?
Biting the hand that feeds IT
