eza-community / eza Goto Github PK
View Code? Open in Web Editor NEWA modern alternative to ls
Home Page: https://eza.rocks
License: MIT License
A modern alternative to ls
Home Page: https://eza.rocks
License: MIT License
After following the instructions for debian/ubuntu:
N: Skipping acquire of configured file 'main/binary-armhf/Packages' as repository 'http://deb.gierens.de stable InRelease' doesn't support architecture 'armhf'
and
N: Skipping acquire of configured file 'main/binary-arm64/Packages' as repository 'http://deb.gierens.de stable InRelease' doesn't support architecture 'arm64'
similar to the exa-linux-x86_64-musl-v0.10.1.zip packages packaged as part of exa releases. These are very useful for those of us packaging things in a corporate environment without access to external package repos.
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.
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.
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.
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.
I may take a look into this at the weekend if I get the chance & no one has any complaints with this change.
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 :)
> 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
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.
The SHA-256 hash of the file is 480bceb36fe41c436d4ae3816333e0dcb2c9afbc5da56a8fb78315faaf5dc24f
. VirusTotal analysis can be found here.
see context in #213
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).
This is a fairly severe regression as the the default expected behavior of
exa
/zetta
is to run--grid
if nothing else is specified.
When checking my PR #167 doesn't break the Windows build I discovered that the Windows build has been broken for a while. Bisected to:
C:\Users\daviess\eza>git bisect bad
afeac47 is the first bad commit
commit afeac47
Author: Christian Göttsche [email protected]
Date: Sun Apr 25 15:00:58 2021 +0200
Which is #61.
Context: #170
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)
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.
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.
Currently there is no binary for mac: https://github.com/eza-community/eza/releases/tag/v0.11.0
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)
Completions for bash are still missing. I haven't made them because I'm not very adept at bash completions.
See: #77
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
Hi,
could you perhaps publish .deb packages for Debian based distros, so eza could be easily installed on Debian or potentially included in Debian repo or added to deb-get:
https://github.com/wimpysworld/deb-get
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")
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.
eza
just showed up in my new-formulae list, and brew install eza
does what you'd expect.
Code extracted from devtools/dev-create-test-filesystem.sh
and slightly edited:
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'']'
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.
Generate a Gentoo ebuild upon release, and perhaps automatically submit it to the Guru overlay.
Can someone assign this to me?
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.
Introduced in PR #32 in the merge hell.
This should not be hard to fix, I'll try to find time to take a look at it.
eza uses Black.bold()
to display punctuations, making them unreadable in some cases:
eza/src/theme/default_theme.rs
Line 80 in 724b6dd
Tested on alacritty with default config:
Tested on kitty with default config:
Tested on xterm with default config:
Relevant information:
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!
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:
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.
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)
Currently there are 3 PRs trying to implement an -A
flag. I'm unsure which one is preferred to focus on.
https://github.com/cafkafk/eza/pulls?q=is%3Apr+is%3Aopen+label%3A%22-A+flag%22
@sbatial how do you feel about this?
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?
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.
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.
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.
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)
trycmd seems like it will be the option we go for.
Todo:
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.
Review the icon changes.
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'?
I'm pretty sure we should move to https://github.com/uutils/uutils-term-grid (see ogham/rust-term-grid#15).
See: #66 for more context.
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 🙂
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:
eza --version
)
eza -T
bug: -T --tree
line-drawing characters color hard to see in dark background console.
Brotli archives are using .br extension
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:
✓ If GIT_DIR
is set, and the path is inside that Git repo, great!
❌ 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).
✓ 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.)
❌ 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:
✓ if eza
was executed inside a Git repo, and the path is inside the same repo, great (by coincidence)!
❌ if eza
was executed inside a Git repo, and the path is outside that repo, Eza lies (same as case 2).
✓ 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)?
eza --version
exa - list files on the command-line
v0.10.2 [+git]
https://the.exa.website/
I'll fix this tomorrow.
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.