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	many
eza	Rust	many
lsd	Rust	many
colorls	Ruby	many

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 supports theming using a global YAML file like pls . But pls goes further with 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's output is very colorful by default whereas pls employs sparse color and formatting, to add meaning or context. pls markup syntax is more compact than eza's separate fields for colors and styles.

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

• pls can render high-quality SVG icons from icon packs like Catppuccin for files and directories. eza cannot do this.

• pls creates a grid of uniform width for each cell, which looks more spaced out, whereas eza's grid view is more compact by compressing each column into as small a width as necessary.

Cons

• eza's interface is much more compatible with ls(1) in the base case. A lot of ls(1) options map 1:1 with eza. pls does not maintain compatibility with ls(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 in pls .

• eza has a tree mode that pls does not yet have.

• eza supports Windows which pls does not yet do.