Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: nushell table output mode #472

Open
giard-alexandre opened this issue Oct 3, 2023 · 19 comments
Open

feat: nushell table output mode #472

giard-alexandre opened this issue Oct 3, 2023 · 19 comments

Comments

@giard-alexandre
Copy link

giard-alexandre commented Oct 3, 2023

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.

@cafkafk
Copy link
Member

cafkafk commented Oct 3, 2023

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.

@MartinFillon
Copy link
Contributor

see #783

@MartinFillon MartinFillon self-assigned this Jan 16, 2024
@MartinFillon
Copy link
Contributor

@heuristicAL feel free to compile from source and do some feedback on the json options

@giard-alexandre
Copy link
Author

@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)
image

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.

@MartinFillon
Copy link
Contributor

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.

@PThorpe92
Copy link
Member

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 👍

@MartinFillon
Copy link
Contributor

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

@MartinFillon
Copy link
Contributor

Done if you wanna try it.

@giard-alexandre
Copy link
Author

@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"}
]
}

@MartinFillon
Copy link
Contributor

Oh yeah, as of right now you need the --header option to have items labels

@PThorpe92
Copy link
Member

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?

@MartinFillon
Copy link
Contributor

no i decided that eza --json was eza --long as json, and eza --json -1 is eza as json. But this is debatable

@eggbean
Copy link

eggbean commented Jan 19, 2024

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.

@MartinFillon
Copy link
Contributor

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 ?

@daviessm
Copy link
Contributor

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.

@MartinFillon
Copy link
Contributor

Just a heads up, the json tree is taking me more time than anticipated, but will eventually come I think

@MartinFillon
Copy link
Contributor

Tree is growing, as per my last commit big complex trees are not working, but small ones are.

@MartinFillon
Copy link
Contributor

Hey just a heads up to everyone here

The recurse option is here 🎉

Can I have you all thought on it, and if you think --json --tree is needed

@oabragh
Copy link

oabragh commented Dec 23, 2024

What's the status of this i really like the idea

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants