| |||||||||||||
Sorry, but this is wrong. Dead wrong.Sorry, but this is wrong. Dead wrong.Posted Dec 11, 2011 0:11 UTC (Sun) by nix (subscriber, #2304)In reply to: Sorry, but this is wrong. Dead wrong. by Cyberax Parent article: Evolution of shells in Linux (developerWorks)
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.)
(Log in to post comments)
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.
|
|||||||||||||