LWN: Comments on "Evolution of shells in Linux (developerWorks)"

Sorry, but this is wrong. Dead wrong.

tom.prince — Fri, 16 Dec 2011 05:11:59 +0000

>>Yes, it's not 100% automatable without a bit of per-tool scripting. The workload is minimal compared to writing the tools. Perhaps in an ideal world it could be completely automated, but that just shifts the burden from writing the autocompletion code to writing some sort of reflective description of the system. Big deal.

>And in PowerShell I get autocompletion basically for free. And it's good. It's VERY good. I'm actually using PowerShell instead of Postgres's psql because PowerShell is much more powerful.

You only get this for free, if your software is designed to work with PowerShell, otherwise you are in the same boat as with zsh/bash.

There is at least one framework (twisted-python) that automatically generates zsh completions from the description of options.

Evolution of shells in Linux (developerWorks)

useerup — Fri, 16 Dec 2011 03:56:08 +0000

I believe he may be referring to the fact that PowerShell not only allows objects to be passed through the pipes, but also allows you/the script to actually *interact* with the objects, ie calling methods.

Evolution of shells in Linux (developerWorks)

useerup — Fri, 16 Dec 2011 03:33:23 +0000

You err because you want PowerShell to act exactly the way POSIX shells do. PowerShell is actually a bit more structured and it may require you to do things in a little different way. The advantage is that many of the error-prone constructs in bash are avoided.

For your example try this:

PS>$foo="/groups","/user"
PS>whoami $foo

And then try
PS>whoami $foo[0]
PS>whoami $foo[1]

PowerShell actually integrates quite nicely with external programs; it does so even retaining (not re-interpreting) arguments.

In your example you told PS to pass a string containing "arg1 arg2" to an external program - which it did. You assume that the entire commandline is turned into text and re-interpreted (the way of POSIX shells).

As you can see above, PowerShell understands arrays and will readily pass the array items as discrete arguments. It's not harder - just a little different and a lot more robust and avoids the risk of injection vulnerabilities.

Evolution of shells in Linux (developerWorks)

tertium — Wed, 14 Dec 2011 00:01:46 +0000

