-
-
Notifications
You must be signed in to change notification settings - Fork 241
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
Comments
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! 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. |
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 👍 |
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 |
I think it would make more sense for |
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 🎉 Can I have you all thought on it, and if you think |
What's the status of this i really like the idea |
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.The text was updated successfully, but these errors were encountered: