GithubHelp home page GithubHelp logo

eza-community / eza Goto Github PK

View Code? Open in Web Editor NEW
7.3K 20.0 143.0 7.36 MB

A modern, maintained replacement for ls

Home Page: https://eza.rocks

License: MIT License

Shell 2.62% Rust 93.64% Just 1.44% Nix 1.59% Brainfuck 0.03% Nushell 0.68%
color command-line files icons ls nerd-fonts rust terminal tools hacktoberfest

eza's Introduction

eza

A modern, maintained replacement for ls.

Gitter

Built with Nix Contributor Covenant

Unit tests Crates.io Crates.io

eza demo gif


eza is a modern, maintained replacement for the venerable file-listing command-line program ls that ships with Unix and Linux operating systems, giving it more features and better defaults. It uses colours to distinguish file types and metadata. It knows about symlinks, extended attributes, and Git. And it’s small, fast, and just one single binary.

By deliberately making some decisions differently, eza attempts to be a more featureful, more user-friendly version of ls.


eza features not in exa (non-exhaustive):

  • Fixes “The Grid Bug” introduced in exa 2021.
  • Hyperlink support.
  • Mount point details.
  • Selinux context output.
  • Git repo status output.
  • Human readable relative dates.
  • Several security fixes.
  • Support for bright terminal colours.
  • Many smaller bug fixes/changes!

...and like, so much more that it became exhausting to update this all the time. Like seriously, we have a lot of good stuff.


Nix ❄️

If you already have Nix setup with flake support, you can try out eza with the nix run command:

nix run github:eza-community/eza

Nix will build eza and run it.

If you want to pass arguments this way, use e.g. nix run github:eza-community/eza -- -ol.

Installation

eza is available for Windows, macOS and Linux. Platform and distribution specific installation instructions can be found in INSTALL.md.

Packaging status


Click sections to expand.

Command-line options

Command-line options

eza’s options are almost, but not quite, entirely unlike ls’s.

Display options

  • -1, --oneline: display one entry per line
  • -G, --grid: display entries as a grid (default)
  • -l, --long: display extended details and attributes
  • -R, --recurse: recurse into directories
  • -T, --tree: recurse into directories as a tree
  • -x, --across: sort the grid across, rather than downwards
  • -F, --classify=(when): display type indicator by file names (always, auto, never)
  • --colo[u]r=(when): when to use terminal colours (always, auto, never)
  • --colo[u]r-scale=(field): highlight levels of field distinctly(all, age, size)
  • --color-scale-mode=(mode): use gradient or fixed colors in --color-scale. valid options are fixed or gradient
  • --icons=(when): when to display icons (always, auto, never)
  • --hyperlink: display entries as hyperlinks
  • --absolute=(mode): display entries with their absolute path (on, follow, off)
  • -w, --width=(columns): set screen width in columns

Filtering options

  • -a, --all: show hidden and 'dot' files
  • -d, --list-dirs: list directories like regular files
  • -L, --level=(depth): limit the depth of recursion
  • -r, --reverse: reverse the sort order
  • -s, --sort=(field): which field to sort by
  • --group-directories-first: list directories before other files
  • -D, --only-dirs: list only directories
  • -f, --only-files: list only files
  • --git-ignore: ignore files mentioned in .gitignore
  • -I, --ignore-glob=(globs): glob patterns (pipe-separated) of files to ignore

Pass the --all option twice to also show the . and .. directories.

Long view options

These options are available when running with --long (-l):

  • -b, --binary: list file sizes with binary prefixes
  • -B, --bytes: list file sizes in bytes, without any prefixes
  • -g, --group: list each file’s group
  • -h, --header: add a header row to each column
  • -H, --links: list each file’s number of hard links
  • -i, --inode: list each file’s inode number
  • -m, --modified: use the modified timestamp field
  • -M, --mounts: Show mount details (Linux and MacOS only).
  • -S, --blocksize: show size of allocated file system blocks
  • -t, --time=(field): which timestamp field to use
  • -u, --accessed: use the accessed timestamp field
  • -U, --created: use the created timestamp field
  • -X, --dereference: dereference symlinks for file information
  • -Z, --context: list each file’s security context
  • -@, --extended: list each file’s extended attributes and sizes
  • --changed: use the changed timestamp field
  • --git: list each file’s Git status, if tracked or ignored
  • --git-repos: list each directory’s Git status, if tracked
  • --git-repos-no-status: list whether a directory is a Git repository, but not its status (faster)
  • --no-git: suppress Git status (always overrides --git, --git-repos, --git-repos-no-status)
  • --time-style: how to format timestamps. valid timestamp styles are ‘default’, ‘iso’, ‘long-iso’, ‘full-iso’, ‘relative’, or a custom style ‘+<FORMAT>’ (E.g., ‘+%Y-%m-%d %H:%M’ => ‘2023-09-30 13:00’. For more specifications on the format string, see the eza(1) manual page and chrono documentation.).
  • --total-size: show recursive directory size
  • --no-permissions: suppress the permissions field
  • -o, --octal-permissions: list each file's permission in octal format
  • --no-filesize: suppress the filesize field
  • --no-user: suppress the user field
  • --no-time: suppress the time field
  • --stdin: read file names from stdin