Then you might find this useful: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467231 (disclaimer: I'm the original reporter). The script still works fine for me, I only added "declare -p bash4 2>/dev/null" when upgraded to bash 4.

Evolution of shells in Linux (developerWorks)

ccchips — Tue, 13 Dec 2011 16:20:05 +0000

There should be a fix because people need to use that information, not dig around on the Internet, figure out how braindead the timestamp is, and come up with a scheme to read it in human-readable form. Quest Software fixed it by providing a conversion method.

I was asking about fixing *accessibility to the information.* Which is far more important to me than what shell handles what arguments, and how the pipelines work.

Evolution of shells in Linux (developerWorks)

cmccabe — Mon, 12 Dec 2011 23:33:49 +0000

TermKit is (was?) an extremely ambitious project basically involving a redesign from scratch of the whole terminal system. It seems like they wanted it to be GUI-based and mostly coded in HTML5.

What I am thinking of is just a set of utilities to manipulate JSON easily-- nothing more, nothing less.

Evolution of shells in Linux (developerWorks)

Cyberax — Mon, 12 Dec 2011 21:41:33 +0000

No. Why should there be a fix?

LastLogon is a valid timestamp, just in a very braindead format (in 100-s nanosecond increments since 1601).

Evolution of shells in Linux (developerWorks)

ccchips — Mon, 12 Dec 2011 21:34:50 +0000

Interesting.

Does Samba4 or related utility have the fix?

I was a bit surprised to learn about the [System.DateTime]::FromFileTime() function in Powershell. I did a lot of research into this previously and didn't see that.

Evolution of shells in Linux (developerWorks)

Cyberax — Mon, 12 Dec 2011 21:08:11 +0000

That's mostly a problem of the tool itself. AD is just braindead in many respects. We just have to live with it.

Samba4 on Linux has the same behavior, btw.

Evolution of shells in Linux (developerWorks)

raven667 — Mon, 12 Dec 2011 18:59:39 +0000

For good reason, as I said--such systems have never won out in the past, why should .NET and PowerShell be any different?

What is this "winning" you are concerned about? PowerShell is already the preferred standard command shell and scripting environment on MS Windows servers and is not really relevant outside that space. UNIX shells like bash are really only relevant on UNIX systems, they have only marginal presence in the Windows space, so there is really no context where "winning" makes sense as they are not directly comparable.

The idea that the shell can be both built out of and expose a full featured programming language and library is not new as you point out but is well demonstrated by PowerShell and not a bad idea.

Evolution of shells in Linux (developerWorks)

raven667 — Mon, 12 Dec 2011 18:48:44 +0000

But it still strikes me as odd how a discussion of UNIX shells and their evolution turned into an argument about how great Powershell is compared to all the other methods people have used to perform system administration activities.

Well, it didn't start out that way, there was just one "PowerShell is neat" post and in response a flurry of negative responses were written which lead to a lively discussion.

Evolution of shells in Linux (developerWorks)

ccchips — Mon, 12 Dec 2011 18:31:09 +0000

Oh, and I did do some research into this. It is possible to do, but I don't find the solution to be any indication of how great Powershell is compared to the other UNIX shells. Yeah, there's a system function to convert this, but again, we're supposed to be making it easier for administrators to do their work, not requiring them to do research into date/time conversions from a "standard" tool.

It is good, as far as I'm soncerned, that Windows system administrators now have a decent shell to work with in their day-to-day activities, and I laud Microsoft for this. In my shop, it has been hard to get administrators to script *anything* before Powershell, as they were not willing to use Perl, Awk, Python, etc. And Powershell does have some interesting innovations. But it still strikes me as odd how a discussion of UNIX shells and their evolution turned into an argument about how great Powershell is compared to all the other methods people have used to perform system administration activities.

Evolution of shells in Linux (developerWorks)

ccchips — Mon, 12 Dec 2011 18:05:06 +0000

Ah, yes - so I hand the above link to a new system administrator who has to use Powershell, ask him to give me a list of Last Logon Dates for anyone who hasn't logged on in 30 days, and.....then what?

This issue should have been addressed *before* Microsoft releasted the Active Directory tools for Powershell, not after, and not by requiring some kind of conversion kluge.

Evolution of shells in Linux (developerWorks)

jimparis — Mon, 12 Dec 2011 17:42:46 +0000

I know, that matches the behavior of the PowerShell code that Cyberax posted (as far as I can tell). Not really "touch" but "make this file empty".

Evolution of shells in Linux (developerWorks)

Cyberax — Mon, 12 Dec 2011 17:27:32 +0000

Uhm. That's a timestamp in awful ActiveDirectory format. No need for third-party software.

http://msdn.microsoft.com/en-us/library/windows/desktop/m...

Evolution of shells in Linux (developerWorks)

mpr22 — Mon, 12 Dec 2011 17:07:23 +0000

That only works if the file doesn't exist. Otherwise, it replaces your file with an empty file.

Evolution of shells in Linux (developerWorks)

ccchips — Mon, 12 Dec 2011 16:44:10 +0000

LastLogon: 129681773131629678
LastLogonTimestamp: 129681773131629678

Quest Software fixed this in their product, which is, fortunately "free beer."

Somehow, I think we've been trolled. Smoke signals?

Evolution of shells in Linux (developerWorks)

jimparis — Mon, 12 Dec 2011 16:40:13 +0000

That's just about the most trivial thing you can do:

>filename

Evolution of shells in Linux (developerWorks)

Cyberax — Mon, 12 Dec 2011 08:59:50 +0000

>The point was that the 'sort' utility used in PowerShell only really adds anything over the standard Unix sort command if the source application includes bindings for .NET.[1] A similar utility could be written for Unix with the same features, if anyone was actually interested.

The problem is, you have to write a special-case utility. While PowerShell provides you a generic mechanism for this. It provides a robust platform that other systems can use.

And some features of sort are quite difficult to replicate in bash, for example, custom comparators (I believe, the only way to do this is to create string ordinals suitable for the 'sort' utility).

You've mentioned D-BUS - it's actually quite similar to PowerShell in a lot of regards. It provided a platform that other applications could easily use and adapt (instead of inventing their own ad-hoc remoting). And so application quickly adopted it. The same is happening with PowerShell in Windows.

>For good reason, as I said--such systems have never won out in the past, why should .NET and PowerShell be any different?

Well, it is different because it's already adopted in the Windows world and it's clear that PowerShell is here to stay.

And I think the main reason for adoption is that the time has come for it. All the ingredients for PowerShell were finally in place - even twelve years ago it would have been impossible without the common environment that .NET provides (PowerShell based on COM? Shudder).

The same story with DBUS - there quite a few failed attempts to build a common desktop RPC system in Unix: DCE RPC, DCOP, CORBA in GNOME and I probably forgot quite a few others. Yet DBUS has clearly won and is now ubiquitous. We even have projects for kernel-accelerated DBUS.

>[1] Purely out of curiosity, how does this kind of sort command work if the data is coming from a file, without the .NET APIs, rather than directly from an application?

That depends on what you're trying to do. You surely can dump objects' content in XML/JSON/binary but it's rarely useful in practice. More often you'd use FT command (Format-Table) to create textual representation that fits your purposes. For objects like files or list of files you can dump them as simple filenames. PowerShell is quite flexible in that regard.

Evolution of shells in Linux (developerWorks)

nybble41 — Mon, 12 Dec 2011 06:25:09 +0000

>> It's not like PowerShell automatically adds support for sorting arbitrary data to an existing sort utility, either.

> But it does. You can easily sort any data on any field even using your own custom comparator (try that with 'sort'!), using only one utility. Which had to be written, just as 'sort' utility in Unix.

The point was that the 'sort' utility used in PowerShell only really adds anything over the standard Unix sort command if the source application includes bindings for .NET.[1] A similar utility could be written for Unix with the same features, if anyone was actually interested. It's not exactly a difficult problem, even including fancy features like custom comparators. The critical part is a runtime-specific binding for the source application. If aptitude had bindings for Python, Ruby, or Scheme you could do exactly the same thing from these shells under Unix today. It wouldn't require any more work than implementing the .NET bindings necessary to make aptitude work with PowerShell (assuming they worked on the same platform to begin with). In fact, if aptitude had a DBUS interface, as many other application s do, it would automatically with with all these Unix shells and more.

> Well, of course you can achieve the same functionality as in PowerShell by replicating what PowerShell does (namely, by introducing structured data). The point is - no one is really doing it in the Unix world.

For good reason, as I said--such systems have never won out in the past, why should .NET and PowerShell be any different? Anyway, my suggestion wasn't to replicate what PowerShell does, it was to implement a record-oriented sort utility within the existing Unix byte-stream framework, using a standard data encoding rather than opaque "structured data" in a particular runtime. Historically, forcing everything to work within a single complex runtime or RPC model has not been a winning strategy. Simple, portable, reliable interfaces as best.

----

[1] Purely out of curiosity, how does this kind of sort command work if the data is coming from a file, without the .NET APIs, rather than directly from an application? Is it even possible to get the same effect as redirecting the output of a command to a file before sorting it, or must the source and sort command be directly coupled? It seems like the extra features must get lost in translation, since only the textual representation will be saved on disk.

Evolution of shells in Linux (developerWorks)

Cyberax — Mon, 12 Dec 2011 06:00:18 +0000

Well, try to write 'touch' utility in Bash (assume that there's no 'touch' utility present).

Evolution of shells in Linux (developerWorks)

Cyberax — Mon, 12 Dec 2011 05:58:24 +0000

>It's not like PowerShell automatically adds support for sorting arbitrary data to an existing sort utility, either.

But it does. You can easily sort any data on any field even using your own custom comparator (try that with 'sort'!), using only one utility. Which had to be written, just as 'sort' utility in Unix.

>You could get the same effect by standardizing the labeled-groups-of-lines format output by 'aptitude show' and writing a sort utility specialized on that format (a 10-minute job in any major scripting language). Or you could just use one of the many portable interactive scripting language shells, like python or irb or scsh, which provide the same services for their respective bindings that PowerShell provides for .NET.

Well, of course you can achieve the same functionality as in PowerShell by replicating what PowerShell does (namely, by introducing structured data). The point is - no one is really doing it in the Unix world.

Evolution of shells in Linux (developerWorks)

chuckles — Sun, 11 Dec 2011 23:59:38 +0000

or just use:
touch ./-a

rm ./-a

In PowerShell it's all natural:
>function touch {set-content -Path ($args[0]) -Value ([String]::Empty) }
>touch -test

lol. 'all natural' sorry that made me laugh.

Evolution of shells in Linux (developerWorks)

nybble41 — Sun, 11 Dec 2011 22:48:35 +0000

It's not like PowerShell automatically adds support for sorting arbitrary data to an existing sort utility, either. Microsoft also had to write a new sort utility to handle structured data, which in turn relies on API support from the applications supplying that data. You could get the same effect by standardizing the labeled-groups-of-lines format output by 'aptitude show' and writing a sort utility specialized on that format (a 10-minute job in any major scripting language). Or you could just use one of the many portable interactive scripting language shells, like python or irb or scsh, which provide the same services for their respective bindings that PowerShell provides for .NET.

An aptitude-equivalent under PowerShell would need to export the ability to compare package objects by version for any third-party sort utility to work with the data anyway, which is 90% of the way toward just implementing the -O option internally.

"Structured data" is nearly always the first thing anyone tries when implementing a new system. A number of older systems don't support anything *but* structured data for disk files, for example--I've worked on operating systems where even plain text files were stored, one row per line, as tables in a database. The fact that all modern systems actually treat disk files and most inter-process communications as plain byte streams should tell you something. Standardized data *formats*, encoded as plain byte streams, are more flexible and resilient than standardized APIs, as used by PowerShell.

Sorry, but this is wrong. Dead wrong.

raven667 — Sun, 11 Dec 2011 17:03:09 +0000

I also think that standardization wasn't an unmitigated positive because it solidified and made rigid 20 years worth of crufty, work-in-progress system software and didn't allow for any forward progress for cleaning up the mess. GNU helped a lot but only now are we going back and re-thinking the system from the beginning and making it super awesome. Plan9 did much of the same work but failed because it wasn't a gradual, in-place migration path.

Sorry, but this is wrong. Dead wrong.

anselm — Sun, 11 Dec 2011 16:21:14 +0000

Which would be why POSIX, uh, standardized them more than ten years ago, and imposed rules which virtually all standard tools follow.

Some of the most basic aspects were indeed standardised by POSIX, but that doesn't detract from the fact that, say, the option to specify a field delimiter is »-d« for cut(1), »-t« for sort(1), »-F« for awk(1), and so on. POSIX basically codified the wild hodgepodge that existed at the time.

Now the meaning of common options (as opposed to basic option syntax) would have been something actually worth standardising, but of course it would have rendered 20 years' worth of shell scripts virtually useless, so it didn't happen.

Sorry, but this is wrong. Dead wrong.

Cyberax — Sun, 11 Dec 2011 11:50:58 +0000

>I'll agree that man is not a very nice documentation system, but it *is* one, so your claim that it does not exist is vacuous on its face.

I'm claiming that it's not a GOOD system.

>Ah. Like POD, doxygen, and similar systems, all of which can generate manpage output. i.e., dead heat here.

So... How do I make documentation for my bash script (with all its options), make a man page, link it into the central system and all of it without doing anything more than simply declaring options?

And no, doxygen won't help you - it doesn't support bash (I'd actually tried to find an automatic documentation system for bash some time last year - there was none).

>That's great -- if and only if Microsoft wrote the tool. Only useful in a software monoculture.

That's easily adapted if tools' authors provide their own URLs (which they can do in PowerShell - VMWare has its own doc system, for example).

>Yes. Learn about apropos databases and MANPATH. Manpages can be stored absolutely anywhere (as can info pages).

I know perfectly well how most of Linux tools work. I know that one can maintain their own local man databases. And I also know perfectly well that almost nobody does, mostly because it's complicated and error-prone.

>Most of the rest of what you say is a combination of ignorance of what the Unix tools you discuss can actually do, and complaints that things are not acceptable because they're not just like PowerShell does them.

I know most of the standard Unix tools. I've built my own custom distributions from scratch (first time without the benefit of the LFS book) and support a network of embedded devices. I've been using Linux on my desktops since 90-s and can recollect all the steps that have been taken to make Linux to be at least possible to use on desktop.

A lot of these steps involved bashing at least some old Unix-heads with spiked hammers: udev, HAL, KMS, dbus to name a few. Oh, and the whole 'Android' thingie. Now the same thing repeats with pulseaudio, systemd and journald.

>We get that you like it, but we've all been through this parochial 'the newest system I just saw is the answer to everyone's prayers' phase, and, y'know? It's always wrong. There are limitations there: you're just not seeing them.

Some things do solve all the (existing) problems. Because they are designed to solve them.

PowerShell is one such example. It's designed to be a better shell than text-based shells and it excels at it. It's not yet as polished as bash/zsh but it's getting better with each new release.

Of course, PowerShell has limitations and a set of new problems, but so does bash/zsh. And limitations of bash/zsh are MUCH more constricting.

Evolution of shells in Linux (developerWorks)

HelloWorld — Sun, 11 Dec 2011 11:22:57 +0000

There was a project like that actually:
http://lwn.net/Articles/443473/
I haven't heard of it since though, and its github repo hasn't seen any activity since June.

Sorry, but this is wrong. Dead wrong.

nix — Sun, 11 Dec 2011 11:07:52 +0000

I'll agree that man is not a very nice documentation system, but it *is* one, so your claim that it does not exist is vacuous on its face.

PowerShell allows to embed documentation directly into objects and also structure it by parameters, methods, etc.

Ah. Like POD, doxygen, and similar systems, all of which can generate manpage output. i.e., dead heat here.

And there's nice "-online" switch that leads you directly into the TechNet article associated with tool, with Q&A and other additional functionality.

That's great -- if and only if Microsoft wrote the tool. Only useful in a software monoculture.

Can you make your scripts in your home directory have their documentation automatically be included and made searchable into the central help system?

Yes. Learn about apropos databases and MANPATH. Manpages can be stored absolutely anywhere (as can info pages).

Most of the rest of what you say is a combination of ignorance of what the Unix tools you discuss can actually do, and complaints that things are not acceptable because they're not just like PowerShell does them. We get that you like it, but we've all been through this parochial 'the newest system I just saw is the answer to everyone's prayers' phase, and, y'know? It's always wrong. There are limitations there: you're just not seeing them.

Evolution of shells in Linux (developerWorks)

HelloWorld — Sun, 11 Dec 2011 10:39:51 +0000

You're missing the point. The point is that it's not possible to use the sort(1) tool to actually sort stuff. The fact that aptitude offers the -O switch for sorting is a symptom of that problem, as it wouldn't be necessary to implement sorting in aptitude if Unix shells sucked less.

Sorry, but this is wrong. Dead wrong.

Cyberax — Sun, 11 Dec 2011 05:36:23 +0000

>So... the central Unix documentation system is not acceptable because... you say so?
Nope. Man's shortcomings are well known. It's basically a simple indexed document storage, without built-in searching and poorly structured.

PowerShell allows to embed documentation directly into objects and also structure it by parameters, methods, etc.

And there's nice "-online" switch that leads you directly into the TechNet article associated with tool, with Q&A and other additional functionality.

Can you make your scripts in your home directory have their documentation automatically be included and made searchable into the central help system?

>I'd rather use man than HTML Help with its abysmal searching, insulting baby talk, and horrendous security holes.

You're in luck because PowerShell doesn't use HTML Help :)

>Which would be why POSIX, uh, standardized them more than ten years ago, and imposed rules which virtually all standard tools follow.

Yeah, sure.
> tar czf myfile myfile.tgz
Damn, I just deleted 'myfile' with doubly-archived myfile.tgz

> dd if=... of=...
Very standard.

Then there are --argument=blah and "--argument blah" forms which don't always work. And then there are short forms which sometimes require argument to be written immediately without intervening spaces.

In PowerShell _everything_ is standardized _and_ autocompleteable. I can do things like "my-command -p<tab>" and get the list of parameters (with description and default values!) starting with 'p'. This is sort of possible in bash/zsh with cooperating tools, but in PowerShell it's all completely automatic.

And since PowerShell is a static language with type inference, it'll warn me if I write stuff like this "destroy-hard-drive -in hello -seconds" (because 'hello' is not an integer).

>You carefully named the two shells which have extremely extensive autocompletion, in zsh's case shipped with the package

I know perfectly well how bash/zsh autocompletion work.

>Yes, it's not 100% automatable without a bit of per-tool scripting. The workload is minimal compared to writing the tools. Perhaps in an ideal world it could be completely automated, but that just shifts the burden from writing the autocompletion code to writing some sort of reflective description of the system. Big deal.

And in PowerShell I get autocompletion basically for free. And it's good. It's VERY good. I'm actually using PowerShell instead of Postgres's psql because PowerShell is much more powerful.

I can autocomplete table names while writing SQL queries. In command line.

This is not really possible in bash/zsh because text matching games only can lead you so far. Even autocompletion for scp in bash is already straining things.

I wish people would sometimes go out and see what's happening outside of the Linux/Unix world. It's not a wonder that the most popular Linux distribution is actually barely a Unix system.

It does not matter...

Cyberax — Sun, 11 Dec 2011 01:03:44 +0000

>They do offer introspection and as for "structured pipelines"... this is only important if you want to pretend you are replacing "shell proper".

Please show me how I can tab-complete SQL queries in any elisp shell. I'd like to be able to at least complete all table names in all contexts.

PowerShell is freakingly powerful in that regard - I already use it instead of psql shell to work with Postgres databases. Mostly because autocompletion in posh based on simple introspection is miles ahead of what's present in psql.

And that says something.

>If you don't like LISP Machines analogue then I have another for you: Space Shuttle

Yup. It's funny because bash is very much like Space Shuttle: it's old, it's expensive to use (bash hell scripts are not easy to write), it's prone to crashes, etc. The only reason it's used is because of a sunken costs of tons of hell scripts.

It's apples to oranges...

Cyberax — Sun, 11 Dec 2011 00:26:07 +0000

>Only if your program uses .NET - which is not always the case. In other cases you first need to write the command-line utility anyway and in addition you need to write the cmdlet. If you write command-line utility anyway then why bother with cmdlet at all?

Nope. VMWare doesn't use .NET but its PowerShell management interface is top-notch. git doesn't use PowerShell but posh-git beats bash_completion in usability.

Have you actually managed something on new Windows Server platforms? Or do you think that Windows Server is still used only for file-servers?

Sorry, but this is wrong. Dead wrong.

nix — Sun, 11 Dec 2011 00:11:50 +0000

3) No central documentation or help system. And no, 'man' isn't it.

So... the central Unix documentation system is not acceptable because... you say so? I'd rather use man than HTML Help with its abysmal searching, insulting baby talk, and horrendous security holes.

Scripts and utilities have all kinds of argument formats without any real convention.

Which would be why POSIX, uh, standardized them more than ten years ago, and imposed rules which virtually all standard tools follow. A couple of holes exist, mostly for backward compatibility or ease-of-use's sake (e.g. tail and head's - and +-based arguments) and a couple are just deeply unusual (e.g. find and dd), but most are pretty consistent, and the ones with weird user interfaces get comprehended in the end by frequent use. I'd prefer Lisp everywhere, but, face it, it's not gonna happen.

