The Rule of Silence (2006)

Post by junke » Tue, Dec 13, 2016, 2:58 PM UTC

cyphar wrote: post #92

rtpg wrote: post #87

Earlier quoted context omitted.

Surely you can reconcile structured representations and something like the Unix command line. Imagine if the default wasn't bash, but something like Ruby + pipes (or some other terse language). What is the argument for shell scripts not working on typed objects? How much time has been lost, how many bugs have been created because every single interaction between shell scripts has to include its own parser. How many v…

> What is the argument for shell scripts not working on typed objects? How much time has been lost, how many bugs have been created because every single interaction between shell scripts has to include its own parser. How many versions of " get file created timestamp from ls" do we need? Aside: that's what the stat command is for. My big concern with types is how would you make sure that the output of a command will…

Post by athenot » Tue, Dec 13, 2016, 3:01 PM UTC

taneq wrote: post #116

martijn_himself wrote: post #33

I wish people would live by this rule more often.

Have you ever tried to talk to a person who gives absolutely no nonverbal cues as to whether or not they're listening to you? It's infuriating. Acks are important.

Post by digi_owl » Tue, Dec 13, 2016, 3:04 PM UTC

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…

Post by eriknstr » Tue, Dec 13, 2016, 3:05 PM UTC

teddyh wrote: post #106

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

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…

  examples ()
  {
    man $1 | less +/^EXAMPLES
  }

  $ 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 to su.
       su -m man -c 'catman /usr/share/man /usr/local/man'
              Same as above, but the target command consists of more than a
              single word and hence is quoted for use with the -c option being
              passed to the shell.  (Most shells expect the argument to -c to be
              a single word).
       su -m -c staff man -c 'catman /usr/share/man /usr/local/man'
              Same as above, but the target command is run with the resource
              limits of the login class “staff”.  Note: in this example, the
              first -c option applies to su while the second is an argument to
              the shell being invoked.
       su -l foo
              Simulate a login for user foo.
       su - foo
              Same as above.
       su -   Simulate a login for root.

Post by ryandrake » Tue, Dec 13, 2016, 3:08 PM UTC

TeMPOraL wrote: post #131

qwertyuiop924 wrote: post #112

Earlier quoted context omitted.

Structured text is good. Very good, in fact. It might even be idea. structured binary data , less so, at least as a storage format. I want to be able to look at your file format using tools that haven't been specialized to the task. Is that so wrong?

Well, I'm advocating for structured text , not binary . Mostly because I haven't seen a future-proof binary format yet, and editing binary formats indeed would require special tooling. I think - for a data exchange protocol meant to be used between many applications - going structured text instead of binary is a worthwhile tradeoff of little lower efficiency vs. much better accessibility. EDIT: Some comments here are…

    curl -svo /dev/null http://example.com/file 2>&1 | grep Last-Modified | cut -d ' ' -f 3-

    curl(http://example.com/file).response_headers.Last-Modified.subtract(date().now).days