[HN Gopher] Show HN: Elles - A nicer /bin/ls
       ___________________________________________________________________
        
       Show HN: Elles - A nicer /bin/ls
        
       Author : arp242
       Score  : 47 points
       Date   : 2024-06-13 22:58 UTC (2 days ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | fp64 wrote:
       | >It differs from eza or lsd in that it has a slightly different
       | feature set, and makes some different choices about various
       | aspects.
       | 
       | Can you elaborate? Eza supports icons and I guess I prefer its
       | color scheme, but difficult to judge without installing Elles
        
         | arp242 wrote:
         | 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.
        
       | thebeardisred wrote:
       | An interesting idea, but like `lsd` it also overlooked
       | introspecton of extended file attributes
       | (https://en.wikipedia.org/wiki/Extended_file_attributes).
       | 
       | Appropriate timing given the 2024 POSIX release. It's a good
       | reminder that writing portable software isn't easy.
        
         | arp242 wrote:
         | 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.
        
       | kleiba wrote:
       | Would that potentially break shell scripts that rely on the
       | standard ls behavior?
        
         | meribold wrote:
         | If you use `alias ls=elles`, scripts should be unaffected as
         | aliases are ignored in non-interactive shells.
        
         | g0xA52A2A wrote:
         | Don't parse the output of ls, use globbing or find. Here are
         | some examples https://mywiki.wooledge.org/ParsingLs
        
           | kleiba wrote:
           | The problem is existing shell scripts not written by
           | yourself.
        
       | pama wrote:
       | 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.
        
         | arp242 wrote:
         | It's a box drawing character (U+2502) rather than a pipe. Pipes
         | are typically drawn with fairly large gaps.
        
       | erichdongubler wrote:
       | This reminds me of Nushell's structured output for its `ls`
       | command. Nice!
        
       | salil999 wrote:
       | I would also take a look at exa: https://the.exa.website/
       | 
       | It's been my ls replacement for a while now and it's very
       | customizable!
        
         | horse666 wrote:
         | Exa is unmaintained, but there's a maintained fork called eza -
         | https://github.com/eza-community/eza
        
       | precompute wrote:
       | Exa is what I use now, but the column separation in Elles is
       | pretty cool!
        
         | johnny22 wrote:
         | as someone else said you should be using eza since exa is
         | unmaintained
        
       | layer8 wrote:
       | 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.
        
         | mtmail wrote:
         | > And sometimes there can be file times in the future
         | 
         | Like emails with a future date I hope that's rare and caused by
         | mistakes.
        
         | arp242 wrote:
         | 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.
        
       | Sophira wrote:
       | > -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.
        
         | arp242 wrote:
         | 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).
         | 
         | I'll probably put the standard -L behaviour back.
        
       ___________________________________________________________________
       (page generated 2024-06-15 23:02 UTC)