Hi Larry, 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. 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.

On 2/11/20 4:40 AM, arnold(a)skeeve.com wrote: The one change I might consider is to disable this feature if the shell is executing a command list, so something like cd /usr/bon && rm -f sh* doesn't do something unexpected before a user has a chance to react. Does the v9 shell do that? Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/

My favorite example is a business trip my wife took. Her surname is Hsi which was "corrected" to His at the site she visited. Upon arrival it took her several *hours* to work out with the security folks that Ms Hsi was not impersonating Ms His. (That says as much about the security group as it does about autocorrect, I suppose.) Mike Markowski On Tue, Feb 11, 2020 at 9:38 AM Clem Cole <clemc(a)ccc.com> wrote:

On Tue, Feb 11, 2020 at 11:03 AM Bakul Shah &lt;bakul(a)bitblocks.com&gt; wrote: I've been known to same something similar. Usually with a #$%^& before it. +1, amen brother Shah, amen, FWIW: I referenced both PL/C and IBM PL/1 compiler in my quora answer. In an interactive world, offering a note like Grammerly's underline, seems reasonable to me - because it forces me to accept it. The automatic doing it for me, is what I dislike - as you said, on touch interfaces it's twice as bad. I remember having a conversation with Doug Cooper when we all were teaching the intro to CS course and I we were getting students turning in 'auto-corrected' code for assignments and wondering why the TAs were not amused. I had thought that having the compiler tell you what was in error and then maybe offering a suggestion, might make sense, but there needed to be some action on the student's part to accept >>and<< repair to code before the compiler would produce something that 'ran.' Anyway, I still think "*Damn Warren's Infernal Machine*" was always well named. Clem