A shared exported guard `__NIXOS_SET_ENVIRONMENT_DONE` is introduced that can
be used to prevent child shells from sourcing `system.build.setEnvironment`
the second time.
This fixes e.g. `nix run derivation` when run from e.g. ZSH through the console or
ssh. Before this Bash would resource the common environment resetting the `PATH`
environment variable.
We also export `system.build.setEnvironment` to `/etc/set-environment` making it
easy to reset the common environment with `. /etc/set-environment` when
needed and to grep for environment variables in `/etc` (which was the
motivation of #30418).
This reverts changes made in b00a3fc6fd
(the original #30418).
In the last year `programs.oh-my-zsh` gained more complexity and since
the introduction of features like `customPkgs` which builds a
`ZSH_CUSTOM` path from a sequence of derivation a documentation may be
fairly helpful to make the knowledge how to use the module and how to
package new ZSH plugins visible.
See https://github.com/NixOS/nixpkgs/pull/43282#issuecomment-410770432
If multiple third-party modules shall be used for `oh-my-zsh` it has to
be possible to create another env which composes all the packages.
Now it can be done like this:
```
{ pkgs, ... }:
{
programs.zsh.enable = true;
programs.zsh.ohMyZsh = {
enable = true;
customPkgs = with pkgs; [
lambda-mod-zsh-theme
nix-zsh-completions
];
theme = "lambda-mod";
plugins = [ "nix" ];
};
}
```
Please keep in mind that this is not compatible with
`programs.zsh.ohMyZsh.custom`, only one of these options can be used
ATM.
Each package should store its outputs into
`$out/share/zsh/<output-name>`. Completions (and ZSH-only) extensions
should live in the `fpath` (`$out/share/zsh/site-functions`), plugins in
`.../plugins` and themes in `.../themes` (please refer to
fdb6bf6ed68c2f089ae6c729dfeaa3eddea2ce6a and 406d64aad162b3a4881747be4e24705fb5182573).
All scripts in `customPkgs` will be linked together using `linkFarm` to
provide a single directory for all scripts from all derivations in
`customPkgs` as suggested in https://github.com/NixOS/nixpkgs/pull/43282#issuecomment-410396365.
The `zsh-autosuggestions` package provides several configuration options
such as a different highlight style (like `fg=cyan` which is easier to
read).
With `rename.nix` the old `programs.zsh.enableAutosuggestions` is still
functional, but yields the following warning like this during evaluation:
```
trace: warning: The option `programs.zsh.enableAutosuggestions' defined in `<unknown-file>' has been renamed to `programs.zsh.autosuggestions.enable'.
```
The module provides the most common `zsh-autosuggestions` (highlight
style and strategy) as options that will be written into the interactive
shell init (`/etc/zshrc` by default). Further configuration options can
be declared using the `extraConfig` attr set:
```
{
programs.zsh.autosuggestions.extraConfig = {
"ZSH_AUTOSUGGEST_BUFFER_MAX_SIZE" = "buffer_size";
};
}
```
A full list of available configuration options for `zsh-autosuggestions`
can be viewed here: https://github.com/zsh-users/zsh-autosuggestions/blob/v0.4.3/README.md
The default cache directory set by oh-my-zsh is $ohMyZsh/cache which
lives in the Nix store in our case. This causes issues with several
completion plugins provided by oh-my-zsh.
`cfg.interactiveShellInit` is used by modules like
`programs.zsh.oh-my-zsh`. This means that all aliases defined in
`programs.zsh.shellAliases` might be overriden which is highly
unpredictable
Originially, `programs.zsh` sets default values for some
initialisation scripts.
Nix resolves the case of multiple values by concatenating them all.
It is however impossible to predict where the default script will be
inserted; but we never want the default value to override the
user-specified ones.
Now, it doesn't set default values; almost everything is hardcoded at
the begining of the file.
Right now the `programs.zsh.syntax-highlighting.highlighters` option
lacks appropriate validation which can cause confusing things when
mistyping a higlighter for zsh-syntax-highlighting.
* programs.zsh: factor zsh-syntax-highlighting out into its own module
* programs.zsh.syntax-highlighting: add `highlighters` option
* programs.zsh: document BC break introduced by moving zsh-syntax-completion into its own module
* programs.zsh: add enableOhMyZsh option to automate setup of oh-my-zsh in global zshrc
* programs.zsh: make oh-my-zsh plugins configurable
* programs.zsh: add ohMyZshCustom option
* programs.zsh: add ohMyZshTheme option
* programs.zsh: applying minor fixes to evaluate expressions properly
* programs.zsh: fix ordering of oh-my-zsh config and execution
* programs.zsh: move all oh-my-zsh params into its own scope named programs.zsh.oh-my-zsh
The content of programs.zsh.interactiveShellInit was
inserted too soon in the generated zshrc
This caused some settings related to autocompletion to be ignored
Every interactive zsh sources /etc/zshrc (see STARTUP/SHUTDOWN FILES in zshautll(1))
Therefor every interactive zsh process will respect the content of these variables.
Using `export` will also lead to child processes inheriting this value.
This leads to problems, if other interactive shells are spawned such as bash,
because they use an incomptabible history format (without timestamps).
There seems to be also cases, where the local HISTSIZE in ~/.zshrc is
not sourced but /etc/zshrc, which leads to history truncation in other shells.
This reverts commit 766207ca1d.
We need to solve the problem with `environment.profileRelativeEnvVars`.
The best workaround is to make profileRelativeEnvVars prepend paths.
NixOS has a pervasive dependency on bash. For instance, the X11
session script sources /etc/profile to get a reasonable
environment. Thus we should not provide an option to disable bash.
Also, enabling zsh no longer sets ‘users.defaultUserShell’ to zsh, to
prevent a collision with bash's definition of the same
option. (Changing the default shell is also something that should be
left to the user.)
Using pkgs.lib on the spine of module evaluation is problematic
because the pkgs argument depends on the result of module
evaluation. To prevent an infinite recursion, pkgs and some of the
modules are evaluated twice, which is inefficient. Using ‘with lib’
prevents this problem.
