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:

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.

3
7

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.

7
7

Re: jpsoft

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

http://jpsoft.com/

3
1

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.

9
5
Roo
Silver badge

Re: jpsoft

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

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

3
6
Silver badge

Re: jpsoft

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

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

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

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

8
0
Silver badge

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.

3
0
Holmes

Re: Why not use jpsoft / bash

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

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

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

7
1

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
3
Anonymous Coward

Re: jpsoft

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

Powershell is way more powerful though.

1
6
Silver badge

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).

6
2
Silver badge

Re: jpsoft

Reasons to use Powershell over BASH, etc.

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

2) Command metadata. PowerShell commands, functions and even *script files* expose metadata about the names, positions, types and validation rules for parameters, allowing the *shell* to perform type coercion, allowing the *shell* to explain the parameters/syntax, allowing the *shell* to support both tab completion and auto-suggestions with no need for external and cumbersome completion definitions.

3) Robust risk management. Look up common parameters -WhatIf, -Confirm, -Force and consider how they are supported by ambient values in scripts you author yourself.

4) Multiple location types and -providers. Even a SQL Server appears as a navigable file system. Want to work with a certain database? Just switch to the sqlserver: drive and navigate to the server/database and start selecting, creating tables etc.

5) Fan-out remoting. Execute the same script transparently and *robustly* on multiple servers and consolidate the results back on the controlling console. Try icm host1,host2,host3 {ps} and watch how you get consolidated, object-oriented process descriptions from multiple servers.

6) Workflow scripting. PowerShell scripts can (since v3) be defined as workflows which are suspendable, resumable and which can pick up and continue even across system restarts.

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

8) True remote sessions where you don't step into and out of remote sessions but actually controls any number of remote sessions from the outside.

9) PowerShell web access. You can now set up a IIS with PWA as a gateway. This gives you a firewall-friendly remote command line in any standards compliant browser.

10) Superior security features, e.g. script signing, memory encryption, proper multi-mode credentials allowing script to be agnostic about authentication schemes which may go way beyond stupid username+password and use smart cards, tokens, OTPs etc.

11) Transaction support right in the shell. Script actions can join any resource manager such as SQL server, registry, message queues in a single atomic transaction. Do that in bash?

12) Strongly typed stripting, extensive data types, e.g first class xml support and regex support right in the shell. Optional static/explicit typing. Real lambdas (script blocks) instead of stupidly relying on dangerous and error prone "eval" functions.

13) Real *structured* exception handling as an alternative to outdated traps (which PowerShell also has). try-catch-finally blocks.

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

15) Consistent naming conventions covering verb-noun command names, common verbs, common parameter names.

13
1
Silver badge
Pint

@TheVogon

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

3
0
Anonymous Coward

Re: jpsoft

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

1
1

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 :)

2
13

Questionable reason to use powershell over bash. Part I

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

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

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

explain the parameters/syntax, allowing

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

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

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

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

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

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

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

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

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

To be Cont'd

1
9
Silver badge

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?

16
2
Anonymous Coward

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

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

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

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

"1) makes it more complex"

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

"Objects that are not a universal standard as POSIX"

POSIX doesn't support objects AT ALL.

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

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

"hence an extra complexity."

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

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

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

6
4

Questionable reason to use powershell over bash. Part II

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

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

8) True remote sessions where you don't step into and out of remote sessions but actually controls any number of remote sessions from the outside.

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

9) PowerShell web access.

What the hell is that, what for?

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

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

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

Sounds very fishy and insecure to me.

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

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

11) Do that in bash?

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

12) Strongly typed stripting, extensive data types,

Why not scripting in C then?

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

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

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

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

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

2
11
Silver badge

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

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

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

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

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

Won't survive a reboot....

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

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

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

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

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

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

6
3

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.

2
5

@TheVogon

Not even worth replying to most of these

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

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

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

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

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

Both of those have had recent security vulnerabilities patched

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

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

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

1
6

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

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

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

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

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

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

9) PowerShell web access.

What the hell is that, what for?

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

Sounds very fishy and insecure to me.

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

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

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

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

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

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

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

How do you sign a bash script, btw?

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

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

11) Do that in bash?

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

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

12) Strongly typed stripting, extensive data types,

Why not scripting in C then?

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

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

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

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

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

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

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

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

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

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

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

4
1

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.

1
1

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.

4
1

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
4
Anonymous Coward

Re: jpsoft

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

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

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

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

1
3
Silver badge

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.

8
0

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.

4
0
Anonymous Coward

Re: @TheVogon

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

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

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

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

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

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

"Run it as a system utility"

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

1
2
Anonymous Coward

Re: jpsoft

"you can't really mix the two."

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

0
0

PASH @TheVogon

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

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

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

3
1
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.

1
0

@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
1

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?

3
1

@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

1
2
Silver badge

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?

4
0
WTF?

Re: @TheVogon

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

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

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

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

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

1
1

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.

0
1

@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.

2
1

@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.

2
1
Silver badge

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
0

This post has been deleted by its author

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?

0
0

@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
0

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.

0
0

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

0
0

Re: jpsoft

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

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

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

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

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

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

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

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

(**) ditto

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

0
0

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
0

@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 .

0
0

Page:

This topic is closed for new posts.

Forums

Biting the hand that feeds IT © 1998–2017