From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 844e4228 for ; Tue, 11 Feb 2020 11:25:30 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id E6A6A9BD80; Tue, 11 Feb 2020 21:25:28 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 42EFE9BCE3; Tue, 11 Feb 2020 21:24:32 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id A117C9BCE3; Tue, 11 Feb 2020 21:24:28 +1000 (AEST) Received: from relay05.pair.com (relay05.pair.com [216.92.24.67]) by minnie.tuhs.org (Postfix) with ESMTPS id A78B09BCDE for ; Tue, 11 Feb 2020 21:24:27 +1000 (AEST) Received: from orac.inputplus.co.uk (unknown [84.93.178.134]) by relay05.pair.com (Postfix) with ESMTP id AD73E1A263A; Tue, 11 Feb 2020 06:24:26 -0500 (EST) Received: from orac.inputplus.co.uk (orac.inputplus.co.uk [IPv6:::1]) by orac.inputplus.co.uk (Postfix) with ESMTP id CA23522170; Tue, 11 Feb 2020 11:24:25 +0000 (GMT) To: tuhs@tuhs.org From: Ralph Corderoy MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit In-reply-to: <20200211035340.GA852@mcvoy.com> References: <202002110332.01B3WwWE015186@tahoe.cs.Dartmouth.EDU> <20200211035340.GA852@mcvoy.com> Date: Tue, 11 Feb 2020 11:24:25 +0000 Message-Id: <20200211112425.CA23522170@orac.inputplus.co.uk> Subject: Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Doug McIlroy Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" 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.