Evolution of shells in Linux (developerWorks)
Evolution of shells in Linux (developerWorks)
Posted Dec 9, 2011 9:06 UTC (Fri) by HelloWorld (guest, #56129)In reply to: Evolution of shells in Linux (developerWorks) by GhePeU
Parent article: Evolution of shells in Linux (developerWorks)
Posted Dec 9, 2011 9:28 UTC (Fri)
by khim (subscriber, #9252)
[Link] (13 responses)
Not if your programs continue to produce "untyped byte streams". PowerShell is classic example of well-known problem. With bash you need to know how to handle mess which existing programs produce and consume. With PowerShell you still need to know that (see lots of threads above about how to handle it - it's as ugly as in bash if not uglier), but you also have thus nice, user-friendly way which does not work all that often, but presented as the solution "for the future". Just like all other "grand unification schemes" before and after it'll fail so to say that PowerShell is better then bash is crazytalk: it's strictly worse and this is very easy to prove... PowerShell must die - but I'm content because it'll do just that anyway. It'll take a long time, but now, when madness around JVM and CLR is slowly dying because people understand that they were duped it's only matter of time. It'll be interesting to see if Microsoft will survive destruction of it's .NET dream or if it'll die off with too. I'd be relighted to see that, but don't hold my breath: Microsoft still looks way too resilient for that. Albeit lately it does so many stupid things die-off is actually likely. We'll see.
Posted Dec 10, 2011 2:52 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (12 responses)
PowerShell _is_ a unified language which interoperates with all other .NET languages. It does allow to transfer structured data in a unified way. UNIX people should sometimes leave their self-righteousness at the door and actually check what other people are doing.
PowerShell is definitely more powerful than bash or zsh because IT IS BUILT ON A GOOD FOUNDATION. It's that simple.
Bash knows nothing but byte streams. That's nice - for 1973. You can construct pipes in bash and then try use them to do something. But:
Posted Dec 10, 2011 6:18 UTC (Sat)
by khim (subscriber, #9252)
[Link] (4 responses)
In other words: it's LISP Machines all over again. In a hypothetical world where everyone is using .NET it may even be a good thing. In real world where .NET rage is on decline and it's now clear that .NET will not ever take over the world... not so much. UNIX people have looked from sidelines when first coming of LISP machines have come and gone. They'll do that a second time (and third time - if that'll ever happen), they are patient guys. They'll pick some good ideas from the whole sad story, as usual, but the whole "let's redo everything from scratch" thing is just not what UNIX people plan to ever do. 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. Sure, it's possible to use emacs as as shell replacement - but few people do. PowerShell is the same way. But unlike Emacs it's just as shell wannabe, nothing else, so I'm not sure it'll survive when all the rage about this generation of LISP Machines will die off. Long list of arguments skipped. Just note how everything you've cited was solved in "the first coming" (on LISP Machines), too. The difference is in scale: first time tens of millions were burned thus only thousands of machines were produced and the whole saga took about ten years on sidelines. Second time architecture astronauts had billions so the whole story took longer and rage was raised higher. The result is the same (one company was burned to a crisp, second one is stagnating, but is more-or-less ready to throw all these baubles out), it just took longer. When the hype will die off PowerShell will either die with .NET or it'll be used in some limited settings, while bash will live as a mainstream tool (albeit may be in split personality if Apple will continue to fear GPLv3). P.S. Note that I'm not saying .NET will die off totally: "first coming" left Emacs behind, I'm pretty sure "second coming" will leave few IDEs behind, too. Apparently that's the niche where all your vaunted advances are really helpful.
Posted Dec 10, 2011 7:18 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
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
Posted Dec 10, 2011 8:41 UTC (Sat)
by khim (subscriber, #9252)
[Link] (2 responses)
They do offer introspection and as for "structured pipelines"... this is only important if you want to pretend you are replacing "shell proper". So what? Any turing-complete language with support for fork/exec (or CheateProcess on Windows) can do the same. 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. 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.
Posted Dec 10, 2011 13:15 UTC (Sat)
by dlang (guest, #313)
[Link]
Posted Dec 11, 2011 1:03 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
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.
Posted Dec 11, 2011 0:11 UTC (Sun)
by nix (subscriber, #2304)
[Link] (6 responses)
Posted Dec 11, 2011 5:36 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
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.
> dd if=... of=...
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.
Posted Dec 11, 2011 11:07 UTC (Sun)
by nix (subscriber, #2304)
[Link] (1 responses)
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.
Posted Dec 11, 2011 11:50 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
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.
Posted Dec 16, 2011 5:11 UTC (Fri)
by tom.prince (guest, #70680)
[Link]
>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.
Posted Dec 11, 2011 16:21 UTC (Sun)
by anselm (subscriber, #2796)
[Link] (1 responses)
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.
Posted Dec 11, 2011 17:03 UTC (Sun)
by raven667 (subscriber, #5198)
[Link]
Sorry, but this is wrong. Dead wrong.
That isn't necessary if there's a standard mechanism for structured data.
Sorry, but this is wrong. Dead wrong.
1) There is no static typing or checks. Everything is dynamic which combines nicely with...
2) No real way to unit-test your scripts.
3) No central documentation or help system. And no, 'man' isn't it. Scripts and utilities have all kinds of argument formats without any real convention. Which leads to...
4) No discoverability. Autocompletion is not sanely possible in bash or zsh.
5) Abysmal tooling. The only real tool is just a text editor. Continuous integration? Unit testing? Static analysis? Code coverage analysis? Who needs them, not us!
Keep dreaming...
PowerShell _is_ a unified language which interoperates with all other .NET languages.
UNIX people should sometimes leave their self-righteousness at the door and actually check what other people are doing.
PowerShell is definitely more powerful than bash or zsh because IT IS BUILT ON A GOOD FOUNDATION.
Bash knows nothing but byte streams. That's nice - for 1973.
Keep dreaming...
It does not matter...
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.
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.
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...
It does not matter...
Sorry, but this is wrong. Dead wrong.
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.)
Sorry, but this is wrong. Dead wrong.
Nope. Man's shortcomings are well known. It's basically a simple indexed document storage, without built-in searching and poorly structured.
> tar czf myfile myfile.tgz
Damn, I just deleted 'myfile' with doubly-archived myfile.tgz
Very standard.
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.
Sorry, but this is wrong. Dead wrong.
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).
Sorry, but this is wrong. Dead wrong.
Sorry, but this is wrong. Dead wrong.
Sorry, but this is wrong. Dead wrong.
Which would be why POSIX, uh, standardized them more than ten years ago, and imposed rules which virtually all standard tools follow.
Sorry, but this is wrong. Dead wrong.