bug: different behaviour from `ls` when stdout is not a tty.

[slqy123]

When I am using eza with xargs -I, I get different output with ls.

❯ ls
1  2  3

❯ /bin/ls | xargs -I {} echo {} {}
1 1
2 2
3 3

❯ /bin/eza | xargs -I {} echo {} {}
1  2  3 1  2  3

It seems that when stdout is not a tty, ls will separate each file by '\n'

❯ /bin/ls > ../ls_out
❯ /bin/eza > ../eza_out
❯ diff eza_out ls_out
1c1,3
< 1  2  3
---
> 1
> 2
> 3

❯ /bin/ls > /dev/pts/2
❯ 1  2  3

env:

• findutils 4.9.0-3
• coreutils 9.3-1
• eza 0.13.1-1

[cafkafk]

When I am using eza with xargs -I, I get different output with ls.

❯ eza
1  2  3

~/stu 
✦ ❯ ls | xargs -I {} echo {} {}
1 1
2 2
3 3

~/stu 
✦ ❯ eza | xargs -I {} echo {} {}
1 1
2 2
3 3

I can't reproduce this. Can you try running with #438?

[slqy123]

I can't reproduce this. Can you try running with #438?

This dose not work too.

eza/target/release on  main
❯ ./eza | xargs -I {} echo {} {}
build  deps  examples  eza  eza.d  incremental  libeza.d  libeza.rlib build  deps  examples  eza  eza.d  incremental  libeza.d  libeza.rlib

I am using archlinux in wsl2, but I have also tested in my archlinux real machine and a new ubuntu in wsl2, both the same result.

[MartinFillon]

Cannot reproduce too

[hehelego]

I can reproduce this exactly.

> /bin/eza | xargs -I {} echo {} {}
Desktop  Documents  Downloads  go  MOOC  Music  Pictures  Public  QAQ  SHTU  SOUND  Templates  Videos Desktop  Documents  Downloads  go  MOOC  Music  Pictures  Public  QAQ  SHTU  SOUND  Templates  Videos

> /bin/ls | xargs -I {} echo {} {}
Desktop Desktop
Documents Documents
Downloads Downloads
go go
MOOC MOOC
Music Music
Pictures Pictures
Public Public
QAQ QAQ
SHTU SHTU
SOUND SOUND
Templates Templates
Videos Videos

• eza version: v0.13.1 [+git]
• ls version: ls (GNU coreutils) 9.3

[hehelego]

Also, the last release of exa behaves like ls. You can get it here: https://github.com/ogham/exa/releases/tag/v0.10.1

[hehelego]

438 only dealt with --color=auto without touching code handling grid/oneline output. That patch should not have any effect. But I think finding and replacing terminal_size::terminal_size() calls with std::io::stdout().is_terminal() can fix this.

BTW, I can expect much more ls compatbility issues like this one to come out, as eza gains popularity. I kind of know what are people's feeling. I've been using exa as a drop-in replacement of ls for nearly two years and it was mostly fine. I switched to eza from exa roughly a 2/3 weeks ago when a pacman -Syu update replaced exa wiith eza automatically (now if you try to install with pacman -S exa, what you'll actaully get is our eza). That migration did not go smoothly. I noticed eza behavior differs from exa, causing some small trouble, because I actually have alias ls=exa in my config.fiish.
You are (I mean, I am) really expecting eza to be ls compatible especially when it comes as a replacement of exa which was ls compatible.

[hehelego]

I think I can fix that. See https://github.com/eza-community/eza/pull/438#issuecomment-1741188125 I've tried to replace it with terminal_size_with_raw_fd() on stdout and it works

[cafkafk]

You are (I mean, I am) really expecting eza to be ls compatible especially when it comes as a replacement of exa which was ls compatible.

Well we're always looking for people willing to help that effort. We've been discussing adding a flag that would ideally be strictly compatible with ls, and we've worked a lot on getting proper integration testing to ensure issues like these don't happen suddenly.

Also, exa certainly wasn't ls compatible, although it does seem to have had some overlaps. Hopefully, with testing, we'll be enabled to better ensure that compatibility, and not have regressions on it... but we need people.

✦ ❯ ls -a
.         Cargo.lock    CODE_OF_CONDUCT.md  deny.toml  empty       .git                    Justfile  README.md            screenshots.png  target
..        Cargo.toml    completions         devtools   .envrc      .git-blame-ignore-revs  LICENCE   result               SECURITY.md      tests
benches   CHANGELOG.md  CONTRIBUTING.md     .direnv    flake.lock  .github                 man       rustfmt.toml         snap             treefmt.nix
build.rs  cliff.toml    deb.asc             dump       flake.nix   .gitignore              out.gif   rust-toolchain.toml  src

eza on  Brijeshkrishna/main:main [$] is 📦 v0.13.1 via 🦀 v1.70.0 via ❄️  impure (nix-shell-env) 
✦ ❯ exa -a
.direnv                 .github     Cargo.lock    CODE_OF_CONDUCT.md  deny.toml  flake.lock  man        rust-toolchain.toml  snap    treefmt.nix
.envrc                  .gitignore  Cargo.toml    completions         devtools   flake.nix   out.gif    rustfmt.toml         src     
.git                    benches     CHANGELOG.md  CONTRIBUTING.md     dump       Justfile    README.md  screenshots.png      target  
.git-blame-ignore-revs  build.rs    cliff.toml    deb.asc             empty      LICENCE     result     SECURITY.md          tests   

eza on  Brijeshkrishna/main:main [$] is 📦 v0.13.1 via 🦀 v1.70.0 via ❄️  impure (nix-shell-env) 
✦ ❯ exa --version
exa - list files on the command-line
v0.10.1 [+git]
https://the.exa.website/

[hehelego]

You are (I mean, I am) really expecting eza to be ls compatible especially when it comes as a replacement of exa which was ls compatible.

Well we're always looking for people willing to help that effort. We've been discussing adding a flag that would ideally be strictly compatible with ls, and we've worked a lot on getting proper integration testing to ensure issues like these don't happen suddenly.

We will have more people. eza has 2.6k stars. There are certainly people who are willing to help.

[hehelego]

@slqy123 can you try to run with https://github.com/eza-community/eza/pull/438 now?
It should have fixed the problem. at least on my machine.

[slqy123]

@slqy123 can you try to run with #438 now? It should have fixed the problem. ~at least on my machine~.

Yes, it works pretty well now, thanks for your help.