`ls -s other-directory` wrong colors for directories

[ComputerDruid]

Describe the bug

when using ls -s to list the contents of other directories, the colors are wrong for subdirectories

How to reproduce

> mkdir /tmp/a/b /tmp/b/a
> touch /tmp/a/a /tmp/b/b
> cd /tmp/b
> ls -s .
> ls -s ../a

Expected behavior

When running ls -s ../a I expected the directory (b) to be colored blue, and the file (b) to be colored white, but the reverse was true.

Configuration

version | transpose key value | to md --pretty

key	value
version	0.102.0
major	0
minor	102
patch	0
branch
commit_hash
build_os	linux-x86_64
build_target	x86_64-unknown-linux-gnu
rust_version	rustc 1.82.0 (f6e511eec 2024-10-15)
cargo_version	cargo 1.82.0 (8f40fc59f 2024-08-21)
build_time	2025-02-10 15:06:05 -08:00
build_rust_channel	release
allocator	mimalloc
features	default, sqlite, trash
installed_plugins

[ComputerDruid]

For comparison, external ls gets the colors right

[fdncred]

It's a known bug. ls -s doesn't maintain LS_COLORS because our LS_COLORS implementation needs to know the full path and -s removes it.

[ComputerDruid]

Some words about why this issue is important to me:

nushell seems like a nice language that I would enjoy using as my default shell environment. Since most commands don't produce structured output by default, I figured they would need to be wrapped in functions that switch them to a structured mode by default. Because colorized output is important to me, I started trying to figure out how to make custom commands emit colorized output (without ruining the actual file paths in case I later needed to work with them programmatically). Not finding any documentation about that, I tried to look into how the ls builtin accomplished that, and was disheartened to find that ls itself doesn't do it at all, and instead defers it toward the end, leading to predictable bugs like this one. Also it doesn't suggest a way for custom commands to accomplish the same kind of goal (colorized output that doesn't mess up future consumers of said output).

So for me, this bug is important for two big reasons:

• The colors emitted by ls -s are legitimately important to me. My brain uses the "blue color"-ness of directories to interpret them, and ls -s has the closest output to /bin/ls so that's what I would likely want to use as default in my shell.
• Colors in general are important to me as a terminal user, and the fact that they don't seem to be integrated into nushell in a principled way makes me feel like nushell isn't ready for me to use as a daily driver

Hopefully that's helpful as extra motivation for why this bug is important. And maybe that's all already obvious to y'all and the current implementation is just a placeholder for some grand vision that I haven't seen.

Meta note: I was motivated to leave this comment because I didn't get the sense that it was viewed as an important problem and thought sharing my perspective would help. I intend it to be constructive, but would be interested in feedback if it doesn't come across as constructive

[fdncred]

Thanks for sharing. We're looking for motivated users to fix problems by submitting PRs as they have time. I've tried to fix this problem before and what it required was holding a String that was the file's path and a String that was used only for Display purposes. I figured that would be too heavy handed, so I never landed it. That closed PR is probably in this repo still as closed not implemented. There may be other ways to tackle it but I'm not sure what they are.

[boomshroom]

This seems like it would be impossible if the only thing nushell has to work with is the shown string that gets printed. However that isn't all that's available. ls also gives the type of the directory entry even in short mode, and displaying that and the size also requires a stat call, which also gives the mode (which itself is shown in long mode) needed to tell if something is executable, etc.

So the needed information is still there, just not within the one cell being shown. This is particularly noticible when using grid, which reads from the given table and doesn't use the built-in path formatting, so it could read the type and mode fields if it wanted to show the correct colors and icons.

[fdncred]

Go for it if you think you can make it work across Win, Lin, Mac. I'd love to see it.

[132ikl]

I've bounced around the idea of styled strings. It would basically solve all the concerns you raise here. I sketched out something on this branch in my repo, and discussed it a bit in this Discord thread.

It's definitely something I still think would be good to add, but it's been difficult for me to justify working on it. It's a rather significant feature that will take a good amount of effort to get up and going, but it could also be tacked on post-1.0 since it really won't break anything ­– compared to the many other language breaking features I'd also like to work on, it doesn't feel like as big of a priority.

That being said, it might be good to get some basic in, even if it's not user accessible at first, to fix some of the glaring problems it would solve (like this and find). I would be absolutely thrilled if somebody picked it up though – and like @fdncred said earlier today, getting a basic version of some functionality in makes it more likely that somebody who's interested will take it further.

Anyways, all that to say that we definitely see the issues here and appreciate your feedback. I definitely think that colored output is something that is neglected in languages generally, and is definitely worthy of being a first-class citizen in a shell. I would love to have better ways of interacting with color in Nushell.