of paths will be searched. The constant `NU_LIB_DIRS` will be searched _first_ and have
precedence. If a file matching the name is found in one of those directories, the search will
stop. Otherwise, it will continue into the `$env.NU_LIB_DIRS` search path.
#### `NU_PLUGIN_DIRS` Constant
`const NU_PLUGIN_DIRS` works in the same way for the plugin search path.
The following `NU_PLUGIN_DIRS` configuration will allow plugins to be loaded from;
- The directory where the `nu` executable is located. This is typically where plugins are located in release packages.
- A directory in `$nu.data-dirs` named after the version of Nushell running (e.g. `0.100.0`).
- A `plugins` directory in your `$nu.config-path`.
```nu
const NU_PLUGIN_DIRS = [
($nu.current-exe | path dirname)
($nu.data-dir | path join 'plugins' | path join (version).version)
($nu.config-path | path dirname | path join 'plugins')
]
```
### Colors, Theming, and Syntax Highlighting
You can learn more about setting up colors and theming in the [associated chapter](coloring_and_theming.md).
### Configuring Nu as a Login Shell
The login shell is often responsible for setting certain environment variables which will be inherited by subshells and other processes. When setting Nushell as a user's default login shell, you'll want to make sure that the `login.nu` handles this task.
Many applications will assume a POSIX or PowerShell login shell, and will either provide instructions for modifying the system or user `profile` that is loaded by POSIX login-shells (or `.ps1` file on PowerShell systems).
As you may have noticed by now, Nushell is not a POSIX shell, nor is it PowerShell, and it won't be able to process a profile written for these. You'll need to set these values in `login.nu` instead.
To find environment variables that may need to be set through `login.nu`, examine the inherited environment from your login shell by running `nu` from within your previous login shell. Run:
```nu
$env | reject config | transpose key val | each {|r| echo $"$env.($r.key) = '($r.val)'"} | str join (char nl)
```
Look for any values that may be needed by third-party applications and copy these to your `login.nu`. Many of these will not be needed. For instance, the `PS1` setting is the current prompt in POSIX shells and won't be useful in Nushell.
When ready, add Nushell to your `/etc/shells` (Unix) and `chsh` as discussed in [the Installation Chapter](./default_shell.md).
### macOS: Keeping `/usr/bin/open` as `open`
Some tools such as Emacs rely on an [`open`](/commands/docs/open.md) command to open files on Mac.
Since Nushell has its own [`open`](/commands/docs/open.md) command with a different meaning which shadows (overrides) `/usr/bin/open`, these tools will generate an error when trying to use the command.
One way to work around this is to define a custom command for Nushell's [`open`](/commands/docs/open.md) and create an alias for the system's [`open`](/commands/docs/open.md) in your `config.nu` file like this:
```nu
alias nu-open = open
alias open = ^open
```
Place this in your `config.nu` to make it permanent.
The `^` symbol tells Nushell to run the following command as an _external_ command, rather than as a Nushell built-in. After running these commands, `nu-open` will be the Nushell _internal_ version, and the `open` alias will call the Mac, external `open` instead.
For more information, see [Running System (External) Commands](./running_externals.md).
## Detailed Configuration Startup Process
This section contains a more detailed description of how different configuration (and flag) options can be used to
change Nushell's startup behavior.
### Launch Stages
The following stages and their steps _may_ occur during startup, based on the flags that are passed to `nu`. See [Flag Behavior](#flag-behavior) immediately following this table for how each flag impacts the process:
| Step | Stage | Nushell Action |