The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Ralph Corderoy <ralph@inputplus.co.uk>
To: tuhs@tuhs.org
Cc: Doug McIlroy <doug@cs.dartmouth.edu>
Subject: Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation]
Date: Tue, 11 Feb 2020 11:24:25 +0000	[thread overview]
Message-ID: <20200211112425.CA23522170@orac.inputplus.co.uk> (raw)
In-Reply-To: <20200211035340.GA852@mcvoy.com>

Hi Larry,

> Doug McIlroy wrote:
> > We now know that silent correction is a terrible idea.
>
> I had the same thought,
>
>     cd /some/place/I/want/to/remove
>     $PWD is /some/place/I/want/dont/remove
>     rm -rf ./*

An extract from the Jargon File's DWIM entry echoes that.

    http://www.catb.org/~esr/jargon/html/D/DWIM.html

    In one notorious incident, Warren added a DWIM feature to the
    command interpreter used at Xerox PARC.  One day another hacker
    there typed delete *$ to free up some disk space.  (The editor there
    named backup files by appending $ to the original file name, so he
    was trying to delete any backup files left over from old editing
    sessions.)  It happened that there weren't any editor backup files,
    so DWIM helpfully reported *$ not found, assuming you meant 'delete
    *'.  It then started to delete all the files on the disk!  The
    hacker managed to stop it with a Vulcan nerve pinch after only a
    half dozen or so files were lost.

    The disgruntled victim later said he had been sorely tempted to go
    to Warren's office, tie Warren down in his chair in front of his
    workstation, and then type delete *$ twice.

> > Postel's principle: "be conservative in what you do, be liberal in
> > what you accept from others" was doctrine in early HTML specs, and
> > led to disastrous disagreement among browsers' interpretation of web
> > pages. Sadly, the "principle" lives on despite its having been
> > expunged from the HTML spec.

I often point to this Internet Draft when Postel's Law is brought up in
modern discussions about letting standards slip.

    The Harmful Consequences of Postel's Maxim
    M. Thomson, Mozilla, 2015-03-09
    https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00

After looking at divergence over time, and long-term costs, it suggests
instead ‘Protocol designs and implementations should be maximally
strict’.  A shame it never became an RFC.

Arguing Postel's Law for accepting to deviate is easy as those arguing
for strictness have to work out how the laxness could cause a problem.

(I'm sad to see Golang accepting deviations from standards.  It has been
a big enough language to take a stand for ages.
https://github.com/golang/go/issues/34540 is one example of a CVE from
allowing white-space where there shouldn't be any in the HTTP protocol.
Just white-space, what could be harmful about accepting that?
https://github.com/golang/go/issues/19989 was another HTTP white-space
deviation from the spec.  All to help one particular unnamed GPS system.)

-- 
Cheers, Ralph.

  reply	other threads:[~2020-02-11 11:25 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-11  3:32 Doug McIlroy
2020-02-11  3:53 ` Larry McVoy
2020-02-11 11:24   ` Ralph Corderoy [this message]
2020-02-11 15:51     ` Larry McVoy
2020-02-11  4:46 ` Warren Toomey
2020-02-11  5:12   ` Steve Nickolas
2020-02-11  6:33 ` Rob Pike
2020-02-11  9:40 ` arnold
2020-02-11 15:06   ` Chet Ramey
2020-02-11 14:36 ` Clem Cole
2020-02-11 15:29   ` Mike Markowski
2020-02-11 16:03   ` Bakul Shah
2020-02-11 17:12     ` Clem Cole
2020-02-11 17:17     ` Steve Nickolas
2020-02-11 17:21 ` Dan Cross
  -- strict thread matches above, loose matches on Subject: below --
2020-02-07 22:25 [TUHS] Warner's Early Unix Presentation Warren Toomey
2020-02-07 23:57 ` Rob Pike
2020-02-08 15:15   ` Warner Losh
2020-02-08 21:50     ` Rob Pike
2020-02-10 15:05       ` Dan Cross
2020-02-10 15:46         ` [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] arnold
2020-02-10 18:39           ` Rob Pike
2020-02-10 18:59             ` Bakul Shah
2020-02-10 19:58             ` Angelo Papenhoff
2020-02-10 20:11               ` Chet Ramey
2020-02-11  9:33             ` arnold
2020-02-11  9:47               ` Noel Hunt
2020-02-11  9:47               ` Rob Pike
2020-02-11  9:59                 ` Rob Pike
2020-02-11 17:05                   ` Steffen Nurpmeso
2020-02-11 17:18                     ` Arthur Krewat
2020-02-11 18:22                     ` Kurt H Maier
2020-02-16 21:34                       ` Wesley Parish
2020-02-11 18:26                     ` Jon Steinhart
2020-02-11 23:56                       ` Steffen Nurpmeso
2020-02-12  0:12                         ` Jon Steinhart
2020-02-12  5:54                           ` Rob Pike
2020-02-11 17:36                   ` Dan Cross
2020-02-11 18:35                   ` Christopher Browne
2020-02-11 18:54                     ` Rob Pike
2020-02-11 21:36                     ` Harald Arnesen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200211112425.CA23522170@orac.inputplus.co.uk \
    --to=ralph@inputplus.co.uk \
    --cc=doug@cs.dartmouth.edu \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).