Immutable Variables, Scoped Environment, and Nushell's Design

To resolve this, of course, simply use the full-path to the file to be sourced. ```nu source-env spam/foo.nu ``` ::: ### Summary ::: important For a more in-depth explanation of this section, see [How Nushell Code Gets Run](how_nushell_code_gets_run.md). ::: ::: warning Thinking in Nushell Nushell is designed to use a single Parsing stage for each expression or file. This Parsing stage occurs before and is separate from Evaluation. While this enables many of Nushell's features, it also means that users need to understand the limitations it creates. ::: ## Variables are Immutable by Default Another common surprise when coming from other languages is that Nushell variables are immutable by default. While Nushell has optional mutable variables, many of Nushell's commands are based on a functional-style of programming which requires immutability. Immutable variables are also key to Nushell's [`par-each` command](/commands/docs/par-each.md), which allows you to operate on multiple values in parallel using threads. See [Immutable Variables](variables.html#immutable-variables) and [Choosing between mutable and immutable variables](variables.html#choosing-between-mutable-and-immutable-variables) for more information. ::: warning Thinking in Nushell If you're used to relying on mutable variables, it may take some time to relearn how to code in a more functional style. Nushell has many functional features and commands that operate on and with immutable variables. Learning them will help you write code in a more Nushell-idiomatic style. A nice bonus is the performance increase you can realize by running parts of your code in parallel with `par-each`. ::: ## Nushell's Environment is Scoped Nushell takes multiple design cues from compiled languages. One such cue is that languages should avoid global mutable state. Shells have commonly used global mutation to update the environment, but Nushell attempts to steer clear of this approach. In Nushell, blocks control their own environment. Changes to the environment are scoped to the block where they occur. In practice, this lets you write (as just one example) more concise code for working with subdirectories. Here's an example that builds each sub-project in the current directory: ```nu ls | each { |row| cd $row.name make } ``` The [`cd`](/commands/docs/cd.md) command changes the `PWD` environment variables, but this variable change does not survive past the end of the block. This allows each iteration to start from the current directory and then enter the next subdirectory. Having a scoped environment makes commands more predictable, easier to read, and when the time comes, easier to debug. It's also another feature that is key to the `par-each` command we discussed above. Nushell also provides helper commands like [`load-env`](/commands/docs/load-env.md) as a convenient way of loading multiple updates to the environment at once. ::: tip See Also [Environment - Scoping](./environment.md#scoping) ::: ::: note [`def --env`](/commands/docs/def.md) is an exception to this rule. It allows you to create a command that changes the parent's environment. ::: ::: warning Thinking in Nushell Use scoped-environment to write more concise scripts and prevent unnecessary or unwanted global environment mutation. :::

This section details Nushell's design choices regarding variables and the environment. It highlights that variables are immutable by default, promoting a functional style of programming and enabling parallel operations with `par-each`. It then introduces the concept of a scoped environment, where environment changes are limited to the block they occur in, providing predictability and ease of debugging. It uses `cd` as an example. It also mentions the `load-env` command for loading environment updates and notes that `def --env` is an exception to the scoped environment rule. The section emphasizes avoiding global mutable state and encourages using the scoped environment for concise and predictable scripts.