Windows PowerShell vs. bash examples - Linux

This is a discussion on Windows PowerShell vs. bash examples - Linux ; Homer writes: > Verily I say unto thee, that Chris Ahlstrom spake thusly: >> After takin' a swig o' grog, jsnover13@hotmail.com belched out > >>> Jeffrey Snover [MSFT] >>> Windows PowerShell Architect >>> Visit the Windows PowerShell Team blog at: ...

+ Reply to Thread
Page 10 of 11 FirstFirst ... 8 9 10 11 LastLast
Results 181 to 200 of 217

Thread: Windows PowerShell vs. bash examples

  1. Re: Windows PowerShell vs. bash examples

    Homer writes:

    > Verily I say unto thee, that Chris Ahlstrom spake thusly:
    >> After takin' a swig o' grog, jsnover13@hotmail.com belched out

    >
    >>> Jeffrey Snover [MSFT]
    >>> Windows PowerShell Architect
    >>> Visit the Windows PowerShell Team blog at:
    >>> http://blogs.msdn.com/PowerShell
    >>> Visit the Windows PowerShell ScriptCenter at:
    >>> http://www.microsoft.com/technet/scr.../hubs/msh.mspx

    >>
    >> Who called in the Big Gun?

    >
    > Fuddie probably sent the Vole an emergency telegram, telling them that
    > the Munchkins know squat about PowerShell, and Sweaty then sent a memo
    > to the department head looking for a volunteer to do damage limitation
    > and "evangelism" for a couple of days.


    And the fun thing is, is that the Microsoft guy, assuming he is real
    (and I do), just demolished Erik's argument by conceding that
    Powershell has to catch up with thirty years of shell ecosystem built
    on Unix.

    The nice thing about Erik is that sooner or later he *will* shoot
    himself in the foot.

    Mart

    --
    "We will need a longer wall when the revolution comes."
    --- AJS, quoting an uncertain source.

  2. Re: Windows PowerShell vs. bash examples

    After takin' a swig o' grog, Terry Porter belched out
    this bit o' wisdom:

    > On Sun, 09 Nov 2008 21:03:50 -0500, none of your buisiness wrote:
    >
    > I have to agree, awesome PowerShill analysis Kelsey, thanks for the time
    > and effort for your huge followup.
    >
    > Funkentroll is off his head if he thinks any Linux user is going to
    > stick their feet back in the MS tarpit, just because he can't get out.


    http://images.pearsoned-ema.com/jpeg...0201835953.jpg

    http://coleteamla.com/photogallery/p...a_Tar_Pits.jpg

    --
    Serenity through viciousness.

  3. Re: Windows PowerShell vs. bash examples

    Terry Porter writes:

    > On Sun, 09 Nov 2008 21:03:50 -0500, none of your buisiness wrote:
    >
    >> Kelsey Bjarnason wrote:
    >>
    >>> Which simply accomplishes what I already said: vendor lock-in. *As the
    >>> code gets tied ever more tightly to a non-portable API set, the code
    >>> becomes ever less portable to a different platform. *Which is exactly
    >>> what MS wants, which explains why they released PS with support for all
    >>> those other goodies, but with an incomplete cmdlet set - "Yes, sure,
    >>> well get those eventually... long after you've invested so much in
    >>> using custom APIs that you'll never bother with the cmdlets anyhow and,
    >>> more to the point, you'll never even consider moving this code to
    >>> another system, as you *can't*. *We win."
    >>>

    >> way to go, kelsey, that is exactly what PS is all about. another ploy
    >> for Microsoft to use on developers that are ignorant enough to use their
    >> products. vendor "lock in" is a game that microsoft knows all too well.
    >>
    >> any "nix" programmer would see the farce for what it is within miniutes
    >> of using PS
    >>
    >> notice how quick microsoft was to send a employee into this group to
    >> defend the FUD.

    >
    > I have to agree, awesome PowerShill analysis Kelsey, thanks for the time
    > and effort for your huge followup.


    Would you listen to Terry Bighead? He thinks he is the queen of the
    group! Constantly "thanking people" for posting to his newsgroup! What
    an complete and utter fruitcake!

    > Funkentroll is off his head if he thinks any Linux user is going to
    > stick their feet back in the MS tarpit, just because he can't get out.


    I rarely do, but in the real world where most businesses use Windows one
    has to. No wonder you're always on the look out for free stuff.


  4. Re: Windows PowerShell vs. bash examples

    Terry Porter writes:

    > On Sun, 09 Nov 2008 19:47:35 -0500, Erik Funkenbusch wrote:
    >
    >> On Sun, 9 Nov 2008 12:50:27 -0800, Kelsey Bjarnason wrote:
    >>

    >
    >
    >
    >>>> They're all built-in or .net functions.
    >>>
    >>> PS is built-in? Bull****.

    >>
    >> Are you a ****ing idiot?

    >
    > No Erik the Wintroll, Kelsey is no idiot, in fact Kelsey possesses the
    > kind of mind that when focused, sets morons like you on fire quite easily.
    >
    > I've still got the burn marks from when Kelsey focused on me several
    > years ago.
    >
    > Unlike you tho, I soon realised *I* was the ****ing idiot.


    The one correct thing you have posted here this year.

  5. Re: Windows PowerShell vs. bash examples

    Terry Porter writes:

    > On Sun, 09 Nov 2008 08:57:06 -0800, Kelsey Bjarnason wrote:
    >
    >> [snips]
    >>
    >> On Thu, 06 Nov 2008 22:39:08 -0500, Erik Funkenbusch wrote:
    >>
    >>>> We just ignore Wintrolls.
    >>>
    >>> Because you prefer to bask in your ignorance.

    >>
    >> Now that's rich - the notion that a *troll* is going to cure ignorance.
    >>
    >> No, Erik, if we wish to reduce our ignorance, there are people we will
    >> indeed listen to. Trolls are not among those people, as trolls, more or
    >> less by definition, *promote* ignorance.

    >
    > I'm sitting back here, clapping for Kelsey, like one might the actors in
    > an outstanding play.
    >
    > What a classic line Kelsey, it just has to go into my sig!


    It's not classic. It's not clever and it's certainly wrong. It's yet
    more hot air and bull**** intended to hide the issues at hand.

    You constantly snip, lie and evade. You are the troll telnet boy.



  6. Re: Windows PowerShell vs. bash examples

    On Mon, 10 Nov 2008 07:02:34 +0100, Mart van de Wege wrote:

    > Hadron writes:
    >
    >> Mart van de Wege writes:
    >>
    >>> Hadron writes:
    >>>
    >>>> Mart van de Wege writes:
    >>>
    >>>
    >>>>> However, the fanboys like Erik do. And they'll get hammered for their
    >>>>> hyperbole. Nothing to do with the relative merits of MS software, but
    >>>>> everything to do with the idiocy of some of your fanboys. Not your
    >>>>> fault, but at least you know why some people here get a decidedly less
    >>>>> friendly treatment than you.
    >>>>>
    >>>>> Mart
    >>>>
    >>>> Allowing for the fact that you are an obvious sock,
    >>>
    >>> Interesting. What makes you think that?

    >>
    >> Ask Willy.
    >>

    > No, I am asking you. What makes you think I'm a sock?
    >
    > (This could get fun).


    LMAO! Quack thinks (for want of a better word) you're a sock!

    >>>> would you like to post links to this "fanboy" posts from Erik? I
    >>>> have never seen them. It strikes me that all he does is point out
    >>>> the lies and stupidity of the likes of Mark Kent, Roy and Terry "The
    >>>> Big I Am" Porter.
    >>>>
    >>> Uhuh.
    >>>
    >>> I guess you missed Erik's "Powershell blows all Unix scripting
    >>> environments away".

    >>
    >> I guess I did. Please post a link to him saying that specifically.
    >>

    > Peter already did.
    >
    > So yes, you *are* irretrievably stupid.
    >

    Something's screwed his "brain".

    --
    Most people are sheep. *
    Microsoft is very effective
    at fleecing the flockers.



  7. Re: Windows PowerShell vs. bash examples

    On Sun, 09 Nov 2008 21:56:04 -0600, Terry Porter wrote:

    > On Sun, 09 Nov 2008 19:47:35 -0500, Erik Funkenbusch wrote:
    >
    >> On Sun, 9 Nov 2008 12:50:27 -0800, Kelsey Bjarnason wrote:
    >>
    >>

    >
    >
    >>>> They're all built-in or .net functions.
    >>>
    >>> PS is built-in? Bull****.

    >>
    >> Are you a ****ing idiot?

    >
    > No Erik the Wintroll, Kelsey is no idiot, in fact Kelsey possesses the
    > kind of mind that when focused, sets morons like you on fire quite
    > easily.
    >
    > I've still got the burn marks from when Kelsey focused on me several
    > years ago.
    >
    > Unlike you tho, I soon realised *I* was the ****ing idiot.
    >


    Nobody's perfect.

    When you returned, I was more than ready to either killfile you or vent
    some in your direction, as I couldn't think of a more deserving target.

    That said, I _also_ decided to let you dig your own grave. You haven't.
    So, on that note, here's _my_ formal "Welcome back, Terry". Go kick a
    troll for us.


  8. Re: Windows PowerShell vs. bash examples

    [snips]

    On Sun, 09 Nov 2008 19:47:35 -0500, Erik Funkenbusch wrote:

    >> Many people - myself included - quickly came to *loathe* the
    >> fundamental idiocy of the entire approach to software distribution and
    >> installation in Windows. It was slow, it was clunky, it was expensive,
    >> it was time consuming and it sucked space the way a black hole sucks
    >> matter.

    >
    > When disk space costs $150 for 1TB, i don't think it much matters to
    > most people.


    Ah, yes, the Windows mentality in all its glory: it's okay to suck disk
    space - and the bandwidth costs needed to fill it. It's okay to ignore
    MS's persistent failure to produce a usable toolset out of the gate.
    It's okay to have 400+ million users *each* suck down gigs of pointless
    crap which *could have* been on the install CD, except for MS's short-
    sighted incompetence. No, none of that matters, as long as we can ensure
    that the developer *never* has *any* reasonable expectation that *any* of
    the tools he needs on the user's machine will actually be there.

    Yes, do keep defending this sort of stupidity.


  9. Re: Windows PowerShell vs. bash examples

    On Nov 9, 7:59*am, Kelsey Bjarnason wrote:
    > On Thu, 06 Nov 2008 22:37:42 -0500, Erik Funkenbusch wrote:
    > > On Thu, 06 Nov 2008 21:19:54 -0600, Terry Porter wrote:

    >
    > >> I'm taking issue with Erik the Wintroll who claimed that Powershell is
    > >> superior to Linux Bash, and to me *one* example is enough to prove him
    > >> wrong.

    >
    > > That's because you can't possibly understand set theory.

    >
    > > If there's 2000 examples that prove me right, but one that proves me
    > > wrong, in your eyes, i'm wrong.

    >
    > Which is a correct summation of the problem as you state it, to wit,
    > "Powershell is superior to Linux bash". *A single example suffices to
    > show that the absolutist form offered by you is incorrect. *A more
    > general form, such as "Powershell is generally superior to Linux bash"
    > would, however, remain true.
    >
    > That said, I think it's a bit weird to be quibbling about "2000 versus 1"
    > when you've failed to post the 2000 cases it's supposedly better in.
    >
    > >> Why would I bother understanding Windows Powershell, I only use Linux,
    > >> and this is a Linux advocacy group ?

    >
    > > Know thy enemy? *Get ideas to copy? *Lament your wish that Linux had
    > > something like it?

    >
    > "Thy enemy" here is, fundamentally, Wintrolls. *As to ideas to copy, one
    > might point out that MS has, historically, had the *worst* ideas in
    > computing rather than the best. *Executable emails, for example. *Or
    > "I'll run anything, if the filename's right - and I'll hide the bit that
    > matters." *Or this nonsense notion of OneCare - adding bandages to
    > provide security, rather than fixing the OS. *Need we mention such items
    > as Bob?
    >
    > One might point out the most glaringly obvious potential flaw in
    > PowerShell. *I've not used it, I'm simply going by what's being said
    > here, but as I understand it, PS relies on a lot of COM interfaces to do
    > things - compressing and decompressing files, say - for which there
    > aren't direct shell commands available.
    >


    That isn't quite correct. Powershell can understand and use COM
    interfaces, but does not rely on them. Windows and many windows
    applications expose themselves as COM automation servers, so you can
    script them using Powershell, just as you were able to in vbscript or
    any of the wsh languages.

    I brought up using shell.applicaiton to do the decompression, simply
    because - System.IO.Compression sort of sucks for anything beyond very
    simple applications, and for the example (a self extracting raw
    installer), I didn't want the baggage of distributing a real
    compression library like #ziplib.

    If you are fine with cab files, then you could use the built in
    commandline tools that windows supplies - makecab and expand (at least
    win2k and up).

    > Bash, by contrast, does exactly the opposite - what it ain't got
    > internally, it spawns sub-commands for. *Shell commands. *Programs one
    > _can_ run directly.


    No different then powershell. It's just that:

    1) Because powershell is based on .NET it has lot more internally.
    2) It can understand com interfaces exposed by windows and other
    applications natively
    3) can call any native command line application.

    > Which means that to migrate even a hairy bash shell to another platform
    > means ensuring bash and the other relevant tools are available,
    > Powershell is, like VB, essentially designed to tie one to a specific OS
    > - you can't just copy the shell, port PS itself and port a hatful of
    > associated cli tools; you have to port the relevant COM interfaces
    > instead, which is liable to be considerably more effort, or you have to
    > rewrite the PS script to use those cli tools - which means it no longer
    > does the right thing in its native environment.
    >


    obviously, powershell scripts that rely on COM api's are not going to
    be directly portable. And I give bash a check mark in the more cross-
    platform box. But, I think you are thinking that PS relies a lot on
    COM - it doesn't - but a lot of windows services do.

    > This, to me, is not a good thing. *It smacks too much of the endlessly
    > repeated "We got some tool - Excel, IIS, whatever - we wrote a mess of
    > code specific to it, now we can't afford to switch platforms or tool
    > sets."
    >


    If you are already using Excel, IIS, whatever, then adding ps to the
    mix isn't really changing anything. It's just making it easier for
    windows admins to do their jobs...

    I am certain that a Linux admin will not care much about powershell in
    and of itself - but, might be interested in the paradigm behind it.
    That of a shell that pipes objects rather then strings. I know that's
    the part that interests me - much more then my shell is bigger then
    your shell arguments that seem to be going on.

    > >> You can argue the fine points all day long, but surely the advocacy of
    > >> the Windows Powershell belongs in another Usenet group where *Windows
    > >> Advocacy* is welcome ?

    >
    > > Who's advocating anything?

    >
    > Someone around here is apparently trying to convince us that PS is better
    > than bash; that definitely sounds like an advocacy-type comment.
    >
    > > I responded to the false comments about how
    > > Windows lacks a decent shell or scripting, I proved him wrong.

    >
    > Okay, you say it has a decent shell and scripting. *So tell us where, on
    > a typical user's XP machine, we find Powershell - plus all the cli tools
    > needed to do all the little tasks one generally uses such things for. *
    > Tools such as grep.
    >
    > Last I checked, PS simply wasn't on most people's XP machines, and from
    > what I'm hearing here, even if you do have PS on your machine, you still
    > don't have the cli tools to make it a really sensible scripting
    > environment. *
    >


    grep maybe a bad example for you... It really depends on the context,
    but if your searching for words in files, then that's pretty easy:

    ls -r -i *.txt 'c:\somepath\* | select-string -pattern "idiot" -
    casesensitive

    pattern is a regular expression (and there are tons more options)

    you don't need it for listing processes:

    ps f*

    will return all processes whose process names starts with f. Lots of
    things accept filters, so grep isn't quite as necessary. nor are
    things like cut - because most things are objects.

    The other point you seem to be missing is that PS is really desinged
    for power users and admins - so, average joe probably isn't going to
    give hoot about ps. Though, it ships with 2008 as an option and it
    will be the default shell in Windows 7. If you need some of those
    other tools, well you can download and install them via cygwin and use
    them from ps.

    > Do feel free to show me wrong, though... just tell me where I find this
    > PS thing on Joe Sixpack's XP machine and where all those other little cli
    > tools - compressors and decompressors and pattern matching and string
    > replacement and on and on and on - all live.
    >


    pattern matching, string replacement, etc are all part of ps. You
    don't need those little command line tools for those - unless you
    really want them (you can use the windows FINDSTR command for some
    stuff if you want, but not sure why you would want to). As for
    compression, if you don't mind simple compression then
    system.io.compression is automatically available by virtue of it being
    part of the .net core libraries. You can use makecab and expand for
    cabinet files, COM automation, or any 3rd party tool or command line
    tool you want to install.

    --
    Tom Shelton

  10. Re: Windows PowerShell vs. bash examples

    On Nov 9, 2:08*pm, Kelsey Bjarnason wrote:
    > [snips]
    >
    > On Sun, 09 Nov 2008 14:33:49 -0500, Erik Funkenbusch wrote:
    > >> You "shelled out" to another tool, the system.net.webclient. *The fact
    > >> that you used an API call rather than a process launch is no more
    > >> "doing it in powershell" than if you'd printed the string "Please type
    > >> in the titles from slashdot" and waited for user input.

    >
    > > Bull. *Since .net is required for PowerShell, that function is always
    > > going to be there.

    >
    > Yet you yourself admit it's not part of powershell. *Since the whole
    > point was to show off powershell, I'm still waiting. *Yes, fine, we've
    > seen what .NET can do, we don't care. *Let's see what PowerShell can do..
    >


    I don't get this argument. Powershell relies on .NET - it is a .NET
    app. PS loads the most useful parts of the .NET framework
    automatically, so they are just available. How are they not part of
    the shell?

    If you wrote a shell using python, wouldn't you expect to have access
    to python libraries?

    > If all it can muster up is being a thin layer of VBscript capable of
    > calling .NET, then it's about as tired a piece of junk as you can get.
    >
    > >> No shelling to other scripting _environments_? *Easy:

    >
    > >> cat file.txt | sort > outfile

    >
    > > cat and sort are external tools.
    > >> Now, if you'd meant something like "without invoking other
    > >> applications", you might have had a point, except that were that the
    > >> case, I'd simply note that sort can do all that itself: *sort < infile
    > >> > outfile - voila, one app, no calling anything else.

    >
    > > Except sort itself, which is not part of the shell.

    >
    > Sorry, where's the shelling out? *You have to run your PS script to do a
    > job, I'm running the tool that does the same job directly. *
    >


    sort is one of the standard cmdlets. You don't have to invoke a cli
    tool for sorting in ps. In fact, that entire example is all inside of
    ps, your's (except the pipe) is an external tool - not bash at all.

    > Sorry, but if you get to run a cli tool - a script - I get to run a cli
    > tool. *'Course, mine doesn't have all the overhead of the scripting
    > engine, parsing, linking 97 million screwball interfaces and the like,
    > but hey, that's kinda the point, ain't it?
    >
    > > Not that it really
    > > matters, since I have nothing against using such tools. *It's just a
    > > point about how the shell itself is more powerful.

    >
    > Because you have to run a script, whereas I run an executable. *Ah, yes,
    > it's so obvious now.
    >
    > >> Linux builds upon small tools to accomplish larger tasks. *


    So does PS. small, single function cmdlets are the preferred method
    of doing things in ps.

    >Need
    > >> something sorted? *Pipe it through sort. *Need something searched?
    > >> Pipe it through grep. *And so forth.

    >


    PS... Pipe it through sort. Need it searched pipe it through select-
    object or select-string depending on your needs. No different, except
    these are built into ps.

    > > Which means, learning the syntax of multiple tools, which all seem to
    > > have different quirks and issues.

    >
    > Well, golly gee, imagine that - invoking sort isn't going to work exactly
    > the same as invoking tar or gzip. *The fact they do different things
    > might have been a clue.
    >


    I think what Eric is getting at, is that PS cmdlets have certain
    naming conventions and common properties. There is a lot of
    consistency in the way cmdlets work, because they all inherit from the
    same objects.

    > Another clue might be the fact that this methodology has been working
    > quite well for, oh, 30 years, whereas Microsoft hasn't come up with a
    > functional CLI environment *yet* - even PS is being doled out in drips
    > and drabs.
    >


    well, you have to admit that the average user doesn't give hoot about
    the cli. So, no great loss. Those of us the care have it downloaded
    and installed.

    > Oh, yes, definitely the winning horse there - 30 years late and lame in
    > three legs, to boot.
    >


    For someone whose never used it, your opinion, with all due respect,
    is pretty useless.

    > >> So, for example, if I find that overall, sorting is just too damned
    > >> slow and the reason is that the sort utility is using a shell sort
    > >> instead of a stable merge sort, I can replace the algorithm without
    > >> mucking up - or even looking at - a single script relying on it.

    >
    > > And since powershell uses heavy aliasing, you can do the same in
    > > powershell, just replace the alias with a different cmdlet.

    >
    > Alias? *WTF? *Who is dicking around with aliases? *Oh, I see, you're
    > adding *yet another* layer of crud to be interpreted, parsed, linked,
    > sorted out and yet another layer of things to go wrong, whereas I've got
    > a nice little standalone executable. *Yes, the improvement in the
    > PowerShell way is just screamingly obvious.
    >
    > >> So, for the sake of comparison, how do you replace PowerShell's
    > >> presumably built-in sort? *Note that sort-object, whatever it is, must
    > >> in fact be built right into PowerShell - i.e. not be a cmdlet - or your
    > >> entire question falls apart, but that in turn means that to replace it,
    > >> you have to modify powershell itself, no? *Okay, fine, how do you do
    > >> it?

    >


    What's your problem with alias's? Bash does aliasing to you know?

    Though, in this case, I think to make this really work is that you
    would define a new cmdlet that works the way you want it (with the
    same parameters) and then create a function in your profile named Sort-
    Object.

    The reason is that ps looks at functions before cmdlets, so including
    a function with the same name basically hides the built in sort-
    object. so everything just works wether your using alias's at the
    command line or using full names in your scripts (the recommended
    practice).

    > > You can re-alias it to a cmdlet if you want.

    >
    > No, I want to replace the built-in sort. *You know, as in the existing
    > sort code/binary simply *no longer exists*. *Why do I need the old crud
    > crufting up the computer? *No, I want it *gone*. *So again, where exactly
    > does it reside and how, exactly, does one replace it?


    I don't believe you can do that. You can override it, but I'm not
    sure you can just make it disappear from the system.

    --
    Tom Shelton

  11. Re: Windows PowerShell vs. bash examples

    On Nov 10, 2:53*pm, Tom Shelton wrote:
    > On Nov 9, 2:08*pm, Kelsey Bjarnason wrote:
    >
    > > [snips]

    >
    > > On Sun, 09 Nov 2008 14:33:49 -0500, Erik Funkenbusch wrote:
    > > >> You "shelled out" to another tool, the system.net.webclient. *The fact
    > > >> that you used an API call rather than a process launch is no more
    > > >> "doing it in powershell" than if you'd printed the string "Please type
    > > >> in the titles from slashdot" and waited for user input.

    >
    > > > Bull. *Since .net is required for PowerShell, that function is always
    > > > going to be there.

    >
    > > Yet you yourself admit it's not part of powershell. *Since the whole
    > > point was to show off powershell, I'm still waiting. *Yes, fine, we've
    > > seen what .NET can do, we don't care. *Let's see what PowerShell can do.

    >
    > I don't get this argument. *Powershell relies on .NET - it is a .NET
    > app. *PS loads the most useful parts of the .NET framework
    > automatically, so they are just available. *How are they not part of
    > the shell?
    >
    > If you wrote a shell using python, wouldn't you expect to have access
    > to python libraries?
    >
    >
    >
    > > If all it can muster up is being a thin layer of VBscript capable of
    > > calling .NET, then it's about as tired a piece of junk as you can get.

    >
    > > >> No shelling to other scripting _environments_? *Easy:

    >
    > > >> cat file.txt | sort > outfile

    >
    > > > cat and sort are external tools.
    > > >> Now, if you'd meant something like "without invoking other
    > > >> applications", you might have had a point, except that were that the
    > > >> case, I'd simply note that sort can do all that itself: *sort < infile
    > > >> > outfile - voila, one app, no calling anything else.

    >
    > > > Except sort itself, which is not part of the shell.

    >
    > > Sorry, where's the shelling out? *You have to run your PS script to do a
    > > job, I'm running the tool that does the same job directly. *

    >
    > sort is one of the standard cmdlets. *You don't have to invoke a cli
    > tool for sorting in ps. *In fact, that entire example is all inside of
    > ps, your's (except the pipe) is an external tool - not bash at all.
    >
    > > Sorry, but if you get to run a cli tool - a script - I get to run a cli
    > > tool. *'Course, mine doesn't have all the overhead of the scripting
    > > engine, parsing, linking 97 million screwball interfaces and the like,
    > > but hey, that's kinda the point, ain't it?

    >
    > > > Not that it really
    > > > matters, since I have nothing against using such tools. *It's just a
    > > > point about how the shell itself is more powerful.

    >
    > > Because you have to run a script, whereas I run an executable. *Ah, yes,
    > > it's so obvious now.

    >
    > > >> Linux builds upon small tools to accomplish larger tasks. *

    >
    > So does PS. *small, single function cmdlets are the preferred method
    > of doing things in ps.
    >
    > >Need
    > > >> something sorted? *Pipe it through sort. *Need something searched?
    > > >> Pipe it through grep. *And so forth.

    >
    > PS... Pipe it through sort. *Need it searched pipe it through select-
    > object or select-string depending on your needs. *No different, except
    > these are built into ps.
    >
    > > > Which means, learning the syntax of multiple tools, which all seem to
    > > > have different quirks and issues.

    >
    > > Well, golly gee, imagine that - invoking sort isn't going to work exactly
    > > the same as invoking tar or gzip. *The fact they do different things
    > > might have been a clue.

    >
    > I think what Eric is getting at, is that PS cmdlets have certain
    > naming conventions and common properties. *There is a lot of
    > consistency in the way cmdlets work, because they all inherit from the
    > same objects.
    >
    > > Another clue might be the fact that this methodology has been working
    > > quite well for, oh, 30 years, whereas Microsoft hasn't come up with a
    > > functional CLI environment *yet* - even PS is being doled out in drips
    > > and drabs.

    >
    > well, you have to admit that the average user doesn't give hoot about
    > the cli. *So, no great loss. *Those of us the care have it downloaded
    > and installed.
    >
    > > Oh, yes, definitely the winning horse there - 30 years late and lame in
    > > three legs, to boot.

    >
    > For someone whose never used it, your opinion, with all due respect,
    > is pretty useless.
    >
    >
    >
    > > >> So, for example, if I find that overall, sorting is just too damned
    > > >> slow and the reason is that the sort utility is using a shell sort
    > > >> instead of a stable merge sort, I can replace the algorithm without
    > > >> mucking up - or even looking at - a single script relying on it.

    >
    > > > And since powershell uses heavy aliasing, you can do the same in
    > > > powershell, just replace the alias with a different cmdlet.

    >
    > > Alias? *WTF? *Who is dicking around with aliases? *Oh, I see, you're
    > > adding *yet another* layer of crud to be interpreted, parsed, linked,
    > > sorted out and yet another layer of things to go wrong, whereas I've got
    > > a nice little standalone executable. *Yes, the improvement in the
    > > PowerShell way is just screamingly obvious.

    >
    > > >> So, for the sake of comparison, how do you replace PowerShell's
    > > >> presumably built-in sort? *Note that sort-object, whatever it is, must
    > > >> in fact be built right into PowerShell - i.e. not be a cmdlet - or your
    > > >> entire question falls apart, but that in turn means that to replace it,
    > > >> you have to modify powershell itself, no? *Okay, fine, how do you do
    > > >> it?

    >
    > What's your problem with alias's? *Bash does aliasing to you know?
    >


    Actually, I thought I'd point out, that bash aliasing actually is
    superior than that in the current version of ps. In PS v1, you can
    only alias the command, not it's parameters. For example, you can't
    alias say get-childitem -recursive to ls. You can only alias get-
    childitem to ls. So you have to call it always with the argument ls -
    r[ecursive] if you want a recursive search by default. I think this
    is changing for v2, but I'm not 100% sure.

    --
    Tom Shelton



  12. Re: Windows PowerShell vs. bash examples

    After takin' a swig o' grog, Tom Shelton belched out
    this bit o' wisdom:

    > On Nov 10, 2:53*pm, Tom Shelton wrote:
    >> On Nov 9, 2:08*pm, Kelsey Bjarnason wrote:
    >>

    > Actually, I thought I'd point out, that bash aliasing actually is
    > superior than that in the current version of ps. In PS v1, you can
    > only alias the command, not it's parameters. For example, you can't
    > alias say get-childitem -recursive to ls. You can only alias get-
    > childitem to ls. So you have to call it always with the argument ls -
    > r[ecursive] if you want a recursive search by default. I think this
    > is changing for v2, but I'm not 100% sure.


    Actually, you should be comparing powershell to zsh, which looks to me to be
    a lot more powerful than bash.

    On the other hand, I've found bash plus the command-line tools to be quite
    sufficient for the little bit I do.

    The proliferation of scripting-cum-glue-languages is a good thing. You have
    Ruby, Python, Perl, the various sh-shells, and, on the Windows side,
    VB/WSH/Powershell. Although I no longer get very deep into the Windows end,
    it's nice to have this ferment.

    --
    "No one talks peace unless he's ready to back it up with war."
    "He talks of peace if it is the only way to live."
    -- Colonel Green and Surak of Vulcan, "The Savage Curtain",
    stardate 5906.5.

  13. Re: Windows PowerShell vs. bash examples

    On Nov 10, 3:48*pm, Chris Ahlstrom wrote:
    > After takin' a swig o' grog, Tom Shelton belched out
    > * this bit o' wisdom:
    >
    > > On Nov 10, 2:53*pm, Tom Shelton wrote:
    > >> On Nov 9, 2:08*pm, Kelsey Bjarnason wrote:

    >
    > > Actually, I thought I'd point out, that bash aliasing actually is
    > > superior than that in the current version of ps. *In PS v1, you can
    > > only alias the command, not it's parameters. *For example, you can't
    > > alias say get-childitem -recursive to ls. *You can only alias get-
    > > childitem to ls. *So you have to call it always with the argument ls -
    > > r[ecursive] if you want a recursive search by default. *I think this
    > > is changing for v2, but I'm not 100% sure.

    >
    > Actually, you should be comparing powershell to zsh, which looks to me tobe
    > a lot more powerful than bash.
    >


    Yes, it does look pretty powerful. Thanks

    > On the other hand, I've found bash plus the command-line tools to be quite
    > sufficient for the little bit I do.
    >


    Oh, me to. Don't get me wrong. I have bash (via cygwin) and PS
    installed on all of my windows boxes

    > The proliferation of scripting-cum-glue-languages is a good thing. *Youhave
    > Ruby, Python, Perl, the various sh-shells, and, on the Windows side,
    > VB/WSH/Powershell. *Although I no longer get very deep into the Windowsend,
    > it's nice to have this ferment.


    uh, you also have ruby, python, and perl on the windows side as
    well and a bunch of sh-shells. I have bash on here, and I used to
    have korn (part of SFU).

    --
    Tom Shelton

  14. Re: Windows PowerShell vs. bash examples

    After takin' a swig o' grog, Tom Shelton belched out
    this bit o' wisdom:

    > On Nov 10, 3:48*pm, Chris Ahlstrom wrote:
    >
    >> The proliferation of scripting-cum-glue-languages is a good thing. *You have
    >> Ruby, Python, Perl, the various sh-shells, and, on the Windows side,
    >> VB/WSH/Powershell. *Although I no longer get very deep into the Windows end,
    >> it's nice to have this ferment.

    >
    > uh, you also have ruby, python, and perl on the windows side as
    > well and a bunch of sh-shells. I have bash on here, and I used to
    > have korn (part of SFU).


    My bad for not being clear.

    I first encountered a UNIX shell on DOS with MKS tools. It was the Korn
    shell, too, though I never used it at all for scripting back then.

    --
    If not completely satisfied, return for full refund of purchase price.

  15. Re: Windows PowerShell vs. bash examples

    [snips]

    On Mon, 10 Nov 2008 13:31:12 -0800, Tom Shelton wrote:

    > I brought up using shell.applicaiton to do the decompression, simply
    > because - System.IO.Compression sort of sucks for anything beyond very
    > simple applications, and for the example (a self extracting raw
    > installer), I didn't want the baggage of distributing a real compression
    > library like #ziplib.
    >
    > If you are fine with cab files


    I prefer .tgz or .tar.bz as a rule.

    >, then you could use the built in
    > commandline tools that windows supplies - makecab and expand (at least
    > win2k and up).


    Sounds good. What do they bundle which supports some sane non-
    proprietary format? Bzip-compressed tarballs, for example?


    >> Bash, by contrast, does exactly the opposite - what it ain't got
    >> internally, it spawns sub-commands for. *Shell commands. *Programs one
    >> _can_ run directly.

    >
    > No different then powershell. It's just that:


    Funny, then, that the examples thus far all say otherwise.

    > 1) Because powershell is based on .NET it has lot more internally.


    Right; since you're tied to a largely proprietary framework, we should
    all immediately jump on this.

    > 2) It
    > can understand com interfaces exposed by windows and other applications
    > natively


    Whereas nothing else in the universe can, because when 112 development
    companies got together and decided to adopt a "universal" mechanism for
    handling such things, 111 of them managed to agree on it while a certain
    other decided to do something different, thus ensuring their
    incompatibility with everything under the sun. Yes, we're all quite
    familiar with COM, thanks.

    > 3) can call any native command line application.


    Yet in example after example, this supposed strength of it fails to come
    out. Funny that.


    > obviously, powershell scripts that rely on COM api's are not going to be
    > directly portable.


    Gee, ya think?

    > And I give bash a check mark in the more cross-
    > platform box. But, I think you are thinking that PS relies a lot on COM
    > - it doesn't - but a lot of windows services do.


    Which means PS does, though indirectly. The one redeeming feature it
    might actually have - decent cli support - seems to be missing in the
    examples *and* missing support from MS.

    >> This, to me, is not a good thing. *It smacks too much of the endlessly
    >> repeated "We got some tool - Excel, IIS, whatever - we wrote a mess of
    >> code specific to it, now we can't afford to switch platforms or tool
    >> sets."


    > If you are already using Excel, IIS, whatever, then adding ps to the mix
    > isn't really changing anything.


    OpenOffice and Apache, thanks. And what you just said doesn't make a lot
    of sense. Adopting PS with its com-based interface (or .NET-based) is
    little better than just writing VBScript - you're *still* using what
    amounts to a Windows-only and fundamentally unportable tool. In this day
    and age where people - developers, at least - should know better, why
    would they do such a thing? Complete blindness to the fact MS is a small
    and diminishing world?

    > It's just making it easier for windows
    > admins to do their jobs...


    Which can be done *without* tying them to proprietary APIs, which is
    kinda the point you seem to be missing, repeatedly.

    > I am certain that a Linux admin will not care much about powershell in
    > and of itself - but, might be interested in the paradigm behind it.


    "Ensure user code will not port to anything but MS." Yes, we know the
    paradigm.

    >> Last I checked, PS simply wasn't on most people's XP machines, and from
    >> what I'm hearing here, even if you do have PS on your machine, you
    >> still don't have the cli tools to make it a really sensible scripting
    >> environment.
    >>
    >>

    > grep maybe a bad example for you... It really depends on the context,
    > but if your searching for words in files, then that's pretty easy:
    >
    > ls -r -i *.txt 'c:\somepath\* | select-string -pattern "idiot" -
    > casesensitive
    >
    > pattern is a regular expression (and there are tons more options)


    So "select-string" is just another name for grep? Sounds good. Of
    course, select-string is a cli tool, right? One which, oh, I could copy
    over to or download to my XP machine which doesn't have the whole PS
    thing and still use? Might be handy, as long as I don't have to bugger
    around with umpteen hundred megs of crap just to get a tiny little
    utility.

    Or is it, as I suspect, not a cli tool at all, but another of those
    magical "builtin" things which requires 600MB of overhead to do a job I
    can do in 100K?

    > The other point you seem to be missing is that PS is really desinged for
    > power users and admins


    No, it's designed to tie users into MS toolchains to the point they
    cannot hope to ever escape. This is being repeatedly demonstrated by
    each example offered, each calling mechanism described, the reliance on
    COM to do many things, the absence of many cli tools a Linux admin would
    regard as necessary, etc, etc, etc.


    >- so, average joe probably isn't going to give
    > hoot about ps. Though, it ships with 2008 as an option and it will be
    > the default shell in Windows 7. If you need some of those other tools,
    > well you can download and install them via cygwin and use them from ps.


    Cygwin? Err... that's effectively adopting a *nix shell and utilities.
    If PS is so much better than bash et al, why would we need to skip PS and
    bring in the *nix goodies?

    >> Do feel free to show me wrong, though... just tell me where I find this
    >> PS thing on Joe Sixpack's XP machine and where all those other little
    >> cli tools - compressors and decompressors and pattern matching and
    >> string replacement and on and on and on - all live.


    > pattern matching, string replacement, etc are all part of ps.


    Yes, we get that. The question is where the cli tools live.

    We've seen - again and again and again - MS and many another Window
    developer making the boneheaded mistake of bundling 89,000 pieces of
    functionality into a single enormous tool, then being surprised when it
    breaks or when it's found to be unstable, insecure and the like.

    For 30 years and more, *nix has been *trying* to show MS the way: small
    tools, each doing a small part of the job, which can be combined as
    needed. Keep the tools small, keep them efficient, keep them safe.

    I keep hearing how PS is so much better, how it finally "gets it" by
    providing proper cli tools to actually do the tasks, how it has finally,
    after decades of MS getting it wrong, been designed with a sane
    architecture.

    Yet when we ask, what do we find? Exactly the opposite. "It uses .NET",
    the umpteen-MB monster. It builds "grep" in, instead of providing a
    proper tool which it could simply call.

    So the reality is, despite the claims of "designed by *nix fans", that
    it's just another MS monster with the same old MS design philosophy. And
    we've all seen how well that works, in little things like the 100 million
    plus viruses for Windows, the need for AV and anti-spyware and registry
    cleaners and in the fact that here it is, what, 20+ years after Windows
    first hit the market... and they *still* don't have a viable shell.

    Color me unimpressed.


  16. Re: Windows PowerShell vs. bash examples

    [snips]

    On Mon, 10 Nov 2008 13:53:32 -0800, Tom Shelton wrote:

    > I don't get this argument. Powershell relies on .NET


    Fine. I'll import the entire CPAN repository and we'll see whose dick is
    bigger. Or we can stop trying to compare _frameworks_ and focus on
    _tools_.

    As in, I don't care what .NET - or CPAN - can do for me. I want to know
    what PS or Perl can do for me. The most functional, powerful, flexible
    language in the world becomes essentially useless to many people, myself
    included, if it:

    a) Has sufficiently poor syntax it becomes difficult to write solid code
    b) Imposes - whether through lack of available additions, or by design -
    an undesirable methodology (i.e. reliance on COM, .NET, etc, rather than
    relying on a *nix-like chaining mechanism)
    c) Ties one to a particular platform, by largely relying upon non-ported
    and even non-portable APIs and the like.

    i don't know what PS's syntax is, beyond a quick "Looks like VB, gimme a
    break", but it falls on its face in the other two.

    Okay, fine, it can tie into .NET and yadda yadda happy bull****, who
    cares. It's just another MS tool to tie more things to an MS platform.
    Seen it before. 30 years late and lame in three legs.


  17. Re: Windows PowerShell vs. bash examples

    Verily I say unto thee, that jsnover13@hotmail.com spake thusly:

    > Jeffrey Snover [MSFT]
    > Windows PowerShell Architect


    Dear Jeffrey,

    It seems as though, thanks to you, Microsoft finally has a viable
    command line, although as you admit, you still have some way to go.

    I can't help but feel this may be too little too late, however,
    especially since this development seems antithetical to the overall
    direction Microsoft is heading with Vista and 7.

    While it is true that Linux users tend to have a more autonomous
    ideology; prefer to "DIY"; and hence have a predisposition towards
    complex scripting, Windows users OTOH tend to be quite the opposite,
    and seem to have an almost pathological aversion to anything more
    complex than choosing between one of two buttons in a GUI ("OK" or
    "CANCEL"). Each successive release of Microsoft's operating system has
    attempted to further enforce this ideology of "simplicity", with the
    (what I must assume is) ultimate goal of changing the user experience
    into something akin to an almost entirely non-interactive activity, such
    as watching television.

    I must admit, I am somewhat perplexed as to where something like
    PowerShell fits in to this vision of Windows' future. Perhaps you can
    explain this apparent contradiction.

    As one of the aforementioned Linux users, and someone whose preferred
    environment is the command line, here are the only two questions I need
    answered in order to determine if PowerShell is useful to me, and indeed
    the answers to these questions may also determine whether or not any
    discussion of PowerShell is even relevant, let alone useful, in the
    Linux advocacy newsgroup:

    1) ... Is PowerShell multi-platform (counting all Microsoft products as
    a single platform, in case there's any doubt), and specifically -
    does it run on Linux?
    2) ... Is it Free Software (and again to save any confusion, I mean is
    it licensed in such a way as to uphold the Four Freedoms as
    expounded by the Free Software Foundation)?

    If the answer to any of those questions is anything other than "yes",
    then I fear your evangelism has been completely wasted on me and this group.

    Thanks anyway.

    --
    K.
    http://slated.org

    ..----
    | "At the time, I thought C was the most elegant language and Java
    | the most practical one. That point of view lasted for maybe two
    | weeks after initial exposure to Lisp." ~ Constantine Vetoshev
    `----

    Fedora release 8 (Werewolf) on sky, running kernel 2.6.25.11-60.fc8
    01:11:32 up 5 days, 8:54, 3 users, load average: 0.08, 0.08, 0.07

  18. Re: Windows PowerShell vs. bash examples

    On Nov 10, 5:57*pm, Kelsey Bjarnason wrote:
    > [snips]
    >
    > On Mon, 10 Nov 2008 13:53:32 -0800, Tom Shelton wrote:
    > > I don't get this argument. *Powershell relies on .NET

    >
    > Fine. *I'll import the entire CPAN repository and we'll see whose dick is
    > bigger. *Or we can stop trying to compare _frameworks_ and focus on
    > _tools_.
    >
    > As in, I don't care what .NET - or CPAN - can do for me. *I want to know
    > what PS or Perl can do for me. *The most functional, powerful, flexible
    > language in the world becomes essentially useless to many people, myself
    > included, if it:
    >
    > a) Has sufficiently poor syntax it becomes difficult to write solid code
    > b) Imposes - whether through lack of available additions, or by design -
    > an undesirable methodology (i.e. reliance on COM, .NET, etc, rather than
    > relying on a *nix-like chaining mechanism)
    > c) Ties one to a particular platform, by largely relying upon non-ported
    > and even non-portable APIs and the like.
    >
    > i don't know what PS's syntax is, beyond a quick "Looks like VB, gimme a
    > break", but it falls on its face in the other two.
    >


    It doesn't look anything like VB. In fact, it looks closer (and
    behaves a lot like) Perl.

    Here is a small part of my customized profile:

    set-alias vi vim

    function Prompt
    {
    $host.ui.RawUI.WindowTitle = $(get-location)
    write-host ($CurrentUser.Name) -nonewline -foregroundcolor Green
    " $ "
    }

    function Edit-Profile
    {
    & $env:EDITOR $profile
    $response = read-host -p "Source Profile? [Y]es [N]o"
    if ($response -ieq "y")
    {
    . $profile
    }
    }

    --
    Tom Shelton

  19. Re: Windows PowerShell vs. bash examples

    Homer writes:

    > Verily I say unto thee, that jsnover13@hotmail.com spake thusly:
    >
    >> Jeffrey Snover [MSFT]
    >> Windows PowerShell Architect

    >
    > Dear Jeffrey,
    >


    Note To Jeffery : Homer is a pathological loony.

    > It seems as though, thanks to you, Microsoft finally has a viable
    > command line, although as you admit, you still have some way to go.


    Here we go ....

    >
    > I can't help but feel this may be too little too late, however,


    Yes, Linux won the war eh Homer? Idiot.

    > especially since this development seems antithetical to the overall
    > direction Microsoft is heading with Vista and 7.


    *chuckle*

    >
    > While it is true that Linux users tend to have a more autonomous
    > ideology; prefer to "DIY"; and hence have a predisposition towards


    No. Most prefer just not to pay for anything and have zero experience of
    the corporate desktop and the programs people use daily to run their
    businesses.


    > complex scripting, Windows users OTOH tend to be quite the opposite,
    > and seem to have an almost pathological aversion to anything more
    > complex than choosing between one of two buttons in a GUI ("OK" or
    > "CANCEL"). Each successive release of Microsoft's operating system has
    > attempted to further enforce this ideology of "simplicity", with the


    What a lot of nonsense. And I suppose Gnome is a complex GUI for
    geniuses is it?

    You do talk some rubbish.


    > (what I must assume is) ultimate goal of changing the user experience
    > into something akin to an almost entirely non-interactive activity, such
    > as watching television.


    Clearly Homer thinks people fiddle with scripts rather than use the well
    tailored GUI UIs people want and need to interact with powerful utility
    programs which benefit their working process.

    Homer would rather pipe a bit stream through imagemagick than click or
    hot key "filter" in Paint Shop Pro. Homer is a nut case.

    >
    > I must admit, I am somewhat perplexed as to where something like
    > PowerShell fits in to this vision of Windows' future. Perhaps you can
    > explain this apparent contradiction.


    The only contradiction is in your deceased mind.

    >
    > As one of the aforementioned Linux users, and someone whose preferred
    > environment is the command line, here are the only two questions I
    > need


    Aha. You admit it. You are therefore incapable and unsuited to ever
    comment on GUI systems.

    *EOS*

  20. Re: Windows PowerShell vs. bash examples

    On Mon, 10 Nov 2008 09:35:06 -0800, Kelsey Bjarnason wrote:

    > On Sun, 09 Nov 2008 21:56:04 -0600, Terry Porter wrote:
    >
    >> On Sun, 09 Nov 2008 19:47:35 -0500, Erik Funkenbusch wrote:
    >>
    >>> On Sun, 9 Nov 2008 12:50:27 -0800, Kelsey Bjarnason wrote:
    >>>
    >>>

    >>
    >>
    >>>>> They're all built-in or .net functions.
    >>>>
    >>>> PS is built-in? Bull****.
    >>>
    >>> Are you a ****ing idiot?

    >>
    >> No Erik the Wintroll, Kelsey is no idiot, in fact Kelsey possesses the
    >> kind of mind that when focused, sets morons like you on fire quite
    >> easily.
    >>
    >> I've still got the burn marks from when Kelsey focused on me several
    >> years ago.
    >>
    >> Unlike you tho, I soon realised *I* was the ****ing idiot.
    >>
    >>

    > Nobody's perfect.
    >
    > When you returned, I was more than ready to either killfile you or vent
    > some in your direction, as I couldn't think of a more deserving target.


    Perfectly understandable.

    >
    > That said, I _also_ decided to let you dig your own grave. You haven't.
    > So, on that note, here's _my_ formal "Welcome back, Terry". Go kick a
    > troll for us.


    Thanks Kelsey

    --
    If we wish to reduce our ignorance, there are people we will
    indeed listen to. Trolls are not among those people, as trolls, more or
    less by definition, *promote* ignorance.
    Kelsey Bjarnason, C.O.L.A. 2008

+ Reply to Thread
Page 10 of 11 FirstFirst ... 8 9 10 11 LastLast