Open wlritchi opened 2 weeks ago
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?)
When eza's output is piped, it switches to the
lines
view, 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--dereference
for parity withls
.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
toeza
, 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 samelines
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 thaneza | cat
? I think it would be reasonable to havepiped
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.