Z-shell has been my command line interpreter of choice for decades.
Someone recently asked me whether I could provide a copy of my .zshrc
, the
startup initialization file configuring how the shell should respond to its
controlling user. As these files tend to become a bit personal, they are not
easily shared in their entirety. Posting my unedited file(s) would likely not
be useful to any audience. No two individuals have the exact same preferences
or needs. If that would had been the case, the configuration files would not
have needed to exist in the first place.
Even for someone who wishes to have very similar shell initialization files as
mine, the value of merely copying them would be limited as the few comments in
them are only meaningful to me. In order to be able to utilize and expand,
explanations are crucial. Hence this blog post covering the very basics of my
.zshrc
and .zshenv
skeletons.
Very few of my actively used text based configurations are placed in a single
file. Instead a structure of a main file including partial files is used. It is
my opinion that organizing like that makes configuration more maintainable,
eases host specific deviations and aids with debugging when something breaks
due to some change to ones environment. Here follows a slightly shortened, but
conceptually complete, version of my .zshenv
file:
_zdotenv="${ZDOTDIR:-${HOME}}/.zshenv"
_ZDOTDIR_site="${_zdotenv:A:h}"
if [ "${_ZDOTDIR_site}" = "${HOME}" ]; then
_zdotenvdir="${_ZDOTDIR_site}/.zshenv.d"
else
_zdotenvdir="${_ZDOTDIR_site}/zshenv.d"
fi
case "${OSTYPE}" in
solaris*)
. "${_zdotenvdir}/zshenv.illumos"
;;
esac
. "${_zdotenvdir}/zshenv.cloud"
# There are quite a few more includes in my real `.zshenv` file.
unset _zdotenv _ZDOTDIR_site _zdotenvdir
Essentially the file only does two things, it figures out where to find files to include and it sources the ones it is specifically told to include. Reading the manual might be a good idea for understanding the details of exactly how it works.
As should be easily seen, the environment variable _zdotenvdir
is set to
point at where files are included from. The idea is that it points to a
subdirectory situated in the same directory as the main configuration file. By
default that would be the home directory, and in that case the subdirectory
.zshenv.d/
name starts with a period in order to be hidden. In case the
startup file is located somewhere else, which is easily obtained by making
.zshenv
a symlink, the subdirectory zshenv.d
is named without the initial
period and is thus not hidden from directory listings.
For true drop dir style behaviour, you might wish to simply include all files
found in _zdotenvdir
. I prefer explicitly specifying used files, as is done
with zshenv.illumos
and zshenv.cloud
above.
Similarly my .zshrc
looks like:
_zdotrc="${ZDOTDIR:-${HOME}}/.zshrc"
_ZDOTDIR_site="${_zdotrc:A:h}"
if [ "${_ZDOTDIR_site}" = "${HOME}" ]; then
_zdotrcdir="${_ZDOTDIR_site}/.zshrc.d"
else
_zdotrcdir="${_ZDOTDIR_site}/zshrc.d"
fi
. "${_zdotrcdir}/zshrc.prompt"
# There are quite a few more includes in my real `.zshrc` file.
unset _zdotrc _ZDOTDIR_site _zdotrcdir
The contents of that file should require no further explanation. For context
it might be worth knowing that the shell sources .zshenv
for all invocations,
while .zshrc
only is used when launched interactively.
Please feel free to use these as inspiration for your own startup files. I would recommend creating keeping a folder under version control and reusing it on all relevant computers.
I mightThere is a follow up with posts on my
zshenv.illumos
, zshenv.cloud
and zshrc.prompt
in Partial zshrc
Config upcoming blog entries. Possibly other files
too, if there is sufficient interest. Watch this space.