[TUHS] V9 shell [was Re: Warner's Early Unix Presentation]

Ralph Corderoy ralph at inputplus.co.uk
Tue Feb 11 21:24:25 AEST 2020

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.


    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

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.

More information about the TUHS mailing list