display_output hook ignored default LS_COLORS

[fdncred]

Describe the bug

When using this hook, it appears that the default LS_COLORS is being ignored and some other system level LS_COLORS are being used.

        display_output: {
            if (term size).columns > 100 { table -e } else { table }
        }

How to reproduce

1. install hook
2. execute ls
3. observe the wrong LS_COLORS

Expected behavior

This is what it looks like

This is what it should look like

Screenshots

No response

Configuration

key	value
version	0.71.1
branch	main
commit_hash	6454bf6
build_os	macos-aarch64
build_target	aarch64-apple-darwin
rust_version	rustc 1.63.0 (4b91a6ea7 2022-08-08)
rust_channel	1.63.0-aarch64-apple-darwin
cargo_version	cargo 1.63.0 (fd9c4297c 2022-07-01)
pkg_version	0.71.1
build_time	2022-11-18 15:59:15 -06:00
build_rust_channel	release
features	database, dataframe, default, trash, which, zip
installed_plugins	custom-value generate, custom-value generate2, custom-value update, from parquet, gstat, inc, nu-example-1, nu-example-2, nu-example-3, query, query json, query web, query xml

Additional context

This could be a problem with table -e as well. I'm not sure exactly.

[sophiajt]

Here's what I'm seeing in Windows:

[sophiajt]

And for the Nushell directory:

[sophiajt]

Here's a screenshot for me on macOS with a fresh build and fresh env/config files.

[fdncred]

This is a little hard to follow but it's what I'm seeing.

I think I'm narrowing down on some influencing factors

1. i'm using fish shell as my login shell
2. i'm using /opt/homebrew/opt/coreutils/libexec/gnubin/ls as my default ls
3. that coreutils ls, apparently creates LS_COLORS env var, each time you type ls, if you don't have one set
4. i believe these default coreutils LS_COLORS are the colors i'm seeing as "wrong"
5. when i unset the env var in fish shell and type env to ensure LS_COLORS is gone, then immediately start nushell, the colors seem fine. i.e. it's not inheriting any false LS_COLORS.
6. the opposite it true too, if I unset the LS_COLORS env var in fish shell, then type ls (which creates a default LS_COLORS), then type env, i see the false LS_COLORS created by the coreutils ls command. then if i run nushell, somehow with the display_output, it's picking up on this env var and using it, even though the last line in my config.nu is hide LS_COLORS

So, stated another way, if I've told nushell to specifically hide LS_COLORS in my config.nu, meaning no LS_COLORS env var should ever be set anywhere, why does it inherit whatever my host shell had in certain circumstances?

[sophiajt]

I'm not sure if you can hide what the host gives us, but we'd have to confirm with Jakub. I was trying to remember - I think we always fall back to the environment we get from the host.

[fdncred]

So, you're saying, that even though, when I'm in nushell and do env or $env, and there is no LS_COLORS anywhere in my nushell environment, that ls should still query the hosts LS_COLORS environment variable?

[fdncred]

I still think there's a bug here. If I do a hide LS_COLORS there should be no way that nushell see's my parent shell's LS_COLORS. The only way I've been able to get this to work properly is to follow this and do an unset LS_COLORS before launching nushell. That should not be necessary since I also have a hide LS_COLORS as my 2nd to last line in my config.nu.