- 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.
When eza's output is piped, it switches to the
linesview, which causes it to print symlink targets.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 inls). This didn't work, and so #937 changed the behavior of--dereferencefor parity withls.However, I believe most users of the
--dereferenceflag 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--dereferenceshow 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 | catprint 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
lstoeza, and I can't tell you how many times I've screwed up als | 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 ofeza | less.A trickier problem is
--oneline, which currently uses the samelinesview. 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--onelinebe a different view thaneza | cat? I think it would be reasonable to havepipedas 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.