feat: work as a drop-in ls replacement about eza

[adrian-the-git]

eza -F works the same

...it works the same unless you try something like -Fl.

The -t flag is my personal dealbreaking itch with this tool (I run ls -lrt hundreds zillions of times per day). I don't want to develop muscle memory for -lsnew and find myself fighting with vanilla linux.

I haven't looked at the argument parsing code—is this kind of disambiguation for ls compatibility likely to be complicated to implement? I think we all have our repetitive behaviors with ls. If this kind of fix is unlikely to work with eza, I might go back to my ancient-but-functional color ls drop-in replacement.

[moonfruit]

• When -t is specified with arguments, it behaves much like exa -t X.

• When -t is specified without arguments, it behaves like ls.

I don't think this can be done. This is because when parsing a single character argument, it is necessary to know if the corresponding argument requires an additional parameter.

According to the existing parsing logic, a command line like eza -tmodified is valid. If, as suggested by @WhyNotHugo, eza can't tell whether the ra after the letter t in eza -ltra is another two arguments or the parameters belonging to t. This is ambiguity.

[MartinFillon]

I've also discovered recently ls -p which suffixes folders with a /, making them more distinct, and that eza lacks:

eza -F works the same as it classifies which type of file it is, it then adds the / for directories and * for executables and '@' for links

[MartinFillon]

this can either be picked up by someone as I myself will wait/implement this in #640 but not in main branch

[WhyNotHugo]

Quite true. I guess the only options are to chose one of the following:

• Remain compatible with exa.
• Remain compatible with ls.

[MartinFillon]

I don't think this can be done. This is because when parsing a single character argument, it is necessary to know if the corresponding argument requires an additional parameter.

This is doable, and we have what needed but as Clap is incoming I dont wanna take time to modify it, you are free to do it yourself tho.

[teto]

I've also discovered recently ls -p which suffixes folders with a /, making them more distinct, and that eza lacks:

➜ eza -p                    
eza: Unknown argument -p
home on  boot-fixes via ❄️  IMPURE (dotfiles-shell-env) 
❌3 ❯ eza --version  
eza - A modern, maintained replacement for ls
v0.18.0 [+git]
https://github.com/eza-community/eza

[cafkafk]

I've also discovered recently ls -p which suffixes folders with a /, making them more distinct, and that eza lacks:

➜ eza -p                    
eza: Unknown argument -p
home on  boot-fixes via ❄️  IMPURE (dotfiles-shell-env) 
❌3 ❯ eza --version  
eza - A modern, maintained replacement for ls
v0.18.0 [+git]
https://github.com/eza-community/eza

This should probably be a separate issue, seems useful, and easy to implement, although I'm not much for using a single letter flag for this

[WhyNotHugo]

I haven't looked at the argument parsing code—is this kind of disambiguation for ls compatibility likely to be complicated to implement?

I implemented it and it works on many cases, but there are edge cases where it can be ambiguous (as mentioned in a comment above).

[moonfruit]

The -t flag is my personal dealbreaking itch with this tool (I run ls -lrt hundreds zillions of times per day). I don't want to develop muscle memory for -lsnew and find myself fighting with vanilla linux.

@adrian-the-git Yes. It itches me too. So I made a script to wrap eza: when -lrt appears the script simply replaces it with -lsnew, then sends the argument to eza.