4) No discoverability. Autocompletion is not sanely possible in bash or zsh.

You carefully named the two shells which have extremely extensive autocompletion, in zsh's case shipped with the package. I don't know what you're trying to do, but you're doing such a good job arguing against yourself that I don't see why I need bother. (Yes, it's not 100% automatable without a bit of per-tool scripting. The workload is minimal compared to writing the tools. Perhaps in an ideal world it could be completely automated, but that just shifts the burden from writing the autocompletion code to writing some sort of reflective description of the system. Big deal.)

It's apples to oranges...

raven667 — Sun, 11 Dec 2011 00:07:53 +0000

Ok, we get it, you don't like (MS, .NET/C#, PowerShell) The idea that MS or the industry in general is moving away from VM style languages is just laughable as is the idea that .NET is an "abomination". We can certainly have a discussion on the merits but this isn't one.

It does not matter...

dlang — Sat, 10 Dec 2011 13:15:03 +0000

the shuttle was also an attempt to 'greenify' space travel, by making things reusable.

It's apples to oranges...

khim — Sat, 10 Dec 2011 08:57:36 +0000

Because writing a cmdlet is like 10 times easier than writing a command-line utility!

Only if your program uses .NET - which is not always the case. In other cases you first need to write the command-line utility anyway and in addition you need to write the cmdlet. If you write command-line utility anyway then why bother with cmdlet at all?