Some of the options accept parameters:

  • Valid --colo[u]r options are always, automatic (or auto for short), and never.
  • Valid sort fields are accessed, changed, created, extension, Extension, inode, modified, name, Name, size, type, and none. Fields starting with a capital letter sort uppercase before lowercase. The modified field has the aliases date, time, and newest, while its reverse has the aliases age and oldest.
  • Valid time fields are modified, changed, accessed, and created.
  • Valid time styles are default, iso, long-iso, full-iso, and relative.

Hacking on eza

If you wanna contribute to eza, firstly, you're expected to follow our code of conduct. After having understood the code of conduct, you can have a look at our CONTRIBUTING.md for more info about actual hacking.

Star History Chart

eza's People

Contributors

9glenda avatar agrzeslak avatar alpn avatar ariasuni avatar asoderman avatar brijeshkrishna avatar cafkafk avatar daviessm avatar dependabot[bot] avatar erwinvaneijk avatar fraggerfox avatar gierens avatar hehelego avatar hulxv avatar ignatenkobrain avatar lilyball avatar maandree avatar martinfillon avatar nwin avatar ogham avatar pthorpe92 avatar sbatial avatar skade avatar skyline75489 avatar spk avatar syphar avatar tertsdiepraam avatar tygrisiq avatar tyrubias avatar xemptuous avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

eza's Issues

[Question]: Parsing for git support

What's the recommended way to test (in a shell) for git support.

> eza --version
eza - A modern, maintained replacement for ls
v0.10.4 [+git]
https://github.com/cafkafk/eza
> eza --version | head -n2 | tail -n1 | grep -qF '[+git]'
> eza --version | grep -qF '[+git]'

Can you be guaranteed the features will always be on the second line?
Will the git feature always be '[+git]' or '[-git]'?
Should I instead search for '+git'?

feat: Provide binaries for mac

Currently there is no binary for mac: https://github.com/eza-community/eza/releases/tag/v0.11.0

image

Would it be possible to create one, e.g. via some github action which is triggered by a release? E.g. using the one from rye: https://github.com/mitsuhiko/rye/blob/main/.github/workflows/release.yml (which creates a draft release upon a new tag and uploads all relevant binaries and fills in the changelog into the release description and publishes the release; draft -> changelog -> publish., so the release email contains the changelog)

feat: ebuild for Gentoo

Generate a Gentoo ebuild upon release, and perhaps automatically submit it to the Guru overlay.

Can someone assign this to me?

Finding Git directory was broken by adding GIT_DIR support in the general case

A problem introduced by how GIT_DIR support was added: makes Eza find the wrong Git directory in some cases.

For any given path argument given to Eza:

  1. ✓ If GIT_DIR is set, and the path is inside that Git repo, great!

  2. ❌ If GIT_DIR is set, but the path is outside that Git repo, Eza lies: it prints the git status column but every line shows -- as if there are no changes (the status check is done against the wrong repo; Eza never tried finding the Git repo for that path, since it found the one at GIT_DIR and was satisfied).

    1. ❌ If the path is in a different Git repo, the ideal behavior would be to show the correct Git status.
    2. ❌ If the path is not in any Git repo, the ideal behaviour would be to not even show the Git column.
  3. ✓ If GIT_DIR is set to something that's not a gitdir, great! (git2::Repository::open_from_env returns a not-found error, so Eza falls through to trying to normal git repository lookup on the path.)

    1. ✓ If the path is in a Git repo, the normal lookup finds it and shows the correct Git status.
    2. ✓ If the path is not in a Git repo, the Git column is correctly omitted.
  4. ❌ If GIT_DIR is not set, git2::Repository::open_from_env will try searching from the current directory (instead of searching from the given path), so:

    1. ✓ if eza was executed inside a Git repo, and the path is inside the same repo, great (by coincidence)!

    2. ❌ if eza was executed inside a Git repo, and the path is outside that repo, Eza lies (same as case 2).

    3. ✓ if eza was executed outside of a Git repo, great!

