@Zanna Sorry, I didn't mean to push you toward doing it through my silence here. I was afk for a while. I'll read your answer shortly.

@EliahKagan oh no I didn't feel pushed into it. I appreciate the encouragement because I've become too scared to write answers there these days

@Zanna Why so?

I feel that I don't know anything that could possibly be of any use to those knowledgeable folks :)

in my first year or so on AU, I was sort of embarrassed by gaining reputation quickly, because I knew I could only answer the very easy questions and if I didn't write all the answers I was writing, someone else would write similar but better answers to the same questions

so, it would be better if I left writing answers to the smarter folks, I thought.

Well, I'm glad you wrote answers on Ask Ubuntu anyway! :)

@Zanna But only... recently?

well, at first I didn't realise how awesomely knowledgeable the U&L people are. Also, I used to visit more regularly, before the vegetarianism site went to beta... then that site became very quiet, but I am giving more attention to offline stuff. So if I was there more often, maybe I would occasionally see a question I wanted to answer in spite of myself :) But if I was less intimidated I might go there more often - I only go when reading the weekly email or when I want some info these days

@EliahKagan :) thanks! Now I think people writing answers should be more encouraged. Our site needs much more answers than it has!

I agree.

@Zanna I'm not sure why you'd said so, but I have no reason to think I would have written a better answer.

hmm your answers are always great :)

In particular, I was also unaware of -- and had not even thought at all about -- how, because -execdir is not specified by POSIX, different find implementations that choose to support it can assign it different semantics, and that not all implementations choose to precede the relative paths with ./.

(got yearling badge! 2 years on AU!)

:)

@EliahKagan yeah! I'm glad Kusalananda drew attention to that issue

With the aid of hindsight -- partly from the comments -- I do have a couple thoughts about how that answer might be improved/extended.

ah very good...

When I was looking to the thing about the preceding ./, it reminded me of the actually unrelated issue -- which is very minor in practice, I think -- that POSIX technically requires at least one path to be passed to find as a starting point. Most implementations assume . if you don't pass one, but this is not officially required.

This is virtually never a problem on Ask Ubuntu where readers are responsible for investigating differences if they are reusing the material on a system that, due to not being Ubuntu (nor most others GNU/Linux system, in this case), does not have GNU find. But on Unix & Linux I think it might be a good idea to put the . in explicitly, as the first argument to find (i.e., before any tests or actions).

ah, good point. I will do that

My other thought is that you should be able to offer a version with an alternate regular expression that causes it to behave identically regardless of whether or not the implementation's -execdir prepends ./ (and that also works with the recursive-globbing version and the -exec version). Specifically, you can match trailing non-slashes:

rename -n 's|[^/]+$|x_$&|'

This wouldn't work if the path being renamed itself had a trailing /, as directories are sometimes represented in other contexts. But I don't think any system's find command does that. POSIX says:

oh neat!

> The relative portion shall contain no dot or dot-dot components, no trailing <slash> characters, and only single <slash> characters between pathname components.

I was dozing off last night thinking "hmm there must be a way to match both of those patterns..." but I fell asleep (thankfully)

So it will take the path of a starting point you pass it to have a trailing / if you passed it one, but it won't add an unnecessary trailing / to anything it finds.

Also, in this case -type f is being used anyway (and the goal is to rename .c files which are rarely directories).

We have specified -type f, so we shouldn't get any directories (er having assumed OP didn't want to rename any directories, possibly incorrectly!)

oops sorry

Great minds think alike. :p

yes although I recreated OP's example to test, I then tested on my whole playground directory which is conveniently full of source files and therefore has loads of files that end with .c at various levels :)

Could you just keep what you have but add that as an alternative?

Aside from that, the only change I can think of is that you might want to put the -exec version first. In Kusalananda's answer, -execdir was important because the prefix was prepended directly to the match in {}.

Depending in part on the performance characteristics of rename, I suspect calling rename via -exec with + may be markedly faster than via -execdir with +, in cases where the files are distributed through many different directories. Even with +, -execdir has to run as many separate commands as there are distinct match-containing directories.

yes, good point. I even noticed that it was faster with -exec, so the difference was considerable on my system

@Zanna How many .c files, in how many different directories, did you have?

What am I going to do about the questionable use of the term "word splitting" in this answer?

@EliahKagan what's an elegant way to find out?

Assuming their names don't have any newlines...

$ for d in **/; do find "$d" -maxdepth 1 -type f -name "*.c" >> out/$(basename "$d"); done; ls -1 out | wc -l; cat out/* | wc -l
bash: out/$(basename "$d"): ambiguous redirect
bash: out/$(basename "$d"): ambiguous redirect
175
1113

@EliahKagan I'm not sure what "Fortunately, even though xterm -e in Ubuntu will perform word splitting on one argument to treat it as a command, it also accepts multiple arguments." means or is trying to mean...

$ for d in **/; do find "$d" -maxdepth 1 -type f -name "*.c" >> out/$(basename "$d"); done; ls -1qA out | wc -l; cat out/* | wc -l
176
1113

(dotglob was enabled)