Possible to render $HOME as ~ in fd output?

[cohml]

❯ fd --version
fd 8.7.0

Say my $HOME is /Users/LongName/. If I run fd . ~, all results will have /Users/LongName/ prepended. Is it possible to have this prefix rendered as ~/?

Of course, I could do something like fd . ~ | sed 's/\/Users\/LongName/~'. But this would require fd to finish running before any substitution occurs, slowing things down massively. So I'm wondering if it is possible to have this substitution happen at the source.

If it matters, my use case is with fzf, where results start being loaded as soon as fd returns them. Hence why the slowdown of the sed approach just described would be untenable.

[tavianator]

Judging by /Users, I'm guessing you're on macOS? I think it supports -u to make the output unbuffered, which may help.

Ultimately I think the best solution for this is going to be #1043.

[cohml]

Incidentally, and on a completely different train of thought, I stumbled upon that issue yesterday. It sounds very exciting and may indeed resolve this.

But I was dismayed by how long it seemed to have languished. Hopefully the activity will pick up on that PR and it can get merged soon. Thanks!

[cohml]

So #1043 has finally been merged, and while it does seem incredibly useful as is, it actually doesn't seem to allow for $HOME -> ~ substitution requested in this issue.

@sharkdp @tmccombs - Might this kind of substitution be possible/worth adding as an additional template string into --format? Or perhaps arbitrary substring substitution more generally?

[tavianator]

@cohml you can now do this:

tavianator@graphene $ fd --base-directory ~ --format '~/{}'
~/code
~/code/sharkdp
~/code/sharkdp/fd
~/code/sharkdp/fd/README.md
~/code/sharkdp/fd/Cross.toml
~/code/sharkdp/fd/Cargo.toml
~/code/sharkdp/fd/Cargo.lock
~/code/sharkdp/fd/CHANGELOG.md
~/code/sharkdp/fd/scripts
~/code/sharkdp/fd/scripts/version-bump.sh
...

Something more general might be useful though, it's worth making a new feature request if you have use cases that aren't covered by the existing feature.

[cohml]

@tavianator That looks perfect!

But how are you getting those colors? For me, --format seems to disable colorization entirely, even with --color="always":

[tmccombs]

Yes, --format disables colors currently. Possibly support could be added. I'm not sure how difficult that would be. Or exactly how that would work (do we put color on the whole line, or just the path part of it?)

[tavianator]

@tavianator That looks perfect!

But how are you getting those colors? For me, --format seems to disable colorization entirely, even with --color="always":

Oh those colors are just GitHub syntax highlighting for ```console

[tavianator]

Yes, --format disables colors currently. Possibly support could be added. I'm not sure how difficult that would be. Or exactly how that would work (do we put color on the whole line, or just the path part of it?)

For bfs -printf I just color the paths

[cohml]

A more generally useful feature which would also address this issue might be to replace any arbitrary substring with another. For example, something like (in pseudocode)

substitutions = {
    $HOME: ~,
    $USER: me,
    /some/sensitive/path: [redacted],
    ...
}

fd could then, upon discovering a path, make any relevant substitutions before printing to stdout.

If implemented, something like ~/.config/fd/substitutions might be a nice place to enumerate one's substitutions (instead of or in addition to a dedicated option).

[tmccombs]

@cohml that could be accomplished by piping the output of fd through sed:

fd $options | sed -e 's/$HOME/~/; s/$USER/me/; s|/some/sensitive/path|[redacted]|;'

[cohml]

@tmccombs That is certainly possible, and would produce the correct output. But it would also negate what is IMHO fd's #1 strength: speed. From my OP:

Of course, I could do something like fd . ~ | sed 's/\/Users\/LongName/~'. But this would require fd to finish running before any substitution occurs, slowing things down massively.

To allow for substitutions while maintaining the speed, I think this feature would need to be implemented natively within fd.

[tmccombs]

But this would require fd to finish running before any substitution occurs, slowing things down massively.

that isn't entirely true. sed will process lines as it gets them. However, I think by default sed will buffer both reading and writing, so if it takes a while to get enough results, it will take longer before you get the first result. Passing --unbuffered to sed (at least in gnu sed, I'm not sure if that option exists in other versions) might help.