Especially if you are using .NET (which most large vendors already do at least for some functionality).

Not especially. Only. If you don't use .NET then it's easier to write command-line utility - and while large vendors are prone to misallocation of the resources even Microsoft is ready to scale back this abomination as Windows8 shows. But it'll probably be 10 more years till it's finally dropped...

And it's already happening - all good software vendors for server-side apps on Windows already expose functionality using PowerShell.

s/good/buzzword-compliant/

PowerShell is obvious waste of the resources, but it's not a zero-sum game: most sensible solutions are not the ones which sell well thus sometimes you need to invest in the most buzzword-compliant approach. But it only makes sense if this approach slays buzzword. When it's no longer the case support dries up quite fast. As world becomes less Windows-centric and Windows becomes less .NET-centric it makes less and less sense to spend resources on PowerShell.

People will probably not drop already written things (albeit it may happen later), but new developments... I doubt it.

It does not matter...

khim — Sat, 10 Dec 2011 08:41:18 +0000

Nothing had ever came close to PowerShell in functionality and usability for system shells. And no, old elisp shells or Rexx scripts ARE NOT the answer. They don't offer the two most powerful features of PowerShell: introspection and structured pipelines.

They do offer introspection and as for "structured pipelines"... this is only important if you want to pretend you are replacing "shell proper".

