> -L (dereference ALL symlinks) is not implemented; don't see why you'd ever want to follow all symlinks. Instead, -L prevents showing the symlink targets in -l.
I can tell you why I use -L in normal "ls" - to see destination sizes.
I often use symlinks to deduplicate files but still have them in relevant places. For example, I may want to keep the original filename but also have it available via a "friendlier" name too, or I may want to categorise files without loving them, etc.
In a similar vein, I also make "source trees" of ISO images that I want to build (using mkisofs) for use in emulators and such using symlinks, because I don't want to take up too much space but they're easy to handle.
In both cases, being able to occasionally see sizes of the destination files (instead of the symlink itself) can be very useful, particularly if I'm sorting by size (-S -r) or want to make a quick estimation on whether two files are the same file or not (although in that case having the size display in bytes is also useful to me. GNU is has the -h flag to show human-readable sizes, though).
Anyway, thought you might be interested in this viewpoint! This looks very nifty.
Ah cheers, that's helpful! I don't really use symlinks that extensively myself (at least not in that way).
I implemented it in an earlier version; one reason I removed it is so I can re-use -L for "don't show link target" because I had a symlink with a very long link target. The -w to set column width and/or -trim to not wrap to the next line solve the same problem, so this option is now somewhat redundant (or at least, doesn't need a short one-letter "quick to type" flag).
Instead of “yst” and “dby”, which are a bit cryptic and hard to localize, I would suggest “-1” and “-2”. There could be a configuration parameter for how far back (and forth) relative dates should go. And sometimes there can be file times in the future, which could use “+1” and so on.
Ideally I would like to have a good way to configure this, via some sort of "strftime++" syntax or something which allows different format strings depending on the age of the file.
For me, personally, this has been working quite well. If something is older than two days I don't often care about the exact time it was changed. While "yst" and "dby" are indeed slightly cryptic, it's quite mnemonic and reads naturally: "yesterday 15:14", "day before yesterday 07:42". Something like "-1 15:15" and "-2 07:42"? Rather less so.
It doesn't support icons and the colour scheme is identical to ls. I'm not a fan of hugely colourful output in general.
I don't have a full comparison table, often it's in small things. Personally I don't care for some decisions the eza/lsd people made, and that's fine. I don't really want to spend time explaining what I think is "wrong" with some tool someone made in their spare time.
I didn't overlook it, I just didn't implement it (a subtly different thing). It's mentioned in the README as a "TODO".
Doing this cross-platform isn't so easy, because once you go beyond the basic traditional Unix permission bits, different systems have all sorts of different stuff. You should see what illumos ls outputs.
Given that all of this is fairly rarely used on the types of machines that "elles" (or "lsd", "eza", etc.) is typically run – desktop machines, rather than servers, and that it's quite some effort to implement it well, it's not a huge priority. But I'll probably get around to it eventually.
I’m afraid that the pipe character as a separator of columns will lead to inevitable errors in scripts or copy/paste with more parts of the output having a chance of being executed than with regular ls.
This is why I encourage not overriding common commands in $PATH. Setup an alias instead so it only applies to interactive shells (or just type the new command :p).
Shell scripting is already fickle enough with compatibility issues across the major implemtations of POSIX utils (GNU, macOS/ BSD, Busybox). Even /bin/sh itself cannot be relied upon to behave consistently across platforms. Notably, Busybox's ash supports the non-POSIX substring syntax that Bash does. This won't work on distro's like Debian where /bin/sh is linked to dash shell.
I can tell you why I use -L in normal "ls" - to see destination sizes.
I often use symlinks to deduplicate files but still have them in relevant places. For example, I may want to keep the original filename but also have it available via a "friendlier" name too, or I may want to categorise files without loving them, etc.
In a similar vein, I also make "source trees" of ISO images that I want to build (using mkisofs) for use in emulators and such using symlinks, because I don't want to take up too much space but they're easy to handle.
In both cases, being able to occasionally see sizes of the destination files (instead of the symlink itself) can be very useful, particularly if I'm sorting by size (-S -r) or want to make a quick estimation on whether two files are the same file or not (although in that case having the size display in bytes is also useful to me. GNU is has the -h flag to show human-readable sizes, though).
Anyway, thought you might be interested in this viewpoint! This looks very nifty.