Allow case-sensitive environment variable setting

[lunagl]

Basics

• I have done a basic search through the issue tracker to find similar or related issues.
• I have made myself familiar with the available features of Nushell for the particular area this enhancement request touches.

Related problem

Nushell treats all environment variables as case-sensitive, and has #17558 made this more consistent on all platforms.
Unfortunately, as #14551 correctly notes, this goes against the Unix convention and POSIX (https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap08.html).

As also noted in that issue, this becomes particularly problematic when multiple variables that only differ in casing are present. Personally, it caused me a decent amount of headache just now to figure out why $env.SHELL is suddenly modified when loading a Nix devShell using direnv.

Describe the solution you'd like

It would therefore be great to have a way of defining/assigning env vars in a case-respecting manner. That means at minimum not coercing an assignment to shell into an assignment to the existing variable SHELL, and ideally allowing two variables that only differ in casing (such as SHELL and shell) to coexist.

It might be implemented in the form of a special flag for load-env and similar commands.

Describe alternatives you've considered

Ideally, I would love to be able to turn off case-insensitivity entirely, since I see little benefit (beyond Windows compatibility, which is not relevant for my use case) and believe it only causes more issues and annoying edge cases.

But as Nushell seems to have committed to case insensitivity I assume such a toggle would be difficult to realize and would probably cause a bunch of incompatibility between scripts etc.

Additional context and details

No response

[fdncred]

You can see on the first 2 commits of #17558 I did what you were asking for. Unfortunately, you weren't there to discuss the topic with @NotTheDr01ds and myself. So, we kept it working like it was before but just more consistent.

[lunagl]

Yeah I only became aware of the issue after updating to 0.111.0 and running into the situation I described. Also I apologize if the original text came of as rude, I really appreciate the work y'all do. Maybe the handling can still be changed in some way to make Nushell work better on Unix systems?

[fdncred]

Oh, it can be changed. It's just software. But you'll have to get @NotTheDr01ds and perhaps others on your side to make that change. I already tried. :)

[NotTheDr01ds]

A few quick notes here:

• I'd support something like @lunagl suggests, with a case-preserving way of setting environment variables inside Nushell using flags on load-env. For instance:

  {
    http_proxy: "https://example.com/blah"
    HTTP_PROXY: "https://example.com/blah"
  }
  | load-env --keep-case

• As mentioned in the past, POSIX compatibility isn't a goal of Nushell. I'm all in favor of it when it's the best way of doing something, but ...

• In general, I still support case-insensitive, case-preserving behavior across both Windows and Unix. I don't think we should have different behavior on each platform, and I think case-insensitive, preserving is a better solution.

• In 0.110, we had the ability to inherit two different environment variables with the same name, but different case, and Nushell would treat each individually. We seem to have lost that in 0.111, so we need to look at a fix there.

  # In Bash:
  export foo="foo"
  export FOO="FOO"
  nu -n
  # In 0.110, there are two variables, and each can be changed without changing the other
  # In 0.111, only the `foo` version exists

  When this was working, we could specify variable names we needed to treat separately in the terminal config, parent environment, etc. In 0.111, I can't think of a way to do this.

[lunagl]

@NotTheDr01ds thanks for your reply! I've been thinking about how to solve this elegantly, but I can't think of any good solution other than "follow the system regarding case sensitivity".

In fact I would argue that case-sensitive variables would be the expected normal case, since that is how all other (non-env) variables in Nushell behave, as well as in most other modern programming languages.

Now Windows decided to treat them as case-insensitive, which a shell should arguably respect and be able to deal with correctly.
On most other systems however (I believe all other current Nushell targets) this case-insensitivity does not exist, and by treating them as such anyway we are introducing a discrepancy between Nushell and the system / all other software on the system.
In particular, we are artificially limiting the ability to deal with all potential environments (not being able to represent multiple vars that only differ in casing) and we are causing potential for bugs / unexpected behavior, such as what I experienced above (SHELL already exists, load-env gets shell from an external program and overrides SHELL with the latter because of adaptive casing).
Introducing some mechanism to allow the mentioned case-preserving behavior when explicitly invoked could technically alleviate the first issue, but as long as it is not the default, the issue of users running into unexpected behavior still remains.

So for me all of this begs the question, why bother in the first place? We have the same kind of situation with filesystem paths, where Windows/NTFS is case-insensitive, but most others are not (I think here MacOS can be, depending on configuration). Obviously it would be very poor design if we went ahead and always treated paths as case-insensitive for the sake of consistency between systems. If we accept environment variables as a similarly system-dependent resource as filesystem paths it only makes sense to apply the same logic there.

[fdncred]

Now Windows decided to treat them as case-insensitive ...

This statement is not quite correct. I believe Windows is a little more nuanced unfortunately.
Keys: case-insensitive lookup, case-preserving storage
Values: case-preserving (and usually compared case-sensitively by applications)

I could live with Windows doing its own thing and Linux/MacOS because case sensitive. Although I'm not sure I'm up for yet another round of changes to this since I've done it twice already.

This is how I originally had the PR. I bring this up because we're going to keep PATH case-insensitive either way we go.

//! Environment variable name handling with platform-specific case sensitivity.
//!
//! This module defines `EnvName`, a wrapper around `String` that handles case sensitivity
//! for environment variable names according to platform conventions and Nushell's needs.
//!
//! ## Case Sensitivity Rules
//!
//! - **Windows**: All environment variable names are case-insensitive but case-preserving.
//!   This matches Windows' behavior where `PATH`, `Path`, and `path` refer to the same variable.
//!
//! - **Other platforms (macOS, Linux, etc.)**: Environment variable names are case-sensitive,
//!   meaning `HOME` and `home` are different variables.
//!
//! - **Special case for PATH**: Regardless of platform, the `PATH` environment variable
//!   (and its variants like `Path`, `path`, `pAtH`) is treated as case-insensitive on all platforms.
//!   This ensures compatibility with existing scripts and external command execution.
//!
//! This ensures that:
//! - `$env.PATH`, `$env.path`, `$env.Path` all work on any platform
//! - Other env vars like `$env.HOME` vs `$env.home` remain distinct on Unix
//! - Windows continues to work as before
//! - Existing tests and scripts don't break