I love this rule, as it is the opposite of what modern computing does. When i plug something into a Windows PC i get a multitude of beeps and popups saying it did everything right. But if something goes wrong there is a eerie silence and i have to dig into the error hex dumps to hope i find anything useful at all (or just reboot and hope it works right on second try).
The Rule of Silence (2006)
211–220 of 318 posts
Re: The Rule of Silence (2006)
#212Earlier quoted context omitted.
In 1993, someone made exactly your argument a in Redmond board room, and so many people agreed that what you describe could be adequately called "The Windows Philosophy". All settings in a database and not text files (the registry); a command-line that pipes data, not text (PowerShell). Tailored UIs to change settings, not magic invocations and obsure text file syntaxes. I guess most developers on HN are also aware o…
For the best of both worlds, why not something that is both text and structured, like JSON or sexps?
Yes! I don't know how many times I've had to learn yet another one-off configuration syntax, logging format, or template language and wondered why oh why doesn't this use s-expressions (or even json?)... I fail to understand why the same people who are so allergic to lisp-like syntax will happily work on some project that makes you context switch between about a dozen different syntaxes once you count in all of the configuration, templating, and expression languages, some of which are embedded in string literals with absolutely no tooling or syntax highlighting.
Re: The Rule of Silence (2006)
#213Earlier quoted context omitted.
If you want a fast way to read the EXAMPLES section only for a command, here is a shell function which creates an ‘eg’ command which only displays the “EXAMPLES” section of manual pages: eg(){ MAN_KEEP_FORMATTING=1 man "$@" 2>/dev/null \ | sed --quiet --expression='/^E\(\x08.\)X\(\x08.\)\?A\(\x08.\)\?M\(\x08.\)\?P\(\x08.\)\?L\(\x08.\)\?E/{:a;p;n;/^[^ ]/q;ba}' \ | ${MANPAGER:-${PAGER:-pager -s}} } Usage: $ eg tar EXAM…
Here's mine: examples () { man $1 | less +/^EXAMPLES } Usage: $ examples su EXAMPLES su -m man -c catman Starts a shell as user man, and runs the command catman. You will be asked for man's password unless your real UID is 0. Note that the -m option is required since user “man” does not have a valid shell by default. In this example, -c is passed to the shell of the user “man”, and is not interpreted as an argument t…
You probably still want the MAN_KEEP_FORMATTING=1 part, to keep colorization and bolding etc. in the manual page. Also, your solution does not respect the user’s pager preference; the user might prefer to read man pages in “w3m”, for instance.
Re: The Rule of Silence (2006)
#214To play devil's advocate, part of the reason things like The Rule of Silence are talked about is because of the messy unix philosophy of treating everything like plain text. If structured data was embraced we would have developed appropriate tooling to interact with it in the way that we prefer. This runs very deep in unix and a lot of people are too "brainwashed" to think of other ways. Instead they develop other ex…
> When you get tot that point you have to understand that you have chosen to ignore the fact that the data you are dealing with must be represented in something much closer to a relational database than lines of ASCII text.
This is true. But when your needs aren't that complex, basic textual output sure is nice.
> The fetish for easily-editable ASCII files and escaping from structure is holding us back. Structured data does not automatically imply hidden and inaccessible, that's a matter of developing appropriate tooling.
Good plan. I'll set up a schema by which people can exchange data, and wse'll get it standardized. Given the complexity of the relationships involved - and the fact that I really don't know how my data will be used downstream of me - I'd better make it something really robust and extensible. Maybe some kind of markup language?
Then we can ensure that everyone follows the same standard. We can write a compatibility layer that wraps the existing text-only commands and transforms the data into this new extensible markup language (what to call it thought? MLX?). Then anyone who has the basic text tools can download the wrappers, learn the schema , and start processing output.
Then again, I could just do that grep | cut. The only thing I have to learn is the shape of the thing I'm grepping for, and the way to use cut - the basics take a few seconds, and no additional tooling is required. Best of all, chances are high that it'll work the same way 20 years from now (though likely with expanded options not current available).
There's a lot to be said for having simple tools that accept simple input and produce simple output.
This doesn't mean it's the only approach - databases and structured data absolutely have their places in modern CLI tooling - but that has no bearing on the value of an ASCII pipeline.
Re: The Rule of Silence (2006)
#215To play devil's advocate, part of the reason things like The Rule of Silence are talked about is because of the messy unix philosophy of treating everything like plain text. If structured data was embraced we would have developed appropriate tooling to interact with it in the way that we prefer. This runs very deep in unix and a lot of people are too "brainwashed" to think of other ways. Instead they develop other ex…
In 1993, someone made exactly your argument a in Redmond board room, and so many people agreed that what you describe could be adequately called "The Windows Philosophy". All settings in a database and not text files (the registry); a command-line that pipes data, not text (PowerShell). Tailored UIs to change settings, not magic invocations and obsure text file syntaxes. I guess most developers on HN are also aware o…
lol at powershell in 1993
Re: The Rule of Silence (2006)
#216To play devil's advocate, part of the reason things like The Rule of Silence are talked about is because of the messy unix philosophy of treating everything like plain text. If structured data was embraced we would have developed appropriate tooling to interact with it in the way that we prefer. This runs very deep in unix and a lot of people are too "brainwashed" to think of other ways. Instead they develop other ex…
In 1993, someone made exactly your argument a in Redmond board room, and so many people agreed that what you describe could be adequately called "The Windows Philosophy". All settings in a database and not text files (the registry); a command-line that pipes data, not text (PowerShell). Tailored UIs to change settings, not magic invocations and obsure text file syntaxes. I guess most developers on HN are also aware o…
The philosophy sounds great.
Maybe the downsides are because of the execution?
Re: The Rule of Silence (2006)
#217Earlier quoted context omitted.
This is in line with my experiences with powershell (or powershit as we refer to it). The canonical example of the complete failure and total friction is in the simple case of obtaining a file from a web server and sticking it on disk. This is the steps: 1. Try various built in cmdlets. Eventually find one that works. 2. It's a big file and gets entirely buffered in RAM and takes the machine out. You don't get the pr…
man iwr Oh, there's an OutFile parameter. Let's see what it does man iwr -param outfile How nice, it writes the response directly to a file instead of to the pipeline. The curl alias actually points to the very same cmdlet. Not to excuse bad examples on the internet (there are lots of people who fail to grasp PowerShell and still try to write articles and how-tos), but PowerShell having built-in documentation for com…
It doesn't work for large files. Try iwr with outfile on a 16Gb file on a 4/8Gb machine.
Knowing all the edge cases, exceptions and places where reality breaks down is the problem.
Where software should indeed work with the principle of least surprise, Microsoft have patented the principle of most inconvenient surprise.
Also SO has one small comment about this which didn't exist when I discovered it. I had to use windbg to dump the CLR heap and find out that there were a crap ton of buffers...
And that's every day using powershell. It's even worse if you trip over someone else's cmdlets which aren't aware of the correct harry potter style incantations to issue that don't cause the universe to implode.
The whole thing is a joke. A bad one.
Re: The Rule of Silence (2006)
#218I always liked how MacOS loads silently without annoying the user even when it does some "hard" stuff like fsck. Generally I think engineers need to fight the temptation to show off the importance and complexity of their software by spitting out all the unnecessary details and logs.
I generally like how Windows and OSX both load silently when things go right too. Text on a black screen, to your standard computer user, looks like an error at worst and just a bunch of junk at best. Most Linux systems I've used, and I know when talking about Linux distributions someone can always find an exception, print a bunch of stuff when they start up.
Re: The Rule of Silence (2006)
#219Earlier quoted context omitted.
In 1993, someone made exactly your argument a in Redmond board room, and so many people agreed that what you describe could be adequately called "The Windows Philosophy". All settings in a database and not text files (the registry); a command-line that pipes data, not text (PowerShell). Tailored UIs to change settings, not magic invocations and obsure text file syntaxes. I guess most developers on HN are also aware o…
What you get from text + availability of source code = a set of practical documentation that shipped right where you needed it. Microsoft forgot (and still forget) the documentation for Windows - if you want a nice A-Z reference for the bootloader, or kernel, or shell or IIS's configuration file or half the command-line tools, you're usually out of luck. The official place is often an inaccessible, badly-written know…
You should have kept looking at the MSDN and TechNet, because the idea that there's no documentation because it has been forgotten, or indeed the idea that there is no documentation, is utter nonsense.
Windows Server 2012 Command-line reference:
* https://technet.microsoft.com/en-gb/library/cc754340(v=ws.11...
Windows XP A-Z Command-line reference, that is actually named that:
* https://technet.microsoft.com/en-gb/library/bb490890.aspx
Doco for the wdsutil and md commands, picked at random:
* https://technet.microsoft.com/en-gb/library/cc771206(v=ws.11...
* https://technet.microsoft.com/en-gb/library/cc754711(v=ws.11...
bcdedit command references:
* https://technet.microsoft.com/en-gb/library/cc731662(v=ws.11...
* https://msdn.microsoft.com/en-gb/library/ff542205(VS.85).asp...
And so forth. There's a huge amount of doco, including reference doco.
Re: The Rule of Silence (2006)
#220Earlier quoted context omitted.
It's not like unstructured piped text is the only possible way to work. It's widely used precisely because it's so expedient. If you use structured data, then every program in the sequence has to understand the structure. If you just smash everything flat into a stream of text, you can then massage it into whatever form you need. It's not always the best way to approach a problem, but it's not meant to be. It's duct…
The way i see it, shell scripting and piping allows non-programmers to get their feet wet, one command at a time. You run a command, look at the output, now you know what the next command in the pipeline will see, and can add adjustments as needed. Powershell etc seems to be more programmer oriented in that one keep thinking in terms of variables and structures that gets passed around. And this seems to be the curse…
UNIX actually came when users were programmers at the same time. There was an expectation in the past that using computers involved knowing your way around your OS and being able to configure and script things.