Re: adding a toplevel zsh.spec.in file

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Jul 17,  7:07pm, Adam Spiers wrote:
} Subject: Re: adding a toplevel zsh.spec.in file
}
} Bart Schaefer (schaefer@xxxxxxxxxxxxxxxxxxxxxxx) 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