eza: bug: macOS, issue with `--extended` or `-@`

Just found this community fork support and really appreciate your work!

I tried to swap the alias from exa to eza in .zshrc, but one of the alias seems not working in eza but working in exa. (see The command-line arguments you are using)

The version of eza being used (eza --version)

eza --version
eza - A modern, maintained replacement for ls
v0.13.1 [+git]
https://github.com/eza-community/eza

The command-line arguments you are using

eza -lbhHigUmuSaZ@ --time-style=long-iso --git --color-scale

[1]    25228 segmentation fault  eza -lbhHigUmuSa@ --time-style=long-iso --git --color-scale

I apologise if the arguments I used are incorrectly configured and please correct me if I am wrong, cheers!

Your operating system and hardware platform

macOS Ventura v13.6
MacBook Pro 2019 (Intel)

About this issue

Original URL
State: closed
Created 9 months ago
Reactions: 1
Comments: 21 (7 by maintainers)

Most upvoted comments

Can confirm that running eza -lbhHigUmuSa@ --time-style=long-iso --git --color-scale will no longer get segmentation fault error with eza v0.16.2. I noticed the only difference is the last part of the Name column between eza and original exa.

exa will display the length of the value for the extended item in the list. ├── com.apple.FinderInfo (len 32)
eza will display the value itself instead. (which is better I guess) ├── com.apple.FinderInfo: " @\u{10}"

Feel free to close this issue for now.

Edit: Thank you very much for getting it fixed! @cfxegbert

origamirabbit on Dec 6, 2023

Can you please check in v0.16.1 or later

cfxegbert on Dec 5, 2023

exa will display the length of the value for the extended item in the list. ├── com.apple.FinderInfo (len 32)

eza will display the value itself instead. (which is better I guess) ├── com.apple.FinderInfo: " @\u{10}"

I try to detect “printable” attributes now and display them. If it is a binary attribute and under 16 bytes I will display a hex dump else I display the length. I also decode com.apple.lastuseddate, com.apple.macl, and binary plist values.

cfxegbert on Dec 6, 2023

There’s a lot of unsafe code in there, I think we at least need some // SAFETY: comments explaining how we guarantee that the block is safe, on top of actually making it safe and not just assuming it’s valid UTF-8.

daviessm on Nov 9, 2023

I’ve not idea, but I can confirm that the latest build ofexa does not exhibit the same issue, so something has happened somewhere!

oscillik on Oct 30, 2023

Sorry macOS as well. Sonoma 14.0 (23A344)

jcoetzee on Oct 10, 2023

can confirm segmentation fault every time in ~/ executing eza -la@ -> [1] 20342 segmentation fault eza -la@ eza -l@ -> correct behaviour eza -a@ -> correct behaviour eza -la -> correct bahviour

happens in ~/, /tmp/, /Applications, ~/Applications (which its strange since I only have 3 automator applications) doesn’t happen in /dev, /opt, and a bunch of other directories i have tried

an error message would be much better than segmentation fault even if some options are incompatible

using iTerm but happens in the default terminal too using zsh but happens from bash too rustc 1.72.1 (d5c2e9c34 2023-09-13) macOS Sonoma 14.0 (23A344)

elvilio on Oct 1, 2023

I read a bit too fast the bug description, I’m on Linux so that may be a macOS-only issue. Some options aren’t «triggered» when using --long, in this case it means that if you try to use --extended with --long it won’t even try to read the extended attributes (in eza --help, --extended is listed in the LONG VIEW OPTIONS to indicate you that).

ariasuni on Sep 26, 2023