In particular, note that last ❌ case is a regression: even if a user doesn't use GIT_DIR, if they just happen to be inside a Git repo when they run Eza, the output will now show wrong status information for paths outside that repo (potentially importantly wrong! eza -l --git ../foo is something a user might run before deciding to rm -r ../foo based on the status infomation!) I'm surprised there wasn't a test to catch this in the automated tests (or maybe there is, but it's in the Vagrant tests which no one seems to be able to run)?

feat: Add eza support in home-manager

This is really a change in home-manager, but the exa config in home-manager needs to be copied to eza instead for some of the nix uptake to transfer.

tracking issue: permissions

On organization roles

I created a request to join maintainers so I can move it there.

I looked into permissions for doing this, and I can only give "repository roles" via teams on a repository level, not organizationally.

There are only two types of organizational roles:
2023-08-21_15-16

There is a feature to add more, but it's paid :(

The best I can do in the free tier seems to be enabling all organization members to create public repositories, which I have just done.

On team roles

I'm gonna think about the best way to structure repository permissions and then redo these very soon!

I think it makes sense to give out more permissions to you and @PThorpe92, so you can triage and do stuff like assign labels, or assigning yourself to issues etc, which I just realized today you couldn't!

Tell me if there is something you can't do that you should be able to do.

Originally posted by @cafkafk in #150 (comment)

All the exa issues

feat: `exa -l` doesn't show group info (from `exa`)

From exa Issue: ogham/exa#1118

tl;dr
The ls -l command includes the name of the group that the "group permissions" apply to. This is pretty commonly used info, but requires adding the --group flag to get it now. Please add it back to the default, or make it a customizable default for when -l is used.

bug: Windows defender flags `eza` as a trojan (false positive)

I downloaded the latest version of eza (0.11.0) from github releases, and Windows defender flagged it as malicious as soon as the download finished. The message from Defender is shown below.

image

The SHA-256 hash of the file is 480bceb36fe41c436d4ae3816333e0dcb2c9afbc5da56a8fb78315faaf5dc24f. VirusTotal analysis can be found here.

feat: Support timezone for Windows

First, Thank you for your great work :)

It would be nice to be able to display the time taking the timezone into account, such as ls and dir.

image

feat: Dynamically link libgit2.so

hi!

The Cargo.toml currently enables the vendored-libgit2 feature unconditionally, I think this should default to off with an option to enable it (similar to the vendored-openssl feature that can optionally be enabled).

Thanks!

feat: option to hide empty detail columns

I'd love an option to hide a column completely if there's no useful information in that column. This would be particularly useful for --git output, e.g.:

$ eza --header --binary -l --git
Permissions  Size User   Date Modified Git Name
.rw-r--r--@ 1.3Ki qyriad 17 Jan 16:26   -- board.c
.rw-r--r--@   750 qyriad 17 Jan 16:26   -- mpconfigboard.h
.rw-r--r--@   331 qyriad  9 Aug 20:17   -- mpconfigboard.mk
.rw-r--r--@ 2.8Ki qyriad 17 Jan 16:26   -- pins.c

In the above results the the "Git" column is completely empty (since none of those files have any relevant git status). It'd be awesome to, for example, put --git in my eza alias without getting an extra column when it doesn't have any information to add.

If this is a reasonable feature request, I'm willing to PR if anyone has any pointers on where to start in the codebase 🙂

feat: add completion files to deb package

Hello,

It seems that deb packages don't contain any completion file. I have looked at all the packages that were downloadable on the repo, it doesn't seem like a recent issue, they have never been there.

I'm not a Rust dev at all, so I don't know how it should work, but the configuration section in the Cargo.toml file seems right to me. Or at least it's exactly how it was in exa. So maybe things changed in the packaging tool?

bug: Not visible lines on kitty terminal sometimes.

On kitty terminal if background and color0 are the same, then the lines in size column or in permission colours are not visible, is it possible to have option to change them or set. On exa it worked fine

