[BUG] `--strip-cwd-prefix` does nothing

[rien333]

Sorry for not using the official bug template, it always returned error code 400 on my end, and acted pretty buggy in general.

Bug description

I use a variant of the following line to find pdf files and sort them by date:

fd --strip-cwd-prefix -e pdf -X ls -t

--strip-cwd-prefix should remove the leading ./ string from the output (as per https://github.com/sharkdp/fd/pull/861). However, this string is still present in the output of fd in my interactive shell session, as well as in my shell scripts.

Expected behavior

fd should always remove the leading ./ when I invoke it with --strip-cwd-prefix.

Version information

$ fd --version
fd 8.3.0
$ uname -srm
Linux 5.15.5-arch1-1 x86_64
$ lsb-release -a
-e LSB Version:	1.4
-e Distributor ID:	Arch
-e Description:	Arch Linux
-e Release:	rolling
-e Codename:	n/a

[sharkdp]

Sorry for not using the official bug template, it always returned error code 400 on my end, and acted pretty buggy in general.

@tmccombs I heard this from others as well. I'm afraid we might have to disable the new template for some time.

Expected behavior

fd should always remove the leading ./ when I invoke it with --strip-cwd-prefix.

--strip-cwd-prefix has no influence on x/-X. I realize now that this should have probably been documented better. Or maybe we should even mark the respective options as "conflicting" (in the command-line parser) to generate an error.

The option only has an influence on the normal (non-TTY) output of fd. But I'm happy to discuss this again.

In #861, the author initially implemented new placeholders that would have allowed you to call something like fd -e pdf -X ls -t {-} where {-} would have represented the prefix-stripped path. I thought that we don't need this feature. So I'm curious: what is your use case? Why do you want to get rid of the ./ prefix? For visual reasons only?

As a workaround, you can use

fd -0 -e pdf | xargs -0 ls -t

for now.

[rien333]

Thanks for the detailed reply, and your commitment to keeping fd user-friendly 😊

Why do you want to get rid of the ./ prefix? For visual reasons only?

Yes, you could say that. I rely on fd + dmenu to show me all pdfs/epubs in /home and subfolders (which there are quite a lot of) , and since I'm generally interested in the most recent ones, I sort them with -X. Not having ./ in front of every file reduces the visual clutter in what is already a lot of output.

I'm okay with using xargs or something like sed to avoid the visual clutter, as long as that doesn't impact performance (atm it's all quite snappy) .

EDIT

The following script still outputs the ./ prefix 😕

#/bin/sh
fd -0 -e pdf | xargs -0 ls -t | dmenu

I kinda use fd because I'm too stupid to remember how xargs works.

[tmccombs]

Sorry for not using the official bug template, it always returned error code 400 on my end, and acted pretty buggy in general.

@tmccombs I heard this from others as well. I'm afraid we might have to disable the new template for some time.

Interesting... I was able to reproduce, weirdly there isn't even any error message or response at all. This feels like a bug in github to me. I'm fine with reverting my change, or just adding the template in addition to the form.

[sharkdp]

The following script still outputs the ./ prefix confused

#/bin/sh
fd -0 -e pdf | xargs -0 ls -t | dmenu

Ah, sorry. My bad. Still needs the --strip-cwd-prefix option, of course. Also, to avoid https://github.com/sharkdp/fd/issues/760, we should add a -- argument to ls:

fd --strip-cwd-prefix -0 -e pdf | xargs -0 ls -t -- | dmenu 

[rien333]

fd --strip-cwd-prefix -0 -e pdf | xargs -0 ls -t

For some reason, this doesn't work as well as just using fd -X ls -t, in the sense that the xargs variant can return elements out of order (weird, huh?). Which elements are out of order and how they're exactly mis-ordered is inconsistent, perhaps a weird race condition or something?

fd -X ls -t | sd '^./' '' does the job though.

[tavianator]

What do you mean "out of order"? fd doesn't really output things in any particular order

[rien333]

fd doesn't really output things in any particular order

I understand that it doesn't, but it should do so when used in conjunction with -X ls -t.

My point is that it doesn't do so with the xargs workaround provided in https://github.com/sharkdp/fd/issues/898#issuecomment-981995940. That could just be because we're not supplying xargs with the right options (but then again, something like that would be a reason I would avoid using xargs in the first place)

[sharkdp]

fd output is sorted if the results come in very quickly. This is why it may look like the results are sorted when piping to xargs instead of using fd -X. But output order of fd should never be relied upon. If you want that, add a sort in between.

[tmccombs]

The -t option to ls should sort by time, newest first. Maybe xargs is splitting it into multiple calls to ls?

[sharkdp]

@rien333 Could you please summarize the current state of this?

[rien333]

Sorry for the slow answer.

Currently, --strip-cwd-prefix does nothing when used with -X (the original reason why I opened this). If you consider the man page to already cover this incompatibility sufficiently, then close this issue I guess.

You then proposed a workaround for my specific use case, i.e. fd -0 -e pdf | xargs -0 ls -t, which, in virtue of including ls -t should deliver the results in order. It doesn't though, for whatever reason. (in short: xargs is more annoying than plain fd). This problem is unrelated to this issue, ofc.

[Animeshz]

My usecase: dirdiff script (kind of like: set A - set B)

a=$(realpath $1)
b=$(realpath $2)

cd $a
fd -x sh -c "[ -e '$b/{}' ] || echo $1/{}" 2>/dev/null

it prints like:

>>> dirdiff fprintd pam-fprint-grosshack
fprintd/./scripts/uncrustify.cfg
fprintd/./scripts
fprintd/./doc
fprintd/./doc/meson.build
fprintd/./scripts/uncrustify.sh

Using a temporary workaround atm: fd -x sh -c "[ -e '$b/{}' ] || echo $1/\$(echo {} | sed 's/^\.\///')" 2>/dev/null

[sharkdp]

Okay. I see that this is a reasonable use case. I guess we have two options.

• Change -x/-X to also respect --strip-cwd-prefix. We would have to document that this can lead to security problems (https://github.com/sharkdp/fd/issues/760).
• Introduce new placeholders, as originally suggested in #861.

Maybe someone put in the work and write down upsides/downside of these two possibilities? Are there other proposals?

[tavianator]

I think the first option is good. We already have --strip-cwd-prefix, it might as well do what it says :). I'll do that on top of #1115

[sharkdp]

I think the first option is good. We already have --strip-cwd-prefix, it might as well do what it says :). I'll do that on top of #1115

Ok, let's go with this. I read your comment too late, so #1115 is already merged.

[tavianator]

Oh no worries, I meant as a separate PR anyway