Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Rule of Silence (2006)

linfo.org

Post reply on HN
Print view View original

141–150 of 318 posts

Re: The Rule of Silence (2006)

#141

Post by teddyh »

setrofim_ wrote: post #22
dom0 wrote: post #15

Earlier quoted context omitted.

> Note that the "rule of silence" (combined with the habit of writing documentation like longform essays) is also one factor that makes unix-like systems newbie-unfriendly. (Famous example: trying to exit vi) $ man foo *scroll to the end with the EXAMPLES section* There should be an option for that. man --take-me-to-the-examples foo

You might find this intersting: https://github.com/tldr-pages/tldr

That project is a symptom of manual pages not having good “EXAMPLES” sections. The examples on that web page should be contributed upstream to the manuals pages of the software that they are for.

Re: The Rule of Silence (2006)

#142

Post by ygra »

setq wrote: post #134
Pxtl wrote: post #124

Earlier quoted context omitted.

Around the office when teaching PowerShell we say it takes about two Googles per line. That's not a compliment.

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 commands and parameters is actually fairly easy to figure out from within the shell. Admittedly, once you learn the basic half dozen or so cmdlets you tend to use all the time.

You're free to ask me (or on SO, I tend to answer PowerShell questions there) if you're having trouble. Figuring above out took literally just 20 seconds. Really. I'm kinda sick of people cursing and blaming tools just because they're different from what they're used to. If I did the same and complained about bash and Unix (which I rarely find the need or time to learn) I'd be tarred and feathered in seconds ...

Re: The Rule of Silence (2006)

#143

Post by upofadown »

borplk wrote: post #74

To 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…

Our civilization has been using unstructured text for a very long time now...

I totally agree that Unix sux. We need a better philosophy. But you eventually have to come up with something that actually works in practice. I am still waiting.

I remember my excitement at the idea that things like CP/M and MSDOS running on personal computers were going to free us all from the tyranny of mainframe computers running things like Unix. We all know how that turned out. Everyone eventually just gave up and started emulating the top of a desk.

So Unix is good at messing with unstructured text? Good. Get back to me when you have something better that actually works.

Re: The Rule of Silence (2006)

#144

Post by deadbunny »

return0 wrote: post #45
vog wrote: post #26

Earlier quoted context omitted.

> Famous example: trying to exit vi To be fair, this has been fixed a long time ago. At least Vim (which is the Vi installed on most systems) shows the following message on startup: ~ VIM - Vi IMproved ~ ~ version 7.4.1829 ~ by Bram Moolenaar et al. ~ [...] ~ Vim is open source and freely distributable ~ ~ Help poor children in Uganda! ~ type :help iccf for information ~ ~ type :q to exit ~ type :help or for on-line…

to be fair thats not enough either. someone might accidentally have pressed 'a' , and now good luck understanding how to get out of it without having a crash course on vim

^z

pkill vi

Re: The Rule of Silence (2006)

#145

Post by justinlaster »

Pxtl wrote: post #124
Chris2048 wrote: post #89

Earlier quoted context omitted.

The windows registry is not too bad. You can easily store this stuff in a SQLite file though: https://www.sqlite.org/appfileformat.html PowerShell' object-oriented nature is great btw!

Around the office when teaching PowerShell we say it takes about two Googles per line. That's not a compliment.

I'm sorry what? Powershell has to be one of the better documented systems I've used in quite some time, and the sytnax lends itself to a certain "learning velocity" if you will. I also find that the general standard for tooling is a bit higher than say, bash.

It's also been really neat to see how well Powershell lends itself to extending other applications.

Re: The Rule of Silence (2006)

#146

Post by setrofim_ »

teddyh wrote: post #141
setrofim_ wrote: post #22

Earlier quoted context omitted.

You might find this intersting: https://github.com/tldr-pages/tldr

That project is a symptom of manual pages not having good “EXAMPLES” sections. The examples on that web page should be contributed upstream to the manuals pages of the software that they are for.

The issue isn't just the lack of EXAMPLES, but also with how man pages tend to be structured. They tend to be very "encyclopedic". There is a set ordering for sections, with a lot of them very verbose, and examples, when present, near the end. Options are often listed in alphabetic order, which doesn't usually correspond to how often they are used or useful.

Man pages are OK when you're first learning how to use something; but if you're already familiar with a command and just need to remind yourself of a the specific sequence of options to achieve a desired result, they're not the most convenient.

I think it's useful to have a tool that fulfills the latter purpose without worrying about the former.

Re: The Rule of Silence (2006)

#147

Post by norswap »

Pxtl wrote: post #124
Chris2048 wrote: post #89

Earlier quoted context omitted.

The windows registry is not too bad. You can easily store this stuff in a SQLite file though: https://www.sqlite.org/appfileformat.html PowerShell' object-oriented nature is great btw!

Around the office when teaching PowerShell we say it takes about two Googles per line. That's not a compliment.

For people who don't know the standard Unix tools, I expect much the same.

Re: The Rule of Silence (2006)

#148

Post by augustk »

laumars wrote: post #119
augustk wrote: post #66

One consequence of "the rule of silence" is that sometimes it is not obvious if a command is processing data or waiting for input, there is no visual difference.

That's more an occasional annoyance than a real problem though. The only commands that don't prompt when waiting for input are commands that are written specifically for stream processing from stdin. In which case the user should already be aware of it's behaviour because they're either already familiar with the command or have have consulted it's man page (or similar reference) before executing it. So the unprompted…

I was more thinking of a situation where you have misunderstood the syntax of a command or forgot to type an argument.

Re: The Rule of Silence (2006)

#149

Post by yason »

borplk wrote: post #74

To 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…

> If structured data was embraced we would have developed appropriate tooling to interact with it in the way that we prefer.

What kind of tooling might work with ad-hoc structured data and still getting all the tools to talk with each other like in Unix? How would it work without having to write input parsing rules, data processing rules, and output formatting/filtering/composing rules for each tool?

I suspect that the reason it's not very popular to pass around structured data is that it's damn difficult to make various tools understand arbitrary data streams. Conversely, the power of text is that the tools understand text, only text, and do not understand the context, i.e. the user decides what the text means and how it needs to be processed. Then the tools become generic and the user can apply them in any number of contexts.

Re: The Rule of Silence (2006)

#150

Post by zeveb »

setrofim_ wrote: post #18
zeveb wrote: post #13

Earlier quoted context omitted.

Note that I'm not arguing for structured binary data. Structured text (e.g. s-expressions, JSON, even the-extensible-structured-text-format-which-shall-not-be-named) can last just as long. Indeed, S-expressions have existed since the 1950s. There's no particular reason why /etc/passwd couldn't be: ((root nil 0 0 root /root /bin/bash) (daemon nil 1 1 daemon /usr/sbin /usr/sbin/nologin) …) There are any number of simil…

What would your example achieve? You're making the format more verbose and error-prone (someone might easily forget to match a paren), without imposting any additional structure over what is already implied by line breaks. Though I do agree with your overarching point that some of the formats/outputs could do with a more consistent structure. Perhaps something like YAML would strike a good balance between structure a…

> You're making the format more verbose and error-prone (someone might easily forget to match a paren), without imposting any additional structure over what is already implied by line breaks.

It's already error-prone (as anyone who's ever incorrectly edited /etc/passwd knows).

Ultimately, structured data (which is pretty much all data) should be edited with structure editors. Good text formats make it easy to write such structure editors.

Post reply on HN