Ubuntu 20.04, kitty 0.28.1 created by Kovid Goyal, eza from nix-env

eza - A modern, maintained replacement for ls
v0.10.8 [+git]
https://github.com/eza-community/eza


 ➜ eza --long
.rw-rw-r--  10k dkorbuszewski 18 Jul 15:34 conf22.txt
drwxr-xr-x    - dkorbuszewski 11 Aug 12:04 Desktop
drwxr-xr-x    - dkorbuszewski 28 Aug 10:57 Documents
drwxr-xr-x    - dkorbuszewski 24 Aug 13:06 Downloads
drwxrwxr-x    - dkorbuszewski 28 Aug 11:58 gits
drwxrwxr-x    - dkorbuszewski 17 Aug 08:59 go
drwxrwxrwx    - root          28 Aug 12:28 labnet
.rw-rw-r--  38k dkorbuszewski 24 Aug 15:51 log-error.log
.rw-rw-r-- 207k dkorbuszewski 24 Aug 16:20 log.txt
drwxrwxr-x    - dkorbuszewski 31 Jul 16:44 logs
.rw-rw-r-- 2.0k dkorbuszewski 28 Aug 12:51 minicom.log
drwxr-xr-x    - dkorbuszewski  8 May 10:06 Music
drwxr-xr-x    - dkorbuszewski 23 Jun 13:58 Pictures
drwxr-xr-x    - dkorbuszewski  8 May 10:06 Public
drwxr-xr-x    - dkorbuszewski  2 Aug 15:56 Templates
drwxrwxr-x    - dkorbuszewski 18 May 11:54 ti
drwxrwxr-x    - dkorbuszewski 17 Jul 09:06 tmp
drwxr-xr-x    - dkorbuszewski  2 Aug 15:56 Videos

image

feat: Custom colors for file categories

Request the ability to change colors for file categories — e.g. immediate, document, image, etc. If this feature already exists I have not been able to find it in the documentation.

Currently if you want, for instance, to change the immediate file color, you would have to separately specify it for 41 different filenames — and you would have to make changes every time a new immediate file is added.

For those of us who prefer light background, yellow is a terrible, unreadable color, and changing it individually for every immediate file is a pain.

Windows Support

Right now, Eza does not support windows.

It's not really something I care to implement, specially because I don't own a windows box.

But if anyone is up for it, you could start by making a PR with the changes to CI from here.

See: #19

tracking: testing

Status

Current testing is based on https://github.com/ogham/exa, which eza forks.

Here, vagrant, as well as https://github.com/ogham/specsheet is a huge pain.

  • It's currently not working
  • No active contributor knows (or wants to know) how it works
  • Vagrant is NOT open source

Fixing something we don't like, instead of just finding a more permanent solution would be short sighted. So instead, I'm looking into various options.

Notice that generating releases will be done through nix at some point (via cross), as it allows for docker-tier build isolation, and could easily later be done on a build server, which would be very nice. We use cross now.

See: #137 (comment)


Progress

trycmd seems like it will be the option we go for.

