UNIX for Dummies Questions & Answers

You are right, this thread isn't about the standard and you indeed provided an interesting use case where quoting the curly braces has an effect.
It does because quotes are themselves quoted and thus propagated to the exec command.

This was interesting debate. The space is a powerful parser for all shells and has to be dealt with carefully.
This is why unix old-timers use _. Like in file_1 instead of "file 1". It saves you lots of aggravation in script writing.

"gch" has got the right idea. We evolve script which works well on as many platforms as possible. The quoting of "find ... -exec" "{}" or '{}' is not needed in many shells, but still works with the vast majority of modern shells.

The open poster has recognized being mistaken in its initial observations and has failed to provide more details about it so let me rephrase that not to confuse the readers, if you don't mind.
The quoting of "{}" and '{}' is needed in no know shell except with the obscure fish shell interpreter and with it for a reason that has nothing to do with embedded spaces.

jiliagre you cannot draw conclusions about all versions of unix based solely on your own experience. As stated in earlier posts I have seen this problem before which is why I gave the reply which fixed the problem. The quoting of "{}" in unix "find" is well documented though I didn't know that until I looked.

I do not use my experience here but only reasoning. These quotes can't work differently whether the file has embedded spaces or not. I explained it many times but you obviously fail to understand it.
There is no evidence your reply fix anything relating to spaces as the OP back-out. The quoting of "{}" is documented as being possibly required for those hypothetical shells that would interpret them to mean something special. This isn't the OP case who use either bash or dash on Ubuntu.

Hi jiliagre, point taken (at last!). The exact space character in the filename is your issue. We don't know exactly what triggered the fault, only that quoting the braces fixed it. We don't know that the character was a actually a space character.

I do understand the documented normal behaviour of current "find ... -exec" and the passing of one argument via '{}'.

I have had the issue myself in the past with exact space characters in mainstream unix and have now traced the version tree of "find ... -exec" for what it is worth. Due to a parallel issue with "-exec" ("too many forks") I mostly used a construct which avoided "-exec" for large numbers of files. The variant just composed the command line using "normal" shell substitution and then executed the command line in parallel. The current "-exec" does not behave like this.

I too can find no current mainstream unix or Linux with the same variant documented and for completeness I'd be quite interested in any shell construct which interfered with '{}' in this context.

Right fix, wrong reason!