Exa: Feature request: provide structured output

[dbohdan]

Parsing ls is an ages-old problem that exa could help solve by providing an option for producing structured key-value output. By "structured key-value output" I mean one or more of JSON (pretty much the default nowadays), YAML, XML (boo!), TOML (yay!) or Tcl dictionaries (sample).

[ogham]

Do you have a use case for why you'd want this sort of output? To write another front-end for exa, perhaps? Parsing ls _is_ annoying, but exa isn't guaranteed to be installed, so you couldn't use it for scripts. There might be something I'm missing here.

[dbohdan]

The overall use case I have in mind is to avoid the typical problems of handling files with odd filenames from the shell (is it find -print0 or find -0, again?) and other complex text parsing. The best way to accomplish this that I can think of is through making a suite of replacements for the standard POSIX tools that accepts and produces structured data in a common serialization format. Until something like that is reasonably complete the usefulness of this feature will be admittedly limited. The upside with structured data is you don't necessarily need to have find that is distinct from ls (except to terminate search early for performance reasons) and there already exists a replacement for sed and awk for JSON in jq.

Selecting groups of files from directory trees with jq is one thing that could be immediately useful. I have not tried it extensively but it looks like an interesting alternative to doing the same with find.

Frankly, I hadn't thought of the front end idea.

exa isn't guaranteed to be installed, so you couldn't use it for scripts

In many scenarios you could deploy exa with your scripts. Can it be statically linked?

[ogham]

is it find -print0 or find -0, again?

Ah yes, this case. I've been bitten by filenames with spaces in before, and _know_ about the 0 fix, but never actually remember how to do it.

I designed exa to be user-facing, hence the colours, styles, and alignment, rather than a tool designed to have its output piped somewhere else. The fields it produces are available through other tools - albeit it would be a lot trickier to write a script that uses these tools if you have to use more than one. Are you thinking about doing, for example, "Find me all files that are modified by Git, that have been created in the past month" by using exa's Git and Date columns then piping that to jq?

Can it be statically linked?

Potentially - I'm not sure what exa's installation story is going to be, but Rust does allow static linking.

[dbohdan]

Ah yes, this case. I've been bitten by filenames with spaces in before, and know about the 0 fix, but never actually remember how to do it.

Spaces are bad enough but it gets way worse with newlines, leading dashes and other characters, and more so if you want to avoid the GNU extensions.

Are you thinking about doing, for example, "Find me all files that are modified by Git, that have been created in the past month" by using exa's Git and Date columns then piping that to jq?

Pretty much.

[demurgos]

I designed exa to be user-facing, hence the colours, styles, and alignment, rather than a tool designed to have its output piped somewhere else.

It's an old issue but I agree with the sentiment that having a cross-platform way to get structured directory output would be great. Even if it wasn't the first goal of your project, I believe that adding it to your project makes more sense than using another tool just for this.

[notramo]

The serialized output should include also the colours of the entries.
This is useful e.g. when writing Elvish shell completions (using the &style option of edit:complex-candidate), and the completions should have the same colouring of filenames as when listed with exa, but it requires additional filtering, that the builtin filename completion can't do (e.g. only git untracked/tracked/new/etc. files, or character/block devices, or that are modified last week, etc.).