Todo:

  • #261
  • #273
  • #274
  • #275
  • #276
  • some logic for platform dependent testing (this was already done in #261)
  • #323
  • #347
  • #288
  • #279
  • #280
  • documentation of how to use this (not assigned, shouldn't be done before we have more experience)

And also just writing a lot of tests when this gets merged.


If there is anything else we should do, comment and I'll add it.

feat: Windows Hidden Files Support

So I installed eza on my work laptop (which unfortunately has Windows 11 installed) because I wanted a more Linux-ey way to search for files in PowerShell.

Something that would make eza an even better alternative to PowerShell's Get-ChildItem would be to hide Windows hidden files when -a isn't specified. The current behaviour only hides dot files.

I don't think this would be too hard to implement as the hidden flag is included when running eza -l so the information is there.
image

I may take a look into this at the weekend if I get the chance & no one has any complaints with this change.

Indicate folder state with icon

The default folder icon is a closed one.
It would be nice to have an indication for folders that are recursed into/contain files.

See discussion on #46 for further information.

bug: eza doesn’t show characters in filename after last escaped character

Code extracted from devtools/dev-create-test-filesystem.sh and slightly edited:

create files
export TEST_ROOT=test_root
mkdir -p "$TEST_ROOT/file-names"
echo -e "\033[1m[ 3/13]\033[0m Creating file names testcases"

echo -ne "$TEST_ROOT/file-names/ascii: hello" | xargs -0 touch
echo -ne "$TEST_ROOT/file-names/emoji: [🆒]"  | xargs -0 touch
echo -ne "$TEST_ROOT/file-names/utf-8: pâté"  | xargs -0 touch

echo -ne "$TEST_ROOT/file-names/bell: [\a]"         | xargs -0 touch
echo -ne "$TEST_ROOT/file-names/backspace: [\b]"    | xargs -0 touch
echo -ne "$TEST_ROOT/file-names/form-feed: [\f]"    | xargs -0 touch
echo -ne "$TEST_ROOT/file-names/new-line: [\n]"     | xargs -0 touch
echo -ne "$TEST_ROOT/file-names/return: [\r]"       | xargs -0 touch
echo -ne "$TEST_ROOT/file-names/tab: [\t]"          | xargs -0 touch
echo -ne "$TEST_ROOT/file-names/vertical-tab: [\v]" | xargs -0 touch

echo -ne "$TEST_ROOT/file-names/escape: [\033]"              | xargs -0 touch
echo -ne "$TEST_ROOT/file-names/ansi: [\033[34mblue\033[0m]" | xargs -0 touch

echo -ne "$TEST_ROOT/file-names/invalid-utf8-1: [\xFF]"             | xargs -0 touch
echo -ne "$TEST_ROOT/file-names/invalid-utf8-2: [\xc3\x28]"         | xargs -0 touch
echo -ne "$TEST_ROOT/file-names/invalid-utf8-3: [\xe2\x82\x28]"     | xargs -0 touch
echo -ne "$TEST_ROOT/file-names/invalid-utf8-4: [\xf0\x28\x8c\x28]" | xargs -0 touch

echo -ne "$TEST_ROOT/file-names/new-line-dir: [\n]"               | xargs -0 mkdir
echo -ne "$TEST_ROOT/file-names/new-line-dir: [\n]/subfile"       | xargs -0 touch
echo -ne "$TEST_ROOT/file-names/new-line-dir: [\n]/another: [\n]" | xargs -0 touch
echo -ne "$TEST_ROOT/file-names/new-line-dir: [\n]/broken"        | xargs -0 touch
$ eza -1 test_root/file-names/
ansi: [\u{1b}[34mblue\u{1b}
ascii: hello
backspace: [\u{8}
bell: [\u{7}
emoji: [🆒]
escape: [\u{1b}
form-feed: [\u{c}
invalid-utf8-1: [�]
invalid-utf8-2: [�(]
invalid-utf8-3: [�(]
invalid-utf8-4: [�(�(]
new-line-dir: [\n
new-line: [\n
return: [\r
tab: [\t
utf-8: pâté
vertical-tab: [\u{b}

$ exa -1 test_root/file-names/
ansi: [\u{1b}[34mblue\u{1b}[0m]
ascii: hello
backspace: [\u{8}]
bell: [\u{7}]
emoji: [🆒]
escape: [\u{1b}]
form-feed: [\u{c}]
invalid-utf8-1: [�]
invalid-utf8-2: [�(]
invalid-utf8-3: [�(]
invalid-utf8-4: [�(�(]
new-line-dir: [\n]
new-line: [\n]
return: [\r]
tab: [\t]
utf-8: pâté
vertical-tab: [\u{b}]

$ ls -1 test_root/file-names/
'ansi: ['$'\033''[34mblue'$'\033''[0m]'
'ascii: hello'
'backspace: ['$'\b'']'
'bell: ['$'\a'']'
'emoji: [🆒]'
'escape: ['$'\033'']'
'form-feed: ['$'\f'']'
'invalid-utf8-1: ['$'\377'']'
'invalid-utf8-2: ['$'\303''(]'
'invalid-utf8-3: ['$'\342\202''(]'
'invalid-utf8-4: ['$'\360''('$'\214''(]'
'new-line: ['$'\n'']'
'new-line-dir: ['$'\n'']'/
'return: ['$'\r'']'
'tab: ['$'\t'']'
'utf-8: pâté'
'vertical-tab: ['$'\v'']'

bug: `-T --tree` line-drawing characters color hard to see

If eza does something unexpected, or its output looks wrong, or it displays an error on the screen, or if it outright crashes, then please include the following information in your report:

  • The version of eza being used (eza --version)
    • v0.11.0
  • The command-line arguments you are using
    • eza -T
  • Your operating system and hardware platform
    • Arch Linux

bug: -T --tree line-drawing characters color hard to see in dark background console.

Screenshot from 2023-09-08 02-27-06

Grid view is broken

Running --grid with the latest git version of zetta is broken on my machine.

E.g. by doing cargo run --release -- --grid, or using an installed version (see screenshot below).

2023-07-28_13-43

This is a fairly severe regression as the the default expected behavior of exa/zetta is to run --grid if nothing else is specified.

ogham/exa#1165 (comment)

syphar/zetta#4

feat: Support configuration file

In checking out LSD earlier today before I eventually found my way here.
one of the first things that sticks out is their support for a config file (I believe they use yaml)

I think it's a decent longer term goal, as it allows for sharing of "themes" between users and doesn't require ENV VAR="ga;23", etc etc

If that is something the project is interested in, the first thing would probably be to decide on what format and therefore what crates to use.

MacOS flake support

On latest main:

error: linking with `cc` failed: exit status: 1
  |
  = note: LC_ALL="C" PATH="<removed for privacy>" "-Wl,-dead_strip" "-nodefaultlibs"
  = note: ld: framework not found Security
          clang-11: error: linker command failed with exit code 1 (use -v to see invocation)
          

error: could not compile `eza` (bin "eza") due to previous error

Someone on an apple computer would need to bisect this.

`-t` option is tricky

So I don't think there is a way to make -t the same as in ls.
I don't say it is impossible.
But the best implementation I have right now does work but nevertheless eats the next argument, even if it starts with a -.

The core problem(s) seem(s) to be: -t is not really a shorthand in ls but a dedicated option which is equivalent to --time=modified. And our parser can currently not represent shortform-only options.

I'll have to think about what the best way forward is in my eyes but my gut is that the best way of getting such a feature to work is to make changes to the parser first to have it support short options without a long form.

bug: can't see the dashes in permission

I'm using eza v0.11.0 in Arch Linux.

When I run "eza -l", the dashes in the permission column are invisible, as shown in the figure below:
image

I can see the dashes when color is disabled.

As a comparison, exa doesn't have this issue, as shown in the figure below:
image

bug: Obscure width bug

I'm adding this just so I don't forget about it.

Seems to occur around COL 399
2023-08-13_06-37

Seems not to occur before COL 398
2023-08-13_06-37_1

I don't have time to look more into this right now, and this probably will not matter in this decade, but it's still a bug.

--version has outdated info

eza --version
exa - list files on the command-line
v0.10.2 [+git]
https://the.exa.website/

I'll fix this tomorrow.

Bug: output wraps in terminal (with --icons)

Here's a reproduction:
Note that the line splitting is put in place by me. It is technically outputting a single line, but because it reaches the end, it wraps. When copying the output, I had to manually insert newlines to mimic the output seen on my terminal.

> echo $COLUMNS
168
> mkdir /tmp/test
> for i in {1..11}; do touch /tmp/test/file-number-$i; done
> cargo run --release /tmp/test/
file-number-1  file-number-2  file-number-3  file-number-4  file-number-5  file-number-6  file-number-7  file-number-8  file-number-9  file-number-10  file-number-11
> cargo run --release /tmp/test/ --icons
 file-number-1   file-number-2   file-number-3   file-number-4   file-number-5   file-number-6   file-number-7   file-number-8   file-number-9   file-number-1
0   file-number-11
> touch /tmp/test/file-number-12
> cargo run --release /tmp/test/
file-number-1  file-number-3  file-number-5  file-number-7  file-number-9   file-number-11
file-number-2  file-number-4  file-number-6  file-number-8  file-number-10  file-number-12
> cargo run --release /tmp/test/  --icons
 file-number-1   file-number-3   file-number-5   file-number-7   file-number-9    file-number-11
 file-number-2   file-number-4   file-number-6   file-number-8   file-number-10   file-number-12
> rm /tmp/test/file-number-* && rmdir /tmp/test # Don't forget to clean up :)
Versioning Git commit: 5f29705
> cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.2 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.2 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy
> rustc --version
rustc 1.73.0-nightly (db7ff98a7 2023-07-31)

Does this have something to do with #66 / #83?

Note: the same procedure with exa v0.10.1 [-git]:

> echo $COLUMNS
168
> mkdir /tmp/test
> for i in {1..11}; do touch /tmp/test/file-number-$i; done
> exa /tmp/test/
file-number-1  file-number-2  file-number-3  file-number-4  file-number-5  file-number-6  file-number-7  file-number-8  file-number-9  file-number-10  file-number-11
> exa /tmp/test/ --icons
 file-number-1   file-number-3   file-number-5   file-number-7   file-number-9    file-number-11
 file-number-2   file-number-4   file-number-6   file-number-8   file-number-10  
> touch /tmp/test/file-number-12
> exa /tmp/test/
file-number-1  file-number-3  file-number-5  file-number-7  file-number-9   file-number-11
file-number-2  file-number-4  file-number-6  file-number-8  file-number-10  file-number-12
> exa /tmp/test/  --icons
 file-number-1   file-number-3   file-number-5   file-number-7   file-number-9    file-number-11
 file-number-2   file-number-4   file-number-6   file-number-8   file-number-10   file-number-12
> rm /tmp/test/* && rmdir /tmp/test

Conventional Commits Version Standard

          Conventional Commits also really ought to provide a standard way of declaring+detecting what version of the spec is being followed in a repo for any given commit. After thinking through a few designs, here's the standard I would propose (posting it here for initial feedback, but I'll probably post it as a proposal in the Conventional Commits repo soon):

The project adds a COMMITS.md file in the root of the repo, which must start with exactly the line https://www.conventionalcommits.org/{{language}}/{{version}}, where {{language}} is the language identifier (ignored by tooling - a tolerance to let projects use the link to their native language), and {{version}} is for example v1.0.0 (optionally with a trailing /). Nothing else on that first line.

(In a precise spec I'd probably mandate that this string must be in UTF-8/ASCII, to reduce the odds that one popular implementation goes looser and all tools end up having to know how to detect or interpret other byte patterns.)

(For a proper spec, note that language identifiers are not always just two characters like en, but sometimes it's strings like pt-br, and a spec should either pin down precisely what it could be, or go explicitly loose and permit one URL path part, no matter what it is.)

Advantages/rationale:

Both tools and humans can know if Conventional Commit semantics apply to a commit, and which exact version. We can even know this with per-commit granularity by checking just the start of that file's contents for a given commit (for those who don't know, something like git show can do that without having to check out the whole commit) - and we get this per-commit granularity without having to specify the spec version in every commit. With that solved, the spec is much more free to evolve semantics without breaking interpretation by tooling.

By keeping it super simple (the version string and the URL string are one, it's the very first thing in the file by itself on the first line, there is no markdown syntax to parse, etc), we make it extremely simple+easy for tools to know what version of the spec is being used, humans can still see and understand a URL (and the markdown extension helps editors/viewers automatically style it as a link, make it clickable, etc), and there's a clear single source of truth.

By making the spec explicitly about the first line (so tools just look at the first line and ignore/tolerate the rest), it allows forward-compatibility with future spec changes or other unforeseen uses adding other information.

Discoverability is really high because it looks like one of the conventional about-this-repo files (all-uppercase, like README, CONTRIBUTING, etc), it points you right to the full documentation of that commit convention. It would also sort in basically the same place as a CONTRIBUTING file in an alphabetic listing - if I was looking for a "contributing" file and saw a "committing" file (as a dev who already knows what a "commit" is) I'd almost certainly think to look in it.

Originally posted by @mentalisttraceur in #149 (comment)

About ENV_VARS

Currently, the environment variables retain their old name, EXA_.

If no one sees an issue with this, I'll change it to EZA_ in the foreseable future. Zetta wil probably remain backwards compatible.

feat: Order of the columns

#1237 from exa

A resource to define the order of the columns. If I want for example:

User, Group, Octal, Permission, Date Modified, Size, Icon, Name

would be beyond the perfection, it is a lot better than lsd and other already

I am re-posting this here because I think that is a good feature request.

I am going to check it out and see what it would take to implement, but I have a feeling it will be much more complicated than it sounds.

issue: ansi_term no longer maintained

Obligatory issue, to move Eza away from the unmaintained ansi_term crate.

#165 removes it in favor of nu_ansi_term but if anyone had suggestions, or if we wanted to maintain our own fork. Possibly under Eza-community or Rustadopt.. this would be the place to suggest/discuss.

Let it snow? :snowflake: (Add first-party flake)

How are we feeling about adding a flake.nix and maybe try to move the dev and test-environment from Vagrant to nix as well?! (It seems like Vagrant and nix do not oppose each other... So we might just keep Vagrant but treat nix as the primary "environment control")

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.