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.

Page:

  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 Silver badge

      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.

Page:

This topic is closed for new posts.

Biting the hand that feeds IT © 1998–2022