Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: Good, easy to use, upstream defaults for zsh (i.e. improving usability)



On Jul 14,  6:43pm, Peter Stephenson wrote:
}
} Bart Schaefer wrote:
} > Here's something that occurred to me:
} > 
} > During startup, if none of the ${ZDOTDIR:-$HOME}/.z* files are found,
} > zsh looks for (but does not complain if it does not find) a "new user"
} > module, e.g. zsh/newuser, and loads it.
} > 
} > (Or the module could be loaded unconditionally, and the test for whether
} > the .z* files exist could be part of the module bootup.)
} 
} The second alternative is more natural from the point of view of
} modularity, although a little less efficient.  Presumably we could
} safely attempt to unload the module immediately.

Agreed on both counts.

} > We could provide a default implementation of zsh/newuser that looks
} > for files in /usr/share/zsh/$VERSION

On further thought, probably the right thing is for the module to look
for a *single* file, and either simply source it, or autoload it and
then call a specified function that it is expected to define.  Anything
else we might want to do can then be programmed in shell language,
within that file or function.

(I think the test for existence of the .z* files should remain within
the C code, though.)

} One thing that occurs to me is that we need to make it easy for admins
} to override the defaults.  Hence I think it should look in, say,
} <install-path>/newuser/ and <install-path>/$VERSION/newuser/, probably
} in that order

This would be fine, though perhaps <install-path>/site-functions/ is a
better spot to look first if it were a single autoloadable file.  There
may be valid reasons to make this something that can be manually loaded/
called, as with compinstall.



Messages sorted by: Reverse Date, Date, Thread, Author