| |||||||||||||
Evolution of shells in Linux (developerWorks)Evolution of shells in Linux (developerWorks)Posted Dec 8, 2011 13:45 UTC (Thu) by cortana (subscriber, #24596)In reply to: Evolution of shells in Linux (developerWorks) by HelloWorld Parent article: Evolution of shells in Linux (developerWorks)
I'll bite. The 'sort' utility wants to sort line-based output. The output of aptitude is not line-based. It uses the Debian RFC822-like format. The right thing to do would be to find a tool that sorts this output based on a particular field. You could argue that there's a hole here that could be filled by some kind of sort-dctrl tool.
...
I wrote that paragraph before I noticed that I already have a sort-dctrl program on my system; it's part of dctrl-tools. Unfortunately it doesn't actually work with aptitude's output; aptitude doesn't output deb822 data... it doesn't use a . to represent blank lines in its fields. :)
Anyway, I actually agree that PowerShell is pretty cool. I find it utterly unusable, however, because it's still welded to the utterly dreadful excuse for a terminal emulator that is conhost.exe. In 2011, essential features such as multiple tabs, run-based selection and the ability to click URLs are entirely absent, and the features that do exist, such as resizing windows, block based selection and changing the font/colours are buried behind a UI that seems to be actively designed to get in my way, making me want to nuke the computer and install Debian rather than be forced to use them for even one minute longer.
(Log in to post comments)
Evolution of shells in Linux (developerWorks) Posted Dec 8, 2011 14:54 UTC (Thu) by HelloWorld (guest, #56129) [Link]
> The 'sort' utility wants to sort line-based output.
Yes, and that is precisely what makes it useless. And actually, it can't even sort lines properly; try sorting, say, the output of ps by ppid or something. Yeah, it's doable, but it's messy, and it needn't be.
> I wrote that paragraph before I noticed that I already have a sort-dctrl program on my system; it's part of dctrl-tools. Unfortunately it doesn't actually work with aptitude's output; aptitude doesn't output deb822 data... it doesn't use a . to represent blank lines in its fields. :)
> Anyway, I actually agree that PowerShell is pretty cool. I find it utterly unusable, however, because it's still welded to the utterly dreadful excuse for a terminal emulator that is conhost.exe.
Evolution of shells in Linux (developerWorks) Posted Dec 8, 2011 15:35 UTC (Thu) by cortana (subscriber, #24596) [Link]
You're complaining that the sort utility is useless because it can't sort every possible thing you would ever want it to sort. I'm saying that is a misunderstanding of what sort is supposed to do. It only sorts line-based data. For example, "ps -o ppid,pid | sort -n" seems to work quite nicely. The sort-dctrl example is unfortunate, but not terribly suprprising; the output of aptitude is, after all, designed for human consumption; 'grep-status -F installed | sort-dctrk -k version:v' happily tells me that fonts-sil-gentium is the package installed with the highest version number (20081126:1.02-12, in an amazing misunderstanding of the purpose of the epoch part of the Debian version numbering scheme...)
I'm not saying that PowerShell isn't terribly clever and all that, but I don't see every tool I use on a daily basis being rewritten to output its data in some standard structured format, and consume data in that format. As a result, actually using Powershell is annoying because it comes with some nice built-in stuff, but not enough third-party programs bother to make use of it. At best you end up with a bunch of scripts that parse the structured output of other programs and turn them into whatever it is that PowerShell uses internally so that Sort-Object & co. will deal with them. At that point you may as well just use a programming language that provides a decent selection of data structures in the first place (e.g., python, perl), with a module that gives you the data you want in such a structure.
Finally, and to digress, thanks for the link to Console2. Everyone who uses Windows should have it installed. Although it makes using the command-line on Windows a much less frustrating experience, it doesn't do all of what I want and sadly introduces its own quirks into the mix. It's funny you say that the lack of a standard structured data format is a fundamental problem with Unix; after many years of being trying to various conhost replacements, I've come to the conclusion that there is in fact something terribly wrong within some fundamental layer of Windows itself that makes it impossible to implement a decent terminal emulator. If that were not the case then surely someone would have done so by now; the awfulness of the command prompt on Windows is not so much an itch that needs scratching as a foot-long needle through the eye that inflicts a constant searing pain upon all users of the platform. Whereas I think the problem with a standard for structured data is that there are already plenty of standards to choose from; line-based character-separated or deb822 if you merely want a flat list of data with attributes; JSON or XML if you want something that can represent a tree of data, to name but a few. The power of Unix's use of unstructured data is that you are able to pick and choose with of these formats, plus many others, you can use when glueing together other bits of software.
Evolution of shells in Linux (developerWorks) Posted Dec 8, 2011 16:07 UTC (Thu) by boudewijn (subscriber, #14185) [Link]
I always thought that the Windows console was intentionally painful to make people stop using it and learn to love the gui.
Evolution of shells in Linux (developerWorks) Posted Dec 8, 2011 16:47 UTC (Thu) by nix (subscriber, #2304) [Link] the awfulness of the command prompt on Windows is not so much an itch that needs scratching as a foot-long needle through the eye that inflicts a constant searing pain upon all users of the platformNow that's a QoTW candidate if ever I've seen one.
Evolution of shells in Linux (developerWorks) Posted Dec 8, 2011 19:16 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
<flamebait mode>
Heh. I have COMPLETELY opposite experience. Console on Linux sucks and can't be fixed by any means short of going back in time and shooting K&R before they start writing the first line of Unix code.
Standard _console_ _emulator_ on Windows definitely sucks, that's true. But the console layer itself is quite robust and easy to use.
For example, there is no freaking way in Unix consoles to detect if a modifier key is pressed. Then there's the fact that Unix consoles are in reality a result of adding features to something that initially had been a line printer output.
As a result, making applications with good text UI in console is close to impossible. That's why Midnight Commander is such a buggy POS. In fact, Unix consoles are so bad that tmux/screen had to implement console emulators working on top of console emulators because it's impossible to reliably track the state of a console.
I really really love one good Windows console application - FAR Manager. It's far ahead of everything else on the planet for console-style work.
Evolution of shells in Linux (developerWorks) Posted Dec 8, 2011 21:19 UTC (Thu) by quotemstr (subscriber, #45331) [Link]
> But the console layer itself is quite robust and easy to use.
Are you on the payroll, or are you just completely unacquainted history and actual programming?
The Windows console layer has no pseudoterminals. That's why there are a dozen remote-command-invocation facilities in Windows, and it's why none of them works right. It's why Console2 fails badly when talking to some programs (e.g., cmd) --- Windows programs are forced to use pipes instead of consoles, so programs run under a console other than conhost itself don't even know they're being used interactively, resulting in various horrible issues the Unix world fixed 20 years ago.
Evolution of shells in Linux (developerWorks) Posted Dec 8, 2011 21:33 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
No. I'm just trying to port FAR Manager to Linux without going insane. Alas, sanity is fleeing fast so I'll soon need some of Linus' meds.
>The Windows console layer has no pseudoterminals.
It would have been OK, but terminal emulators suffer from terminal schizophrenia. They try to act as if they are line printers while at the same time trying to act as if they are driving a VT100 console. Which fails badly.
In Windows consoles are just consoles. I.e. a screen buffer on which you can draw text - and that's basically all. You can do whatever you want with it.
Instead of pseudoterms you can create child consoles (including invisible ones) and use them to start other programs. I'm not sure why console2 doesn't do it.
Evolution of shells in Linux (developerWorks) Posted Dec 8, 2011 21:44 UTC (Thu) by quotemstr (subscriber, #45331) [Link]
> No. I'm just trying to port FAR Manager to Linux without going insane.
Consider using the VTE widget from GNOME: http://developer.gnome.org/vte/0.30/
> It's essentially a channel to transmit bytecode which is executed by terminal emulator to draw text.
Yes, the unix terminal system uses in-band signaling. In-band signaling has advantages and disadvantages with respect to out-of-band signaling, but in the case of the tty layer, the advantages outweigh the disadvantages, which have all been overcome. The chief advantage is being to use a terminal-agnostic channel (like a TCP connection) over which a terminal-program and a terminal-emulator can communicate. The Windows world has no equivalent because its console uses opaque out-of-band signaling.
> Which fails badly.
No, the terminal system actually works very, very well in practice.
> Instead of pseudoterms you can create child consoles (including invisible ones) and use them to start other programs. I'm not sure why console2 doesn't do it.
The reason console2 doesn't use the technique you describe is that it doesn't work. Yes, you can create "child consoles" and associate processes with them, but there's no "master side" interface to these child consoles: there is no way to extract text from them, to see what your child programs are attempting to output and output it yourself in a controlled manner. Yes, you can scrape the console, but the scraping process has inherent race conditions. (And scraping is messy besides: you're complaining about terminal control codes?)
Evolution of shells in Linux (developerWorks) Posted Dec 8, 2011 21:54 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
>Consider using the VTE widget from GNOME: http://developer.gnome.org/vte/0.30/
I want it to work in plaing text consoles (over SSH). There are more than enough GUI file managers. Right now I'm trying to layer it over tmux, and I'm slowly making progress.
>Yes, the unix terminal system uses in-band signaling. In-band signaling has advantages and disadvantages with respect to out-of-band signaling, but in the case of the tty layer, the advantages outweigh the disadvantages, which have all been overcome.
I don't mind the idea of transmitting bytecode for drawing. I just don't like the way it works right now. It's messy, ugly, buggy and so on.
Have you ever tried to read the code of terminal emulators? Nightmares of escape sequences still plague my dreams :)
>The reason console2 doesn't use the technique you describe is that it doesn't work. Yes, you can create "child consoles" and associate processes with them, but there's no "master side" interface to these child consoles: there is no way to extract text from them, to see what your child programs are attempting to output and output it yourself in a controlled manner. Yes, you can scrape the console, but the scraping process has inherent race conditions. (And scraping is messy besides: you're complaining about terminal control codes?)
You can associate a child console with parent which would make it visible. But yes, I guess it's one week spot. As far as I remember, conman (console manager) worked around it by intercepting console layer calls by injecting a DLL into address space of child processes.
If I were to design a console layer right now, then I'd have have chosen Windows model with explicitly defined marshalling protocol.
Evolution of shells in Linux (developerWorks) Posted Dec 8, 2011 20:50 UTC (Thu) by HelloWorld (guest, #56129) [Link]
> You're complaining that the sort utility is useless because it can't sort every possible thing you would ever want it to sort. I'm saying that is a misunderstanding of what sort is supposed to do. It only sorts line-based data.
Yes, and the only reason it's so limited is that the Unix shell paradigm doesn't allow anything better. Which was the point all along. Is that so hard to understand?
Evolution of shells in Linux (developerWorks) Posted Dec 8, 2011 22:15 UTC (Thu) by ebiederm (subscriber, #35028) [Link]
Worse is better
Evolution of shells in Linux (developerWorks) Posted Dec 9, 2011 12:23 UTC (Fri) by nix (subscriber, #2304) [Link]
Except when worse is worse. Case in point that has been raised before here: the Windows Command Prompt. It's worse than xterm, the Linux console, and screen(1). It's also... worse.
Evolution of shells in Linux (developerWorks) Posted Dec 8, 2011 23:13 UTC (Thu) by GhePeU (subscriber, #56133) [Link]
> Yes, and that is precisely what makes it useless. And actually, it can't even sort lines properly; try sorting, say, the output of ps by ppid or something. Yeah, it's doable, but it's messy, and it needn't be.
I don't find 'ps -Ao user,pid,ppid,time,command | sort -k3n' particularly messy.
Evolution of shells in Linux (developerWorks) Posted Dec 9, 2011 9:06 UTC (Fri) by HelloWorld (guest, #56129) [Link]
OK, I admit I didn't know about the -k switch. Which pretty much proves the point: If you want to work with untyped byte streams, you have to learn new switches for every program that you want to work on some specific field of a line. That isn't necessary if there's a standard mechanism for structured data.
Sorry, but this is wrong. Dead wrong. Posted Dec 9, 2011 9:28 UTC (Fri) by khim (subscriber, #9252) [Link] That isn't necessary if there's a standard mechanism for structured data. 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.
Sorry, but this is wrong. Dead wrong. Posted Dec 10, 2011 2:52 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
Nope, sorry. You don't know what you're talking about.
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:
Keep dreaming... Posted Dec 10, 2011 6:18 UTC (Sat) by khim (subscriber, #9252) [Link] PowerShell _is_ a unified language which interoperates with all other .NET languages. 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 should sometimes leave their self-righteousness at the door and actually check what other people are doing. 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. PowerShell is definitely more powerful than bash or zsh because IT IS BUILT ON A GOOD FOUNDATION. 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. Bash knows nothing but byte streams. That's nice - for 1973. 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.
Keep dreaming... Posted Dec 10, 2011 7:18 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
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
It does not matter... Posted Dec 10, 2011 8:41 UTC (Sat) by khim (subscriber, #9252) [Link] 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.
It does not matter... Posted Dec 10, 2011 13:15 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
the shuttle was also an attempt to 'greenify' space travel, by making things reusable.
It does not matter... Posted Dec 11, 2011 1:03 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
>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.
Sorry, but this is wrong. Dead wrong. Posted Dec 11, 2011 0:11 UTC (Sun) by nix (subscriber, #2304) [Link] 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. Posted Dec 11, 2011 5:36 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
>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.
> 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.
Sorry, but this is wrong. Dead wrong. Posted Dec 11, 2011 11:07 UTC (Sun) by nix (subscriber, #2304) [Link] 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.
Sorry, but this is wrong. Dead wrong. Posted Dec 11, 2011 11:50 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
>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.
Sorry, but this is wrong. Dead wrong. Posted Dec 16, 2011 5:11 UTC (Fri) by tom.prince (subscriber, #70680) [Link]
>>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.
Sorry, but this is wrong. Dead wrong. Posted Dec 11, 2011 16:21 UTC (Sun) by anselm (subscriber, #2796) [Link] 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. Posted Dec 11, 2011 17:03 UTC (Sun) by raven667 (subscriber, #5198) [Link]
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.
Evolution of shells in Linux (developerWorks) Posted Dec 9, 2011 0:06 UTC (Fri) by grg (guest, #76756) [Link] essential features such as multiple tabs, run-based selection and the ability to click URLs are entirely absentI use xterm and reject all other X based terminal emulators. Its small, fast, and has enough features for me. I don't need multiple tabs or the ability to click urls and I don't know what the hell run-based selection is supposed to be - these don't seem particularly essential.
Evolution of shells in Linux (developerWorks) Posted Dec 9, 2011 2:44 UTC (Fri) by cortana (subscriber, #24596) [Link]
Run based selection as opposed to block based selection. In Windows you can only select by block. This drives me up the wall whenever I have to use Windows!
|
|||||||||||||