Sorry, but PowerShell can do ANYTHING bash can do. Without exceptions.

So what? Any turing-complete language with support for fork/exec (or CheateProcess on Windows) can do the same.

Some things might be more clumsy than in bash - because PowerShell is not bash and things are done differently there.

And that's the point: PowerShell can not replace bash so bash will survive while PowerShell will die (or at least will be relegated for niche work).

If you don't like LISP Machines analogue then I have another for you: Space Shuttle. This extremely expensive program was invented to replace old rockets: Atlas, Delta, Saturn, etc. Just like PowerShell it promised the world and delivered very little¹. After all the hype and all the expenses it was only able to replace few of them - the ones which were forcibly killed to "open the road for the future". Today Space Shuttle is history and in it's place is huge glaring void - while people who were sensible enough to continue to use "old school" tools (Delta, Proton, Soyuz, etc) are still around and doing what Space Shuttle was supposed to do.

PowerShell integration with git is much nicer than in bash: https://github.com/dahlbyk/posh-git - and achieves the similar functionality in a fraction of lines of code.

It does not matter how many lines of code it requires. The same story as with Space Shuttle: sunk costs. When people try to justify Space Shuttle craze they compare development costs of Saturn V² and Space Shuttle - but this is completely wrong: it was not possible to get money spent on Saturn V back, thus you need to compare ongoing costs of Saturn V with new development costs of Space Shuttle - and there are no comparison.

