Comparison
pls
has the distinction of being an ls(1)
replacement specifically
targeted a pro audience. This leads to different motivations, different
decisions, different choices and different defaults. This also gives us the
advantage of being able to provide features that are powerful but complex.
There are other ls(1)
alternatives that have been around for longer and have
sizeable user bases.
Tool | Language | GitHub stars |
---|---|---|
exa | Rust | |
eza | Rust | |
lsd | Rust | |
colorls | Ruby |
pls
strives to provide all the features expected from these tools, and more.
For an idea, here is a comparison between pls
and the most popular
alternatives, eza and its predecessor
exa.
Pros
-
eza hides files with a leading dot by default, an approach it inherits from
ls(1)
.pls
dims or hides files based on their importance, making it suitable for modern dev workflows involving tooling configs. -
eza uses arcane environment variables for customisation.
pls
uses cascading YAML files to enable per-project configuration that's also more readable, maintainable and ergonomic. You can also check these config files into your VCS and share them with your team. -
eza uses globs which limits the match to simple queries.
pls
uses specs which match files using the full power of regex and then provide both styling and icons for their matches. These specs can also be cascaded. -
eza output is very colorful, but limited to customisation using ANSI escape codes.
pls
employs sparse color and formatting, to add meaning or context, and these styles can be customised using English names or even RGB notation. -
pls
has more metadata fields compared to eza. It also allows the user to view some metadata fields in multiple ways (including simultaneously), which eza cannot do. -
eza provides filtering by glob matches and sorting by one field.
pls
provides filtering (by regex or type) and sorting (by multiple selections out of over 18 bases × 2 directions). -
eza can dim a small list of generated files.
pls
has a much more powerful collapse feature that can render generated files differently and can be extended with specs. -
eza defaults to no icons, grid view, files mixed with folders and sorting by name.
pls
defaults to showing icons, list view, folders listed first and leading dots aligned and sorting by canonical name.
Cons
-
eza's interface is much more compatible with
ls(1)
in the base case. A lot ofls(1)
options map 1:1 with eza.pls
does not maintain compatibility withls(1)
CLI flags. -
eza is a mature product with a large contributor base.
pls
is a young project with a novice 🦀 Rustacean maintainer. Contributions, both in code and as sponsorship, are welcome! -
The spec system
pls
uses might be slow when listing lots of files due to its Cartesian product complexity. Also,pls
lacks the speed optimisations that a mature tool like eza has built over time. -
eza can show if a file has extended attributes.
pls
opted not to do this because it's not a common use case. -
eza has a long grid view (which is a combination of
pls
's detail and grid views) that are not yet present inpls
. -
eza has a tree mode that
pls
does not yet have. -
eza supports Windows which
pls
does not yet do.