From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20434 invoked from network); 18 Jul 2000 06:02:13 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 18 Jul 2000 06:02:13 -0000 Received: (qmail 27703 invoked by alias); 18 Jul 2000 06:02:02 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12292 Received: (qmail 27691 invoked from network); 18 Jul 2000 06:01:58 -0000 From: "Bart Schaefer" Message-Id: <1000718060143.ZM22965@candle.brasslantern.com> Date: Tue, 18 Jul 2000 06:01:43 +0000 In-Reply-To: <20000717190728.A9091@thelonious.new.ox.ac.uk> Comments: In reply to Adam Spiers "Re: adding a toplevel zsh.spec.in file" (Jul 17, 7:07pm) References: <1000707181834.ZM1473@candle.brasslantern.com> <20000717160933.B6739@thelonious.new.ox.ac.uk> <1000717174853.ZM22633@candle.brasslantern.com> <20000717190728.A9091@thelonious.new.ox.ac.uk> <3973751E.2CFC476E@u.genie.co.uk> <20000718003528.A11704@thelonious.new.ox.ac.uk> X-Mailer: Z-Mail (5.0.0 30July97) To: zsh workers mailing list Subject: Re: adding a toplevel zsh.spec.in file MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jul 17, 7:07pm, Adam Spiers wrote: } Subject: Re: adding a toplevel zsh.spec.in file } } Bart Schaefer (schaefer@candle.brasslantern.com) wrote: } > I agree that these don't do much harm, but this is bad: } > } > } HISTSIZE=1000 } > } HISTFILE=~/.zshhistory } > } SAVEHIST=1000 } > } > Please don't mess with the shape of my history or the location of any of } > my dotfiles. } } Why is this messing with your preferences? It's only setting a } default which each user can override, surely? It's setting a default other than the documented one, which I should not be required to override when the documented behavior is already as I prefer it. } > } Now here's a candidate for StartupFiles/RedHat/zshrc. Anything badly } > } wrong? } > } > Yes. Don't screw with my fpath and don't autoload functions for me. } } Again, I must be missing something because I don't see why you } describe this as messing with /your/ fpath when at that stage you (the } user) haven't made any changes to it. What? You said this was in /etc/zshrc. At that point I *HAVE* made changes to it, in ~/.zshenv. But even if I hadn't made any changes, who are you to say that I *WANTED* any changes? } You are still free to set it to whatever you want, aren't you? Once again, I should be able to rely upon the documented defaults, not be required to reassert them. } The only possible problem I can } envisage is that something gets autoloaded which you didn't want to } be, but if you didn't want it autoloaded, you won't be using it } anyway. How do you know I won't be using it? Somthing that you autoloaded may have the same name as an external executable, which is now masked. To get the external executable back, I have to know to unfunction things you autoloaded. No, thank you. } > Your assumptions about where under my home directory there might be } > functions are wrong, } } I wanted to err on the side of convenience. Please err on the side of my sanity instead. } > I won't call the aliases "badly" wrong, but I object to them anyway, } } I'm curious now. Why? Zefram has explained, if it wasn't already clear from my remarks above. Further, who are you to decide that I don't want the first N-1 arguments of cp and mv to be corrected, just because it would be wrong to correct the Nth one? } > and I'd just as soon not have all that crap in my prompt, thanks. } } Just another default, surely? Just another not-the-documented-default. On Jul 18, 12:35am, Adam Spiers wrote: } Subject: Re: adding a toplevel zsh.spec.in file } } [As an aside, I sometimes wonder why we don't make a } bells-and-whistles out of the box install of zsh much more easily } obtainable. After all, the vast majority of people only use zsh for } its bells and whistles.] Sigh. This is exactly the reason that a whole bunch of default setopts got turned on in 3.1 that used to be turned off in 3.0. I still remain unconvinced that it was a good idea, though I've largely given up on complaining about it (except for the occasional pot-shot like this). Bells and whistles are great when one understands what's happening. One is more likely to understand what's happening if one has to take some kind of action to make it so. Otherwise, the more things that happen, the more confused one becomes. For most instances of "one". } > Anything in the distribution is likely to be taken as something } > which is supposed to be installed in /etc. } } Which is exactly what StartupFiles/RedHat/* would be, no? Yes, which is exactly why they ought to have nothing in them that is not absolutely essential to making every RedHat system work correctly. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net