From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11829 invoked from network); 17 May 1998 09:24:25 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 17 May 1998 09:24:25 -0000 Received: (from list@localhost) by math.gatech.edu (8.8.5/8.8.5) id FAA07317; Sun, 17 May 1998 05:19:23 -0400 (EDT) Resent-Date: Sun, 17 May 1998 05:19:23 -0400 (EDT) From: "Bart Schaefer" Message-Id: <980517021927.ZM3822@candle.brasslantern.com> Date: Sun, 17 May 1998 02:19:26 -0700 In-Reply-To: <199805170158.BAA05181@tgape.ed.vnet> Comments: In reply to TGAPE! "Re: Oh my God! They killed completion! YOU BASTARDS!" (May 17, 1:58am) References: <199805170158.BAA05181@tgape.ed.vnet> X-Mailer: Z-Mail (4.0b.820 20aug96) To: TGAPE! , zefram@tao.co.uk (Andrew Main) Subject: Re: Oh my God! They killed completion! YOU BASTARDS! Cc: zsh-workers@math.gatech.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"m2OrN.0.Go1.QkgNr"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/3981 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On May 17, 1:58am, TGAPE! wrote: } Subject: Re: Oh my God! They killed completion! YOU BASTARDS! } } Andrew Main wrote: } > } > Bart Schaefer wrote: } >> Maybe a better approach would be to distribute an autoloadable script } >> that, when run, would report the differences between the current zsh and } >> a specified previous version (default the last major release). } > } > That's what Etc/NEWS is for. It needs to be updated for 3.1. } } Etc/NEWS (or ChangeLog, or whatever) has the problem that it tends to be } longer than many people wish to read before starting to use the new } shell, as well as frequently being too terse [...] to be of much use } anyway - they generally assume that the new program'll work the same as } their old version, except for bug fixes, until they play with the new } options. This is exactly why I generally object so much when changes are made that are not "backwards compatible." A shell isn't like other applications -- if it doesn't start up properly because it can't parse your init files, you may not even be able to log in; and if it does start, but behaves in an unexpected way, it can waste many hours (and in extreme cases cause loss of data) before sanity is restored. This is not to say that any of the 3.1.x changes have those effects, just to emphasize that care should be taken when changing behaviors. } When one of my friends upgrades zsh on his machine, } there are dozens affected, many who aren't necessarily observant enough } to realize 'Hey, a shell upgrade occurred, and zefram's done an annoying } default option change on me on some option I'm completely unfamiliar } with because I immediately dismissed it as a bad idea.' I've heard } there's someone at work who can do this to hundreds, and I've seen ISPs } where they could potentially do it to thousands. And it is often the case that when such an upgrade is done, the Etc/NEWS and other auxiliary doc files aren't installed in any public place, so those poor users can't read them even if they are so inclined. I'm no longer the "zsh admin" for any significant group of people, but I was for a while, and starting with about version 2.4 I always had to dump a bunch of stuff in /etc/zshenv to be sure zsh continued to behave the way everyone expected. I'd bet admins assume that isn't necessary. } I'd suggest rather than an emulate version, just a detect version, like } vim has - when vim changes significantly, anyone who is used to the old } version gets a comment about how their .vimrc file is for an older } version, and would they please read about the changes. This is why I suggested a script that would report differences; sysadmins could set it up to run when the new version is first started up. None of zsh's startup files are suitable for version tagging because zsh has no business rewriting them (except the .zhistory, which may be turned off), so I can't advocate version detection as a built-in, but it could be done in a sample /etc/zshenv or something. } I personally wasn't affected by this one, as I happen to be paranoid - } my .zlogin file sets all options the way I want them; if the default is } what I want, I still set it that way. Not everyone is as looney as } myself, however. I have conditionals for every version of zsh back to about 2.0 to figure out which options are available and set them appropriately to keep things working as consistently as possible. Some of those branches haven't been executed since 1994, but I figure if I take them out then I'll forget to fix something the next time some option or other gets revised. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com