back to article Powershell terminal sucks. Is there a better choice?

El Reg reader h4rm0ny wants your advice. Here goes. I've been using Bash for well over a decade. (About fifteen years?). I'm reasonable with it. I'm now teaching myself Powershell and whilst some of it I like, the default environment is terrible. I'm not talking about the language itself, but the fact that to use Powershell …

COMMENTS

This topic is closed for new posts.
  1. kovesp

    jpsoft

    Windows shell replacement.

    On the other hand... you may not want to use PowerShell then.

    On the third hand ... why not just use bash by installing cygwin? Perhaps with the jpsoft command window.

    1. Steve Button

      Re: jpsoft

      > why not just use bash ?

      How about because you can't pass objects in bash, just a bunch of text. You can do a lot more in Powershell, but bash still has it's place too.

      1. eulampios

        bash

        >>How about because you can't pass objects in bash

        If you "teach" it and let it know of objects and their properties you might (that would create a non-POSIX extension of some sort). Bash is, as any other POSIX shell, mostly a glue between utilities and apps, it can do some quick dirty things on its own, but is not supposed nor intended to do everything. It's not even the most efficient utility, like with text handling, string manipulation, math etc.

        >>just a bunch of text.

        Because text is more universal than any (other) object, plus it's much more human-readable. grep,sed/awk (and even perl),cut, printf etc can handle it far better than bash's own built-in capabilities. As was mentioned below, objects hardly interest anyone beyond MS Windows sandbox, you do have to step out of it from time to time to, e.g., download an html page and parse it.

        If PS can do more than bash's built-ins , it must be more complex, I am very doubtful it can do as much as find, dc, sed, grep awk or perl and as efficiently.

        >>You can do a lot more in Powershel

        And what is it exactly?

        On the topic now:

        I am almost sure that h4rmony is not an Emacs guy, but just in case: there is a power-shell mode for the both scripting and shell tasks. Together with Emacs own superpower and tons of other delicious modes (including the auto-complete mode) this might be very appealing to many (never tried ps-mode myself though)

        As far as the terminal emulator is concerned. So the default terminal sucks? Someone supposedly came up with a good car, but forgot to attach good wheels to it? Who is it again? I think I know this company.

        1. h4rm0ny

          Re: bash

          >>"I am almost sure that h4rmony is not an Emacs guy"

          Neither, actually. :)

          And yes, I use 'vi' pretty much universally and occasionally switch to kate (on KDE) when I want to cut and paste large chunks of code around or use block editing or change character sets. I'm sure emacs is great, but learning either vi or emacs are lifetime tasks so it really has to be one. ;)

          >>"As far as the terminal emulator is concerned. So the default terminal sucks? Someone supposedly came up with a good car, but forgot to attach good wheels to it? Who is it again? I think I know this company"

          Well that's the principles of good, modular design. Like I have an "Ubuntu" box, but I don't have to use Unity, I use Xfce (Xubuntu) instead.

          Like the way you couldn't help but slip a "supposedly" in there, btw. Even with a metaphor you're careful not to imply MS might have produced something good. ;) :D Thank you for the reply, however.

          1. eulampios

            vim, modularity

            Thanks, h4rmony. As a vi(m) connoisseur you might be interested in this discussion, however you'd still need a decent terminal (gvim on Windows, is there such thing?)

            As for modularity and lack of a good default terminal. A GNU Linux/ or BSD (and even MacOS X) are pretty far away from being non-modular, yet in every flavor and DE therein you almost always get a nice default one (plain xterm is much better than what you've dealt with learning PS, I suppose). Speaking of niceness, just recently gnome-terminal has lost transparency feature (not sure what the actual reason was). That was enough for me to not use it, when I am in cinnamon DE (there is still a good ol' mate-terminal) , so we are pretty spoiled ;).

            My own explanation is that CLI tools and environment are still MS' afterthought and their infancy, there is till no culture for it in place. When I was using cmd.exe last time...about 7-8 years ago, the default terminal was ugly and appalling by the same reason, I guess.

            1. h4rm0ny

              Re: vim, modularity

              >>"(gvim on Windows, is there such thing?)"

              Yes. I used it years ago but it felt a bit weird, to be honest. Now that I know about ISE I'm using that currently and I like it a lot. It's lacking the History functionality of Bash, but other than that it meets my needs. In fact, it has a docked sidebar by default which lets you search through all the cmdlets and bring up all their parameters. You can search by name (incl. partial matches) so you've effectively got a kind of permanent man page to hand. And auto-complete on them.

              >>"When I was using cmd.exe last time...about 7-8 years ago, the default terminal was ugly and appalling by the same reason, I guess."

              It's fairly silly to liken that to modern-day Powershell. For example, now that I know about ISE (thanks to the many posters here who mentioned it), I've got tabbed terminals and the auto-complete that I just mentioned earlier...? The reason I mentioned is because it applies to all the parameters as well so as you type a command it has a hovering list of the parameter names and their type much like I were programming in Eclipse or similar. The Gnome Terminal doesn't have that! And ISE has built-in debugger for scripts letting you set break points and step through them, hovering over variables to see their values. I don't do that with Bash scripts much. Honestly, it rivals any terminal on GNU/Linux, imo. Why it's not the default and hidden away out of sight, I have absolutely no idea. It doesnt even show up on the normal program search.

              >>My own explanation is that CLI tools and environment are still MS' afterthought and their infancy, there is till no culture for it in place

              This is wrong. Powershell forms the basis for much of modern Windows Server and Windows 7 and 8. Pretty much every element of the Windows Server GUI is just a wrapper for Powershell scripts. That certainly can't be said for the GUI configuration tools on any GNU/Linux distro that I know of. Powershell runs right through it and I can manage pretty much any aspect of Windows through it. That's not "infancy" and Powershell is used routinely by Windows admins. Indeed, default state of Windows Server now is to install without a GUI. That's definitely not a case of "no culture for it in place".

              Powershell is actually more capable than Bash in many ways and in some respects simpler. I had no intent to criticize Bash. My original question (which got promoted to the main page) was just a simple request for a better terminal (which has been answered), but all your reply contains what I perceive as little swipes at Windows. I don't know if a Vs. discussion is what you want, but it's a poor choice of battlefield if so because Powershell is at least on a par with Bash, and better in some ways. (Unsurprising as it's newer and MS got to learn from Bash).

              1. eulampios

                Re: vim, modularity

                So you might not be such a big connoisseur of vi(m) as it turns out. Not sure about vim, but GNU Emacs or XEmacs are really hard to beat in many things, in my opinion... Say, Emacs got a grep-mode where you could run grep with the result being dumped to a buffer with hyperlinks, an history is kept in another buffer too.

                This is wrong

                No, you're wrong. Proof: no usable terminal for a very important and quite usable tool, hence it's an afterthought, and unlike any *nix-base system to compare with 30 years vs. 9), it's still in its infancy.

                Powershell is actually more capable than Bash in many ways ...

                In which way exactly? As a certain tool, as a substitute for some utilities it might well be, it can't be more capable than bash as a glue between utilities and apps, it can't be more efficient than find, sed awk, grep and others. If tries to do everything by itself, like math, regex, text manipulation it is no good.

                in some respects simpler

                I thought that OOP nature makes it more complex, but I might be wrong. What actually makes it harder is its syntax which doesn't look as clear, elegant as GNU Bash uses.

                I don't know if a Vs. discussion is what you want, but it's a poor choice of battlefield...

                Sorry, I forgot about your allergies for Microsoft's criticism and sorry for your sneezes and coughs this have caused :)

                1. h4rm0ny

                  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?

                  1. eulampios

                    AWK, which you don't seem to know

                    find ./ -exec ls -l {} \; | awk '{print $3}' | grep . | sort | uniq

                    why using find? Why to pipe it to uniq if there is a way to handle it with -u?, reminds me of peculiar pipes like "cat file | grep..." or "cat file |sed ....")

                    Sorry, you didn't get awk as I can see, you don't have over-complicate it:

                    ls -al | awk '$3 ~/./ && $1 ~ /x/{print $3}'| sort -u

                    or even

                    ls -al | awk '$1 ~ /x/{print $3}'| sort -u

                    AWK is a serious language, please don't diminish it. It's not "a part of bash" or any other shell. If you didn't get it, it doesn't mean it is no good. "K", btw, stands for one of its co-author, Brian Kernigan. It's very powerful and efficient. It has peculiar, regex and text oriented paradigm. It's simple, it is reminiscent to C in it\s syntax, it's simple too. Try parsing a multi-gigabyte file. Just like sed and grep, it's dirty, fast, quick and efficient.

                    1) More on this, you declared my statement "wrong", so I felt I could do the same to yours :) If my own, no your own case, is not proof to you, your proof might not be a proof to me.

                    2) OOP makes syntax less readable, more programming-like. For a programmer (who might not be very good at administration, btw) with big projects and when coding complex structures, like GUI, OOP, it makes it less error prone. There is a reason that *nix systems never though an OOP shell, other than an experiment, like python shell

                    3) grep, sed, awk, find, dc, and other utilities are developed for a very long time period independently. (Perl by itself could be considered as a shell on steroids.) Multiple implementations of them exist, like bsd and gnu. They are series tools in each of their niche. It is almost no way to excel them even by such a big and might corporation as MS.

                    4) it's not me that started to boast, that "Bash is better PS", I and some other people tried to counter the negation of this statement.

                    1. eulampios

                      Re: AWK, which you don't seem to know

                      It seems you don't have to use sort or uniq there as well. AWK (or gawk) can handle it by itself. Like this

                      ls -l | awk '$1 ~/x/ && ! match(str," "$3){str=str" "$3;print $3 }'

                      The pre tag wraps things out, btw.

                    2. Uffe Seerup

                      Re: AWK, which you don't seem to know

                      why using find? Why to pipe it to uniq if there is a way to handle it with -u?, reminds me of peculiar pipes like "cat file | grep..." or "cat file |sed ....")

                      I think the point was that he wanted the entire tree processed (recursively). ls -al doesn't do that.

                      or even

                      ls -al | awk '$1 ~ /x/{print $3}'| sort -u

                      This does not process the tree; only the current directory. Even so, the equivalent powershell command would be:

                      ls | get-acl | select -uniq owner

                      Now, which is more *readable*?

                      AWK is a serious language, please don't diminish it. It's not "a part of bash" or any other shell.

                      awk is quite awesome. It is a functional text-processing language with nice features and beautiful consistency. I don't think the point was to *diminish* it. Rather, the point was that the power awk brings simply is not *needed* to compose advanced PowerShell commands. Alas, the power of using objects instead of text.

                      If you didn't get it, it doesn't mean it is no good.

                      ahem. I am *really* tempted to use this opportunity for a snide remark.

                      2) OOP makes syntax less readable, more programming-like

                      Look at the above examples. Which is more readable? Honestly?

                      There is a reason that *nix systems never though an OOP shell, other than an experiment, like python shell

                      Well, if you believe all the grapes that you cannot reach are sour, go ahead and believe that was why *nix systems never though of an OOP shell. I choose to believe that it is because *nix systems never had a system wide object model (and still hasn't). If you were to process objects in *nix, what would they be? Java objects? Without an interoperable object model, the value of an object oriented shell would be severely limited. Ksh actually has an object model - but it is internal to ksh itself and not really a system-wide object model.

                      Windows has COM and .NET - both of which PowerShell use as object models in it's type system.

                      Another important difference is that on *nix configuration is generally text based in line-oriented text files. Which makes tools like sed, awk and grep essential for reading and changing configuration.

                      Windows has an abstracted configuration model, where the actual configuration storage is abstracted away behind a configuration API. To configure something you invoke API functions rather than change text files. Those APIs are almost always either COM or .NET based (or WMI).

                      Hence, it makes sense that *on Windows* you use an object oriented shell and on *nix'es you use a text oriented shell. PowerShell would not be a good fit for *nix. Bash is not a good fit for Windows.

                      The pretext of this was that the OP wanted to learn PowerShell *for Windows*. Deal with it.

                      1. eulampios

                        Re: AWK, which you don't seem to know

                        I think the point was that he wanted the entire tree processed (recursively). ls -al doesn't do that.

                        Okay, that's fine than, you can also pass the "-R" option to ls or do use find, but rather without awk entirely :

                        find . -printf "%u\n" | sort -u

                        (you might use the 2>/dev/null to rid of the permission problems if any)

                        So how does it look to you now? BTW, do dir or ls operator in PS have as many features as find?

                        Or with my AWK ad-hoc pragma:

                        find . -printf "%u\n" | awk '!match(str," "$1){str=str" "$1;print $1 }'

                        ahem. I am *really* tempted to use this opportunity for a snide remark.

                        Go ahead sir, please. I will not wait to respond though :) Again h4armony said:

                        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

                        You need to not know awk enough to run it through grep, awk got that feature and more! Not to mention, that he used many completely unnecessary pipes that could substantially slow down the execution of it. So to me it a no good counterargument. If you let me, this bashing of GNU Bash is no good, please come up with a better one.

                        1. Uffe Seerup

                          Re: AWK, which you don't seem to know

                          (I have not figured out of to use pre and code tags, any help?)

                          find . -printf "%u\n" | sort -u

                          (you might use the 2>/dev/null to rid of the permission problems if any)

                          Ah. Yes, otherwise the command line along with 'permission denied' will be reported as an "owner". So the command really should be:

                          <code>find . -printf "%u\n" 2>/dev/null | sort -u</code>

                          (find all files from current location and below, for each file output a string with the owner-name suffixed with a new-line, ignore errors/warnings; sort all the "lines" and return only unique lines)

                          Compare that to

                          <code>ls -recurse | get-acl | select -uniq owner</code>

                          (find all objects from current location and below; for the objects get the access-control-lists; for each access-control-list get the unique owners)

                          h4rmonys observation was that in bash, fitting commands together frequently requires text monging (formatting and immediate reparsing), whereas in PowerShell the properties/objects "fit" together.

                          BTW, do dir or ls operator in PS have as many features as find?

                          Now that is a really good question. The answer, of course, is that in PowerShell you only have Get-ChildItem (aliased to ls). It does not have as many options as find. However, that is not for the reason you think. find is a monster command which violates the "unix'y principle" (do one thing and do it well).

                          find:

                          * traverses files and directories (so does ls - but with different capabilities)

                          * has multiple options to control output format (why?)

                          * has multiple options to performs "actions", among which are the ability to execute other programs (!), including ability to prompt the user (!)

                          * find has an entire expression language which is different from expressions used in the shell itself, different from expressions used in other utilities.

                          Furthermore, find has many options for dealing with filenames that may contain spaces. It has these options exactly because text parsing is brittle and error-prone. In the past this has led to not only unstable scripts but to severe security problems as well!

                          No other tool can reuse the expression language. Awk has it's own "language", as does grep and ls and even the shell itself ("tests").

                          Now, compare that to PowerShell:

                          * The Get-ChildItem cmdlet traverses files, directories (and outputs objects). It works on all location types, ie. file system objects but also SQL locations, IIS locations, certificate store, registry etc.

                          * The Get-ACL cmdlet retrieves ACL objects for items that are passed to it.

                          * The Sort-Object (aliased to "sort") sorts objects of any type by using property names or expressions.

                          * Output formatting is handled by separate cmdlets, avoiding the need for each and every command to define output formatting options. Do only one thing and do it well.

                          PowerShell expressions are "script blocks" defined by the shell and thus common for *all* commands whether packaged with PowerShell or 3rd party modules. You use the same expression language, and each tool is relieved from having to implement parsing, compilation etc.

                          1. eulampios

                            @Uffe, on find

                            So if you call 'find' "monstrous", how do you find PS that has some of its properties as well as sort and more? (sorry for unintended punt)

                            has multiple options to control output format (why?)

                            because you might different tasks and goals as well as search criteria. And that pretty much one option 'printf" a pretty well familiar operator from C. I don't like the -exec function myself and prefer xargs (-exec is just that alias of that pipe you were mentioning when talking about PS options) .

                            find has an entire expression language which is different from expressions used in the shell itself

                            It's not entirely true according to me, like I said it's printf with pretty familiar formatting syntax. It, btw, took me a few seconds to search "%u" in man, and "\n" is a new line es everywhere else.

                            What you;re saying about PS is that all features that are not complete (compared to the utilities ) and all of them in one bottle? With utilities I could however switch to a different shell, if I don't like bash, say, zsh or kcsh or anything else. (Moreover, they work as calls within GNU Emacs and get really handy there, like there is grep-mode. ) I got more freedom with shel+utils, you see.

                            Moreover, cmdlets are modules that are not completely independent of themselves. You cannot isolate them away from PS, right? So the principle of modularity is not observed fully.

                            1. This post has been deleted by its author

                            2. Uffe Seerup

                              Re: @Uffe, on find

                              I don't like the -exec function myself and prefer xargs

                              Interesting. So how would you write the example using xargs?

                              -exec is just that alias of that pipe you were mentioning when talking about PS options

                              I think i miss something here (honestly). Could you clarify, please?

                              1. eulampios

                                Re: @Uffe, on find

                                Interesting. So how would you write the example using xargs?

                                Sure, if you know that your output does not exceed a certain limit of the pipe length (thre is a shell variable for this) use simple pipe, otherwise xargs

                                find /media/MyBook/classical/ -name "*14" -print0 | xargs -0 grep -i "Op.*1.*No.*6.*C.*Major"

                                In this example I need to find a cddb file with a certain contents as a pattern, I run it with grep (it might possible to do it through grep itself, however there is tones of small text files there)

                                I mean, that essentially an alias for a pipe, since find calls an external program on a file with an argument as this file.

                    3. h4rm0ny

                      Re: AWK, which you don't seem to know

                      Firstly, let's clear up one thing:

                      >> it's not me that started to boast, that "Bash is better PS"

                      There wasn't one word of criticism of Bash in my original post (I have huge respect for it). But you threw in several swipes at Powershell in your answers so really most of this debate has stemmed from people correcting your criticism of Powershell.

                      Indeed, you even ask for such replies explicitly:

                      >>The main thing is though, how PS compares with Bash and other shells in usability, ease and power as shell, an envelop between utilities and processes? That is the real question.

                      So please do not cast me (or several others) as "bashing bash". It is not my intent. Also this part:

                      >>1) More on this, you declared my statement "wrong", so I felt I could do the same to yours :) If my own, no your own case, is not proof to you, your proof might not be a proof to me.

                      Reasoned debate doesn't work that way. If you claim 5+5 = 7 and I show you're wrong, you don't get a freebie to say I'm wrong when I write 3+3 = 6. Reality is not a socialist government that believes in fair distribution of correctness. I gave good solid reasons which you skipped over. You gave flawed reasons which I examined and refuted.

                      Okay, that out of the way, I'd like to respond to your reply to me in the specifics.

                      >>>>find ./ -exec ls -l {} \; | awk '{print $3}' | grep . | sort | uniq

                      >>why using find? Why to pipe it to uniq if there is a way to handle it with -u?,

                      >>reminds me of peculiar pipes like "cat file | grep..." or "cat file |sed ....")

                      >>Sorry, you didn't get awk as I can see, you don't have over-complicate it:

                      >>ls -al | awk '$3 ~/./ && $1 ~ /x/{print $3}'| sort -u

                      As another has pointed out, that doesn't do the same thing. I used find to be recursive. Fair catch about using the -u switch rather than piping to uniq. I was doing it rather old-fashioned, but then that's why I invited you to improve on my script if you could.

                      Anyway, someone else wrote this but you didn't respond to them in your reply so I'm going to repeat it. One of your main claims is that Powershell is harder to read and that OO nature makes it more complicated. So again, how is the Powershell version (second) the more unintuitive one?

                      ls -al | awk '$3 ~/./ && $1 ~ /x/{print $3}'| sort -u (bash)

                      vs.

                      DIR | Get-Acl | Select-Object Owner | Select -Unique (Powershell)

                      The only things I see potentially confusing in the Powershell one are that someone not familiar with Windows wont know that Get-Acl gets you the file permissions and owner. But the structure of it is pretty simple. As another poster wrote, I'm not damning awk as bad, I'm explaining how on Powershell it's not needed. You can extol what a good nozzle-cleaning widget your inkjet printer has all day long, but it's going to mean nothing when you're trying to claim your inkjet is better than a laser. Awk is a patch for something Bash can't do. It's great, but you can't use it as an example of why Bash is better than Powershell, and you were the one that brought it up saying Powershell couldn't rival awk.

                      Also, let's look at the other example you posted to show how you could skip the piping to sort:

                      ls -l | awk '$1 ~/x/ && ! match(str," "$3){str=str" "$3;print $3 }'

                      I understand that, but to my mind it is even more complicated than the first one.

                      The recursive one you came up with really starts to show the differences, however.

                      find . -printf "%u\n" | awk '!match(str," "$1){str=str" "$1;print $1 }'

                      vs.

                      DIR -Recurse | Get-Acl | Select-Object Owner | Select -Unique

                      See how not having to mangle text in between each stage lets you focus on the components that actually do what you want? That is my point. Indeed, you kind of prove my point with your final and shortest example which is interesting:

                      >>find . -printf "%u\n" | sort -u

                      What you've effectively done here is dodged the question of text mangling by finding a program that does everything in one (or most of it). The point of the example was an illustration of how cleanly you could pipe a list of file names to another cmdlet which then did an operation X on them, in this case, getting the usernames. In your example, what you've done is found a program that already does X as part of it .Suppose X was an operation that find didn't support - you're back to text mangling. You've essentially responded to my point that text-mangling to pipe things is complex in Bash by finding a way to avoid the use of pipes with what is essentially a macro. :)

                      >>(you might use the 2>/dev/null to rid of the permission problems if any)

                      That's another thing. In Powershell you can have it throw an actual exception and you can handle that how you choose. Rather than just direct error messages to an output file or terminal to see if anything shows up.

                      >>2) "type coercion", what the hell? It's not a shell then.

                      As others have pointed out, where is it written that a shell shall not support type coercian? It's a useful feature. Also, this just adds one more piece to the puzzle of how much you actually know about Powershell. You skipped this question before so I'm just going to ask it again: do you have any significant or real world experience with powershell? Because you are making extremely confident pronouncements about its inferiority.

                      1. eulampios

                        @h4rmony

                        Ih4rmony, I am sorry to try making you believe that 5+5 = 7, however you have proved that indeed 3+3=6. How silly of me and haw smart of you.

                        I apologize about getting into a discussion with you.

                        BTW,

                        1) I don't know Powershell at all

                        2) I know quite some shell scripting and have been using bash even before PS was launched by MS (in 2005-2006)

                        3) you don't know of Bash and Linux/Unix and utilities enough to judge how much PS is better than all them combined. In proving that 3+3=6 you also forgot about people criticizing PS that actually did have to use PS at one point in the end of this thread.

                        1. h4rm0ny

                          Re: @h4rmony

                          >>"Ih4rmony, I am sorry to try making you believe that 5+5 = 7, however you have proved that indeed 3+3=6. How silly of me and haw smart of you. I apologize about getting into a discussion with you."

                          I'm sorry things have become heated. Or it sounds as though they are perceived that way. I'm actually very happy to continue this discussion. But I have backed up my points and you did say you had "proof" that command line was "in its infancy" on Windows and the proof you offered was the lack of a decent terminal. And many people have offered examples of good terminals. ISE that comes with Windows (which I simply didn't know was there) has built in debugging for Powershell scripts so you can step through them and set breakpoints. That's a solid argument so I do feel able to say your point was wrong. And yes, I do reject the idea that it's just a matter of perspective with you saying I'm wrong having as much validity as my saying that about a factual error on your part.

                          >>1) I don't know Powershell at all

                          Which is what I've been saying. That doesn't mean you can't produce relevant arguments because you obviously know Bash. But it does mean you shouldn't speak authoratitively about what is wrong with Powershell. You've made numerous assumptions which have turned out to be wrong.

                          >>"2) I know quite some shell scripting and have been using bash even before PS was launched by MS (in 2005-2006)"

                          Yes. Same here. I think I first used Bash in around 2001? Something like that. I've never needed to write extensive scripts in Bash, but I have written some and I use Bash pretty much daily. I have a feeling this is leading up to an Appeal To Authority (yourself) or Ad Hominem (myself) argument.

                          >>3) you don't know of Bash and Linux/Unix and utilities enough to judge how much PS is better than all them combined

                          And here it is. A statement about what a stranger on the Internet can know. I've literally been writing Bash script in this discussion as we went to illustrate my points! What possibly gave you cause to declare I don't know enough? That I piped the output to uniq instead of using the -u flag on sort? Hardly an error - just a different way of doing things. Or that I used sort / uniq at all instead of doing everything in awk? Honestly, I was doing everyone a favour there. I was showing how a Powershell script can be a little simpler than a Bash script sometimes. And you would prefer instead of using this to represent Bash:

                          find ./ -exec ls -l {} \; | awk '{print $3}' | grep . | sort -u

                          I used this:

                          ls -l | awk '$1 ~/x/ && ! match(str," "$3){str=str" "$3;print $3 }'

                          Well no, sorry. But I was trying to show Bash in a fair light. Mine is a lot cleaner and easier to read than yours. Just because I don't produce some overbearing glob of awk, does not give you grounds to call me a liar.

                          >>"In proving that 3+3=6 you also forgot about people criticizing PS that actually did have to use PS at one point in the end of this thread."

                          What exactly is it that you think I have forgotten from other people's posts?

                          1. eulampios

                            Re: @h4rmony

                            Sorry about that as well.

                            However,

                            1) I was not trying to show superiority of Bash over PS. No and it wasn't a response to you directly, if you look up. Someone said that "PS is better than Bash, period" I tried to question that statement, by asking to specify it. My confidence in the fact that it might be hard to beat the old school was based on the Novelty of PS and that they had been dismissing CLI approach in general. I also tried rebuff the criticism of THeVogon, whose points were pretty cryptic at best. I pointed out that there are good utilities like gnu parallel or gnu screen you can use for many feature he mentioned and more. I(AMOF, actually use parallel to do parallel computing with pari-gp CAS)

                            2) you made a few blunders in your criticism of Bash's shortcomings as "overcomplicated syntax " choosing a much more complex syntax than that one in fact needs. Using "awk | grep ." is really not showing how bad syntax is but that you didn't get AWK. That got me going, so I didn't realize that, what you want can be done in one pipe. It took me 10-15 secs to run "man find" and search with "/user" to get the corresponding printf's formatting. Of course I knew something about find and "sort -u". My attention was directed to AWK though originally.

                            All those maybe even good properties of PS are what is built-in for Bash. There was a reason for not overwhelming a shell with "features". Remember, that a "program should do one task task and do well". That is why there is a find utility that does finding files damn well. You can't beat it at that. Uffe called it a "monster" earlier. But, if find that handles only searching and listing files and dirs is a monster, what is PS? Find got this ominous option -exec, which I try not to use (I prefer xargs or a plain pipe) and more so using ls with that is disregarding the capabilities of find to search for files and show the results in the preferred format. Again, your counter-example was not convincing.

                            I was not going to go into details of what can find do and PS can't (again as Uffe pointed out above).

                            What exactly is it that you think I have forgotten from other people's posts?

                            Please look up the posts written by Roo and this one

                            3) yes, I also only mentioned, if PS were a tool that would mean a lot for a Windows ecosystem, why did you have to deal with those problems of poor environment for it? And I contrasted it with state of affairs of BSD/GNU Linux and Mac OS X.

                            1. h4rm0ny

                              Re: @h4rmony

                              >>"1) I was not trying to show superiority of Bash over PS. No and it wasn't a response to you directly, if you look up. Someone said that "PS is better than Bash, period" I tried to question that statement, by asking to specify it"

                              I didn't recall anyone saying what you put in quote marks in this thread. I've just searched through all three pages and it's not there. The post you actually replied to at the start of all this was a direct answer to someone saying "why not just use Bash" and their actual reply was this:

                              "How about because you can't pass objects in bash, just a bunch of text. You can do a lot more in Powershell, but bash still has it's place too."

                              They are very far apart in tone, imo, and not really equivalent in meaning. As to whether it's justifiable to say you can do a lot more in Powershell, TheVogon has produced an impressive list, some of which you have been able to find ways of replicating in Bash using third party add ons. Quite simply, no-one actually said what you claim and whilst you did ask what exactly Powershell could do that Bash could not, every answer given to you has been attacked and I think it is reasonable to say that what you have been doing here actually is to try and show that Bash is superior to Powershell.

                              >>"My confidence in the fact that it might be hard to beat the old school was based on the Novelty of PS and that they had been dismissing CLI approach in general"

                              Novelty? The first release of Powershell was in 2007, nearly seven years ago. And it's on version 4 now. I sense an incoming response that Bash has been around a lot longer. It has. That doesn't mean that a project that went to release seven years ago and has been in continuous development since is "novel". And it's already been pointed out to you that MS are not "dismissing CLI approach". Powershell runs through their entire OS now and Server 2012 is routinely administered by it. To be clear, there is no part of Windows Server that cannot be managed via Powershell . Its entire GUI is wrappers for Powershell scripts (which you can export and examine, btw). That is not true of any GNU/Linux distro that I know. There is a reason I am fascinated to learn it.

                              >>"2) you made a few blunders in your criticism of Bash's shortcomings as "overcomplicated syntax " choosing a much more complex syntax than that one in fact needs"

                              I've gone back through my posts and nowhere have I used the phrase "overcomplicated syntax" which you attribute to me in quotes above. Indeed, the only instance of me actually even using the word "syntax" was where I quoted you.

                              The only "blunder" I made was to write sort | uniq rather than sort -u. They are equivalent in output, my version is a little easier to read and infinitesimally longer in performance, possibly. You have zero grounds at all to start making ad hominem attacks claiming I am unaware of how to use Bash or that I'm trying to make it look bad.

                              The "blunder" of using awk's output to a pipe instead of trying to do everything in awk? Seriously? I've already answered that once. I'll repeat it. My aim was to show a simple illustration of how Bash handles piping and you claim I'm not fairly representing it by writing this:

                              find ./ -exec ls -l {} \; | awk '{print $3}' | grep . | sort -u

                              instead of:

                              find . -printf "%u\n" | awk '!match(str," "$1){str=str" "$1;print $1 }'

                              On what planet will you find people who think the latter is more human-readable than the former? My point stands. I have not made "blunders" so stop trying to convince people I'm talking out of a position of ignorance.

                              >>"All those maybe even good properties of PS are what is built-in for Bash"

                              You are confusing Bash with GNU Utils. find is not "built into Bash", it's a program and the reason Uffe called it a monster is because it violates seven ways to Sunday the UNIX principle of do one thing well. It contains its own print formatting language for example. Powershell is far more adhering to the principle of "do one thing well" in that the equivalents return an array of file objects and you pipe it to a formatting cmdlet. The same cmdlet you would use for other programs output as well - thus you get consistent formatting language and discrete programs.

                              >>"That is why there is a find utility that does finding files damn well. You can't beat it at that."

                              Why can't you beat it at that? It's just a program. Why would an equivalent program running on a Windows box be worse? How do you even know that DIR -recurse and piping the file objects to another isn't just as good? It's certainly more flexible - remember you never answered my question about what if you wanted to perform an operation that find didn't support? In my example I piped the output of DIR to a cmdlet to get the file owner. It so happens that find has that in its list of formatting options. But I could pipe the file objects to anything at all including things that find does not handle. Remember that find is just a program, it's not Bash. If you want to perform an action on the files that find does not support you're back to text mangling.

                              >>"I was not going to go into details of what can find do and PS can't (again as Uffe pointed out above)."

                              Actually, I would like you to. I very much want to hear what find can do that can't be done in Powershell. Maybe I wont know how to do it, but someone here will and I will certainly learn from them.

                              So I'm taking you up on that. You are clearly implying that find can do things that can't be done in Powershell, so just give me one example. All that I ask. And if my tone is creeping back toward argumentative, you have basically been calling me a liar several times now. So please - one example.

                              >>Please look up the posts written by Roo and this one

                              I'm not at all sure what I'm supposed to be responding to there. They say they use PyShell, Fine by me, more power to them. Python is a powerful language and extremely well-designed. They say they didn't think Powershell was as good as "Unix shell" (I'll assume Bash). Well, okay. Fine. They have an opinion. They don't actually list any facts or arguments so it's just their opinion which they are entitled to. You however, are making arguments and so people are shooting down innacuracies. Honestly, if you're now making an appeal to authority argument with Zane's post as the authority then I really can't get where you're coming from.

                              Pointing at another poster and saying effectively 'look - they didn't like it and they used it' as a means of exculpating your own complete lack of experience with Powershell is just flawed.

                              1. eulampios

                                @h4rmony

                                Actually, I would like you to. I very much want to hear what find can do that can't be done in Powershell.

                                Here's my challenge for anyone who could try to replicate PS dir for this command

                                find -L . -maxdepth 3 -regextype posix-egrep \

                                -iregex ".*img[1-4]{1,3}\..*" \

                                -atime -10 -size +1M -size -2M \

                                -user john123 \

                                -printf "%f\t%kkb\t%m\n"

                                #Explanation

                                -L follow symlinks

                                -maxdepth - traverse no deeper than that many dirs

                                -iregex -- is case insensitive pretty much POSIX, which I hope one can read Okay

                                -atime -10 - files that have been changed within last 9 days

                                size +1M -size -2M -- with size in the [2,2]M range

                                -user john123 --- belonging to user john123

                                -printf "%f\t%kkb\t%m\n" -- in the format full filename\tsize( in kb)kb\tfile (permissions in octal form)\n

                                Is any of that possible with PS and dir command?

                                1. eulampios

                                  find

                                  Corrections:

                                  1) I put -atime (access time) but really wanted -ctime for "change time"

                                  2) in the size range I also wanted it to be [1,2]M

                                2. Uffe Seerup

                                  Re: @h4rmony

                                  Is any of that possible with PS and dir command?

                                  Yes, of course it is.

                                  (I still don't know the secret behind formatting code in these forums :-( )

                                  -----------------------

                                  ls *, */*, */*/* -pv f | Get-Acl | ?{

                                  $f.Name -match '.*img[1-4]{1,3}\..*'

                                  -and $f.LastAccessTime.AddDays(10) -ge (get-date)

                                  -and $f.Length -gt 1MB -and $f.Length -lt 2MB

                                  -and $_.Owner -eq 'john123' } |

                                  ft {$f.FullName},{$f.Length},AccessToString

                                  -----------------------

                                  #Explanation:

                                  "ls" lists childitems. Here it lists 3 levels.

                                  "Get-Acl" retrieves ACLs for the files on the pipeline.

                                  "?" (an alias for "Where-Object") filters using a boolean expression.

                                  "ft" (an alias for Format-Table) formats the select columns.

                                  Keep in mind that the OSes are different. There is no "octal permissions" on Windows. Windows has true first-class ACLs. (ACLs were added later on *nix, and is still not fully integrated - e.g. there is no "octal" representation).

                                  The only "trick" used here is the pipeline variable (the pv parameter of the ls command). It saves the file in a variable which can then be used in the filter expression.

                                  You will no doubt note how this is "longer" than the specialized find command. However, you should also note how the filter expression can reach out and evaluate for any expression. H4rmony alluded to this previously: Once you need to filter on anything "find" has not been coded for, you are out of luck. PowerShell can draw on anything that can be evaluated as an expression.

                                  1. eulampios

                                    @Uffe

                                    Good job!

                                    (I still don't know the secret behind formatting code in these forums :

                                    I don't think its too good. You can use the code tag though.

                                    Although you might have omitted symbolic links, your command does pretty much what my find command was doing. However, there were a few things I would like point out:

                                    0) it's 2 pipes, if I am not mistaken, my example had no pipes at all (no -exec option was used as well), and hence it might be less efficient and slower, since you list all files, then get what you want etc

                                    1) as one can see, there is no -maxdepth option, so you would have a little harder time if I had -maxdepth 33

                                    2) syntax is not as nice as in h4rmony's and your own example, it is longer than mine

                                    3) printf is pretty much universal in IT, your format might be a little different from mine, since i put in KB and with dimension "kb" How would you get it print out using a different than "\n" delimiter, say ","?

                                    4) when and how many times does this (get-date) evaluated? if it takes several secs, mins or hours would the result be different for files found right away and later on?

                                    Once you need to filter on anything "find" has not been coded for, you are out of luck.

                                    What do you mean by that? h4rmony alluded to many things and used '-exec ls' instead of a better suited -printf formatting. Please show me it with example, since his example was not very convincing.

                                    PowerShell can draw on anything that can be evaluated as an expression.

                                    What can it draw on , while find or other suitable utilities can't.

                                    5) we of course don't know which would be faster more efficient, except the two pipes might slow execution of it down .

                                  2. eulampios

                                    Re: @h4rmony

                                    Windows has true first-class ACLs. (ACLs were added later on *nix, and is still not fully integrated - e.g. there is no "octal" representation).

                                    First, MS Windows didn't have file permissions at all, remember that time, thus fat32 and earlier filesystems still don't have proper file permissions. The *nix systems had it from day one. Second, what's first-class citizen, what is third-class? Please clarify.

                                    1. This post has been deleted by its author

                                    2. Uffe Seerup

                                      ACLs

                                      First, MS Windows didn't have file permissions at all, remember that time, thus fat32 and earlier filesystems still don't have proper file permissions.

                                      Sorry, that is BS. Windows NT was a clean-room implementation which had nothing to do with the Win9x line, except it exposed some of the same APIs.

                                      All current Windows versions is based on the original Windows NT - which had proper ACLs (and network-ready SIDs instead of 16bit numeric uids/gids) from the start.

                                      The *nix systems had it from day one

                                      Wrong. The *nix systems had me-us-everyone rwx permissions from day one. No ACLs.

                                      *nix uids and gids were designed with single-authority in an era where it was not foreseen that you one day would need to network the credentials (multiple authorities), hence you now need to map uids and use other types of quirks. Windows SIDs were designed to support multiple authorities and allow for networked credentials from the start.

                                      The *nix model only had standard users and root and the privileges were fixed: Some things a user could do, everything else required root. Permissions were (and still are) extremely coarse grained. And *nix permissions *still* only applies to file system objects. The need for more securable resources have led to designs where e.g. processes mapped" to file system objects.

                                      All modern *nixes now have ACLs. But you typically have to install/enable them explicitly and much the tooling is still not geared towards ACLs. You yourself have used examples here where you assume a single owner and "octal permission flags", for instance.

                                      The lack of tool integration and the fact that ACLs competes with the traditional file system permissions makes them 2nd class citizens. They are frequently being ignored by tool and script authors. "find" is a very good example.

                                      In computer science (especially language design) we use the term "first class" for kinds of objects that "fit in" analogous to similar or corresponding kinds of objects. When a kind of object is limited in its use cases, we consider it a 2nd class citizen.

                                      You have many *nix tools (and GUI applications) that still assume the traditional *nix rwx me-us-world.

                                      1. eulampios

                                        @Uffe, *nix permissions and more

                                        Before turning to file permissions, I would like find out if you're gonna answer my questions on your alternative of my command and some criticism of it?

                                        Windows NT was a clean-room implementation which had nothing to do with the Win9x line

                                        I know what you mean, but I am sorry, did I ever use "NT" in my statement? that was "MS Windows" in my quote. Do you then mean that Windows 9x line was not labeled 'Windows' or that it never was 'Microsoft' Windows?

                                        Wrong. The *nix systems had me-us-everyone rwx permissions from day one. No ACLs.

                                        True about ACL, however, I was contrasting it with the original Win9x without any rwx at all.

                                        As far as NT is concerned, XP was from that line. yet a lot of people experienced problems with permissions (or the better ACLs). I remember the implementation wasn't without a few kludges, and remember how I tried installing a game and a few applications with admin account and could only run as admin, getting "access denied" errors, that is partly why many people would only use their Windows box out of the Admin account. Whether it was a some system design flaw or 3-d party programmers messed it up, I don't know, however, this wasn't the case with the *nix systems when you had it happen to the userland programs. Maybe acl's were too good and were not understood well by the 3-d party XP programmers.

                                        Also, with all the advantages ACL have before the POSIX permission, as you suggest, I'd want to point out at another fact. The POSIX permissions have their important role: security.

                                        Let's see, how it helped Android and Google there. For the GNU Linux and *BSD there have been software repositories, which users could be installing software from. It's fairly secure with the digital signature and integrity verification and so on. That is why trojan is a "100th class citizen" on those systems :). (Now, Windows 8 got a slightly similar thing not for all software though, Android has it's store too.) Although before 8, what was there since XP (and before) to warn and protect a user, a system against a possible trojan?

                                        Nothing except a warning and advice "to install software from the known sources".

                                        Google came up with a witty yet simple solution of extending POSIX permissions. They divided different tasks and actions into categories (like access to Internet, writing to an sd card and so on) by using groups and mandated all applications to acquire a unique uid thus separating application away from each other and system. Plus granting various permissions categories by having them join the corresponding groups. More so the applications themselves have to disclose those permissions they want, which is achieved by API.

                                        If XP, Vista or even Win7 had it, it would be great and effective, since there was none of that available. I am not sure if ACL are bad or too good, but those were never used to accomplish anything similar.

                                  3. eulampios

                                    @Uffe: your output format

                                    ft {$f.FullName},{$f.Length},AccessToString

                                    So why is this formatting identical to mine, or it is not? I wanted to delimit the fields with the tab "\t", what if had something different, than that? What about the records, in my case it's "\n"? I also had the Length in kilobytes, what if I required it to be in bytes?

                              2. eulampios

                                @h4rmony

                                with all due respect, I would suggest that the manner in which you try to argue would be a little different than this:

                                "you're proving to me that 5+5=7, while I am trying to showing you that 3+3=6"

                                Diminishing your opponent doesn't empower your argument, it's does the opposite dialectical job, for an independent onlooker.

                                every answer given to you has been attacked and I think it is ...

                                So, I am attacking it? And other just gently and friendly showing tha I was wrong? Again, please look at the difference of tones, you're using.

                                TheVogon was again using some cryptic language, I was making remarks on that. If he/she suggested how I could protect the signature from being compromised after I offered to install as a system utility, I simply said that you would be done with the whole system. Is it an attack. Or when it was pointed out how portable and universal S, it can be used for no less than 2 systems! I pointed out it was a joke on potability. Again it was an attack....

                                find ./ -exec ls -l {} \; | awk '{print $3}' | grep . | sort -u

                                instead of:

                                find . -printf "%u\n" | awk '!match(str," "$1){str=str" "$1;print $1 }'

                                You're forgetting that the final was

                                find . -printf "%u\n" | sort -u

                                I also offered AWK because you seemed fixated on AWK in the original post I was responding to and used redundant grep filtering. So you were using 2 redundant pipes plus a redundant command ls instead of just reading man of find.

                                You are confusing Bash with GNU Utils. find is not "built into Bash",

                                No I don't, I never said that, I only likened PS cmd-lets to Bash built-ins, get it now?

                                it's a program and the reason Uffe called it a monster is because it violates seven ways to Sunday the UNIX principle of do one thing well.

                                How so? It only specializes in finding files and printing information on that. While PS is a jack of all trades, right? Say find is independent of the shell, you can use with pretty much any POSIX shell, while you cannot use dir cmdlet with GNU Bash, on the other hand...

                                It contains its own print formatting language for example.

                                It's printf, come-on, it's not "its own" language, escape literals are the same as everywhere, other formatting literals can be looked up via man or info.

                                1. Uffe Seerup

                                  Re: @h4rmony

                                  How so? It only specializes in finding files and printing information on that.

                                  That's 2 things already.

                                  It is called "find" because it should find files. The UNIX principle would be to leave the "printing" to another tool. The find part overlaps with several other tools. The "printing" part is an entire printing language - private to the find tool and not in common with any other tool.

                                  You write that "it's just the C printf". No it is not. C's printf does not know anything about owners, file sizes, rwx permissions, block sized. C's printf understands how to format strings and numbers passed to it as parameters. C's printf does not understand %u. C's printf does not go out and obtain information by itself. It is merely the name and excessive use of the % character that is common.

                                  But even if you want us to ignore it, printf *also* starts and executes new processes. Cookbooks frequently use that capability. The find command can even prompt the user for ok to continue.

                                  That's 3 (to be generous).

                                  The date/time formatting is another area where find excels. But why does a file finding utility have to know about formatting dates and times?

                                  That's 4.

                                  Then there's the expression language. One can argue if it is done well, but a very, very large part of find is dedicated to this expression language and optimizations/tweaks for the evaluation. I'm not referring to the abundance of tests available. I am referring to the parenthesis and logical operators. Find has it's own format for these, incompatible with other tools that also does boolean expressions.

                                  That's 5.

                                  Then there are strange options such as -quit

                                  The find command mixes at least 5 independent "things". Not one thing. There is no reason for this other than the limitations of the constant text formatting and parsing, and the limited bandwidth and expressiveness of a line oriented text format. Many of these "things" are overlapping with functionality of the shell itself (like the "tests") and with other tools. "ls" also excels at printing - only it's a different way to specify the format, and the format is married to the tool.

                                  I am sorry if this sounds like I think find is a bad tool. It is not. It is actually an awesome tool. But it is undeniably complex. And the skills you need to master it does not help you at all when you continue to ls, ps, du or other popular tools.

                                  While PS is a jack of all trades, right?

                                  It has been pointed out to you, that PowerShell has been able to take a responsibility such as finding/locating items and separate it from responsibilities such as managing processes, formatting output, performing date/time arithmetic and interpreting propositions. Those other responsibilities has been generalized and composes with all other responsibilities.

                                  Thus, PS tools tend to be smaller and have (far) fewer options. And yes, then you tend to use more commands on a pipeline, because you pass the object on to the to the tool that excels at it's (single) task.

                                  Consider these commands:

                                  Get-ChildItem | Where Length -gt 2MB | Format-Table Name,Length

                                  Get-ChildItem | Where Length -gt 2MB | Format-Wide Name -Col 8

                                  Get-ChildItem | Where Length -gt 2MB | Format-List FullName,Length,Attributes

                                  Get-ChildItem | Where Length -gt 2MB | ConvertTo-Html

                                  Get-ChildItem | Where Length -gt 2MB | ConvertTo-Json

                                  Get-ChildItem | Where Length -gt 2MB | ConvertTo-Csv

                                  Get-ChildItem | Where Length -gt 2MB | Select FullName,Length,Attributes,LastWriteTime | Out-GridView

                                  Notice how filtering and formatting/printing is left to generalized cmdlets which has the filtering/formatting as their single responsibility.

                                  1. h4rm0ny
                                    Pint

                                    Re: @h4rmony

                                    >>Get-ChildItem | Where Length -gt 2MB | ConvertTo-Html

                                    >>Get-ChildItem | Where Length -gt 2MB | ConvertTo-Json

                                    >>Get-ChildItem | Where Length -gt 2MB | ConvertTo-Csv

                                    That's lovely. I had no idea those existed. Despite this topic turning into a flamewar (there was not the slightest criticism of Bash in my post), it is at least bringing a lot of cool things to my attention. Thanks - I've been really finding yours and TheVogon's posts helpful.

                                    1. Uffe Seerup

                                      Re: @h4rmony

                                      That's lovely. I had no idea those existed.

                                      Then try out-gridview and be blown away :-)

                                  2. eulampios

                                    @Uffe, on find

                                    That's 2 things already...It is called "find" because it should find files. The UNIX principle would be to leave the "printing" to another tool.

                                    When another tool is known like formatting cmdlet in PS, it might be a good idea. Otherwise, sorry, but find has to print out the information somehow, it can't just dump whatever is possible to a printing utility. In case of PS, cmdlets work together, utilities don't. In fact PS is one program divided into modules. You're alluding to PS cdmlets as independent programs, is that correct? Can I take a dir cmdlet and install in a GNU Linux or a *BSD and use it instead of find or ls? If not, then they are not fully independent.

                                    But even if you want us to ignore it, printf *also* starts and executes new processes. Cookbooks frequently use that capability.

                                    Never heard of this feature of -printf 'to execute' anything. Are we talking about the same find's? Which cookbook are you reffering to? Mine is:

                                    find (GNU findutils) 4.4.2

                                    Copyright (C) 2007 Free Software Foundation, Inc.

                                    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

                                    This is free software: you are free to change and redistribute it.

                                    There is NO WARRANTY, to the extent permitted by law.

                                    Written by Eric B. Decker, James Youngman, and Kevin Dalley.

                                    Built using GNU gnulib version e5573b1bad88bfabcda181b9e0125fb0c52b7d3b

                                    Features enabled: D_TYPE O_NOFOLLOW(enabled) LEAF_OPTIMISATION FTS() CBO(level=0)

                                    It has been pointed out to you, that PowerShell has been able to take a responsibility such as finding/locating items and separate it from responsibilities such as managing processes,

                                    Okay, kindly let me know if cmdlets are independent programs. In particular, whether dir (or ls) and Format-Table, date-time are as independent as find, awk, date and Bash? In particular, can I install any of theses cmdlets on my system to work with Bash or Dash? If not, then they are not independent programs and contradict the UNIX principle more than find does.

                                    1. h4rm0ny

                                      Re: @Uffe, on find

                                      >>>>"That's 2 things already...It is called "find" because it should find files. The UNIX principle would be to leave the "printing" to another tool."

                                      >>When another tool is known like formatting cmdlet in PS, it might be a good idea.

                                      Are you now arguing that Bash lacks a formatting tool? Because that would be an argument that Bash lacks something that Powershell has. In justifying the rolling of formatting functionality into the find program, you have started damning Bash.

                                      But that's not entirely true, anyway. You can pipe the output to printf for example. The problem is though, the ability to print out the file owner is part of find. You originally introduced find's formatting to the discussion as a way of avoiding piping to awk to cut out the owner part of its textual output. Once you go to piping the output to a formatting tool, you're back to having to mangle text to the parts of it you want. You either go back to awk and text mangle, or else you end up with TWO formatting commands - one in find to get the file owner, and then another in the formatting tool to represent it how you want.

                                      Passing objects avoids all this because the receving tool can simply pull out the properties that it wants.

                                      Also, as I pointed out, the moment you find an operation that the multi-purpose find program doesn't have in its arsenal, you're out of luck. Whereas with Powershell it can pipe to anything at all. You have been using find essentially, as a way of dodging the issue of Powershell vs. Bash pipelining. It's a macro, essentially, and says nothing about the merits or failings of pipelining in Bash, only that I picked an example that let you find a way to avoid pipelining to some extent. That's what I've repeatedly been explaining and you've never responded to.

                                      >>" In case of PS, cmdlets work together, utilities don't. "

                                      This is because cmdlets can communicate by passing objects to each other and utilities in Bash have to pass text. I.e. the ability to pipeline objects is a significant advantage. Text is a subset of objects. The ability to pass objects is therefore inherently more capable than only being able to pass text.

                                      >>"Okay, kindly let me know if cmdlets are independent programs. In particular, whether dir (or ls) and Format-Table, date-time are as independent as find, awk, date and Bash? In particular, can I install any of theses cmdlets on my system to work with Bash or Dash? If not, then they are not independent programs and contradict the UNIX principle more than find does."

                                      The UNIX principle is to do one thing and do it well. cmdlets generally adhere to that pretty well. find does not. (Nor do some other popular GNU Utilities). That's why they aren't contradicting it. To say they don't because you probably can't install them on GNU/Linux. (Maybe with Wine? I don't know), is orthogonal to that.

                                      Btw, they are independent programs. They're simply programs that implement the .NET cmdlet class and thus, I believe, can be called from anywhere. So now that your question is answered in the affirmative, then by your own reasoning you see that they do adhere to the UNIX principle. (And as Uffe said, more than find does).

                                2. h4rm0ny

                                  Re: @h4rmony

                                  >>with all due respect, I would suggest that the manner in which you try to argue would be a little different than this:

                                  "you're proving to me that 5+5=7, while I am trying to showing you that 3+3=6"

                                  Diminishing your opponent doesn't empower your argument, it's does the opposite dialectical job, for an independent onlooker.

                                  You have a nasty habit of stripping context. You wrote that because I had said you were wrong about something you had the right to say that I was wrong too. I pointed out that someone saying 5+5=7 doesn't get to say someone else's arithmetic is wrong just because they point out yours is. I then went on - and this is quite important - to show quite undeniably that your "proof" was factually wrong (you claimed there were no modern terminals for Powershell) and that the converse was not true (you entirely skipped over my evidence for what I had wrote). Instead of engaging with many of my actual arguments, you have resorted to claiming there's something wrong with the manner I debate or that I'm "diminishing" you. Your own repeated skipping over many of my points and claiming that I don't know what I'm talking about do that.

                                  >>"TheVogon was again using some cryptic language, I was making remarks on that."

                                  Honestly, I understood what they wrote and if you hadn't understood something on their fifteen item list the best response is to ask for clarification. Your accusations of my "tone" are winding me up so here is there list: Post. I've just looked it over and they explain all of their points. I would like to know which on there you found difficult to understand.

                                  >>"If he/she suggested how I could protect the signature from being compromised after I offered to install as a system utility, I simply said that you would be done with the whole system"

                                  This is simply explained. You know how packages you download from a repository on any GNU/Linux distro are signed? Similar thing. You don't say signing those packages is useless because if someone had compromised the entire system they could find a way around that. Same deal with Powershell scripts.

                                  Because Powershell scripts are common and widely shared (scripting is a popular part of managing Windows Server these days), there's a need for signing of scripts. You download Utility X, the signature guarantees that it is indeed from the publisher you think it is. And if somehow an attacker altered a script on your system (you're partially compromised), then the system will detect that and prevent it running. As you can see, it is useful. GNU/Linux doesn't quite have the same enterprise culture of script sharing - you tend to type in something you're looking for, find a script online somewhere that looks like it does what you want (or is close) and copy-paste it from the webpage to your system.

                                  In response to your trying to make an equivalent case for script-signing on GNU/Linux, yes, you could write a wrapper script that checked signatures. It wouldn't by itself stop people bypassing that script, altering the wrapper script (as you yourself point out); and quite frankly it's work, there's no culture of doing this (do you see many organizations publishing signed Bash scripts?) and it's just simply not done. On Windows, this is automatic, baked in and pretty much invisible to the user.

                                  Yes, if someone completely compromises your system, they could interfere with this process. Like signed packages from your distro, that doesn't make it useless. True, for ultimate security you need some way of verifying everything right from the boot stack. I don't know how that could possibly be done but you're right it's a valid security concern. If I found a way around it, I would definitely implement it. I would probably call it something like... "Secure Boot". It just seems that would be a good name for it, for some reason.

                                  >>"Or when it was pointed out how portable and universal S, it can be used for no less than 2 systems! I pointed out it was a joke on potability. Again it was an attack...."

                                  Actually, take a look - the first use of the word "portable" in this thread is yours. Yes it was an attack - you were the one who raised it and used it as a way putting down Powershell. Seriously - go to the first page and search for "portable". It's your post right there. And you did it again in response to Vogon's comment here:

                                  >>"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"

                                  That's not claiming you can run it on GNU/Linux, it's pointing out how cool it is that the OO nature of Powershell lets components expose themselves in neatly integrated ways - such as SQL Server representing itself as a navigable drive (I did not know that, btw. I think it's cool).

                                  As others have pointed out, because Windows is structured in a very OO manner and GNU/Linux is not, it makes Powershell a bad fit for GNU/Linux and Bash non-optimum on Windows (it can't use the power of Windows objects). The only one who raised portability as an assessment criteria was you, and you did so as an attack. That's why people call you on it.

                                  >>You're forgetting that the final was

                                  find . -printf "%u\n" | sort -u

                                  No I'm not. I'm not sure if you're being wilfully obtuse or genuinely don't get why that's not conducive to an illustration of the differences between pipelining in Bash and Powershell. I've gone into this in detail three times already. You've not replied or disagreed with any of the reasons I gave exaplaining this so there's no point in my simply spending my time typing it all out a fourth time. Others have also explained. I can write a program (on Windows or GNU/Linux) that will do the above in a single command with no switches and no piping. It would prove nothing. Seriously, don't respond to this - respond to the earlier times where I explained this fully. Anything else is just trying to avoid the real points in favour of a quick summary.

                                  >>"I also offered AWK because you seemed fixated on AWK in the original post I was responding to and used redundant grep filtering"

                                  I am the one fixated on awk? :o You keep again and again and again making ad homiem attacks, accusing me of "blunders" and such because I write this:

                                  >>find ./ -exec ls -l {} \; | awk '{print $3}' | grep . | sort -u

                                  instead of

                                  >>find . -printf "%u\n" | awk '!match(str," "$1){str=str" "$1;print $1 }'

                                  Can you genuinely not even see how to most people, the version I wrote is cleaner and more understandable? I was comparing complexity in Powershell vs. Bash and I picked the easiest to understand format of Bash pipelining I could. Again, you really want to compare these for your argument about pipelining?

                                  DIR -Recurse | Get-Acl | Select-Object Owner | Select -Unique (Powershell)

                                  find . -printf "%u\n" | awk '!match(str," "$1){str=str" "$1;print $1 }' (Bash)

                                  You're your own worst enemy. But regardless, stop attacking me for using a more readable piece of code. I think in your head you're running some version of "they're being dishonest - they're doing it with more pipes than they have to". I've explained three times why your mental loop is wrong. Go back and actually respond to my explanations if you disagree.

                                  And yes, I'm well aware you actually want to compare to your macro version that does it all in find. Again, I and others have explained why that doesn't prove anything about Bash vs. Powershell pipelining. You claimed that being able to pipeline objects isn't significant. Finding a dedicated program that macros the specific example I gave and lets you avoid using Bash pipes doesn't support that.

                                  >>"No I don't, I never said that, I only likened PS cmd-lets to Bash built-ins, get it now?"

                                  In a word, 'no'. You said "All those maybe even good properties of PS are what is built-in for Bash"

                                  I pointed out that find is a program, not an intrinsic part of Bash that is "built in". I didn't think your argument made any sense because you seemed to be confusing GNU Utils with Bash and possibly cmdlets with Powershell. If you're likening cmdlets to GNU-Utils, I'm afraid I don't see your point.

                                  >>"Please show me it with example, since his example was not very convincing."

                                  I'll correct you on two points. It was convincing and it's "her example". The latter doesn't really matter but I dislike the presumption that anyone technical is male and seeing as my non-guy status was metioned earlier in this thread already, I might as well correct you.

                                  1. eulampios

                                    @h4rmony

                                    I am sorry mam, but your pedantic tone is not bearable to me. Most of your post is dedicated to teaching me and telling me how I was wrong and you're right all the way. (I am a teacher myself and this is not my pedagogical method.) This is how our discussions usually end. Unlike Uffe's posts, yours are felt pretty "ad hominem" to me.

                                    I beg your pardon, but I cannot continue in that manner.

                                    All the best.

                                    1. Uffe Seerup

                                      Debate

                                      I am sorry mam, but your pedantic tone is not bearable to me. Most of your post is dedicated to teaching me and telling me how I was wrong and you're right all the way.

                                      Please do not take this the wrong way, but that seems pretty ad-hominem to me.

                                      You have been arguing the relative merits of PowerShell and Bash from a point where you even admit that you do not know PowerShell. In that setting you should expect that opponents will try to teach you about it.

                                      For me, I thank both you and H4rmony for the debate. :-).

                                      @H4rmony: May I save the link with your take on ACLs for future use? It is precise my sentiment, but I could never explain it as elegant as that!

                                      All the best

                                      1. h4rm0ny

                                        Re: Debate

                                        >>"@H4rmony: May I save the link with your take on ACLs for future use? It is precise my sentiment, but I could never explain it as elegant as that!"

                                        Well by all means. Copy and paste it if you wish, but only if you promise to correct any misaprehensions on it as I strongly suspect you know more about this area than I do! It was the result of my teaching myself ACLs and is written from the perspective of someone who grew up on UNIX. I'm also a programmer by training, not a sysadmin, so it's all from an enthusiastic amateur position.

                                        And thank you for your posts - I've learned a number of very cool things here. Really appreciate your posts.

                                      2. eulampios

                                        @Uffe Seerup, about my point

                                        Please do not take this the wrong way, but that seems pretty ad-hominem to me.

                                        I hope, I won't, I don't see how you can contribute this in this way though. I felt offended by the tone of h4rmony's. It wasn't the first time it happened to our discussions. 'ad hominem' is what I would describe this ( I wasn't the first to use this Latin term though). It's not a kind of pedantism where "things are pointed out for you ", it's rather when "they are pointed out at you" . Bash, PS or even MS don't have to do with that.

                                        Yes I do not know PS, yet I seem to know a little about the GNU utils, enough to find and point at a few issues others have. Here is a fact, I didn't feel your "pedantic tone" to be insulting the same way, in contrast.

                                        Most of us are anonymous here. I didn't bear insults and swearing at my mom as the user dogged did once to me. I told him, that this is cowardly and if that would be in person, he would be dealt with in manly manner with a physical involvement of both of us. So some of us would end up kicking the the other one's arse.

                                        At least, I am thankful to h4rmony for being formally polite and never swearing at me.

                                    2. h4rm0ny

                                      Re: @h4rmony

                                      >>I am sorry mam, but your pedantic tone is not bearable to me. Most of your post is dedicated to teaching me and telling me how I was wrong and you're right all the way. (I am a teacher myself and this is not my pedagogical method.) This is how our discussions usually end. Unlike Uffe's posts, yours are felt pretty "ad hominem" to me.

                                      I don't believe I made any ad hominems. The closest I believe I came was observing that you have no experience with Powershell, which you admit. And I asked you about that because you were pronouncing quite confidently on Powershell's weaknesses in many ways that proved false.

                                      >>I beg your pardon, but I cannot continue in that manner.

                                      That's your privilege. But this was a topic on finding a better Powershell terminal and said nothing about Bash's quality one way or another. You entered the topic making many statements about Powershells' inferiority and if you feel that my tone has been that of someone trying to correct you or teach you, I point out that someone who has no experience of Powershell at all trying to argue about it, is almost certainly going to end up in that position.

                                      Whilst I respect your choice not to engage in dialogue with me further, this is a public forum and if you post something which I think is misinformation, I don't have any compunction about not replying to you. You may continue to discuss with me or not as you please.

                                3. h4rm0ny

                                  Re: @h4rmony

                                  I withdrew my initial post - a full on discussion of Windows ACLs is way off-topic. So I'm just going to respond to the below with a quick comment and a link to a previous discussion.

                                  >>>>Windows has true first-class ACLs. (ACLs were added later on *nix, and is still not fully integrated - e.g. there is no "octal" representation).

                                  >>First, MS Windows didn't have file permissions at all, remember that time, thus fat32 and earlier filesystems still don't have proper file permissions. The *nix systems had it from day one. Second, what's first-class citizen, what is third-class? Please clarify.

                                  Firstly, yes, we all remember XP. At the time, I was using SuSE and enjoyed taking the piss out of Windows security. That has changed. XP, and OS from over a decade ago, has no relevance to this discussion. In fact, if you find yourself resorting to referencing XP in attacks on Windows security, it's a sign you're unable to recognize the world has changed.

                                  I've already done the ACL discussion here recently, but here is my response to someone else who questioned why ACLs on Windows were better than the GNU/Linux system.

                                  Windows ACLs vs. UNIX permissions

        2. Sil

          Re: bash

          Because text is more universal than any (other) object, plus it's much more human-readable.

          Text is universal as long as you use ascii for english languages.

          Other than that it is full of traps and difficulties, even for languages with few additional characters.

        3. Uffe Seerup

          Re: bash

          Because text is more universal than any (other) object

          Really? How do you describe an object graph (like a tree or a network) using text?

          1. eulampios

            @Uffe

            Sorry I can't answer to all of your very prolific posts.

            As far as the text concerned, according to the fathers of Unix (whose ideas are widely adopted now by computer scientists around the world and even by MS)

            1) Text is universal, we use it everyday

            2) it's human readable, it is easier to understand

            Even if MS model differs from it, you still live in a little different world with worldwide web and html, xml, text and numeric data etc

          2. eulampios

            @Uffe

            Really? How do you describe an object graph (like a tree or a network) using text?

            Hah? Is it a graph theory you're talking about? I am a Math professor and coincidentally I am teaching a course that has some graph theory in it :)

            Well, xml is one way. LaTeX got that too (with package tikz, please see this discussion), for computations and graphing I use also maxima as a CAS (that has an a LaTeX output as well)

            Yes it's all text, which I can parse with awk, sed and perl according my own taste. I believe though that it would a problem to achieve just that using bare PS . I also use these tools to make nice drawings of regions for my Calculus III students a lot (with my dirty and fast tool pari-gp). It really helps to have a nice illustration for regions you have to imagine when you need to , say, switch from a double or triple integral over a region or a solid, respe., to arrive at an iterated one.

          3. Anonymous Coward
            Anonymous Coward

            Re: bash

            "How do you describe an object graph (like a tree or a network) using text?"

            You've never seen a mathematical concept expressed using text? I'm told many a computer language is written using text.

            1. h4rm0ny

              Re: bash

              >>"You've never seen a mathematical concept expressed using text? I'm told many a computer language is written using text."

              Yes. And then compiled into something more efficient.

      2. Roo

        Re: jpsoft

        "How about because you can't pass objects in bash, just a bunch of text. You can do a lot more in Powershell, but bash still has it's place too."

        Horses for courses, use C# for messing with objects and bash for scripts... It's not hard.

      3. TheVogon

        Re: jpsoft

        Reasons to use Powershell over BASH, etc.

        1) Object oriented pipes so that I don't have to format and reparse and be concerned about language settings.

        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.

        1. h4rm0ny
          Pint

          @TheVogon

          Thank you for that. I didn't know half of the things on that list and now I have a lot more things to look into and learn! It's a cliché I avoid, but if I could mod your post up several times, I would. I can definitely think of a use for number 9 right now. (PWA). Cheers!

        2. eulampios

          Questionable reason to use powershell over bash. Part I

          Modularity, portability and long history of POSIX shells as well the peculiar choice of architecture (as a shell + independent utilities), while Powershell is an ad-hoc, non portable solution, are the main disadvantages of PS.

          1) makes it more complex and less "shelly", which is a glue, an envelop, less human-readable and more complex. Objects that are not a universal standard as POSIX, they are not as human-readable, portable between systems, like a text object, hence an extra complexity.

          2) "type coercion", what the hell? It's not a shell then.

          explain the parameters/syntax, allowing

          Run "man [number] command" or "info command" then navigate with less utility within (or the Emacs usual UI) which you can search (even using a POSIX regex syntax)

          4) Multiple location types and -providers. Even a SQL Serve

          An ad-hoc MS-only , non-portable stuff, it won't work with PostgreSQL server for me, right, I'd have to use the normal tool, like psql anyways.

          5) Execute the same script transparently and *robustly* on multiple servers and consolidate the results back on the controlling console

          It shouldn't be an in-built feature, in my opinion. Try ssh, or GNU parallel for that matter for many POSIX shells, not only GNU Bash. There is also the GNU Screen utility. Does Powershell let you control the actual number of cores on a certain machine for specific tasks, scripts, for example, GNU parallel can. You can set the resources limit for a shell? On any shell there is ulimit and cpulimit utilities for this. There is also a an emacs utility called tramp that might let you do some of it and even more never leaving your emacs session (where you could laso use PS as your shell, BTW).

          Try "parallel --sshlogin host1,host2,host3 'top -n1'" to do a similar thing, e.g.

          6) ..suspendable, resumable and which can pick up and continue even across system restarts..

          a) "kill -STOP process_pid" or "killall -STOP cmd_name" and then "killall -CONT pid" to resume it.

          b) There is also GNU Screen or/and a good ol' Unix ps utility, nohup etc

          To be Cont'd

          1. Anonymous Coward
            Anonymous Coward

            Re: Questionable reason to use powershell over bash. Part I

            "Powershell is an ad-hoc, non portable solution, are the main disadvantages of PS."

            It seems to work perfectly well to manage all of my VMware vSphere servers. So clearly it is portable.

            Also I have to say Powershell is WAY less ad-hoc and far more uniform and organised than using BASH or similar.

            "1) makes it more complex"

            No - it makes it way simpler and more consistent to use.

            "Objects that are not a universal standard as POSIX"

            POSIX doesn't support objects AT ALL.

            "they are not as human-readable, portable between systems, like a text object"

            Objects can be all of those things or none of them - you have THE CHOICE.

            "hence an extra complexity."

            It is pretty much universally acknowledged that object orientation makes programming simpler.

            ""type coercion", what the hell? It's not a shell then."

            By what definition? I don't think that many people would dispute that it is a Shell type environment.

          2. eulampios

            Questionable reason to use powershell over bash. Part II

            7) Parallel scripting. No, not just starting multiple processes, but having the actual *script* branch out and run massively parallel.

            If it's not an ad bullshit, and you do mean parallelizing tasks, than it's awesome, however, it always has limitations, plus with parallel and some ad-hoc tools you can parallelize tasks inside your scripts with Bash as well.

            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.

            Again, depends on the goal you're trying to accomplish, tramp-mode (in GNU Emacs), GNU Parallel and/or GNU Screen come to my mind.

            9) PowerShell web access.

            What the hell is that, what for?

            You can now set up a IIS with PWA as a gateway.

            So, again, no Nginx, nor Apache. Next one, please.

            This gives you a firewall-friendly remote command line in any standards compliant browser.

            Sounds very fishy and insecure to me.

            10) Superior security features, e.g. script signing, memory encryption..

            "Memory encryption" sounds redundant, did you turn off ASLR? What precludes you from signing or encrypting a Bash script? You can also automate it by writing an easy bash function to check for a signature and execute a script, you can package every script or a number of them inside the Debian/RedHat or other package container with signatures to install it system-wide.

            11) Do that in bash?

            Do what again, an explanation is required, if you don't mean quantum theory.

            12) Strongly typed stripting, extensive data types,

            Why not scripting in C then?

            e.g first class xml support and regex support right in the shell.

            What kind of regex is there, BTW? Is it as good and efficient as in grep, sed, awk or perl? No, it won't. Someone wrote that by default PS tries to read the data in memory, unless you use some non obvious and ugly syntax to do ti the right way.

            14) Instrumentation, extensive tracing, transcript and *source level* debugging of scripts.

            Of course, it needs a lot of debugging thanks to its complexity.

            The main thing is though, how PS compares with Bash and other shells in usability, ease and power as shell, an envelop between utilities and processes? That is the real question.

            1. TheVogon

              Re: Questionable reason to use powershell over bash. Part II

              Not even worth replying to most of these - for many of the points you clearly don't fully understand the concepts and for the others your comments are laughably weak. Here are just a few worth noting:

              "An ad-hoc MS-only , non-portable stuff, it won't work with PostgreSQL server for me, "

              Highly structured - very portable (for instance vSphere) and it WILL work with PostgreSQL - for instance see https://github.com/palpha/Simple-PostgreSQL-module-for-PowerShell

              ""kill -STOP process_pid" or "killall -STOP cmd_name" and then "killall -CONT pid" to resume it."

              Won't survive a reboot....

              "You can also automate it by writing an easy bash function to check for a signature"

              So how do you check the signature checking function is not compromised AT RUNTIME before it runs?

              "with parallel and some ad-hoc tools you can parallelize tasks inside your scripts with Bash as well."

              With Bash you can only execute multiple things at once on a specific script task / line - by using third party tools. Powershell supports true multipath branching and parallel running WITHIN the script

              "So, again, no Nginx, nor Apache....Sounds very fishy and insecure to me.

              Both of those have had recent security vulnerabilities patched. IIS hasn't had a single hole in at least the last year, and has a much lower total vulnerability count over the last decade than Apache.

              1. eulampios

                @TheVogon

                Not even worth replying to most of these

                Same was with you, although, I did respond to yours in a polite manner. Maybe I shouldn't have. GNU Parallel

                Highly structured - very portable (for instance vSphere) and it

                It's a joke right, or what else, what about FreeBSD, GNU Linux, Mac OS X (just from the top of my head)

                With Bash you can only execute multiple things at once on a specific script task / line - by using third party tools.

                "3-d party" is a swear word in the MS world, we know this.

                Both of those have had recent security vulnerabilities patched

                Okay, the whole Microsoft infrastructure has had a huge number of security shortcomings and flaws. Virus and anti-viruses exist only in this world.

                So how do you check the signature checking function is not compromised AT RUNTIME before it runs?

                Run it as a system utility, and be done with it, mon amie.

                1. Anonymous Coward
                  Anonymous Coward

                  Re: @TheVogon

                  "It's a joke right, or what else, what about FreeBSD, GNU Linux, Mac OS X (just from the top of my head)"

                  For those you can use PASH - http://pash.sourceforge.net/

                  "Okay, the whole Microsoft infrastructure has had a huge number of security shortcomings and flaws."

                  Far fewer than in any mainstream commercial Linux distribution like SUSE or Redhat. The Linux kernel alone has had more vulnerabiities than any Microsoft OS. They underlying Microsoft security model is actually much stronger with features like proper constrained delegation and not having to run everything via SUDO (which must execute as root / UID0)

                  "Virus and anti-viruses exist only in this world."

                  Take a look at a Linux based client OS that people actually use interatively like Android for instance. Malware everywhere.

                  "Run it as a system utility"

                  Right - so say I compromise your signature checking script - and anything else I want to - running it as a system utility doesnt mitigate that. Or if you mean run a 3rd party signature checking utility - then you can't do it in BASH - QED.. Powershell won't execute a script at all if a signed script has been modified. No need for bolt ons.

                  1. Uffe Seerup

                    PASH @TheVogon

                    Pash hasn't been updated since 2008 where it stalled. It is a defunct project.

                    PowerShell would not be a good for Unix/Linux anyway. Unix/Linux does not expose management interfaces in an object model that could be used by PowerShell.

                    For Linux/Unix, Bash is still the way to go.

                  2. eulampios
                    WTF?

                    Re: @TheVogon

                    Right - so say I compromise your signature checking script - and anything else I want to - running it as a system utility doesnt mitigate that.

                    You then can compromise everything, can't you? All libs and the system are already compromised, what's the point in anything else, and you're saying that a Windows admin cannot change the public key(s) of the signature you trust? And if a key of the signature changes, how do you make change in the PS script utility?

                    Take a look at a Linux based client OS that people actually use interatively like Android for instance. Malware everywhere.

                    That's viruses vs installable trojans. Malware that no one had ever seen installed by users? There is no statistics of how much malware gets actually installed on Android systems. You talk about trojans that users install by themselves, where statistics exists only to show how much is available, not how much is used. And also doesn't have to do with vulnerabilities you're talking about. Android got a much better mechanism to mitigate the same threat every Windows user has for trojans too, a centralized shop (win8 got it too now but after Google, Apple and others) and a sophisticated permissions system for apps. Permissions are transparent to a user.

                    Again, I will have to know yet a single Android user to have installed at least one malware, pretty much every Windows user I know, on the other hand, had experienced a malware at one point.

            2. Uffe Seerup

              Re: Questionable reason to use powershell over bash. Part II

              If it's not an ad bullshit, and you do mean parallelizing tasks, than it's awesome, however, it always has limitations, plus with parallel and some ad-hoc tools you can parallelize tasks inside your scripts with Bash as well.

              Interesting. So Bash parallel execution allows the parallel parts of the scripts to run in the same environment, having read/write access to the same shell variables and synchronization mechanisms?

              Again, depends on the goal you're trying to accomplish, tramp-mode (in GNU Emacs), GNU Parallel and/or GNU Screen come to my mind.

              Hmm. In Powershell you can *script* multiple remote sessions. For example you can start by opening sessions to 50 hosts. Each host will be a "session". You can now execute commands on each individual session while the state within each session os carried over from command to command, and the result of the command (success code) marshalled back to the controlling console. Which means the the controlling script can exert control over each individual command executed on the remote hosts. This is not just piping a script over to be executed and having the final result reported back. This is about having fine-grained control over each command executed remotely - as part of a script.

              And yes - if you execute commands in parallel using the Invoke-Command cmdlet (alias icm) you can control how many parallel executions you want.

              9) PowerShell web access.

              What the hell is that, what for?

              For remote control using a well-known and firewall-friendly protocol (https).

              Sounds very fishy and insecure to me.

              Yeah well. Any time you open up your infrastructure to the outside world, it incurs a certain amount of risk. See it as an alternative to OpenSSH, only you can integrate with web based authentication mechanisms and minimize the different authentication mechanisms, assuming that you already has a web security regime in place. So, do you open open an SSH port or simply PWA on an existing administrative or intra-corporate website? PWA defaults to "no access" and must be configured to allow PWA to use PowerShell remoting to the internal hosts. The commands/modules available and access levels allowed can be configured as well.

              10) Superior security features, e.g. script signing, memory encryption..

              "Memory encryption" sounds redundant, did you turn off ASLR?

              Memory encrypting in PowerShell is used to ensure that sensitive data - such as passwords and private keys - are stored encrypted in memory. This has nothing to do with ASLR. ASLR is *not* encryption (where did you get that idea?).

              Heartbleed demonstrated what can happen to passwords and privatekeys stored unencrypted in memory. When you read a password/private key through the Read-Host -AsSecureString cmdlet or similar, the password/private key is read and encrypted character-by-character and is *never* stored in cleartext in memory. The encryption is based on the data-protection API (DPAPI) ensuring that not even an administrator using a tool to scan the memory will be able to decrypt the password. There are lots of ways passwords in memory can bleed out. Heartbleed demonstrated one (nasty) way. Other channels are backups, swap files, memory dumps etc.

              What precludes you from signing or encrypting a Bash script? You can also automate it by writing an easy bash function to check for a signature and execute a script, you can package every script or a number of them inside the Debian/RedHat or other package container with signatures to install it system-wide.

              In PowerShell this is built-in security, and the default level is quite restrictive. And it can be controlled through group policies, making it trivial to enforce policies about e.g. script signing across an entire organization. Sure you can build *something* with bash, but how do you *enforce* it?

              How do you sign a bash script, btw?

              Correct me if I am wrong, but I had the impression that Debian/RedHat package container signatures were only check when *installing* the package. PowerShell script signing is used to ensure that scripts executing on a computer has been approved by some authority and has not been tampered with.

              Furthermore, the script execution policies can block scripts obtained through browsers/mail clients/instant messengers etc. or e.g. scripts copied from a non-intranet zone. Files obtained through such channels are "tainted" with the origin, and powershell can be set to disallow execution of such scripts. This is a level of protection against phishing.

              11) Do that in bash?

              Do what again, an explanation is required, if you don't mean quantum theory.

              I think he was referring to using a browser to connect to a command prompt and typing commands/running scripts with intellisense support - right in the browser.

              12) Strongly typed stripting, extensive data types,

              Why not scripting in C then?

              Because C is not script friendly. C is not type-safe. C's scope rules interferes with REPLs.

              "e.g first class xml support and regex support right in the shell."

              What kind of regex is there, BTW? Is it as good and efficient as in grep, sed, awk or perl?

              Yes. It is even better. While it is the "perl" variant it even allows some nice tricks to support e.g. parenthesis balancing (matching only properly balanced open-close parenthesis). PowerShell/.NET regexes are is *very* efficient. Actually the .NET regex engine supports compiling regex'es all the way to machine code.

              No, it won't. Someone wrote that by default PS tries to read the data in memory, unless you use some non obvious and ugly syntax to do ti the right way.

              I assume you are referring to how PowerShell process pipelines of objects? PowerShell actually *does* process objects in a progressive manner - "pulling" each result object through the pipeline one at a time. So if that was what you were referring to, you are wrong (although *some* cmdlets like e.g. sort *will* collect all objects before starting to produce output).

              14) Instrumentation, extensive tracing, transcript and *source level* debugging of scripts.

              Of course, it needs a lot of debugging thanks to its complexity.

              If you develop scripts for any type of automation, you will appreciate debugging capabilities. This sounds rather like a case of sour grapes.

              The main thing is though, how PS compares with Bash and other shells in usability, ease and power as shell, an envelop between utilities and processes? That is the real question.

              To each their own. Bash robust and well established. But it is not without quirks. To someone well versed in Bash, the concepts of PowerShell can be daunting. You will be challenged on "wisdom" you simply accepted as facts before. In my experience, the hardest part for "bashers" to get about PowerShell is how it was made for objects and APIs instead of text files.

    2. poohbear

      Re: jpsoft

      Way back when I was still on DOS I used 4DOS which was bl**dy brilliant. I presume their current product is all new and improved like many washing powders, you should certainly take a look....

      http://jpsoft.com/

    3. h4rm0ny

      Re: jpsoft

      >>"On the third hand ... why not just use bash by installing cygwin? Perhaps with the jpsoft command window."

      Well, several reasons. I haven't used Cygwin in years. It was pretty clunky then though I'm sure it's better now. But I would prefer to use the native approaches just because these will be better integrated with the OS. For example, there are a wealth of cmdlets out there I want to use. For example, I've been playing with Storage Spaces on Windows 8 (with a mix of good and bad results, but that's a tangent). I can configure and manage these with the cmdlets in Powershell. With a ported Bash environment, I don't think that I can.

      Also, it's about learning something new. As I said, I've been using Bash for over a decade (an vi too, which means I'm about half way through learning all the shortcuts ;) and I'm interested to see what Powershell can do. For example, I can pipeline objects in Powershell which is absolutely great. It's not just about creating directories and being able to grep through files. Which is why I didn't really look at Cygwin. I kind of want to be bi-OS properly as I really like both.

      Anyway, tangent - I never expected this to appear on the main page. I posted it in the user forums a while back but I'm gratified by all the replies here!

    4. Guido Brunetti
      Holmes

      Re: Why not use jpsoft / bash

      Because PowerShell (incl. ISE) is installed on every recent Windows system by default and bash isn't :-)

      Because on a recent Windows Server you can script every single server function with it, which you can't do with any other shell.

      Because a lot of server software nowadays comes with it's own PowerShell provider plug-in, which makes scripting this component (Exchange, SQL Server, ...) a whole lot easier.

    5. Anonymous Coward
      Anonymous Coward

      Re: jpsoft

      If you really must use a legacy shell type environment, then just install Services for UNIX from Add / Remove Windows features. It gives you a choice of a couple of shells.

      Powershell is way more powerful though.

    6. Anonymous Coward
      Anonymous Coward

      Re: jpsoft

      Ask yourself why VMWare switched from remote administration via a UNIX type shell to using Powershell for vSphere.....

    7. Anonymous Coward
      Anonymous Coward

      Re: jpsoft

      Every server that I've ever seen Cygwin installed on has slowed to a snails crawl and crashed randomly.

      As soon as you uninstall Cygwin it starts working properly again and rarely if ever crashes.

      I say this as a developer/sysadmin with 16 years experience in a Windows/Linux environment.

      Don't get me wrong - I love Linux and like the idea of having a Linux type shell in Windows, but each environment is designed for difference use cases, and you can't really mix the two.

      1. Anonymous Coward
        Anonymous Coward

        Re: jpsoft

        "you can't really mix the two."

        Use Services for UNIX (part of Windows). It just works.

      2. swampdog

        Re: jpsoft

        "Every server that I've ever seen Cygwin installed on has slowed to a snails crawl and crashed randomly."

        That's a bit sweeping. Must be some component of it. After all, it does *nothing* by default after installation. There isn't even anything running in the background until such time as you elect to configure daemons.

        "I say this as a developer/sysadmin with 16 years experience in a Windows/Linux environment."

        I reckon you've been installing it wrong for 16 years then!

        1) Install it into its own partition (*).

        2) Override the PATH so it cannot see windows and check TMP=/tmp/ is in (1). (**)

        3) Make sure there's only ever a single cygwin DLL on the system. (***)

        (*) or the filesystem will fragment to hell. It's windows not a unix filesystem. NTFS cannot cope.

        (**) ditto

        (***) 3rd party apps are known to silently install their own version.

  2. Anonymous Coward
    Anonymous Coward

    http://www.quest.com/powergui-freeware/

    1. beep54
      Pint

      Dell?? Yr kidding!!!?? Looks interesting tho. My guess is that lot's of people haven't explored Powershell to know what it is actually capable of. Me? I think it is a bit weird, but that seems fitting for an MS thingy. Beer simply for having an interesting link.

      1. KeyTech

        Re: Dell?? Yr kidding!!!??

        PowerGUI is very good. Don't be put off by the Dell branding. Quest is/was the maker of (amongst other things) Litespeed, the defacto sql server backup solution. They were acquired by Dell a couple of years ago. Give it a go, you won't be disappointed. What's more, it doesn't cost a bean so you've nothing to lose.

        1. Youngdog

          Re: Dell?? Yr kidding!!!??

          PowerGUI is great for scripting and debugging but the version I use doesn't have any new features for the command window - clicking on the button just launches the Windows native shell

  3. Guido Brunetti
    Thumb Up

    Just use Powershell ISE

    Installed automatically with Powershell 2.0 and upwards.

    http://technet.microsoft.com/en-gb/library/dd315244.aspx

  4. Nate Amsden

    cygwin

    though a looooooooooong time ago I used to use 4DOS/4NT.

    I hate powershell myself, the object oriented-ness of the whole thing. I prefer working with strings(linux scripting) rather than objects. It's what I'm used to, I have no interest and see no value for myself in going down the object oriented route. Though the way windows operates perhaps objects is the only way.

    disclaimer of course I don't do any scripting that interacts with windows itself, my usage of cygwin is to do linux-like things on windows.

  5. 1Rafayal

    I also suggest the ISE. The version with powershell 3 is even better.

    For a full on scripting IDE, take a look at powershell studio

    1. Phil W

      I concur. Powershell ISE is extremely useful it's the best way to write Powershell scripts.

      1. h4rm0ny
        Pint

        >>"I concur. Powershell ISE is extremely useful it's the best way to write Powershell scripts."

        Someone directed me to this after the original forum post. It's incomparably better than the default terminal and I was learning Powershell for a while without even knowing it was there! They really should make it the default. I love the way that it has a searchable list of cmdlets docked by default that shows all the parameters and definitions. It's like having a permanent man page easily accessible and waiting.

        Minor annoyance - I wish they'd make it so that double-clicking on a cmdlet performed the Insert action. It just feels like it should. More significant annoyance - no history between sessions. Though I can see that as a supportable design decision for security, I'm used to it on Bash.

        Thanks for the response, btw.

  6. not_equal_to_null

    what about...

    How about LINQPad - I use it for all of my little scripts, as it gives me all of .NET, without the bloat of Visual Studio.

    You can make things as simple or as complex as you need, and can choose from VB, C# or F#.

    It *is* still object oriented (again, you don't have to jump in with both barrels), but once you get your head around oop, you'll wonder how you ever did anything any other way ^_^

    1. Spender

      Re: what about...

      LinqPad gets my vote. It's the only software I've ever purchased that hasn't left me feeling shortchanged in some way or another.

  7. T. F. M. Reader Silver badge

    Cygwin

    Can't imagine a usable Windows system without it. Or without X that comes with it. Or without the multitude of familiar tools (bash being the first). Compared to the usual Linux/UNIX environment it has its quirks, but those can be forgiven.

    1. Steve Button

      Re: Cygwin

      > Cygwin?

      Did you actually read any of the original question at all? It's not very long, go back and read it and when you're done come back, I'll still be here.

      Back so soon? OK, Cygwin is great for doing bashy things in Windows and I use it a lot. But if I want to shut down a bunch of VM's or take snapshots or interact with Active Directory I wouldn't dream of doing it in bash. I might do it in Perl if I fancied a challenge.

      All of these problems with the PowerShell DOS box I've experienced myself, and a decent GUI would go a long way. Now, if you could get the Powershell DOS box to behave like the Cygwin DOS box (that's all it is really?) then that would be useful.

      1. Charles Manning

        Can't you mix them?

        If you're "thiking *nix" you think of using a bunch of different tools together, hooked together with some bash scripting. Different languages/tools are optimised to do different things.

        For example, bash might do the top level scripting, but call awk, sed, perl, python,... to do specific functions.

        Can't you do the same with Powershell? Use Powershell for what it is good at and use bash etc for the top-level console scripting.

        1. foxyshadis

          Re: Can't you mix them?

          Sure, Powershell can be used purely as a drop-in replacement for Perl, but the only reason you use Bash everywhere is because it's everywhere, but so is Powershell in Windows. Leave the Bash/Perl/awk/sed ghetto behind, there are enough scripting languages that make doing everything from top to bottom simple now.

          1. Roo

            Re: Can't you mix them?

            "but the only reason you use Bash everywhere is because it's everywhere"

            Speak for yourself. It has other advantages beyond portability and seamless integration with the old school utils (sed/awk/test etc)... Stuff like the shell & utils being very well tested, *extremely* reliable and well understood count for a lot.

            I also find that the conventions, culture & tools around Bourne style shells make working in the pipelined style much easier than the majority of other alternatives I've tried. Case in point, I wanted to process some files line by line in PowerShell, all the examples I found read the entire input file into memory before processing. Eventually I found that I could make it process stuff line by line using some obscure & ugly syntax, but the whole culture around PS & the syntax itself made it awkward to do it the efficient way.

            I frequently work with datasets that vastly exceed the memory capacity of the host, so tools that make pipe-lining simple & efficient are a big win. While folks will argue that few people need that capability, the fact is with Bash you have that capability with no effort and at no extra cost.

          2. Anonymous Coward
            Anonymous Coward

            Re: Can't you mix them?

            [B]"Powershell can be used purely as a drop-in replacement for Perl"[/B]

            Having tried to do this (and succeeded) I can say that it's not a patch on perl. The regex handling alone is utterly inferior, it doesn't have the scoping constructs and arrays quickly become chaotic. Even when the thing is running from a scheduled task there's still a concept of a terminal width, which has to be configured at every script, creating custom objects is a right old faff, there's no equivalent to perl's "use strict" forcing explicit variable declaration (no serious perl people would ever leave that out) and there's a problem redirecting stderr.

            The big plus points are access to .Net's class library, which is good and it's already installed for the most part - which perl isn't on windows and installing third party tools can be bureaucratic in many environments.

            It's a shame it's still not really good enough. So near and yet so far.

    2. h3

      Re: Cygwin

      Cygwin is garbage anyway. If you need something similar then use UWIN it is much much better.

      Cygwin is a total mess.

      (Not saying this is what the article creator should use but people who otherwise would use Cygwin should use UWIN.)

  8. Anonymous Coward
    Anonymous Coward

    Powershell? Arrrggggghhhhhh

    MS broke the way you could invoke a powershell script from a CMD window with a Patch. Then a month or so later they fixed it again. No details in the documentation about the patched, well that is now new at all.

    I find it really clunky but is seems to work after a fashion.

    The sad thing is that MS has you over a barrel if you don't install the GUI (Server 2008/12). Then you are more or less forced to use pwershell for everything.

    Welcome to 1982 people.

    1. h4rm0ny

      Re: Powershell? Arrrggggghhhhhh

      >>"The sad thing is that MS has you over a barrel if you don't install the GUI (Server 2008/12). Then you are more or less forced to use pwershell for everything."

      Genuine question - if you want the GUI, then why can't you just configure it on?

    2. Anonymous Coward
      Anonymous Coward

      Re: Powershell? Arrrggggghhhhhh

      "The sad thing is that MS has you over a barrel if you don't install the GUI (Server 2008/12). Then you are more or less forced to use pwershell for everything."

      Just install the Remote Administration Tools - and use the GUI for everything remotely.

  9. kain preacher

    it's silly

    n increasing the window width till its full size But you can get PS to full screen. Right click on the top. Chose layout go to windows size and just keep o

  10. Morten Bjoernsvik

    activestate perl

    Install activestate perl and with the ppm (perl package manager) you can install around 8000 packages for windows or build your own. It's completely integrated.

  11. seansaysthis

    Try the ISE its not too bad, its not eclipse but its pretty good to start out with.

    http://technet.microsoft.com/en-us/library/dd315244.aspx

    I tend to use use notepad++ for heavy editing cos it has some nice macro capability but the ise is good for knocking out scripts.

    If you are going to admin Windows you need to have some handle on powershell.

    if you are feeling particularly masochistic you could always configure VI to work with powershell, you loose the ability to run scripts directly but if you comfortable in vi then perhaps worth a shot

    http://juliankay.com/development/setting-up-vim-to-work-with-powershell/

    Theres also an eclipse module but I haven't used that

    http://marketplace.eclipse.org/category/free-tagging/powershell

  12. TonyJ Silver badge

    As others have said,

    The ISE isn't all that bad.

    Or take a look at Sapien Powershell Studio. http://www.sapien.com/software/powershell_studio

  13. This post has been deleted by a moderator

    1. Steve Davies 3 Silver badge

      come on, tell us what os so wrong with bash?

      I dare you?

      IMHO, it has its faults but it is far better than anything MS has to offer.

      Mind you, I spent a lot of years using DCL and that probably spoiled me for good.

      1. PC Paul

        Re: come on, tell us what os so wrong with bash?

        bash is fine.

        But on Windows, bash via cygwin or whatever just doesn't have the power it has on Linux, because Windows just doesn't work that way. Linux command line admin is all commands taking strings joined together with loops and pipes, but for Windows you need commands taking OBJECTS held together with loops and pipes. That's what Powershell gives you.

        And it was designed by Linux-y guys, so it will be more familiar to you than you think once you get into it.

        A Powershell clone would be useless for Linux, for the same reason.

        Use the right tool for the job.

        1. Roo

          Re: come on, tell us what os so wrong with bash?

          "but for Windows you need commands taking OBJECTS held together with loops and pipes. That's what Powershell gives you."

          That strikes me as a circular argument. Microsoft have intentionally chosen that route with PowerShell, they could have made it text centric if they wanted too with a bunch of lightweight utils (built in or otherwise).

          1. seansaysthis

            Re: come on, tell us what os so wrong with bash?

            I think the rationale for this was that powershell would work with .NET natively. There are some things that are easier to do in natively powershell and some things that are easier to do using older commands using exec. Yes I know your not supposed to do that but sometimes its just easier.

      2. PhilBuk

        Re: come on, tell us what os so wrong with bash?

        >Mind you, I spent a lot of years using DCL and that probably spoiled me for good.

        Did you ever work out what the /TIFY modifier did?

        Phil.

      3. Roo
        Windows

        Re: come on, tell us what os so wrong with bash?

        "Mind you, I spent a lot of years using DCL and that probably spoiled me for good."

        Granted, as a PFY with a background in AmigaDOS & MS-DOS DCL looked like the dogs bollocks, but on reflection, having spent a while working with UNIX shells, it does look pretty awful in comparison to Bourne. I am cringing right now as I recall some of the DCL scripts I had to work on/fix/write back in the day. :)

        That said the documentation that went with DCL was great - so no complaints there. :)

  14. DB_lanky

    Powershell ISE for writing scripts definitely. For day-to-day terminal based mucking around a useful free tool is ConEmu for tabbing all manner of shells, be it cygwin/powershell/cmd. It also has a full-screen/split-screen options which I find useful.

    https://code.google.com/p/conemu-maximus5/

  15. Law

    I used to use Console 2 for any command prompt and power shell work. Can set it to open to powershell automatically, and theme it, set transparency, and tab multiple windows.

    http://sourceforge.net/projects/console/

    Recently started using conemu, as it can slide down into and up out of view using shortcuts, meaning I can keep scripts running but hidden. It's nice looking too.

    http://sourceforge.net/projects/conemu/

    Nothing really rivals the proper terminal experience I get from my home machines though.

  16. Anonymous Coward
    Anonymous Coward

    Powershell ISE

    I rarely use the Powershell console, I spend most of my time in the Powershell ISE which is much better than the console. the ISE in Powershell v2 is decent, but there is huge improvements on v3 and v4.

    You may also try PowerGUI or Powershell Studio (Licenced).

  17. derp1

    console is awesome http://sourceforge.net/projects/console/

    you can plug it on cmd, powershell and cygwin.bat.

    transparency,tabs,select by lines instead of a stupid square, fully customisable, ctrl+c ctrl+v, select on highlight etc etc...

    makes the powershell experience much much better.

  18. derp1

    console

    you might want to ret console (available on sourceforge)

    It got all the features you may want (tabs, select on highlight, keyboard shortcuts transparency etc...O)

  19. Anonymous Coward
    Anonymous Coward

    Edit the properties of the PS window

    In the upper left corner of the window there's a right-click drop-down menu: the capital sigma icon. Select "properties"; that lets you edit the layout of the window, as well as turn on quickedit mode (options), which enables cut and paste with mouse buttons. Layout lets you modify the number of lines and their width. Font lets you select from a small number of fonts. Colors lets you select colors for text, background, popup text and popup background. These changes will stick until you modify them again.

  20. Guus Leeuw
    Headmaster

    Dear Harmony,

    May point out that I am at an utter loss as to why you don't know how crappy the default Powershell is? Reason being that you are "teaching yourself" Powershell, so you must have, by definition, come across Powershell when you learned it...

    Or maybe Harmony is the handle because of the three people living inside: the one who learned and can now teach, the one who needs to be taught, and the one holding the other in Harmony...

    Interesting case, nevertheless!

    Regards,

    Guus

    1. Kristian Walsh

      Helpful comment?

      Dear Guus,

      I am at an utter loss as to why you don't know what the English idiom "to teach oneself" means? Reason being that you have composed a message in grammatically-correct English whose sole purpose seems to be to insult the original poster.

  21. Anonymous Coward
    Anonymous Coward

    cygwin

    1. phuzz Silver badge
      Stop

      If I want a *nix style terminal on my windows machine, I don't install cywin, I just use Putty to SSH to a linux machine and use it there. Windows is for windows-y stuff, and Linux is for linuxy stuff, each tool has a preferred use.

  22. Anonymous Coward
    Anonymous Coward

    Advice ?

    Depending on why you are doing such a silly thing the correct answer may simply be:

    Windows >>>===>> EXIT

    Rationale: No Windows == No PowerShell == No problem

  23. jake Silver badge

    The eldist Niece reports ...

    A combination of Cygwin, windows version of perl & REXX (with a splash of ruby) does a much nicer job of admining her highschool's network than the microsoft alternative. As always, BSD on the internet facing kit, and Slackware on the internal admin boxen. Seems to work nicely, even though she swears at the school district's policy of "LCD computing".

    She's 17, graduated early, and will be off to Uni in September. She has been employed by the school district full time since the beginning of the year.

    1. h4rm0ny
      Thumb Up

      Re: The eldist Niece reports ...

      I have this funny feeling your niece's highschool are going to miss her. A lot. :)

  24. uncle.bob

    You should try to use Xterm with the Window Manager Ratpoison -> Screenshot http://www.hackers-lab.org/index.php?title=Ratpoison

    in this example I use emacs-nox in xterm ... have fun!

  25. FPfirst
    Megaphone

    Shells are Primitive

    I have never used a shell for any scripting. I go straight to the F# REPL.

    F# is a statically typed language with strong type inference so it feels like a dynamically typed language.

    You can interactively develop a script in Visual Studio where you get the full intellisense experience (and red squiggles). When done, you can run the script via the fsi.exe command line.

    1. Anonymous Coward
      Anonymous Coward

      Re: Shells are Primitive

      "I have never used a shell for any scripting. I go straight to the F# REPL."

      From http://msdn.microsoft.com/en-us/library/dd233175.aspx:

      "F# Interactive can be used to write code at the console or in a window in Visual Studio."

      So in other words... it's a shell.

  26. Anonymous Coward
    Meh

    And the score at half-time

    Not comprehensive, but:

    14 offtopic posts pushing, or defending pushing the use of bash/cygwin/perl for Windows SysAdmin

    1 AC troll slagging off powershell, no other contribution

    3 posts discussing languages in a completely irrelevant context

    1 post from Guus trolling h4rm0ny for not knowing all this already.

    1 offtopic post informing us all of how primitive shells are

    1 offtopic post about xterm and using the ratpoison WM

    1 AC and 1 non-AC troll coming out with the usual 'use Open Source,'cos MS suxx0rs' fuckwittery.

    2 non-AC trolls slagging off cygwin, no other contribution

    1 non-AC post informing us all how he hasn't used Powershell but it 'seems a bit weird'. Thanks for that.

    7 actually constructive posts on ISE/LINQPad

    1 constructive post on managing the console as it is.

    5 constructive posts mentioning Sapien Powershell Studio, Console 2 and ConEmu etc

    1 constructive post on .Net integration

    1 post from jake with his usual irrelevant shite.

    On-topic, here's a couple of other possibilities that build on the functionality of ISE

    I'm currently experimenting with ASE (Admin Script Editor) - this was previously a commercial product for Powershell, the scripting host and KixStart that is now being provided free by the developers. Pretty useful, but the lack of a defined future (or potentially any future) for the product is slightly discouraging.

    I haven't done so yet, but Powershell Plus from Idera is on my list of free IDEs to look at, as is Powershell Analyser

    Others have mentioned products from Sapien and some interesting sounding FOSS consoles, so I'll leave it at that.

  27. WOOOOO

    I like Power GUI (Quest/Dell) as I like the way you get the extra window showing variables and their contents, I find it helpful to expand object properties especially when the an object nests layers.

  28. Spoonsinger

    In what way, (other than GUI), does Powershell actually suck?

    I haven't had anything overly problematic with anything I needed to do in it. Is this just a troll question or is there something fundamentally wrong with it which I need to know about, just in case?

    1. h4rm0ny

      Re: In what way, (other than GUI), does Powershell actually suck?

      It's not a troll question and I don't think it does suck. I originally posted this question on the user forums because I was learning Powershell and found that the standard terminal for it was way behind the GNU/Linux equivalents. I actually quite like Powershell itself.

      I think you replied a little too hastily to my post, tbh, if that's how you see it.

  29. Zane

    Sad but true

    Tried to work with Powershell for about 6 months.

    And I was really upset with it, and thought exactly the same: there must be a better way to use this.

    If there is, then nobody shares it on the internet.

    Compared to Unix shell, powershell doesn't come near. The object-orientedness is a nice concept, but in practice it's not that helpful.

    What I used instead:

    pyshell - much nicer, but I'm not a python fan.

    gitbash (needs mingw) - just feels home when you are used to Unix shell scripting. Using that now for about 18 months, and I'm happy with it.

    Sorry that I do not have a better answer. But I think that fellow posters show that this is as it is.

    /Zane

    1. Anonymous Coward
      Anonymous Coward

      Re: Sad but true

      "Compared to Unix shell, powershell doesn't come near. "

      Actually Powershell is way more powerful than say Bash - you have to use addins for Bash to even come close to what Powershell provides and even then Powershell is a long ahead.

      1. Hans 1

        Re: Sad but true

        Call me when it has a proper regex implementation, that Winglob-regex bastard is awful.

        1. TheVogon

          Re: Sad but true

          Powershell already has a fully capable Regex implementation. What you presumably mean is that it is different from what you are used to in say Perl.

  30. Hans 1
    Linux

    I ssh in from my OpenIndiana box....

  31. Tyrion
    Mushroom

    Kill it with fire!

    Cygwin is about the best it gets on Windows unfortunately. And even that's in a horrible bog standard Windows console. After using a Linux terminal it's like long nails on a chalkboard.

    Even if you can get past PowerShell's fisher price UI, you're got to deal with an excruciatingly verbose syntax, that's ostensibly designed to cause as much RSI as possible. It's awful really. I pity the poor soul who has to use that monstrosity on a daily basis.

    1. Alt0n

      cygwin shell

      These days a fresh cygwin install gives you mintty, a superior terminal based on PuTTY. If you're still suffering the old cygwin terminal, get it installed :)

      1. Tyrion

        Re: cygwin shell

        > These days a fresh cygwin install gives you mintty, a superior terminal based on PuTTY. If you're still suffering the old cygwin terminal, get it installed :)

        I haven't used it for some time so I didn't know that. I'll have to give a try again, thanks :)

  32. herry

    Try PowerShell on top of ConEmu

  33. Anonymous Coward
    Anonymous Coward

    i just love it

    Get a room full of diverse technical specialists and ask them which is the best technology for a given job.

    Stand back.

    Start recording fight for later Youtube hilarity.

    Its like looking at my own firm on-line!

    1. h4rm0ny

      Re: i just love it

      >>Start recording fight for later Youtube hilarity.

      Well okay... But make sure you encode in H.264, not VP8.

  34. dub_dub

    You're all missing the point of the question

    Use conemu or console2 they are far better than the standard console and have tabs, full size windowing decent cut paste etc.

    install vim for text editing and you'll never leave the cli again.

    If you want a proper ide then powergui is about the best.

    1. Anonymous Coward
      Anonymous Coward

      Re: You're all missing the point of the question

      Trying ConEmu now, most impressed cheers for the info.

  35. smug git

    Conemu ftw

    Conemu is excellent; I don't find it _quite_ as good as a typical linux console but the fact that I get to use powershell instead of bash is most welcome, certainly welcome enough to live with any small deficiencies in the Conemu console.

  36. Adrian Bool

    There is a StackOverflow question asking the same thing,

    http://stackoverflow.com/questions/60950/is-there-a-better-windows-console-window

    ...with the top response being for the ConEmu terminal,

    http://sourceforge.net/projects/conemu/

    Quite possibly just what you need! I'll be checking it out too!

  37. Stevie

    Bah!

    The really encouraging thing about the spurious 'bash is better' "debate" is that it shows this old man that he was right in something he theorized a few years ago: much of the rabid Windows=crap, MS=evil zeitgeist in the post 90s graduate population seems to spring from "not what I know", something I am familiar with having worked on more operating systems than some *nix SAs would credit existing (they seemingly being of the 2+1 school of OSs: *nix, Windows and whatever apple is doing).

    I work in a large *nix department which is twinned with a large windows one. The *nix SAs spend a lot of time laughing about how much better they are than the windows crowd at what we do. So much time, In fact, that no-one ever seems to get round to making it true.

    Time and again when we are in panic mode it is the windows SA teams that have plans in place, procedures to follow, and contingency schedules up and running in a jiffy, while my lot flail around, answering "why can't you just do what they do?" with "well, it's windows!" and scrambling for their little black books in which they keep their alchemical secrets to themselves. An unscheduled absence during one of these events can be a thing of high comedy to watch unfold.

    Our hot line can contact users (our user base in in the thousands) impacted by a server outage with good estimates of the down time expected - if those users happen to have the good fortune to be working on apps located on a windows server. If they are using one of our *nix servers they are, to use dense technical jargon, SOL. We have an enterprise-wide system for enabling this technology, but it involves the SAs knowing what is running on their servers and entering that list on a database. This they claim they are too busy to do (a blatant lie obvious to even the most oblivious upper manager).

    I'm not popular just now because after the last disaster, when we were asked for ideas to improve the *nix departmental image, I suggested the SAs wear Stetsons so there would be no confusion as to their professionalism.

  38. Anonymous Coward
    Anonymous Coward

    This topic

    could have been quite useful but, as usual, the posts are not quite what was intended by the author of the article. In case you forgot, during your mindless BASH vs PS vs Microsoft vs UNIX wars that are just completely irrelevant, the author wanted to know if there was an alternative to the shell not a fuckin alternative to the language.

    wankers.

This topic is closed for new posts.

Biting the hand that feeds IT © 1998–2022