CMD/Bash is here, it's not goes away so program will need to support it anyhow. This means all additional developments (things like cmdlets) should be counted extra.

¹) Well, one nice property of this stupidity was the fact that they managed to convince USSR to waste a lot of resources for the mirror project - and if this was the goal then the project can be considered success.

²) Why Saturn? Well, alternative for Space Shuttle idiocy was continuation of Saturn program so it's only natural to compare Space Shuttle to Saturn.

Relative youth?

Cyberax — Sat, 10 Dec 2011 07:28:04 +0000

>Nope. It's an Achilles' heel. PowerShell is half-decade old already, so you can not say it's all that young. It's just not a shell replacement, it belongs to a long list of "universal glue languages" (which were rarely all that universal).

No. It IS the shell replacement. It also is a glue language.

>Why? Because they assume programs will offer specialized interfaces just for that one flavor or scripting. But developers of a lot of programs just don't care enough to do that! They may provide some kind of command line switches and/or offer some textual output (because it's easy),

Sure. And you can work with these programs just fine. It's not going to be as natural as working with native cmdlets, but it's good enough to work with legacy stuff.

For example, PowerShell's git integration is nicer than in bash/zsh and takes only a fraction of code for the similar functionality. See for yourself: https://github.com/dahlbyk/posh-git

