eza
eza copied to clipboard
feat: nushell table output mode
This is basically just a re-creation of the following issue from the original repo but in this fork :)
Original issue by @galop1n
Nushell is a modern take on shell. Nushell's table approach to every thing is neat, and their core ls take on the matter is already an improvement or the old way.
eza remains a more advanced ls replacement, and it would be terrific to have a nushell compatible output, for example with eza --nu that can be pipe the way nushell intends.
I saw a request for structured eza output that kind of overlap with that request, but felt dissociate enough to open the new issue.
@eggbean had suggested that adding a --json
option would be good, like the tree replacement tre has.
I'd really want this myself, but I'm not gonna be the one to implement it (at least not right now). If anyone would want to do this, they should feel free to work on it thou, and I'll happily help review it.
see #783
@heuristicAL feel free to compile from source and do some feedback on the json options
@MartinFillon Tested it locally, awesome start, thank you!
It outputs to valid json and I'm able to parse it into nushell for display purposes. (See screenshot)
I do have a small suggestion for making it more ergonomic, though. I have no idea how doable this suggestion is as I don't know the internal workings of eza at all but I thought I'd bring it up:
Right now, the output for each entry is just an array, is it possible to make each json element a json object? It would make it easier to extract the field name to use as a header name, plus, reduces possible issues of array indexes changing depending on what flags are used with exa or across updates.
is it possible to make each json element a json object?
It is. Its just, and will always with me, be a question of time. But I think it will be easy to apply.
Yeah I imagine the preferred output would be keyed fields?
[
{
"permissions": "rw-rw-r-w-r",
"user": "some_user",
"git": "N",
"size": "2.1K",
"filename": "docker-compose.yml"
}
]
This is an interesting idea, I'll collaborate on the PR this weekend :+1:
This is an interesting idea, I'll collaborate on the PR this weekend 👍
might already be done by this weekend, as I will wrk on it after school
Done if you wanna try it.
@MartinFillon Not sure if I'm doing something wrong here but when I run it, I don't get any keys for each line of the json object. My current output is the following (invalid json):
{
"files":[
{
"drwxr-xr-x@",
"-",
"agiard",
"17 Jan 08:15",
"benches"},
{
".rw-r--r--@",
"3.9k",
"agiard",
"17 Jan 08:15",
"build.rs"},
{
".rw-r--r--@",
"43k",
"agiard",
"17 Jan 08:15",
"Cargo.lock"},
{
".rw-r--r--@",
"3.2k",
"agiard",
"17 Jan 08:15",
"Cargo.toml"},
{
".rw-r--r--@",
"31k",
"agiard",
"17 Jan 08:15",
"CHANGELOG.md"},
{
".rw-r--r--@",
"2.5k",
"agiard",
"17 Jan 08:15",
"cliff.toml"},
{
".rw-r--r--@",
"5.5k",
"agiard",
"17 Jan 08:15",
"CODE_OF_CONDUCT.md"},
{
"drwxr-xr-x@",
"-",
"agiard",
"17 Jan 08:15",
"completions"},
{
".rw-r--r--@",
"8.1k",
"agiard",
"17 Jan 08:15",
"CONTRIBUTING.md"},
{
".rw-r--r--@",
"1.7k",
"agiard",
"17 Jan 08:15",
"deb.asc"},
{
".rw-r--r--@",
"12k",
"agiard",
"17 Jan 08:15",
"deny.toml"},
{
"drwxr-xr-x@",
"-",
"agiard",
"17 Jan 08:15",
"devtools"},
{
"drwxr-xr-x@",
"-",
"agiard",
"17 Jan 08:15",
"docs"},
{
".rw-r--r--@",
"8.1k",
"agiard",
"17 Jan 08:15",
"flake.lock"},
{
".rw-r--r--@",
"9.3k",
"agiard",
"17 Jan 08:15",
"flake.nix"},
{
".rw-r--r--@",
"6.2k",
"agiard",
"17 Jan 08:15",
"INSTALL.md"},
{
".rw-r--r--@",
"7.2k",
"agiard",
"17 Jan 08:15",
"Justfile"},
{
".rw-r--r--@",
"1.1k",
"agiard",
"17 Jan 08:15",
"LICENCE"},
{
"drwxr-xr-x@",
"-",
"agiard",
"17 Jan 08:15",
"man"},
{
".rw-r--r--@",
"2.7k",
"agiard",
"17 Jan 08:18",
"powertest.yaml"},
{
".rw-r--r--@",
"7.9k",
"agiard",
"17 Jan 08:18",
"README.md"},
{
".rw-r--r--@",
"146",
"agiard",
"17 Jan 08:15",
"rust-toolchain.toml"},
{
".rw-r--r--@",
"34",
"agiard",
"17 Jan 08:15",
"rustfmt.toml"},
{
".rw-r--r--@",
"505",
"agiard",
"17 Jan 08:15",
"SECURITY.md"},
{
"drwxr-xr-x@",
"-",
"agiard",
"17 Jan 08:15",
"snap"},
{
"drwxr-xr-x@",
"-",
"agiard",
"17 Jan 08:18",
"src"},
{
"drwxr-xr-x@",
"-",
"agiard",
"17 Jan 08:18",
"target"},
{
"drwxr-xr-x@",
"-",
"agiard",
"17 Jan 08:15",
"tests"},
{
".rw-r--r--@",
"586",
"agiard",
"17 Jan 08:15",
"treefmt.nix"}
]
}
Oh yeah, as of right now you need the --header option to have items labels
Does that output require any of the other flags?
what I mean is are we going to return all that data that would otherwise require the --long flag, without explicitly doing that? would --json by itself not just return the filenames like default eza would?
no i decided that eza --json
was eza --long
as json, and eza --json -1
is eza
as json. But this is debatable
I think it would make more sense for eza --json
to be eza
and eza --long --json
to be eza --long
. That's how the --tree
switch works, for comparison.
Okay I made some updates, tree is not working as I want it to be for the moment, and recurse can be better I think. Would it be a great idea for both to have the files nested in there dirs in the json ?
Okay I made some updates, tree is not working as I want it to be for the moment, and recurse can be better I think. Would it be a great idea for both to have the files nested in there dirs in the json ?
That would make sense to me, yeah.
Just a heads up, the json tree is taking me more time than anticipated, but will eventually come I think
Tree is growing, as per my last commit big complex trees are not working, but small ones are.
Hey just a heads up to everyone here
The recurse option is here :tada:
Can I have you all thought on it, and if you think --json --tree
is needed