bug: piped output causes eza to print symlink targets

[wlritchi]

• eza v0.18.17
• no arguments
• Arch Linux x86_64

When eza's output is piped, it switches to the lines view, which causes it to print symlink targets.

$ touch target
$ ln -s target symlink
$ ln -s missing badlink
$ eza
badlink  symlink  target

$ eza -l
lrwxrwxrwx - wlritchi 12 Jun 04:12 badlink -> missing
lrwxrwxrwx - wlritchi 12 Jun 04:11 symlink -> target
.rw-r--r-- 0 wlritchi 12 Jun 04:12 target

$ eza | cat
badlink -> missing
symlink -> target
target

This breaks user expectations including mine. However, it's also well-established behavior in exa/eza, dating back at least 9 years. Despite the legacy, I'd like to consider changing it.

Related work

In #932 a user attempted to work around this behavior using --dereference, which the user expected would suppress printing the target (as it does in ls). This didn't work, and so #937 changed the behavior of --dereference for parity with ls.

However, I believe most users of the --dereference flag expect, and get more value from, eza's old behavior. As the author of early hacky work towards the feature, I expected targets to continue to be shown, and I think the examples in the original PR implementing --dereference show that author expected the same. Due to this difference of expectations, I'd like to reconsider the original question. If #937 was largely useful as a workaround to this issue, then perhaps once this issue is fixed, #937 could be reverted.

Should eza | cat print symlink targets?

If I were deciding the question for a fresh project, I would lean strongly towards no - it doesn't seem like the sort of behavior that should change just because output is piped, and frankly it makes scripting and pipelines harder to work with. I've aliased ls to eza, and I can't tell you how many times I've screwed up a ls | xargs ... pipeline because of the stray -> in the output. But in an established project, I suppose it's possible some users are used to this behavior, maybe as part of eza | less.

A trickier problem is --oneline, which currently uses the same lines view. Here, I do think printing link targets is useful, and I also think users are more likely to miss it if we changed behavior. So, should --oneline be a different view than eza | cat? I think it would be reasonable to have piped as its own view, but it probably warrants more discussion.

cc @Vosjedev as the reporter in #932 I'd like to know if this issue solves your use case. Also cc @agrzeslak @bd-g @pierzchalski as participants in ogham/exa#1136 who might be able to chime in with their expectations.

[Vosjedev]

Hi,
This would work for me, however it would not be a permanent solution for reverting #932 , we would need a solution to do that without a pipe in some way. Maybe a new flag (--don't-show-link-targets or I guess something shorter?)