>but why should they bother to offer all these other things? This is not what they are paid for!

Because writing a cmdlet is like 10 times easier than writing a command-line utility! It saves time! Especially if you are using .NET (which most large vendors already do at least for some functionality).

And it's already happening - all good software vendors for server-side apps on Windows already expose functionality using PowerShell. Like: VMWare, Amazon Cloud, MSSQL, etc.

Keep dreaming...

Cyberax — Sat, 10 Dec 2011 07:18:42 +0000

Yeah, yeah. .NET is just a rehash of old LISP machines, everything has already been invented in 1969, Lennart is an agent of Microsoft and we kids should get out of your lawn.

Nothing had ever came close to PowerShell in functionality and usability for system shells. And no, old elisp shells or Rexx scripts ARE NOT the answer. They don't offer the two most powerful features of PowerShell: introspection and structured pipelines.

>It's more powerful but it's more complex, too. You may as well say that emacs prompt is more powerful then bash - and you'll be right. But it only helps you if you want to want in "Emacs OS". When you need to interact with a real world it's more complex then bash or zsh because it needs to do what bash/zsh are doing and it needs to do it in a way which makes it possible to easily do things in it's own world.

Sorry, but PowerShell can do ANYTHING bash can do. Without exceptions. Some things might be more clumsy than in bash - because PowerShell is not bash and things are done differently there.

And PowerShell even beats bash at its own game! PowerShell integration with git is much nicer than in bash: https://github.com/dahlbyk/posh-git - and achieves the similar functionality in a fraction of lines of code. A few screenshots can be seen here: http://markembling.info/2010/03/git-powershell-revisited