3 ms·

Show HN: Elles – A nicer /bin/ls

57 points by arp242 2y ago

fp64 2y ago
>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 2y ago
  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 2y ago
An interesting idea, but like `lsd` it also overlooked introspecton of extended file attributes (https://en.wikipedia.org/wiki/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 2y ago
  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 2y ago
Would that potentially break shell scripts that rely on the standard ls behavior?
- meribold 2y ago
  If you use `alias ls=elles`, scripts should be unaffected as aliases are ignored in non-interactive shells.
- g0xA52A2A 2y ago
  Don't parse the output of ls, use globbing or find. Here are some examples https://mywiki.wooledge.org/ParsingLs https://mywiki.wooledge.org/ParsingLs
  - kleiba 2y ago
    The problem is existing shell scripts not written by yourself.
    - nvllsvm 2y ago
      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.
pama 2y ago
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 2y ago
  It's a box drawing character (U+2502) rather than a pipe. Pipes are typically drawn with fairly large gaps.
erichdongubler 2y ago
This reminds me of Nushell's structured output for its `ls` command. Nice!
salil999 2y ago
I would also take a look at exa: https://the.exa.website/ https://the.exa.website/ It's been my ls replacement for a while now and it's very customizable!
- horse666 2y ago
  Exa is unmaintained, but there’s a maintained fork called eza - https://github.com/eza-community/eza https://github.com/eza-community/eza
- deleted 2y ago
  [deleted]
precompute 2y ago
Exa is what I use now, but the column separation in Elles is pretty cool!
- johnny22 2y ago
  as someone else said you should be using eza since exa is unmaintained
layer8 2y ago
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 2y ago
  > 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 2y ago
  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 2y ago
> -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 2y ago
  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.
meribold 2y ago
This looks nice. I added a package to the AUR: https://aur.archlinux.org/packages/elles-bin https://aur.archlinux.org/packages/elles-bin.
- meribold 2y ago
  And here's one that builds the latest code from the Git repo: https://aur.archlinux.org/packages/elles-git https://aur.archlinux.org/packages/elles-git.

57 points by arp242 2y ago

fp64 2y ago

>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 2y ago
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 2y ago

An interesting idea, but like `lsd` it also overlooked introspecton of extended file attributes (https://en.wikipedia.org/wiki/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 2y ago
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 2y ago

Would that potentially break shell scripts that rely on the standard ls behavior?

meribold 2y ago
If you use `alias ls=elles`, scripts should be unaffected as aliases are ignored in non-interactive shells.
g0xA52A2A 2y ago
Don't parse the output of ls, use globbing or find. Here are some examples https://mywiki.wooledge.org/ParsingLs https://mywiki.wooledge.org/ParsingLs
- kleiba 2y ago
  The problem is existing shell scripts not written by yourself.
  - nvllsvm 2y ago
    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.

pama 2y ago

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 2y ago
It's a box drawing character (U+2502) rather than a pipe. Pipes are typically drawn with fairly large gaps.

erichdongubler 2y ago

This reminds me of Nushell's structured output for its `ls` command. Nice!

salil999 2y ago

I would also take a look at exa: https://the.exa.website/ https://the.exa.website/ It's been my ls replacement for a while now and it's very customizable!

horse666 2y ago
Exa is unmaintained, but there’s a maintained fork called eza - https://github.com/eza-community/eza https://github.com/eza-community/eza
deleted 2y ago
[deleted]

precompute 2y ago

Exa is what I use now, but the column separation in Elles is pretty cool!

johnny22 2y ago
as someone else said you should be using eza since exa is unmaintained

layer8 2y ago

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 2y ago
> 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 2y ago
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 2y ago

> -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 2y ago
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.

meribold 2y ago

This looks nice. I added a package to the AUR: https://aur.archlinux.org/packages/elles-bin https://aur.archlinux.org/packages/elles-bin.

meribold 2y ago
And here's one that builds the latest code from the Git repo: https://aur.archlinux.org/packages/elles-git https://aur.archlinux.org/packages/elles-git.