feat: work as a drop-in ls replacement

[WhyNotHugo]

Currently, exa doesn't support the -t flag in the same way as ls, so it won't work as a drop in replacement. That is, ls -ltra works, but exa -ltra won't work.

An issue existed at the exa repository for this: https://github.com/ogham/exa/issues/519

I also wrote a patch fixing this: https://github.com/ogham/exa/commit/fa76a335fd40d1f81b656b3d602309e7d39bed2f

I tried cherry-picking this, but some conflicts seem non-trivial. I'd appreciate hearing some feedback on the patch first, and if it looks good, I'll like to incorporate it into eza. Notably:

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

[MartinFillon]

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

[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.

[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

[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

[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.

[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.

[genevieve-me]

Even if it's not -t, is there a possibility of adding some other short option for sorting by mtime? Like others have mentioned I used this constantly and I suppose I can add a new shell alias lst or lat but I would really love to see eza just stick closer to ls behavior here.

[angrox]

This is also a dealbreaker for me. I run ls -lart too often at too many systems where I just have ls instead of eza.

Idea: compability env variable for those options? EZA_LS_COMPABILITY=1 ?

[cafkafk]

This is also a dealbreaker for me. I run ls -lart too often at too many systems where I just have ls instead of eza.

Idea: compability env variable for those options? EZA_LS_COMPABILITY=1 ?

Our plan is to introduce a flag that makes eza ls compatible, this is gonna be done after the clap migration

[cafkafk]

A lot of specific feedback seems to get lost in this thread, if you have some feature request, make sure to create a separate issue for it, I just see "work as drop-in replacement" in the issue tracker, but there are suggestions here like a short flag for sorting by mtime that likely have a harder time being picked up by contributors from not having their own issue

[MartinFillon]

Our plan is to introduce a flag that makes eza ls compatible, this is gonna be done after the clap migration

speaking of that if anyone wanna help review it as its a long standing pr we will accept the help